 |
Description  |
|
|
The present application includes a microfiche appendix containing 4 fiche
and 378 frames.
BACKGROUND OF THE INVENTION
The present invention relates to computer modelling systems, and more
particularly to a computer system and method for logical modelling.
Prior to making a large-scale investment in a new process, system, physical
structure, or the like, it is useful to create a model thereof so that
simulations and analysis can be performed before constructing the end
product. For example, architects often use models of new buildings to
evaluate feasibility, and to present their design concepts to the client.
More complex models are used by engineers in designing chemical plants,
vehicles such as automobiles and aircraft, and other complicated
structures.
Computer modelling has been successfully applied to various modelling
endeavors, and is useful in evaluating physical properties of a model,
such as the exact orientation and fitting of parts, as well as the
performance of the item being modelled in its final intended environment.
Such modelling systems are often referred to as CAD/CAM systems.
In a different application area, database technology has been employed to
create models of businesses, business transactions, inventory, and the
like. Such systems are referred to as "information systems". Database
technology used in such systems has progressed from hierarchical means of
database management, to network, relational, and most recently object
oriented management. Such information modelling systems typically use a
"forms" interface for data entry and reporting. Data is generally entered
one object at a time, and reporting is used to print and display a cross
section of the database.
There has recently emerged a concept of a more sophisticated modelling
system in which logical techniques are used in the creation of a model.
Logical modelling is similar to information modelling in that a primary
concern is to create objects which represent things in the world and then
to describe the relationships between these objects. Like CAD/CAM
modelling, the best interface to use with a logical modelling system is
graphical due to the number and complexity of the relationships between
objects. To date, logical modelling systems have relied very heavily on
schematic diagrams to model the system being built. Such diagrams are
quite different from those in the CAD/CAM world in that they show
relationships between objects rather than physical descriptions of an
object. While in CAD/CAM modelling, the graphical location of the objects
greatly effects the meaning of the model, the same model can be expressed
with many different diagrams in logical modelling. Moving objects around
in the logical modelling environment will generally have absolutely no
effect on the model.
Logical modelling is concerned with rules about logical structure. An
example of such a rule in a process model may be that one piece of data
must go into and out of a process entity. In a computer network
configuration model, such a rule may require the presence of certain
pieces of hardware, or may invalidate the use of other pieces of hardware.
Violation of such rules in the logical modelling environment is not
tolerated.
Past attempts at logical modelling have focused primarily on the graphical
representation of objects in the model. Each aspect of the model was
specified in isolation, with no meaningful interconnections between the
objects that could be subsequently used in connection with an evaluation
of the structure and/or behavior of the model. Although such logical
modelling systems contained powerful graphics capabilities, they have been
unable to provide easily evaluatable results which could be subsequently
used to actually control a process, manufacture a product, or, in the
software engineering environment, generate actual computer code
implementing the end result that the model was created to simulate.
An example of such a prior system in which the focus is on the graphical
representation of objects is disclosed in commonly assigned U.S. Pat. Nos.
4,656,603 and 4,813,013, both entitled Schematic Diagram Generating
Systems Using Library of General Purpose Interactively Selectable Graphic
Primitives to Create Special Applications Icons, and incorporated by
reference herein.
It would be advantageous to provide a logical modelling system in which the
structure and behavior of models created thereby can be evaluated and
ultimately used to implement the thing being modelled. In such a system,
the underlying database would contain not just information about the
objects in the database, but would also contain data indicative of how the
objects are correlated to provide evaluatable models.
It would be further advantageous if the graphics used as the interface
between the modelling system and the end user did not simply specify the
objects being modelled, as in the past, but were instead used to provide a
form of communication for the user to and from the underlying database. In
this manner, a user could actually view the database through the graphic
interface.
It would be further advantageous to provide tools to enable a modelling
methodology to be created for the subsequent creation of intended models.
Such tools would, in effect, provide a database editor for the underlying
database of the logical modelling system. Such tools would be more useful
than past tools that provided for specification techniques (i.e., how to
specify things about objects in the modelling system) rather than
providing for the creation of modelling methodologies.
It would be further advantageous to provide such a logical modelling system
wherein policies of coordination can be established among a plurality of
modelling sessions of one or more users. Such a system would enable
management of various users who are working on different aspects of a
model toward the common goal of creating a final, evaluatable model.
The present invention relates to such a logical modelling system and method
of modelling.
SUMMARY OF THE INVENTION
In accordance with the present invention, a computer based modelling system
is provided. The system includes a computer processor, and means coupled
to the computer processor for storing a model database. A set of
primitives is stored in the database. Interface means are coupled to the
computer processor for enabling a user to input, retrieve, and manipulate
data within the database. Tooling means responsive to the interface means
enables a high level user of the modelling system to create a modelling
methodology by editing the database to define:
(a) modelling objects in terms of the primitives,
(b) one or more modes of viewing the modelling objects, and
(c) logical relationships between elements of said modelling objects and
views thereof.
In a preferred embodiment, the interface means is a graphical interface.
The primitives stored in the database comprise entities, relationships for
associating entities, and attributes for setting conditions on entities
and relationships. The modelling objects can include entity structures,
which comprise other entities, relationships, and/or entity structure
types. At least one entity and one relationship is required to define an
entity structure.
Modelling means, responsive to the interface means, enable a low level user
to create models for specific applications. Such models are created by
selecting views representative of modelling objects stored in the
database, and manipulating the views in accordance with the modelling
methodology. The views can comprise forms that are manipulated by entering
information thereon, and/or graphic elements that are manipulated by being
connected to forms or other graphic elements.
Management means, responsive to the interface means, enable the high level
user to establish policies of coordination among a plurality of modelling
sessions of one or more low level users. The high level user defines
modelling objects, views thereof, and logical relationships between the
objects and views representative of low level users, low level user tasks,
and low level user results.
The model database has a recursive structure, whereby a change made to a
first object contained in the database, or to a view derived from the
database, will initiate corresponding changes in every other object or
view logically related to the first object or view. The high level user
can define additional attributes that are dynamic in nature for use in
verifying the propriety of changes made to objects or views in the
database. Verification means, coupled to the computer processor, are
provided to test manipulations of views attempted by a low level user to
verify their compliance with the modelling methodology. Means responsive
to the verification means prohibits invalid manipulations.
Means are provided for evaluating a model created with the modelling means
to determine its performance in an intended application for which the
model was created.
A method is provided for creating modelling methodologies to enable a
modeler to build evaluatable models for intended applications. In
accordance with the method, a set of primitives is provided including
entities, relationships for associating entities, and attributes for
setting conditions on entities and relationships. The primitives are
stored in a model database, and modelling objects are created from the
stored entities, relationships and attributes. These modelling objects are
stored in the database, and views thereof are created. Logical
relationships between elements of the graphical views and modelling
objects are defined and stored in the database. Through graphical views
and the logical relationships, a user is provided with access to the
modelling objects to enable models to be created for an intended
application. Model creation is accomplished by manipulating views to edit
entities and relationships in the modelling database in accordance with a
methodology defined by the types of modelling objects provided, and the
relationships and attributes applicable thereto.
In creating modelling objects, the method of the invention encompasses
defining entity structures and storing them as modelling objects in the
database. The method further contemplates the specification of rules, and
associating such rules to modelling objects. Functions can also be defined
and stored in the database. Other objects which can be defined and stored
in the database include graphic objects, menu objects, queries, reports,
forms, and help text. Policies of coordination can be established among a
plurality of modelling sessions of one or more users.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of the modelling system of the present invention;
FIG. 2 is a block diagram illustrating the tasks of various users of the
modelling system of the present invention;
FIG. 3 is a block diagram illustrating how the system of the present
invention is used by the different users thereof;
FIG. 4 is an entity relationship diagram showing an example of a "sends"
relationship that can be provided in a modelling methodology in accordance
with the present invention;
FIGS. 5a and 5b illustrate an attempted use of the relationship of FIG. 4
and the verification thereof;
FIGS. 6a and 6b illustrate another attempted use of the relationship of
FIG. 4 and the verification thereof;
FIGS. 7a and 7b illustrate another attempted use of the relationship of
FIG. 4 and the verification thereof;
FIG. 8 is a diagrammatic view of a modelling object, a graphical view
thereof, and a control flow diagram relating thereto;
FIG. 9 is a flow chart of the "LogicTool" portion of the modelling system
that enables a high level user to create a modelling methodology;
FIGS. 10a and 10b are a flow chart illustrating the "edit object" step of
the flow chart of FIG. 9 in greater detail;
FIG. 11 is a flow chart of the "ModelManage" procedure of the modelling
system, which enables a high level user to establish policies of
coordination among a plurality of modelling sessions of one or more low
level users;
FIGS. 12a and 12b are a flow chart of the "ModelView" procedure of the
modelling system, which enables system users to create actual models based
on a modelling methodology and which provides diagramming capability
within the modelling system;
FIG. 13 is a flow chart of the diagramming mode of the modelling system of
the present invention; and
FIG. 14 is a flow chart illustrating the logical mapping performed by the
modelling system using diagramming fragments.
The flow charts of FIGS. 9-14 are not intended to imply that any particular
sequence of operation is required in the system of the present invention.
Rather, these figures illustrate the various free choices that a system
user will have during a tooling, managing, or modelling session. In a
preferred embodiment, the various choices of action illustrated in the
flow charts are provided on menus associated with different objects and
their availability depends on what step the user is at during a session.
The designations LogicTool, ModelManage, and ModelView are trademarks of
the assignee of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
A block diagram of the modelling system 10 of the present invention is
provided in FIG. 1. At the heart of the system is a computer processor 12
which can comprise a personal computer or the like, but is more typically
part of a larger, network based system having a plurality of workstations
18, each including an interface 16 such as a keyboard and mouse together
with a graphic display 14. Computer processor 12 is under the control of
software, generally designated 20. The method and apparatus of the present
invention is under the control of application software embodied in
software 20. Software 20 will also include the operating system for
computer processor 12 and other programs necessary for the operation of
the system, such as network software (where the modelling system is used
in a network environment). Computer processor 12 communicates with a
database 22 via path 26 which is bi-directional. In other words, computer
processor 12 can input and retrieve data to and from database 22. In
accordance with the present invention, a set of primitives 24 is included
within database 22 for use by a high level user, sometimes referred to as
a "tooler", to create a modelling methodology.
FIG. 2 illustrates the various levels of user that can interact with the
system of the present invention. A high level user 30, in the role of a
tooler, develops a meta model 32 that defines the entity-relationship
model of a design discipline. To create the meta model, the tooler uses a
software tool referred to as the "LogicTool" program. Through the
LogicTool program, the tooler defines modelling objects in terms of the
primitives 24 in database 22, modes for viewing the modelling objects, and
logical relationships between elements of the modelling objects and views
thereof. For purposes of this disclosure, the term "modelling object" will
be understood to include models and portions of models as well as the
entities, relationships, attributes and roles that are used by a tooler to
define a modelling methodology. Form and diagramming interfaces are also
defined by the tooler, and provide tools that a subsequent lower level
user can use to create a model instance. The LogicTool program itself uses
diagrams and forms to define the model structure and interfaces. After
defining the modelling objects, viewing modes, and logical relationships
therebetween, the tooler compiles this information into a usable meta
model 32.
In another role, the high level user functions as a "model manager" as
indicated at 34. The model manager defines a specific project or projects
to be worked on by lower level users. Each project instance 36 defines the
scope of a model to be created by the lower level users. The model manager
can also provide coordination 38 to manage the completion of projects by
system users, through the establishment of policies of coordination among
a plurality of modelling sessions of one or more users.
The low level users 40, referred to as "modelers", are the persons who
actually create an instance model 42. The modelers are constrained in
their use of the system by the modelling methodology defined by the
tooler, and embodied in meta model 32.
The creation of a modelling methodology and model is shown in more detail
in the block diagram of FIG. 3. The system of the present invention is
provided with a tool meta 50 that includes the primitives used by the
tooler to define the modelling methodology. The LogicTool program is used
to build a model definition 54 using the primitives from tool meta 50 as
indicated at 56. The tool meta is instantiated through the ModelManage
program as indicated at 52. After the model definition 54 is complete, the
LogicTool program is used to compile the definition as indicated at 58.
The result is the meta model 60 which embodies the modelling methodology
designed by the tooler.
The ModelManage program is then invoked at 62 to enable a modeler to create
an application model or "instance model" 64 using a "ModelView" program
66. As noted above, the ModelManage program enables the model manager to
define a project instance to be worked on by the modelers and coordinates
the activity of the modelers. A plurality of modeler workstations 68 are
provided to enable work on the project instance to be allocated among a
number of different modelers.
Thus, as is clear from FIGS. 2 and 3, system primitives are used to define
objects, which in turn are used to create models. The tooler defines ways
of viewing the models, wherein changes to views of the models result in
changes in the database representing the model.
Those skilled in the art will appreciate from a study of FIGS. 1-3 that the
present invention differs from prior art CAD/CAM and information systems
by utilizing an underlying database technology to manage a model and to
enforce logical rules in the model (i.e., the integrity of the model). In
order to implement a logical modelling system of this nature, the
interface between the user and the modelling system must involve both
common database techniques such as forms, queries, and reports together
with additional diagramming techniques to create objects and
relationships. Then, the model must be stored and managed in a database.
Existing database management systems do not readily support graphical
interfaces at the front-end thereof. The present invention, however,
supports a powerful graphical interface at the front-end to enable the
various levels of users to input, retrieve, and manipulate data within the
database, as described in greater detail below. It should therefore be
appreciated that the present invention provides a database management
system specialized for logical modelling, in which graphical interfaces
and their mappings to a logical database are defined by the system users.
The graphical interface is used to directly define the database structure,
which together with the forms, diagrams and graphics used to interface to
the database structure form the meta model.
Logical modelling is concerned with describing entities and their
relationships to other entities. Therefore, the present invention uses an
entity-relationship database managed by an ERA
(entity-relationship-attribute) database management system. In such a
database, an entity is composed of a group of attribute values and may be
in various relationships with other entities, each having its own
attribute values. The relationship itself may also have attribute values.
The ERA database management system ("DBMS") of the present invention may
be implemented on top of a lower level, commercial hierarchical DBMS such
as db.sub.-- Vista, to which additional functionality is added to
implement effective ERA models. In accordance with the present invention,
the ERA database management system is designed to support relationships of
any number of objects in a single relationship instance ("N-ary
relationships"). Such a relationship is illustrated in FIG. 4.
In the entity relationship diagram of FIG. 4, a process 72 sends data to
another process 76. A sends relationship 70 involves three entities;
namely, the sender, the receiver, and the data sent as indicated at 74
(i.e., the "what"). In the hypothetical entity relationship diagram model
of FIG. 4, the "meta-roles" in the "meta-relationship" are that a "sends"
relationship 70 has either one sender or no sender (assuming there is a
receiver), one receiver or no receiver (assuming there is a sender), and
one data or two data. Thus, in the defined relationship, one process can
send one data to one process, or one process can send two different data
to one process. As described below, an attempt to invoke the relationship
of FIG. 4 in a manner not defined by the relationship is invalid and will
be prohibited by the system.
An entity-relationship model provided by the present invention allows
information to be viewed about objects and relationships between the
objects in a clear and concise manner. The model consists of entities,
relationships, and roles that entities or relationships play in
relationships. It is important to note that entities in relationships can
also have attributes. The entities are anything that can be identified.
For example, a process in a data flow diagram is an entity, and the meta
model determines what the entity actually is and how it is used in
relationships in a design. Entities in the meta model can be "subtypes" of
other meta entities, such that the entity inherits all attribute
definitions from its supertype and also inherits any future changes in the
supertype. A subtype can also have additional attributes associated with
it. Due to the dynamic nature of the database of the present invention,
when a supertype is deleted, its subtypes are also deleted.
A relationship is an association among entities and perhaps other
relationships. The sends relationship 70 in FIG. 4 is a relationship
between the two process entities 72, 76. Those skilled in the art will
appreciate that when an entity is referred to as being "in a
relationship", it is understood that the entity could just as well be a
relationship. Thus, it is possible to have a relationship which is playing
a role in another relationship. As with entities, a relationship's type
and what it consists of are expressed in the meta model of the database.
Entities play roles in relationships. Thus, process 72 at the beginning of
sends relationship 70 is playing the role of the "sender" of data to the
process 76. At the same time, process 76 plays the role of the "receiver"
of the data. The data 74 is playing the role of "what" is being sent. The
meta model includes information that describes a valid combination of role
players in an instance of a relationship. Such combinations are referred
to as "player sets", and there can be one or more player sets for a
relationship in the meta model. Each player set consists of role-player
combinations, where the role specified must be played by the corresponding
entity or relationship types when the relationship is created or modified.
Consistent with the proper logical operation of the present system, each
role in a relationship in the meta model must be accounted for. Therefore,
the database will not allow a relationship to exist which does not fit
into one of the player sets.
The process by which the system of the present invention validates
relationships is illustrated in FIGS. 5a, 5b, 6a, 6b, 7a, and 7b. Each of
these figures relates back to the relationship illustrated in FIG. 4.
In FIG. 5a, instances 80, 82, and 84 of the sends relationship 70 are
valid. Instance 86 is invalid because by the definition of the sends
relationship 70 in FIG. 4, it is illegal for the process "D" to receive
data "X" from two different senders, namely "B" and "C". This conclusion
is arrived at in the modelling system by holding the "receiver" and "what"
roles constant and seeing that there can only be one "sender".
This analysis is set forth in FIG. 5b. In FIG. 5b, every sends relationship
from FIG. 5a is represented by a stick diagram 88, 90, 92, 94, and 96. The
analysis proceeds by holding two roles constant and looking for variances
in the third. If the "what" and "receiver" roles are held constant, each
instance of a particular data being sent to a particular process would be
checked for adherence to the constraint that there can only be from zero
to one sender. Thus, data "Z" being sent to "B" by "A" in stick diagram 88
is valid since one process can send one data to one process. Similarly,
data "X" and "Y" sent to "C" by "A" in stick diagrams 90 and 92 is valid
since one process can send either one or two different data to one
process. The sending of data "X" to "D" by "B" is valid since one process
can send one data to one process. However, sending data "X" to " D" by "C"
is invalid since two different processes cannot send the same data to one
process. The invalid situation is indicated by box 98 in FIG. 5b.
A similar analysis is made in FIGS. 6a and 6B, where sender 100 sends three
different data to process 102. The relationship defined in FIG. 4 allows a
maximum of two data to be sent to process 76, which is analogous to
process 102 in FIG. 6a. The attempt to send three different data from
process 100 to process 102 is invalid, as indicated by stick diagrams 104,
106, and 108 enclosed by box 110 in FIG. 6b.
In FIG. 7a, data "X" is sent by process 112 to each of processes 114 and
116. This is invalid, because by the definition of the sends relationship
in FIG. 4, it is illegal for one data to be sent by one process to two
different processes. If the "sender" and "what" roles are held constant,
each particular process sending data would be checked for adherence to the
constraint that there can only be from zero to one processes receiving the
data. Since this constraint is not met in FIG. 7a, as indicated by the two
stick diagrams 118, 120, the attempt is invalid as indicated at box 122.
In the manner illustrated in FIGS. 5-7, the system of the present invention
is able to verify, using logical techniques, whether manipulations (e.g.,
connections) of views attempted by a modeler comply with the modelling
methodology established by the system tooler. Attempts at invalid
manipulations are prohibited.
Those skilled in the art will appreciate that the sends relationship
illustrated in FIG. 4 is merely one example of a relationship. A virtually
unlimited number of other relationships can be implemented in accordance
with the present invention in a similar manner.
An example of the interface which a modeler has to the system of the
present invention is illustrated in FIG. 8, which shows a diagrammatic
view of a process type entity structure represented by symbol 130. The
diagram of FIG. 8 is an example of what a modeler might see on the screen
of his or her graphic display 14 (FIG. 1) when creating a model. Menu 132
associated with entity structure 130 simply provides the modeler a choice
of operations that can be performed with regard to the entity structure.
View 134 is a data flow diagram of the entity structure 130. This entity
structure is a particular process, and graphical objects 136, 138, 140,
and 142 depict various aspects of the process. By choosing the option
"control view" on menu 144, which is placed over graphical object 140, the
modeler can obtain a process diagram 146 of the process control reaction
represented by graphical object 140. As will be appreciated from FIG. 8,
the graphical interface used in connection with the system of the present
invention is extremely powerful, and enables the modeler to view the
database from many perspectives. Techniques for providing such graphics
are disclosed in commonly assigned prior U.S. Pat. Nos. 4,656,603 and
4,813,013 referenced above. Other systems for generating such graphics are
well known in the art.
The overall operation of the LogicTool program, which enables a tooler to
create a modelling methodology, is illustrated in the flow charts of FIGS.
9, 10a, and 10b. These flow charts are not meant to indicate a predefined
operational flow of the system. Instead, they are merely indicative of
various free choices that will be provided to a system user. Typically,
these choices will appear on menus associated with objects displayed on a
user's workstation.
Turning to FIG. 9, a tooler logs into the LogicTool program at 150.
LogicTool is used to create the meta model by defining entity,
relationship, and entity structure types. LogicTool is also used to define
how objects in the meta model can be graphically viewed. The logical
database is viewed through the graphics (including forms) defined by the
tooler. The graphic objects in a view can subsequently be used by a
modeler to create or modify logical object instances by manipulating the
graphic objects.
Through LogicTool, the tooler can define both graphic symbols and forms to
represent entities, relationships and entity structures. Forms are an
alternative to the object symbol interface, and can also be defined for
reports and queries.
After logging into the LogicTool program, the tooler may be queried as to
whether the meta model he wishes to work on already exists, as indicated
at box 152 of FIG. 9. If not, as indicated at box 154, the tooler defines
an empty database for the new meta model. Then, at box 156, a
determination is made as to whether the project for which the tooler
wishes to create a methodology needs to be selected. If so, the tooler
selects a new project or an existing project to work on, as indicated at
box 158.
After identifying the project that is to be worked on, the tooler is given
the choice of editing an object in the meta model at box 160. If the
tooler wishes to edit an object, the edit object routine of FIGS. 10a and
10b is entered at box 162. This routine will be discussed in greater
detail below.
If, at box 160, the tooler does not indicate he wishes to edit an object,
the tooler might "check in" or "check out" an object from the meta model
as indicated at box 164. The term check out is used to designate the act
of retrieving an object from the database to be worked on. The term check
in designates the return of an object, that was previously checked out, to
the database. If the tooler wishes to check in or check out an object, the
desired operation can be accomplished at box 166. As indicated in box 166,
the tooler will have the option to check out an object, to check in an
object, to copy out an object, to abort a checkout operation, or to
refresh an object already checked out by updating it to incorporate any
changes made to the object since the time of checkout. The term "copy out"
is used when the tooler desires to get a read-only version of an object
from the database, without actually checking the object out to be worked
on. When "abort" is selected, the checkout status of an object is aborted
and any modifications made on the object since the checkout are nullified.
As indicated at box 168 in FIG. 9, a tooler may wish to query the database.
This function can be used to query pieces of the meta model, and is useful
to find objects and to interrogate relationships between objects. Upon an
indication that the tooler wishes to query the database, the tooler
selects the object of interest at box 170. Such objects can be either
logical, rule, function, graphic, view, menu, query, report, form, or help
text objects. Each of these types of objects is described in greater
detail below, in connection with the edit object routine of FIGS. 10a and
10b.
Once the object of interest is selected at box 170, the query is executed
at box 172. An example of how a tooler might use the query database
function is to find out which views in the meta model use defined icon
menus. To accomplish this, the tooler would create a query on the logical
relationship "contains", and then select the view and icon menu entities
as the container and containee, respectively, of the relationship. A wild
card would be entered for the names of both entities, and the modelling
system would execute a search for all items that satisfy the query. Each
entity that matches the query would then be listed.
The next function available to the tooler is the run report function
designated at box 174. This function enables the tooler to verify the
model which has been created. In a preferred embodiment of the present
invention, three options are provided. The first is the "verify local"
option used to verify the local database at the tooler's workstation. The
second option is the "verify host" option used to verify the centralized
database in the modelling system. Both options will check all of the
objects in the model for consistency and completeness. Any errors will be
displayed for further action by the tooler. The third option that the
tooler can select in the run report function, as indicated at box 176, is
the "compile meta model" option. This option is used, as discussed above
in connection with box 58 of FIG. 3, to compile the completed model
defined by the tooler into a final meta model which can then be used by a
modeler to create model instances.
Once the tooler compiles the meta model, or exits the run report function
for any other reason, an opportunity is provided to terminate the tooling
session If the tooler wishes to terminate the session, the LogicTool
program is ended at box 180. Otherwise, the tooler can choose to complete
further work within the LogicTool program.
Turning now to FIGS. 10a and 10b, the process of editing an object within
the LogicTool program is described. As noted in connection with FIG. 9,
the tooler is given the opportunity to edit objects at box 160, and if he
chooses to do so, as indicated at box 162 of FIG. 9, the edit object
routine is entered at box 182 of FIG. 10a. A tooler is given the choice to
create a logical object, at box 184. If this is the tooler's intent, the
tooler is given an opportunity to define an attribute, or an entity, or a
relationship, or an entity structure at box 186.
Entities and relationships can have attributes. The type of attributes each
entity and relationship can have, and how many can be applied to each, is
specified by the tooler in designing the meta model of the database. The
ERA database provided in the modelling system of the pre | | |
