 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field Of The Invention
This invention relates generally to computer-assisted software engineering
(CASE) systems. In particular, it is directed to a CASE system for
developing applications for execution in cooperative processing
environments.
2. Description Of Related Art
The level of automation used in software development and design is below
the level of automation currently used in the mechanical and electrical
arts. Most software applications are developed manually, using
conventional third-generation languages such as C, COBOL or FORTRAN.
Applications developed manually require a great deal of time and effort to
design and implement, are very expensive to maintain, and often do not
meet the needs of computer system users. An important trend in the
industry is the development of CASE tools to automate and support the
software application development process. Currently, there is a trend to
move CASE tools from mainframe environments to workstations to take
advantage of the workstation's lower cost, faster response time, and
processing power. In addition, the integration of mainframes,
minicomputers and workstations into a seamless distributive computing
environment creates the need for CASE tools that support the development
of software applications in this environment. Integration of workstations,
minicomputers and mainframes is termed a "cooperative processing
environment," wherein applications can be distributed among the different
hardware platforms to optimize performance, while high-speed communication
links facilitate the transfer of messages between applications.
Andersen Consulting, the Assignee of the present invention, has offered the
FOUNDATION.RTM. .sup.CASE system for a number of years. The
FOUNDATION.RTM. .sup.CASE system is comprised of three major modules: the
METHOD/1.RTM. software system, the DESIGN/1.RTM. software system, and the
INSTALL/1.RTM. software system.
The METHOD/1 software system optimizes systems development through an
automated methodology and project management system. METHOD/1.RTM. helps a
systems user prepare a management plan or blueprint of future activities
that can be modified as priorities change. The systems designer can plan,
schedule and scope projects accurately prior to moving to the design
phase.
The DESIGN/1.RTM. software system automates systems design task techniques
to facilitate improved productivity and enhance design quality. The
DESIGN/1.RTM. software system includes systems for data and process
modeling, functional decomposition and prototyping. The DESIGN/1.RTM.
software system automates and integrates these techniques through the use
of a plurality of software tools, including word processing, modeling,
screen and report designing, data design and prototyping tools. These
tools are integrated through a shared repository, thus providing the
ability to share design specifications among designers. Further
information on the DESIGN/1.RTM. software system can be found in the
Andersen Consulting brochure entitled FOUNDATION.RTM.-DESIGN/1.RTM.,
General Description, Version 4.1, 1988, which brochure is hereby
incorporated by reference.
The INSTALL/1.RTM. software system provides a set of software facilities
that allows software designers to create and support application systems.
Prior art INSTALL/1.RTM. software systems were mainframe-based and
designed especially for DB2 development environments. The INSTALL,/1.RTM.
software system addresses all areas of application generation, including
screen and conversation design, code generation, test data management,
production systems report, database administration and technical support.
The INSTALL/1.RTM. software system uses the repository built by the
DESIGN/1.RTM. software system, thus providing a centralized location for
all design specifications. The INSTALL/1.RTM. software system simplifies
coding by generating all of the programming required for basic application
components. Automated code generation improves programmer productivity and
helps ensure standardized software. Further information on the
INSTALL/1.RTM. software system can be found in the Andersen Consulting
brochure entitled FOUNDATION.RTM.-INSTALL/1.RTM., General Description,
Version 1.2, 1989, which brochure is hereby incorporated by reference.
SUMMARY OF THE INVENTION
The present invention comprises a computer-assisted software engineering
(CASE) system for facilitating the design, implementation, and execution
of applications in cooperative processing environments. Design tools are
provided for creating, storing, retrieving, and editing system
specifications in a repository. Construction tools are provided for
generating applications from the systems specification created by the
design tools. A run-time execution architecture is provided for executing
the applications on a plurality of computer hardware platforms. The
run-time execution architecture is comprised of pre-programmed
presentation services for managing the user-interface functions for the
application, pre-programmed distribution services for routing and
transferring messages, and user-programmed application services for
implementing user-defined functions.
DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a cooperative processing environment;
FIG. 2 illustrates a run-time execution architecture for executing
applications on a plurality of computer hardware platforms;
FIG. 3 illustrates a preferred relationship of the different parts of the
run-time execution architecture and the tools used to develop application
components that use these different parts;
FIG. 4 describes a preferred logical relationship of the presentation
services to an operating system and a client application;
FIG. 5 illustrates a preferred use of a memory mode in the Window Editing
Services;
FIG. 6 is a simple example of a window in the preferred embodiment;
FIG. 7 is an example of a simple listbox window in the preferred
embodiment;
FIGS. 8A and 8B describe the data structures used by the preferred
presentation services;
FIG. 9 is a block diagram describing the preferred structure of the window
instance structure;
FIGS. 10A, 10B, and 10C are block diagrams describing the preferred
structure of the WES control table;
FIGS. 11A, 11B are a block diagram describing the preferred structure of
the command table;
FIGS. 12A and 12B are a block diagram describing the preferred structure of
the widget dispatch table;
FIGS. 13A and 13B are a block diagram describing the preferred structure of
the window dispatch table;
FIGS. 14A and 14B are a block diagram describing the preferred structure of
the window definition table;
FIG. 15 is a block diagram describing the preferred structure of the
message header;
FIGS. 16A and 16B illustrate a preferred relationship between the design
tools, the repository, the construction tools, and the user application;
FIG. 17 is a block diagram describing the preferred structure of the window
definition;
FIG. 18 is a block diagram describing the preferred structure of the
window-menu relationship;
FIG. 19 is a block diagram describing the preferred structure of the
window-widget relationship;
FIG. 20 is a block diagram describing the preferred structure of the
window-widget-callback relationship;
FIG. 21 is a block diagram describing the preferred structure of the
window-callback relationship;
FIG. 22 is a block diagram describing the preferred structure of the
listbox definition;
FIG. 23 is a block diagram describing the preferred structure of the
listbox-element relationship;
FIG. 24 is a block diagram describing the preferred structure of the push
button definition;
FIG. 25 is a block diagram describing the preferred structure of the menu
definition;
FIG. 26 is a block diagram describing the preferred structure of the icon
definition;
FIGS. 27, 28, and 29 show the preferred structure of the generated code
shells;
FIG. 30 describes a preferred embodiment of a Shared Data Manager which
provides facilities for applications to access a common pool of
information and register interest in the pool's objects; and
FIG. 31 describes a preferred embodiment of a codes table which is used by
applications to reference commonly used data and provide validation
therefor.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
In the following detailed description of the preferred embodiment of the
present invention, reference is made to the drawings which form a part
hereof and which show by way of illustration a specific embodiment in
which the invention may be practiced. It is to be understood that other
embodiments may be utilized and structural changes may be made without
departing from the scope of the present invention.
General Description
The preferred embodiment of the present invention described herein is a
computer-assisted software engineering system that facilitates the design,
implementation, and execution of cooperative processing applications. The
preferred embodiment provides design tools for creating, storing,
retrieving, and editing system specifications in an electronic data
format. The preferred embodiment also provides construction tools for
taking the systems specification created by the design tools and
generating an application for execution by a run-time execution
architecture. The run-time execution architecture is an environment for
executing applications on a plurality of computer hardware platforms. The
run-time execution architecture provides pre-programmed presentation
services for interacting with the user and pre-programmed distribution
services for routing and transferring messages among applications.
Cooperative Processing Environment
A. Overview
FIG. 1 illustrates one example of a cooperative processing environment,
including workstations 102 for interacting with users, servers 104, and
gateways 106. The servers 104 and gateways 106 ar typically connected to
the workstations 102 via a local area network (LAN) 108. The servers 104
manage a database 110 of information. The gateways 106 provide for
communication 116 between the workstations 102 and remote systems, for
example, host computer 112. Alternatively, the workstations 102 could be
directly connected to the host computer 112. The host computer 112 also
manages a database 114 of information. Those skilled in the art will
readily recognize that any combination of workstations 102, servers 104,
gateways 106, host computers 112, and communication links 116 could be
substituted for the configuration shown.
Run-Time Execution Architecture
The preferred embodiment includes a run-time execution architecture for
executing applications on a plurality of computer hardware platforms. FIG.
2 describes the preferred components of the run-time execution
architecture services for user applications. The pre-programmed services
of the run-time execution architecture insulate the user applications from
the detailed implementation of the presentation services for managing the
user interface and the distribution services for managing message traffic.
A client application 216 executing on a workstation 202 is typically
comprised of pre-programmed presentation services 218, application
functions 220, and pre-programmed distribution services 222. In the
preferred embodiment, only the design of the user-interface and the
application functions 220 are user-specified.
A server application 224 executing on the server 204 is typically comprised
of a pre-programmed server front-end 226, pre-programmed distribution
services 228, application functions 230, and pre-programmed database
access services 232. In the preferred embodiment, only the design of the
database 210 and the application functions 230 are user-specified.
A server application 238 executing on the host computer 212 is typically
comprised of a pre-programmed server front-end 240, pre-programmed
distribution services 242, application functions 244, and pre-programmed
database access services 246. In the preferred embodiment, only the design
of the database 214 and the application functions 244 are user-specified.
It should be noted that the separate components of the server applications
224 and 238 on the two platforms 204 and 212 are functionally similar.
Those skilled in the art will recognize that similar embodiments can be
provided on any platform.
A message manager 234 executing on the gateway 206 and a message manager
236 executing on the host computer 212 are preferably pre-programmed
modules. The message managers 234 and 236 automatically route and transfer
messages from an application on a first platform, for example, client
application 216, to an application on a second platform, for example,
server application 238. In the preferred embodiment, only the
configuration of processes in the cooperative processing environment is
supplied by the user to the message managers 234 and 236.
FIG. 3 generally illustrates the preferred relationship of the different
parts of the run-time execution architecture.
Windows and other display items are created by using a Window
Painter/Generator 304 to define and generate the user interface. The
pre-programmed presentation services 302 are comprised typically of Window
Editing Services 306 and Window Widgets 308 that manage the windows and
display items.
The functions 310 are client-resident functions which are typically
specified by the user with the Structure Chart Editor 312 and generated by
the user with the Code Generator 314 of the DESIGN/1.RTM. software system.
In addition, the users can write their own code in a standard language
such as C, COBOL, etc., using standard programming tools 318, and embed
this code in client applications. The functions are comprised typically of
process control and error handling routines 320.
In the preferred embodiment, the pre-programmed distribution services 322
are not changed by the user. The user, however, does specify the
configuration of hardware and software in the cooperative processing
environment. The pre-programmed Message Manager 324 uses this information
to determine how to route message traffic.
The functions 326 are server-resident functions which are typically
specified by the user with the Structure Chart Editor 328 and Code
Generator 330 of the DESIGN/1.RTM. software system. In addition, the users
can write their own code in a standard language such as C, COBOL, etc.,
using standard programming tools 334, and embed this code in the server
applications. The functions 326 are comprised typically of common business
functions and error handling routines 336.
The pre-programmed database access services 338 manage databases created by
users with a Data Modeler 340 of the DESIGN/1.RTM. software system. In
addition, the users can write their own database access services in a
standard language such as C, COBOL, etc., using standard programming tools
334, and embed this code in the server applications. The Data Modeler 340
defines and generates the database access services 338. In addition, the
users can write their own version of database access services 338 in a
standard language such as C, COBOL, etc., using standard programming tools
334.
In addition to the development tools described above, the user also has a
repertoire of supporting tools including a Data Flow Diagrammer 344 from
the DESIGN/1.RTM. software system, document editors 346, compilers 348,
debuggers 350, copy member generators 354, etc. The specifications and
designs output from all the development tools are stored in a repository
database 352.
Pre-Programmed Presentation Services
A. General Description
FIG. 4 describes the preferred relationship of the pre-programmed
presentation services 402 to the operating system 404 and the client
application 406. In the preferred embodiment, the presentation services
402 are a pre-programmed collection of services designed to provide a
user-interface layer for the run-time execution architecture. The purpose
of this layer is to reduce the amount of effort the programmer must put
into dealing with the user-interface 408 and allow the programmer to
concentrate more on the functions being implemented. Presentation services
402 support a form-filling style of user-interface 408, as well as
interfaces 408 that make use of direct object manipulation, graphics,
images, and sound.
B. Window Editing Services
In the preferred embodiment, the Window Editing Services (WES) of the
presentation services 402 provide a common validation and formatting
service so that applications 406 only have to deal with valid data (e.g.,
a number field is numeric, a date field is valid, etc.), and do not have
to write routines to format and verify certain types of data. WES can
transfer control to application functions in response to widget and window
events 414, for example, such as the user entering a field. These events
are defined by the user. Services to enable and disable end-user commands,
to reflect the state of data entry or the application 406, are also
provided since these are common user-interface features found in
applications 406. WES also provides a link to an on-line help manager and
provides standard mouse, arrow, and cursor reporting services.
In the preferred embodiment, there are two major features of the
presentation services 402: dialogue boxes and widgets. A dialogue box is a
type of window used primarily for presenting or gathering information in a
form-filling style. Widgets are objects used by dialogue boxes to interact
with a user, for example, entry fields, push buttons, check boxes, etc.
Widgets are self-contained objects which interact with the user in a
predetermined manner and interact with their "owner window," usually the
dialogue box, in a predetermined manner, for example, notifying the owner
window of changes to the contents of a window, notifying the owner window
of field exits, etc.
In the preferred embodiment, widgets and dialogue boxes are the primary
interaction mechanisms in the presentation services 402. There may be a
plurality of "callback" functions 420 in the application 406. These
callback functions 420 are invoked for certain events 414 as specified by
the user or the architecture. At the widget level, for example, when the
contents of the widget are valid and the event occurs, a callback function
420 is invoked. At the window level, for example, when all required fields
are entered, and all widget contents are valid, a different callback
function 420 is invoked. There are also callback functions 420 for
transitions to invalid states, i.e., when a widget no longer contains
valid data or when a required field is blank and when a directly
manipulable object is moved to a defined position, etc. This allows the
application 406 to clear the fields, disable functions, and notify the
parent window of any change. For example, an application 406 may want to
disable a "place an order" function when the contents of the order window
are invalid.
In the preferred embodiment, there are two types of events that invoke
callback functions 420 in applications 406: widget and window level events
414. Widget level events include field entry and exit, depressing or
clicking of buttons, the selection of an item in a list box, the
alteration of the contents of an entry field, the change in a field's
status from valid to invalid, etc. Window level events include interfield
validation requests wherein all widgets are invalid when a "major state"
change has occurred, for example, a field exit with new data. Window level
events can also occur when the window enters an invalid state, when a
window is initialized, when a window is closed, or when the user requests
a command. Window level events also occur when the application registers
418 an interest in an object with the Shared Data Manager (discussed
below) and a message is received from the Shared Data Manager. Window
level events also occur when a message is received from the Message
Manager (discussed below), whether unsolicited or as the result of an
asynchronous message sent earlier to some server or other client.
C. Programming Model
Rather than provide a number of calls for interacting with the various
widgets in a dialogue box, the presentation services of the preferred
embodiment provide the application with a memory model that represents the
contents of the screen. FIG. 5 illustrates a preferred use of this memory
model. For each window 502 and 504 on the screen, WES provides a portion
of memory 506 and 508, called WESMaps. WES fills the WESMap with the
current data values, attributes, etc., for the widgets before calling an
application callback function. The application can change values,
attributes, etc., directly in the WESMap with simple assignment
statements. When the application returns the WESMap to WES, WES checks the
changes in the WESMap and updates the widgets accordingly.
In the preferred embodiment, there is only one copy of each WESMap per
window to prevent integrity problems due to concurrent updates caused by
multiple threads. Thus, all other threads in a process are suspended when
one thread requests the WESMap. The other threads are released when the
WESMap is released. Those skilled in the art will recognize that
alternative embodiments could use semaphores or other means to prevent
concurrent updates to the WESMap.
D. WESMap
The preferred structure of the WESMap comprises a window header, a group
status, data values, and field control areas. The window header contains
window-level information that an application may manipulate, for example,
the title of the window, the window size, etc. The group status is an area
intended as a status field for field groups defined within the window.
This allows user commands to be tied dependently to a field group status
so that when the field group is valid the command is enabled. Field values
are the data items on the screen. The field control area is a control
structure for each field in the window. This structure allows user
applications to control the field display attributes, status, access
rights, message id, field cursor, and other attributes which may be unique
to a particular widget type. The display attributes are concerned with
visual attributes. However, a value of -1 in this field indicates that the
application is dealing directly with the widget and that WES should no do
anything with it. The field status is set every time the field data
changes, and thus can be used as a change indicator. It also ensures that
valid data is entered into the field. The field access rights determine
whether a field is enabled, disabled, hidden, etc. The field message id is
the identifier of the message displayed in the message area when the user
is in this field, for example, a brief explanation of the field, a warning
message, etc. The field cursor is used by WES to indicate which field the
cursor was in when the callback function was invoked, even though the
field id is also passed as a parameter to the callback function. In
addition, the application may use this structure to identify and set the
current field. If more than one field has this structure set, then the
first one is made the current field.
Since the WESMap represents a window, no application programmer interface
(API) calls are required in the preferred embodiment to retrieve or set
the contents of a window. A callback function simply sets the various
fields in the WESMap to whatever values it needs and WES will handle the
display events.
In the preferred embodiment, the WESMAP is represented by a copy member or
include file, which those skilled in the art will recognize as a good
technique for multiple functions or programs to use the same data
structure. The copy member generator tool of the DESIGN/1.RTM. software
system generates the WESMap for each window.
E. User Commands
Referring again to FIG. 4, user commands are preferably not tied to a
particular type of widget, for example, push buttons, pull-down menus,
etc. The presentation services 402 allow an abstraction to be made so that
the application 406 does not have to worry about the presentation format.
Thus, the preferred embodiment provides for a separation of the
presentation from the meaning of the command. The application 406 need not
know what type of widget it is working with, instead, an application 406
simply refers to a command for a window and the presentation services 402
take care of the details. If a command needs to move from a menu to a
button or vice versa, the application 406 does not have to be modified;
only a WES control table 412 and a resource file 410 need to be updated.
Similarly, as new widgets are developed, applications 406 can take
advantage of them without changes to the application 406 itself.
There are some presentation services 402 functions used in dealing with
user commands, including Hide, Show, Disable, Enable, and Attribute. The
Hide function is used if an application 406 does not want a user to know
an option exists, for example, if the user security level is not
appropriate. The Show command is used where the command becomes available
for some reason. The Disable command continues to show the command on the
screen but makes it unavailable for use. In most graphical user
interfaces, this means that the push button or menu item corresponding to
the command would be "greyed" to indicate that under the proper
conditions, for example, all fields containing valid input, this command
would be available. The Enable function is used to indicate to the user
that the command is available. The Attribute function is used for
attributes like active/inactive status, for example, when a check mark is
used next to an active menu item.
F. Widget Memory Model
Below are listed various widget types, and some of their internal formats,
preferably supported in the WESMap:
Entry field
String of characters of field size
Numeric field
Signed integer
Unsigned integer
Signed double word integer
Unsigned double word integer
Single precision float
Double precision float
Date field
Julian date
Integer date
Checkbox
Character field (`N`=unchecked; `Y`=checked)
Byte field (0=unchecked/no; 1=checked/yes)
Radio button group
Character string (radio buttons correspond to different values)
Integer field (radio buttons correspond to different values)
Listbox
Maps to a repeating group of entry field references. The first entry in
group is always a one byte `selected` flag
Subsequent entries represent the columns of each row. Each column can be
any data type supported by WES i.e., text, numeric, date, decode, etc.).
The number of occurrences in a `master list` is specified in the WES
Control Table (WCT). This is not necessarily the number of occurrences
visible in the listbox (e.g., 5 visible entries, but a master list of 50
entries).
WES provides the scrolling features through master list.
The application is notified via a callback if the user attempts to scroll
above the top of list or beyond the end of list. This allows the
application to refill the master list (i.e., to page up or down).
G. Example Window and WESMap
FIG. 6 is a simple example of a window. In the preferred embodiment an
application's view of this window is a WESMap data area structured as
follows:
WESMAPHEADER CustInfo;
byte WindowGroupStatus;
long CustNumData;
char CustNameData[33];
float CreditLimitData; byte FriendOfCEOData;
short BillingPrefData;
char ShippingPrefData[5];
WESFLDCTL CustNumCtl;
WESFLDCTL CustNameCtl;
WESFLDCTL CreditLimitCtl;
WESFLDCTL FriendOfCEOCtl;
WESFLDCTL BillingPrefCtl;
WESFLDCTL ShippingPrefCtl;
The WESMAPHEADER structure contains the global fields WindowTitle,
WindowSize, etc. The WindowGroupStatus field is a status field for the
window-level group. The CustNumData field 602 assumes the data type for
the field is a two word integer. The CustNameData field 604 has 32 bytes
for an alphanumeric character string, plus an extra byte to null terminate
the string (corresponding to the standard null terminated string in the C
language; if generated in another language, for example COBOL, the null
terminator would not be generated). The CreditLimitData field 606 assumes
the data type for the field is a floating point value. The FriendOfCEOData
checkbox 608 only needs a single byte to represent checked/unchecked. The
BillingPrefData field 610 uses an integer to represent the various values
corresponding to the radio buttons. The ShippingPrefData field 612 has 5
bytes for representing the length 4 character strings each radio button
represents.
The WESFLDCTL structure contains control vectors for each field above. The
members of the standard WESFLDCTL structure are: "Attr" --logical field
attribute; "Status" --field status; "Rights" --field rights; "Msg"
--message ID for this field; "Cursor" --cursor control. Some examples of
the values for the various field control vectors include:
Attr--AT.sub.-- NORMAL (e.g., use default display attributes for the
field), AT.sub.-- SELECTED (e.g., highlighted), AT.sub.-- ATTENTION (e.g.,
red), AT.sub.-- NONDISPLAY (e.g., hide field contents).
Status--STS.sub.-- WESVALID (e.g., valid WES data), STS.sub.-- VALID (e.g.,
valid data), STS.sub.-- INCOMPLETE (e.g., incomplete), STS.sub.--
INDETERMINATE (e.g., status indeterminate due to asynchronous validation),
STS.sub.-- INVALID (e.g., field invalid).
Rights--RGT.sub.-- DISABLED (e.g., field disabled), RGT.sub.-- PROTECTED
(e.g., protected mode), RGT.sub.-- STANDARD (e.g., standard modes).
Cursor--CUR.sub.-- CURRENT (e.g., current position), CUR.sub.-- MAKECURRENT
(e.g., set cursor position).
The structure of the WCT and the packaging of the pre-programmed services
makes it possible to support additional control vectors in the field
control structure that may be unique to a particular type of widget.
H. Affecting the Contents of a Window
Since the WESMap represents a window in the preferred embodiment, no
procedure calls are required to retrieve or set the contents of a window.
A callback function in the application simply sets the various fields to
whatever values desired, and WES provides the formatting and displaying
functions. In FIG. 6, callback functions would be invoked for "field
exits" or when the push-buttons 614, 616, and 618 are clicked. The
programmer could insert any programming desired at these callback
functions.
For example, in FIG. 6, assume a programmer decided that customer numbers
greater than 1000 should only be billed at home. The following code in the
"field exit" callback for the CustNumData field 602 would do the
following:
if (CustNumData>1000)
BillingPrefData=LT.sub.-- BILLINGPREF.sub.-- HOME;
Additional examples of code for accessing the members of the field-control
structure are provided below:
CustNumAttr=AT.sub.-- ATTENTION;
ShippingPrefRights=RGT.sub.-- DISABLED;
CustNameMsg=MSG.sub.-- HIMOM;
FriendOfCEOCursor=CUR.sub.-- MAKECURRENT;
The complete field-control structure can be referenced (i.e., for passing
to a function) by using the field name without any qualifier (i.e., data,
attr). An example of passing the customer number field to a validation
routine is:
ValidateCustNum (CustNumData, &CustNumCtl);
I. Example ListBox Window and WESMap
FIG. 7 is an example of a simple listbox window. The window 702 has 5 rows
visible at any one time. An application, | | |
