Graphics system for automatic computer code generation5187788Abstract The Avionics Program Expert (APEX) is an automatic code generation tool for the Ada programming language (MIL-STD 1815A). It provides the programmer using APEX with the ability to quickly create a graphical representation of his initial program design. The graphical representation used by APEX is akin to a flowchart, but the interactive capabilities of the tool make design creation much faster and more efficient. Once the programmer has created his complete (or even partial) representation of a program, Ada code can then be generated with (from) APEX. The APEX program representation provides the user with three different, yet consistent, views of his program. The first view allows the programmer to lay out his initial Ada package specifications; this view is called the APEX view. A second view allows the programmer to create and manipulate complex data structures and define local variables; this view is the Data Structure view. The last view allows the programmer to define the control flow of his specific subprogram; this view is called the REM-Net view. APEX has been implanted on two host platforms; these are a Symbolics 3600 Lisp Machine and a Sun 3/XXX Workstation. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
state1 = connection.from.sub.-- state
state2 = connection.to.sub.-- state
if (statel.1evel = state2.level)
connection.value = state2.order - state1.order
}
______________________________________
The connection with the highest value represents the outermost loop within which the state appears (since it includes states with the greatest range in order). Each incoming connection, in turn, is processed. Block 2020 is used to get the first connection in the sorted list. At block 2030, the header code for the loop is generated based on the type of loop being modeled by the connection. The type of loops available is discussed in part A of section IV (under transitions; NOTE: Transitions and Connections means the same thing). The procedure for the generation of the Ada code for the incoming connection is described in slide 10, block 2400. Upon the return from slide 10, there is a check at block 2140 as to whether there are any more incoming connections, and if so the operation goes to block 2150 to get the next connection in the list, and then go back to block 2130. Once the code for all incoming connections has been generated, the program goes from the decision block 2140 to block 2160, where the Ada code for the state itself is generated; this procedure being described in slide 8, block 2200. Next at block 2170, the Ada code is generated for all outgoing connections which occur for the state in question. This procedure is described in slide 9, block 2300. Once all code has been generated for a given state (including incoming and outgoing transitions), the next state in the list of states is processed. After block 2300, there is a decision block 2180 to check if there is a next state, and if so the program goes back to block 2110. After the last state is processed, the program returns via block 2190 to block 2101 in FIG. 19. h. Generate Ada Code--Slide 8 This routine shown in FIG. 22 is quite simple. From the start block 2200, it goes to block 2210, where it examines the attribute of the state passed to it in slide 7. Based on the type of Ada statement the state represents, the appropriate statement template is filled out and the Ada code is output. An APEX state can have the following types: 1. State: represents a subprogram (function, procedure) call or a code/comment block 2. Event: represents an accept statement 3. Slot: represents a rendezvous statement From block 2210, there are a series of decision blocks 2220, 2230, 2240, 2250, and if all decisions are no, then to the return block 2290. If a "yes" decision at block 2220 indicates a subprogram call (if a state type) the program goes to block 2222 to fill in a subprogram template. If a "yes" decision at block 2230 indicates a code block (if a state type) the program goes to block 2232 to fill in a code block template. If a "yes" decision at block 2240 indicates a rendezvous statement (if a slot type) the program goes to block 2242 to fill in a rendezvous template. If a "yes" decision at block 2250 indicates an accept statement (if an event type) the program goes to block 2252 to in fill the accept statement template. From any of the blocks 2222, 2232, 2242 or 2252, the operation goes to block 2260 to output the chosen template, and return via block 2290 to block 2200 in FIG. 21. i. Generate Ada Code--Slide 9 Slide 9 is shown in FIG. 23. Ada code for outgoing connections (or transitions) can include the following: 1. Trailer code for loops 2. Conditional connections (IF statements) First, a check is made for any conditional connections. If they are present, the header is generated for the condition being modeled. After the start block 2300, block 2310 is used to get the next conditional connection, block 2320 is used to fill in the IF statement template, and block 2330 is used to generate the Ada code for the template. Once the header for the condition statement is generated, the nesting level is incremented at block 2340, and slide 7 is called with the first state used in that nesting level. When all code has been generated for the new nesting level, control is returned to slide 9. At block 2305 a check is made for any more conditional connections, and if there are any the operation loops back to block 2310. After the last conditional connection is processed, the operation goes from block 2305 to block 2350. Now all connections within the current nesting level are processed. These are handled in much the same way that the incoming connections are handled in slide 7, except that the sorting at block 2350 occurs in the reverse order (lowest connection value is first, highest connection is last). After sorting, each outgoing connection is processed in its turn. At block 2360, there is a determination of the type of loop the connection represents. In this routine, at block 2370, the trailer code (instead of the header code) for each loop represented by the connection is generated. At block 2375 there is a check for any more outgoing connections, and if there are any block 2380 is used to get the next one, and loop back to block 2360. This routine returns from block 2375 to block 2390 when all outgoing connections have been processed. j. Generate Ada Code--Slide 10 The routine shown in FIG. 24 generates the header code for a given incoming connection. When a connection comes into a state, it represents a loop which begins at that point in the operation. Thus the state into which the connection comes is the first state in the loop. Since the loop includes the state, it is necessary to generate the header code of the loop before the code for the state itself is generated. Conversely, the code associated with outgoing connection must be generated after the code for the state is generated (see slide 9). So much for the theory. What this routine does is examine the type of incoming connection and generate the header code for the appropriate type of incoming connection. There are three (3) basic types of incoming connections: 1. For Loop 2. While Loop 3. Unconditional Ada code is only generated if the incoming connection represents either a For or While loop; no code is generated if the connection represents an unconditional transition between states. From the start block 2400, block 2410 is used to examine the connection attributes. Blocks 2420 and 2430 are decision blocks to check if the connection is a while loop or a for loop. If block 2420 determines that it is a while loop, block 2422 is used to fill in the while statement template, and if block 2430 determines that it is a for loop, block 2422 is used to fill in the for statement template, and from either block 2422 or block 2432, operation goes to clock 2450 to output the Ada code from the template. If the connection is neither a while loop or a for loop, operation goes from block 2430 to block 2440 for an unconditional connection, no code being generated. From block 2440 or 2450, there is a return via block 1490. FIG. 25 is a flow chart illustrating in more detail the blocks 1560, 1640, 1660, 1740, 1760, 1850, 1870, 1940, 2100, 2130, 2160, 2170, 2330 and 2370 of FIGS. 15-23 to generate Ada code. Block 2510 shows filing in templates for generation of the selected code, and in block 2520 the print function is called to output a line of code using the templates. In like manner the blocks 2260 and 2450 in FIGS. 22 and 24 respectively show the output of the chosen template using the print function. An example of calling the print function, is the following line in the C language from the file Apexada.c, which is used as part of the code to generate the with clause for all incoming transitions.
______________________________________
printf("%spackage %s is n",
&bline[NOB-gindent],package.fwdarw.name);
______________________________________
The symbol %s indicates where a template string is inserted in the string between quotes. The addresses for the template strings follow the closing quote. k. Templates To further clarify the use of templates, note that the global declarations in the file Apexdef.c defines several data structures in which the reserved word "struct" of the C language is followed by a tag name preceeding a list of structure members. This provides a template for the structure without actually reserving provides a template for the structure without actually reserving any storage locations. (See Bronson and Manconi, "A First Book of C, Fundamentals of C Programming" 2nd edition, page 332, West Publishing Co. 1991.) (In some other languages such as PASCAL the structure is called a record, which may be defined as a type without reserving any storage locations, and the members of a record are called fields.) Actual storage for members of a structure is reserved when specific variable names are assigned by a statement starting with the word "struct" followed by the tag name for the type, and then a specific variable name for one structure. The structure may then be populated by assigning values to its members. In the file Apexdef.c, a data structure "pck" describes a package defined in the APEX EDITOR, a data structure "op" describes an APEX operation (used in all editors), a data structure "ds" describes an APEX data structure, a data structure "conn" describes the transitions in the APEX editors, a data structure "pnconn" describes the transitions in the REM-net editor, a data structure "pstate" described a state in the REM-net editor, a data structure "pslot" describes a slot in the REM-net editor, and a data structure "pevent" describes an event in the REM-net editor. In the file Apexada.c, the above data structures are used to assign actual variables of these structure types, and members are assigned actual values by the process of generating Ada code as shown in FIGS. 15-25. The values of the members are then used when executing the print function to output statements in Ada code. III. APEX Editor A. Explanation of Methodology Although prior graphical Ada software design tools and methodologies provide methods of defining the top level declarations for an Ada program, there are some problems associated with the current generation of tools; which include: Little support for subprogram specification. No consistency between different views of the program. Methodologies are too complex. Too much extraneous information is required. The APEX system was constructed as a platform for prototyping approaches to overcome these deficiencies. The APEX system consists of a top level editor (APEX Editor) and two peripheral editors (Data Structure, and REM-Net editors). These editors, when used together, provide the programmer with three different, yet consistent, views of his program. Each view is optimized for its specific purpose. This section will focus on the APEX editor itself. The APEX editor permits the user to represent the program's top level package structure, packages contain data structures and the operations (functions, procedures, and tasks) on those data structures. Once created, packages can be connected via transitions. These transitions between packages are the graphical equivalent of Ada with/use statements. A screen dump of a sample APEX editor view is shown in FIG. 5. Once created, a package can be selected (a square by the package name indicates that it has been selected). When selected, the data structures and operations associated with that package will appear in the data structure window 502 (lower right) and operations window 504 (upper right) of the editor, respectively. Additional data structures and operations can be defined using a menu once a package has been selected. Once defined, that item will appear in the appropriate window. When the package is closed, both the object and operations windows will clear. The operation descriptions in the APEX methodology is limited to tasks, procedures, and functions. The parameters of these can be specified in the pop up menu (50 in FIG. 1) during definition. Once the data types and operations have been defined, they (in turn) can be selected. To select either an operation or data structure, the user should click the left mouse button when the mouse cursor is directly over the item name in the appropriate window. At this point, a box will be drawn around the item to indicate that it has been selected. Once an item has been selected, it can be edited (click left) or released (click center) B. Modes of Operation There are multiple commands listed in the APEX command window (511-515 in FIG. 5). These are described below: Load System: Command 511 will cause the file specified (on the pop up menu) to be loaded from the file into APEX. There are three types of APEX files which can be read into the editor. The first is a full system, which is a previously saved APEX representation consisting of one or more packages. Loading a full system will cause APEX to reset itself, thereby erasing whatever existed before. The user can also choose to read in an APEX representation containing a single package. When a single package is loaded, an existing package will be added without destroying the existing APEX representation. When loading a single package, the user can position the package on the screen in the same manner as if he were creating it for the first time. The single package option is useful for building a new program from previously specified APEX representations. The load system option can also be used to load in an Ada package specification from a text file. This feature can only be invoked under special conditions. The first condition is that no other APEX system be loaded when the text file is read in. Second, only one package may be present in the text file loaded. Third, after the text file has been translated to a graphical representation, it must be saved before being loaded again. Once it has been saved, it may be loaded into an existing APEX representation as a single package. This option enables the programmer to reverse engineer an APEX representation from existing Ada code. Section VI of this specification will describe the reverse engineering of code to graphics in more detail. Save System: Command 512 will cause the current system to be saved to the file specified on the pop up menu. Generate Ada: Command 513 will cause Ada source code for the current APEX system representation to be generated. All generated code will be sent to the console screen unless the output has been previously redirected to a file. Generate Documents: Command 514 will generate documentation on the project which is currently loaded. The two documents which are currently produced are a subprogram cross reference (<name>-xref.dox) and a data dictionary describing the function of the program structures (<name>-def.doc). Exit APEX: Command 515 allows the user to exit the APEX system. C. Icon Operation There are several operations associated with the top level icons (such icon 522 in FIG. 5, which represent packages) in the APEX editor; these are described below. 1. Create: Icons can be created if no other icons are currently selected An icon is selected when the square by its name is drawn. To create an icon click the right button on the mouse. A square frame will then appear. Position the square frame at the desired location and click left to permanently position it. At this point, the package menu (50 in FIG. 9) should appear. This menu is used to specify the package name. The creation process can be aborted by selecting the delete option 55 on the Status line of the menu. After the menu has been completed, exit the menu by clicking the mouse with the cursor over the quit option 56. 2. Edit: In order to edit an existing icon, it must be selected. An icon can be selected if the mouse cursor is over it and the square by the name of the package is drawn. At this point, click left to select the icon. Once selected, the user can click left again to bring up a pop up menu with the icon attributes. Editing the menu can change the desired attributes. In order to delete the icon, choose the Delete option on the Status line. 3. Transition: A transition between icons can be easily created. This corresponds to a with/use statement in Ada. In order to make a transition, the initial icon must be selected. Once selected, the user must click the middle mouse button while over the initial icon. The user can then move the mouse cursor until it is over the desired icon and the square of that icon is drawn. At this point the user can click any button to make the transition. The transition skew can be changed by moving the mouse. In order to freeze the desired skew, press any mouse button. The first package is now withed to the second package. Existing transitions can be deleted by following the same procedure used to create them (similar to a toggle switch). 4. Component Creation: Once an icon is selected, clicking right will bring up an options menu. This menu will include options to perform the following operations: a. Create Operation b. Create Data Structure c. Invoke Data Structure Editor d. Exit Package A package component (operation 502 in FIG. 5 or data structure 504) can be created by making the corresponding choice. Choosing either Create Operation or Create Data Structure will cause the appropriate pop-up menu to appear; these can be used to instantiate the new program components. Once created, the components will appear in either the Program Object or Program Operation window (whichever is applicable). When an operation is created, the menu components can be used to instantiate a package specification with pop up menu items in the following manner:
______________________________________
Operation Name
-- function {Name} (x: in float) return
boolean;
-- procedure {Name};
-- task {Name} . . . ;
Operation Type
-- Select Procedure, Function, or Task.
Parameters -- procedure Test ( {parameters} );
Return Type -- function Test return {return type};
Scope -- Select Global or Local.
-- Global: in package spec.
-- Local: in package body.
______________________________________
When a data structure is created, the menu components can be used to instantiate a package specification with pop up menu items in the following manner:
______________________________________
Data Structure Name
-- type {Name} . . . ;
Data Structure Type
-- Select Integer, Float, Boolean,
Array, Enumeration, Access, Record.
Qualifier -- use as follows:
type {Name} is array {Range} of
{Qualifier};
type {Name} is access {Qualifier};
type {Name} is ( {Qualifier} ):
Range -- Use as follows:
-- {Range} .fwdarw. {Lower Range . . . Upper
Range}
-- subtype {Name} is Integer {Range};
-- subtype {Name} is {Qualifier}
{Range};
______________________________________
An existing operation or object can be selected by moving the mouse cursor over the desired object and clicking on the left button. A component can be released by pressing the middle mouse button over the appropriate window. 5. Component Editing: Once a component (either an operation or data structure) has been selected, it can be edited by moving the cursor over the appropriate window and clicking on the left mouse button. The menu describing the attributes of that particular component will then appear. The attributes can then be changed as desired. To delete a particular component, select the delete option under the Status section and exit the menu. 6. Invoke REM-Net Editor: (See FIG. 6) Once an operation has been selected, the user can then click the right mouse button over the Program Operation window to enter the REM-Net editor. The REM-Net editor frame should then appear. All editors (APEX, REM-Net and Data Structure) can be viewed and edited at the same time. 7. Invoke Data Structure Editor: (See FIG. 7) Once a package has been selected, the Data Structure editor can be invoked by making the appropriate choice on the options menu for the selected package. Picking the Data Structure Editor choice will cause the Data Structure editor frame to appear. All editors can be viewed at the same time. 8. Leave Selected package: To leave a selected package, bring up the options menu and choose the Exit package option. IV. REM-Net Editor (FIG. 6) A. Explanation of Methodology One of the main drawbacks of many popular graphical design methodologies is that they are so high level that many important features of the language they support are not represented. This is extremely frustrating for the serious programmer. For example, if there is no convenient way to specify rendevous at the subprogram body level, then a programmer's ability to properly design an Ada application has substantially diminished. The REM-Net editor provides support for a large number of important Ada language constructs; in many cases there is a direct mapping between the graphical icons and the language constructs themselves. The REM-Net editor 600 makes use of four main icons on the command window 611-616 in its design scheme; which are described below. States: States represent an action or sequence of actions in the normal program control flow. In Ada this can take a variety of forms. Specifically, a state can represent the following types a procedure call a function call a code block a raise exception statement a rendevous statement When a state is created, the user can select the appropriate options from a pop-up menu; it is by editing this menu that the user can alter the functionality of a given state. One of the options that can be selected on this menu is the state type. Other attributes of the state (such as name, parameters and return parameter) can also be specified at this time. When code generation takes place, the Ada source corresponding to the information within the icon will be produced. In the case of a procedure or function call, the appropriate call will be generated. In the case of a code block, a place holder (in the form of a comment block) will be generated. The comment block can be filled in later with a text editor. In this respect, the REM-Net editor can be used to generate PDL (program Design Language) since the entire subprogram body need not be specified at the time of code generation; important details of the design can be deferred until a later stage of development, if desired. This can be an especially important feature when designing reusable subprogram modules. Events: Events represent Ada select or accept statements. Events can have a delay associated with them. This information can be added during event creation with the pop-up menu. Slots: Slots represent paths of communication between tasks. A slot which transitions to an event (select Statement) is considered an entry in Ada. A slot which received a transition from a rendevous state is considered a rendevous call to another task. A slot can have either incoming or outgoing transitions (not both). Transitions: Transitions describe the conditions whereby control will be passed to another state. Transitions between states can represent while statements, for/in statements, loops, or unconditional flow of control. If the transition is a loop, it must originate at the end of the proposed loop and transition to the loop's beginning. Each state must have at least one unconditional transition originating from itself if any more code is to be generated for a given code sequence. B. Modes of Operation There are four basic modes of operation for the REM-Net editor (described below). Each mode can be entered by clicking on the button with the same name in the REM-Net command pane 611-616. State Mode: (command 611) In this mode, the programmer can create and edit states (such as state 623). In addition, transitions between states and all other icons can be specified. This is the default mode. The initial state is chosen in this mode as well. Event Mode: (command 612) In this mode, the programmer can create and edit events (such as event 621). Events represent Ada select or accept statements (depending on the number of slot transitions to a particular event). Transitions emanating from events can only go to a state. Events can receive transitions from either slots (if they represent incomming rendevous or states). Transitions between events and states should only be designated as unconditional. Slot Mode: (command 613) In this mode, the programmer can create and edit slots (such as slot 622). Slots represent different "ends" of a rendevous. The rendevous is started by creating a slot in the task which accepts the rendevous call; this slot represents an entry into the task. Once a slot is created in the accepting task, other subprograms can then rendevous with that slot. The rendevous is completed by creating a copy of a slot (in the subprogram which will make the rendevous call) that exists in the accepting task (this is done using the Connect Mode). Any slot (once created) can be edited in the Slot Mode. Connect Mode: (command 614) In this mode, the programmer can create rendevous calls to existing entries defined in other tasks. This is equivalent to making a call to an entry in an existing task. The entry must be established in the task before the programmer can make a call to it. In addition, the Connect Mode can also be used to draw entries which have been defined as a result of reading in a package specification. In this case, the entries will exist, but no slot will have yet been created to represent them in the task's REM-Net diagram. C. Icon Operations States: (623) 1. Create: Enter State Mode (default Mode). A state may be created by moving the mouse cursor to the desired position in the window and clicking the right mouse button. At this point a pop-up menu should appear; the user can then fill in the attributes of the state and quit the menu when done. The image of the state should now appear on the screen. A state which represents a specific function or procedure call can also be created. This is accomplished by picking the desired subprogram from the Visible Subprograms window (move mouse directly over the listed item and click the left mouse button; a box will appear around the chosen subprogram). The state can then be created using normal procedures. When the state's pop-up menu appears, the attributes will be filled in to reflect those of a call to the chosen subprogram. 2. Edit: Place mouse cursor inside the desired state. A box should be drawn around the state. At this point, click the left mouse button. A menu describing the state should appear, make the desired changes, then exit. 3. Delete: Perform an Edit State operation. At this point, choose the Delete option under the Status keyword. Exit the menu. The state and all associated transitions should now be deleted. 4. Transition (624): Place the mouse cursor inside the desired transition start state. A box should be drawn around the state. At this point, click the middle button. The start state for the transition is now selected. Move the cursor to the next desired icon. The icon will become highlighted when the mouse cursor is inside it. At this point press the middle mouse button to complete the transition. The connection line 624 should now appear. The user can change its skew as desired by moving the mouse cursor; click any mouse button to freeze the skew in place. A menu which describes the transition attributes will appear after the transition skew has been determined. The user should fill in the menu attributes and exit the menu. The transition is now complete. Transitions between states and slots should only be done when the transition type is a rendevous and the rendevous emulates from the current subprogram. 5. Initial State Once the REM-Net diagram has been completed, it is important to select an initial state. Without selecting an initial state, the Ada code for that particular subprogram will not be generated properly; for this reason, it is important for the programmer to remember to do this. In order to select an initial state, place the mouse cursor over the desired state. After the state becomes highlighted, click the right mouse button once; the initial state for the subprogram has now been selected. If the right mouse button is not over a highlighted state when pressed, then a new state will be created instead. Events: (621) 1. Create: Enter State Mode. To create an event, move the mouse cursor to the desired position and click on the right mouse button. The pop-up menu will appear for the event attributes. There is only one important attribute for events (the delay specification). After the menu has been exited the event should be complete. 2. Edit: place the mouse cursor inside the desired event. The event should highlight. At this point, click left the on the mouse buttons. A pop-up menu describing the event should appear. Edit as desired. 3. Delete: Follow the edit event procedure. Choose the delete option on the Status line and exit the menu. The event and all associated transitions should be deleted. 4. Transition (624): Move the mouse cursor inside an existing event. The event should highlight. Click the middle button on the mouse to start the transition. The event must transition to a state. Move the mouse cursor inside the desired state and click the middle mouse button to complete the transition. Click any button to freeze the transition skew. When the transition menu appears, exit the menu without modification. Transitions between events and states should be unconditional by default. Slots: (622) 1. Create: A slot must initially be created in the REM-Net diagram of the task that accepts the rendevous. After the initial slot has been created, subprograms can specify a rendevous to the existing entry using the Connect Mode. To create a slot which represents an entry, the present REM-Net diagram must be that of a task and the Slot Mode should be selected. Once this has been done, the user can move the mouse cursor to the position where the slot is desired and press the right mouse button to create the slot. The slot menu should them appear. The user should fill in the name and parameter declaration for the slot. The quit button is used to exit the menu. The Connect Mode can be used to create a slot in two distinct cases. The first case occurs when the programmer wishes to represent a call to an existing entry. The user should move the mouse cursor to the Visible Subprogram window and select the task with which a rendevous is desired. Once selected, the user should press the right mouse button to get a list of entries declared for the chosen task. When the desired entry is selected, the user should move the mouse cursor to the main window and create the slot by pressing the right mouse button when the mouse cursor is in the desired position. The second case occurs when the programmer has read in the Ada code for a package specification. When the package specification contains a task with entries, it is necessary to position the slot icons which correspond to the entries within the task's REM-Net diagram. This is accomplished in the Connect Mode in the same manner as that outlined in the previous paragraph. 2. Edit: To edit an existing slot, move the mouse cursor inside the existing slot. At this point a square should be drawn in front of the slot name. Now press the left mouse button to bring up the slot attribute of the slot name. Now press the left mouse button to bring up the slot attribute menu. Edit the slot attributes as desired. If a slot attribute (such as slot name or parameters) is changed for the original entry, that change should propagate to its related slots in the sending or receiving subprograms. If the slot being edited does not represent the original entry, then none of the attributes will be changed as a result of the edit. The programmer cannot change the name of the receiving task when editing a given slot. 3. Delete: To delete a slot, perform the same procedure as described for editing a slot. When the slot attribute menu appears, choose the Delete option under the Status section of the menu. Exit the menu. The slot and all corresponding connections should now disappear. If the original entry is deleted, any related slots in other subprograms should disappear as well. In this manner, consistency between different subprogram diagrams is maintained. The deletion of a slot has the effect of cancelling a rendevous between a subprogram and a task. 4. Transition (624): Move the mouse cursor inside an existing slot. The slot should highlight. Click the middle button on the mouse to start the transition. The only transition possible is from a slot to an event. Place the cursor inside the desired event (which should highlight) and click any button to complete the transition. Fill in the pop up menu to instantiate the transition (only the guard attribute is important). This transition will represent the actions performed in the accept statement block which corresponds to that particular entry (slot). Transitions coming in to slots may only be from states which are of type rendevous. A safeguard is incorporated into the software to prevent "stupid mistakes" for slot transitions. For example, the system will ignore a user's attempt to connect an outgoing rendevous slot (to another task) to an event within the present task. V. Data Structure Editor (FIG. 7) A. Explanation of Methodology A screen dump of the DS editor is shown in FIG. 7. The data Structure editor 700 provides the means of manipulating those data structures created using the APEX editor. The following examples illustrate how the menu choices are used in defining some sample data structures.
______________________________________
Data Structure Name
-- type (Name) . . . ;
Data Structure Type
-- Choose between (Integer, Float,
Array, Enumeration, Access,
Record);
type {Name} is {Type} . . . ;
Qualifier -- Use as Follows:
type {Name} is array {Range} of
{Qualifier};
type {Name} is {Qualifier};
Range -- Use as Follows:
{Range} .fwdarw. {Lower Range . . . Upper.sub.--
Range};
subtype {Name} is Integer {Range};
subtype {Name} is {Qualifier}
{Range};
______________________________________
Once the data types have been created, the programmer can then edit them using the DS editor. The DS editor 700 has six windows; the function of and location of each window is described below: Visible Data Structure pane 701 (far left): Provides a list of data structures which are visible to the currently selected package. Record Field pane 702 (middle left): Provides a list of fields within the currently selected data structure (if the data structure is a record type). Package Subprogram pane 703 (middle right): List of subprograms in the selected package (middle right). Variable pane 704 (far right): List of variables which are in the selected subprogram or the currently selected package. Documentation window 705 (bottom): Provides a mechanism to document existing subprograms, data structures or variables. Using these windows the user can perform the following operations: 1. Select a visible data structure. 2. Edit the selected data structure. 3. Create/Display/Edit all the local variables inside a visible subprogram which are instances of a selected data structure. 4. Create/Display/Edit all the fields within a given record. 5. Create/Display/Edit documentation for all program structures. B. Modes of Operation The mode of operation in the DS editor 700 is heavily dependent on which pane (701-705) the mouse is in at any given time. For example, variables can only be manipulated (created, edited, or deleted) in the Variable pane. The operations which can be carried out on the icons are related to the panes in the following manner: Variable Data Structure pane: Data structure operations {edit or delete data structures}. Record Field pane: Record field operations {create, edit or delete data structures}. Package Subprogram pane: Operations on subprograms which are within the selected package {edit or delete subprograms}. Variable pane: Operations on variables which are either inside the package or inside a particular subprogram {create, edit or delete variables}. Documentation pane: Allows the user to enter/edit text to describe program structures. Command pane: The Data Structure editor can be closed by pressing the Quit button in the command pane using the mouse. C. Icon Operations Data Structures: 1. Edit: To edit a data structure, move the mouse cursor over the Data Structure pane. Select the desired data structure by placing the mouse cursor directly over it and click the left mouse button. A box should then be drawn around the data structure. To release a selected data structure, click the middle mouse button; the box around the data structure should now disappear. Once a data structure has been selected, click right on the mouse. A menu frame with the data structure attributes should now appear. The attributes can be modified as desired. Use the Quit button to exit the menu frame. 3. Delete: In order to delete a record field entry, the user must follow the same procedure as to edit an entry. Once inside the edit frame, the user must select the Delete option on the Status portion of the menu. After the user quits the menu, the record field will be deleted from the selected data structure. Subprograms: 1. Edit: A subprogram can be edited or deleted in the Data Structure editor. In order to edit the subprogram, it must be selected (the method of selection is similar to that used in the other panes). Once selected, the user must press the right mouse button to edit the subprogram. The menu frame for the chosen subprogram will appear at this point. When finished, the user can press the Quit button in order to exit the menu frame. 2. Delete: A subprogram can be deleted by choosing the Delete option under the Status section in the menu frame. After the menu is exited by the user, the chosen subprogram will be deleted. Variables: Operations can be performed on variables either at the package or subprogram level. When no subprograms are selected, the variable list reflects package variables. When a subprogram is selected, the Variable pane 704 contains variables local to the chosen subprogram. 1. Create: To create a variable, a type for the variable (taken from the Data Structure pane) must first be selected. Once this is done, the user must move the mouse into the variable pane and click right to instantiate that data type. The menu frame for the new variable will then appear. The user can only edit the name of the variable; the type is fixed. If the user desires to change the type of the variable, the present entry must be deleted and a new one created. To exit the menu frame, the user must press the Quit button using the mouse. The Variable pane should update to reflect the new entry. 2. Edit: In order to edit a given variable, the subprogram that the variable is inside must be selected. If the variable is in the current package itself, then no subprograms can be selected. Once the appropriate variable list appears in the Variable pane 704, the desired variable can be chosen (left click of the mouse over the entry) and edited (followed by a right click). Again, only the variable name can be edited. The menu can be exited by using the Quit button. 3. Delete: the entry can be deleted by choosing the Delete option under the Status section of the variable menu frame. After the menu frame is exited, the Variable pane should update to reflect the deletion. D. Documentation While in the Data Structure editor 700, documentation can be produced for the following program structures: Subprograms Data Structures Variables (global and local) Record Fields 1. Create Documentation: After a program structure has been created, edit it by bringing up the menu which describes its attributes. After this has been done, use the mouse to press the Display Documentation button on the command pane. If no documentation exists, then the documentation window should remain blank, but the cursor should activate. Type in the desired comments. When finished, save the comments by depressing the Save Documentation button on the command pane. Be sure to leave the attribute menu up while creating the documentation. 2. Edit Documentation: Select and edit the attributes of a program structure. After the attribute menu has appeared, depress the Display Documentation button on the command pane. Any existing documentation for that program structure should then appear in the documentation pane. The user can then edit the text as required. The documentation can be saved by depressing the Save Documentation button on the command pane. VI. Reverse Engineering Capability A. Explanation of Methodology APEX provides the programmer with the ability to create the graphical representation of his code from an existing Ada package specification. Although this capability is still somewhat limited, it does provide a way of reusing Ada source code which is already in existence. An Ada package specification is the code which describes the portion of a package which can be referenced by a separate program unit. By reverse engineering a package specification for existing software, the application being developed with APEX can make full use of routines and data structures within that package without the programmer having to manually specify the existing code. Since the reverse engineering process is automated, the programmer has a minimal amount of overhead involved with reusing existing software to develop a new application with APEX. B. prerequisites for Use The following prerequisites must be satisfied in order to reverse engineer an Ada package specification: 1. The package specification must have been compiled without error by a validated Ada compiler. 2. There must only be one package specification per file read in. This means only one specification can be read in at a time. There should be nothing else in the file but the package specification. 3. After the package specification has been read in, it must be saved by APEX before it can be reused with another APEX representation. It can be subsequently read in as a single package or a full system. 4. The Ada features which are presently supported for reverse engineering are currently as follows: package declarations; task declarations; function declarations; procedure declarations; entry declarations; variable declarations; enumeration type declarations; array type declarations; record type declarations; access type declarations; integer subtype declarations (reference Ada LRM sections); enumeration subtype declarations; 5. Those Ada features which are presently supported are as follows: variant record declarations; constants; fixed point declarations; floating point declarations (reference Ada LRM sections); derived type declarations (except for enumeration types); initialization of variables/components; string type declarations; unconstrained array declarations; C. Mode of Operation Load System: The Load System option (on the APEX editor command pane) can be used to load in the Ada package specification. After the specification has been read in, a package frame will appear. To position the frame, click the left mouse button. The programmer can then select the package in order to inspect its contents. A sample file (tproc.ada) is included to illustrate the reverse engineering capability. Save System: After the package specification has been loaded, it can be saved using APEX. This is necessary for reusing it with an existing APEX representation. Connect Mode: If the package specification which has been read in contains a task with entries, then the user must create slots which correspond to those entries in the appropriate task. The procedure for doing this is outlined in Section IV. VII. Sample File A sample APEX system file (turnstile) is supplied with the tape. This can be loaded into the APEX system by using the System Load option in the APEX command pane. The user can then learn about the system by experimenting with this sample program. The graphical views produced from this file are shown in the drawings, FIGS. 5, 6, 7 and 8. This should be a useful tool in understanding the methodology presented in sections III, IV and V. The sample file follows:
______________________________________
package Display is
type Deposit.sub.-- Display is
RECORD
dollars: LCD.sub.-- Digit;
tens: LCD.sub.-- Digit;
units: LCD.sub.-- Digit;
end RECORD;
type LCD.sub.-- Digit is ARRAY (0 . . . 7) of boolean;
procedure Update.sub.-- Display (total: in integer);
procedure Reset.sub.-- Display;
procedure Error.sub.-- Message;
function Timer (Milsec: in integer) return boolean;
Out.sub.-- of.sub.-- Order: boolean;
Bell: boolean;
end Display;
package body Display is
procedure Update.sub.-- Display (total: in integer) is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Update.sub.-- Display;
procedure Reset Display is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Reset.sub.-- Display;
procedure Error.sub.-- Message is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Error.sub.-- Message;
function Timer (Milsec: in integer) return boolean;
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
While count > 0
Loop
--
-- Code Block Delay.sub.-- lms
--
--
-- Code Block Decrement.sub.-- Count
--
end Loop:
--
-- Code Block return true
--
end Timer:
end Display;
package Sensors is
type Byte is ARRAY (0 . . . 7) of boolean;
type Coin.sub.-- Type is (nickel,dime,quarter,slug);
type Position.sub.-- Type is (one,two,three,four);
type Throat.sub.-- Status is (open,closed);
type Gate.sub.-- Desc is
RECORD
Position: Position.sub.-- Type;
Open: boolean;
end Record;
function Gate.sub.-- Position return Position.sub.-- Type;
procedure Lock.sub.-- Gate;
procedure Open.sub.-- Gate;
function Get.sub.-- Coin.sub.-- Type return Coin.sub.-- Type;
Gate: Gate.sub.-- Desc;
end Sensors;
package body Sensors is
function Gate.sub.-- Position return Position.sub.-- Type is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Gate.sub.-- position;
procedure Lock.sub.-- Gate is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Lock.sub.-- Gate;
procedure Open.sub.-- Gate is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Open.sub.-- Gate;
function Get.sub.-- Coin.sub.-- Type return Coin.sub.-- Type is
--
Put Local Declarations Here
--
Coin.sub.-- Size.sub.-- Sensor: Byte;
coin: Coin.sub.-- Type;
begin
--
-- Put Subprogram Body Here
--
--
-- Code Block Read.sub.-- Size.sub.-- Sensor
-- if (coin.sub.-- size.sub.-- sensor(7) = true) then
--
-- Code Block coin = quarter
--
-- elseif (coin.sub.-- size.sub.-- sensor(5) = true) then
--
-- Code Block coin = nickel
-- elseif (coin.sub.-- size.sub.-- sensor(5) = true) then
--
-- Code Block coin = nickel
-- elseif (coin.sub.-- size.sub.-- sensor(3) = true) then
--
-- Code Block coin = dime
-- else
--
-- Code Block coin = other
end if
--
-- Code Block return type
--
end Get.sub.-- Coin.sub.-- Type;
end Sensors;
with Sensors; use Sensors;
with Display; use Display;
package Controller is
type SelfTest.sub.-- Status is (normal, throat.sub.-- jammed, gate.sub.--
stuck,
other);
type Time is
RECORD
Hours: integer;
Minutes: integer;
Seconds: integer;
end RECORD;
function Selftest return SelfTest.sub.-- Status;
function Check.sub.-- for.sub.-- Coin return boolean;
procedure Initialize;
procedure Process.sub.-- Coin;
task Monitor is
entry Begin.sub.-- Operation;
end Monitor;
procedure Coin.sub.-- Jam.sub.-- Handler;
procedure Gate.sub.-- Stuck.sub.-- Handler;
procedure Shut.sub.-- Down;
task Clock is
entry Freq.sub.-- 60 Hz;
end Clock;
fare.sub.-- paid: integer;
end Controller;
package body Controller is
function Selftest return SelfTest.sub.-- Status is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end SelfTest;
function Check.sub.-- for.sub.-- Coin return boolean is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Check for.sub.-- Coin;
procedure Initialize is
--
Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
Reset.sub.-- Display;
Lock.sub.-- Gate;
--
-- Code Block.sub.-- Open.sub.-- Coin.sub.-- Throat
Monitor.begin.sub.-- Operation;
end Initialize;
procedure Process.sub.-- Coin is
--
-- Put Local Declarations Here
--
coin: Coin.sub.-- Type;
coin.sub.-- value: integer;
begin
--
-- Put Subprogram Body Here
--
coin := Get.sub.-- Coin.sub.-- Type;
if (coin = nickel) then
--
-- Code Block value = 5
--
elseif (coin = dime) then
--
-- Code Block value = 10
--
elseif (coin = quarter) then
--
-- Code Block value = 25
--
else
--
-- Code Block value = 0
--
end if;
Update.sub.-- Display (coin.sub.-- value);
end Process.sub.-- Coin;
task body Monitor is
--
-- Put Local Declarations Here
--
Next.sub.-- Position: Position.sub.-- Type;
status: SelfTest.sub.-- Status;
coin.sub.-- present: gboolean;
Position: Position.sub.-- Type;
begin
--
-- Put Subprogram Body here
--
--
-- Code Block Init
--
accept Begin.sub.-- Operation do
--
-- Code Block Begin.sub.-- Operation
--
end;
While status = Normal
Loop
status := SelfTest;
if (Coin.sub.-- Throat.sub.-- Status = Open) then
coin.sub.-- present := Check.sub.-- for.sub.-- Coin;
if (coin.sub.-- present) then
Process.sub.-- Coin;
if (fare.sub.-- paid > 100) then
Open.sub.-- Gate;
--
-- Code Block Det.sub.-- Next.sub.-- Gate.sub.-- Pos
--
position := Gate.sub.-- Position;
While position /= Next.sub.-- Position
Loop;
position := Gate.sub.-- Position;
end Loop;
Lock.sub.-- Gate;
Reset.sub.-- display;
end if;
end if;
end if;
end Loop;
--
-- Code Block error.sub.-- Condition
--
if (status = throat.sub.-- jammed)) then
Coin.sub.-- Jam.sub.-- Handler;
elseif (status = gate.sub.-- stuck) then
Coin.sub.-- Stuck.sub.-- Handler;
else
Shut.sub.-- Down;
end if;
end Monitor;
procedure Coin.sub.-- Jam.sub.-- Handler is
--
-- Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
end Coin.sub.-- Jam.sub.-- Handler;
procedure Gate.sub.-- Stuck.sub.-- Handler is
--
-- Put Local Declarations Here
--
begin
--
-- Put Subprogram Body Here
--
end Gate.sub.-- Stuck.sub.-- Handler;
procedure Shut.sub.-- Down is
--
-- Put Local Declarations Here
--
begin
--
-- Put Subproqram Body Here
--
end Shut.sub.-- Down;
task body Clock is
--
-- Put Local Declarations Here
--
Present.sub.-- Time: Time;
Subway.sub.-- Close: Time;
Subway.sub.-- Open: Time;
Midnight: Time;
begin
--
-- Put Subprogram Body Here
--
--
-- Code Block ;Init
While true
Loop
--
-- Code Block Check.sub.-- Time
--
if (Present.sub.-- Time = Subway.sub.-- Open) then
Initialize;
elseif (Present.sub.-- Time = Subway.sub.-- Close) then
Shut.sub.-- Down;
elseif (Present.sub.-- Time = Midnight) then
--
-- Code Block reset.sub.-- Time
--
end if;
accept Freq.sub.-- 60.sub.-- Hz
--
-- Code Block Freq.sub.-- 60 Hz
--
end;
--
-- Code Block Calc.sub.-- New.sub.-- Time
--
end Loop;
end Clock;
end Controller;
______________________________________
It is understood that certain modifications to the invention as described may be made, as might occur to one with skill in the field of the invention, within the scope of the appended claims. Therefore, all embodiments contemplated hereunder which achieve the objects of the present invention have not been shown in complete detail. Other embodiments may be developed without departing from the scope of the appended claims.
|
Same subclass Same class Consider this |
||||||||||