U.S. patent application number 09/790247 was filed with the patent office on 2003-01-30 for generalized software modeling tool.
This patent application is currently assigned to International Business Machines Corporation. Invention is credited to Srinivasa, Deepak M..
Application Number | 20030023413 09/790247 |
Document ID | / |
Family ID | 25150084 |
Filed Date | 2003-01-30 |
United States Patent
Application |
20030023413 |
Kind Code |
A1 |
Srinivasa, Deepak M. |
January 30, 2003 |
Generalized software modeling tool
Abstract
A method, system, software tool and computer program product for
different modeling environments is described. A metamodel
representation, termed a "definition graph" is configured as a
directed weighted multi-graph representation of ordered pairs,
being node and edge pairs. Each node and edge have an associated
weight and attributes. The definition graph is validated. A
user-generated model is then defined, and checked for compatibility
with a validated metamodel. This is achieved by extracting a
template graph from the instance graph of the user model as the
basis for the comparison.
Inventors: |
Srinivasa, Deepak M.;
(Bangalore, IN) |
Correspondence
Address: |
T. RAO COCA
INTERNATIONAL BUSINESS MACHINES CORPORATION
ALMADEN RESEARCH CENTER
650 HARRY ROAD
SAN JOSE
CA
95120
US
|
Assignee: |
International Business Machines
Corporation
Armonk
NY
10504
|
Family ID: |
25150084 |
Appl. No.: |
09/790247 |
Filed: |
February 21, 2001 |
Current U.S.
Class: |
703/2 |
Current CPC
Class: |
G06F 30/00 20200101 |
Class at
Publication: |
703/2 |
International
Class: |
G06F 007/60 |
Claims
I claim:
1. A method for modeling a system, comprising the steps of:
configuring a metamodel with a specified environment in a directed
weighted multi-graph representation; validating said metamodel;
representing a user-generated model; and checking compatibility of
said user model with said validated metamodel.
2. The method of claim 1, wherein, in said step of configuring,
said metamodel representation is a definition graph formed by an
ordered pair, where the first element of the pair is a set of nodes
and the second element of the pair is a set of edges.
3. The method of claim 2, wherein each node and each edge has
associated with it a weight, a node weight indicating a
multiplicity value, and an edge weight indicating directionality
and the multiplicity values of each node associated with that
edge.
4. The method of claim 3, wherein each node and each edge further
has associated with it one or more attributes.
5. The method of claim 3, wherein, in said metamodel validation
step, said definition graph is validated by determining whether the
multiplicity value of a node and the multiplicity value of the
other node in the edge correctly determine the multiplicity value
of the second node.
6. The method of claim 2, 3, 4 or 5, wherein, in the representing
step, said model representation is an instance graph formed by an
ordered pair, where the first element of the pair is a set of nodes
and the second element of the pair is a set of edges.
7. The method of claim 6, wherein said model compatibility checking
step includes the steps of: extracting a template graph from said
instance graph; and verifying said template graph for compatibility
with said definition graph.
8. The method of claim 7, wherein said extracting step is performed
by: creating a skeletal definition graph template from said
definition graph; and parsing said instance graph, and for every
node and edge in said instance graph, updating said template
graph.
9. The method of claim 8, comprising the further step of persisting
a user model if determined to be compatible with said
metamodel.
10. A computer-aided modeling system comprising: input means by
which a metamodel having a specified environment in a directed
weighted multi-graph representation can be input, and by which a
user-generated model also can be input; displaying means for
displaying said metamodel and by which said user model can be
displayed; and processor means, coupled to said input means and
said display means, for validating said input metamodel and for
checking compatibility of said user model with said validated
model.
11. The system of claim 10, wherein said metalmodel representation
is a definition graph formed by an ordered pair, where the first
element of the pair is a set of nodes and the second element of the
pair is a set of edges.
12. The system of claim 11, wherein each node and each edge has
associated with it a weight, a node weight indicating a
multiplicity value, and an edge weight indicating directionality
and the multiplicity values of each node associated with that
edge.
13. The system of claim 12, wherein each node and each edge further
has associated with it one or more attributes.
14. The system of claim 13, wherein said processor means validates
said definition graph by determining whether the multiplicity value
of a node and the multiplicity value of the other node in the edge
correctly determine the multiplicity value of the second node.
15. The system of claim 11, 12, 13 or 14, wherein said model
representation is an instance graph formed by an ordered pair,
where the first element of the pair is a set of nodes and the
second element of the pair is a set of edges.
16. The system of claim 15, wherein said processor means checks
compatibility by extracting a template graph from said instance
graph; and verifying said template graph for compatibility with
said definition graph.
17. The system of claim 16, wherein said processor means extracts
said template graph by creating a skeletal definition graph
template from said definition graph; and parsing said instance
graph, and for every node and edge in said instance graph, updating
said template graph.
18. The system of claim 17, further comprising storage means,
coupled with said processor means, in which metamodels and
compatible user models are persisted.
19. A software tool for modeling a system that is useable to
configure a metamodel with a specified environment in a directed
weighted multi-graph representation, validate said metamodel,
represent a user-generated model, and check the compatibility of a
user model with a validated metamodel.
20. A computer program product comprising computer program code
means carried on a storage medium, said program code means
including: a first program code element for configuring a metamodel
with a specified environment in a weighted multi-graph
representation; a second program code element for validating said
metamodel; a third program code element for representing a
user-generated model; and a fourth program code element for
checking compatibility of said user model with said validated
model.
21. The computer program product of claim 20, wherein for said
first program code element, said metamodel representation is a
definition graph formed by an ordered pair, where the first element
of the pair is a set of nodes and the second element of the pair is
a set of edges.
22. The computer program product of claim 21, wherein each node and
each edge has associated with it a weight, a node weight indicating
a multiplicity value, and an edge weight indicating directionality
and the multiplicity values of each node associated with that
edge.
23. The computer program product of claim 22, wherein each node and
each edge further has associated with it one or more
attributes.
24. The computer program product of claim 22, wherein, for said
second program code element, said definition graph is validated by
determining whether the multiplicity value of a node and the
multiplicity value of the other node in the edge correctly
determine the multiplicity value of the second node.
25. The computer program product of claim 21, 22, 23 or 24,
wherein, for said third program code element, said model
representation is an instance graph formed by an ordered pair,
where the first element of the pair is a set of nodes and the
second element of the pair is a set of edges.
26. The computer program product of claim 25, wherein said fourth
program code element performs the compatibility check by extracting
a template graph from said instance graph; and verifying said
template graph for compatibility with said definition graph.
27. The computer program product of claim 26, wherein by said
fourth program code element, extracting said template graph is
performed by creating a skeletal definition graph template from
said definition graph; and parsing said instance graph, and for
every node and edge in said instance graph, updating said template
graph.
28. A method for modeling a system, comprising the steps of:
configuring a metamodel with a specified environment in a directed
weighted multi-graph representation; validating said metamodel;
representing a user-generated model as an instance graph;
extracting a template graph from said instance graph; and verifying
said template graph for compatibility with said definition graph.
Description
FIELD OF THE INVENTION
[0001] This invention relates to the field of software modeling,
and particularly to a software tool that can be configured with
different modeling environments allowing the creation of a large
class of models.
BACKGROUND OF THE INVENTION
[0002] Software modeling systems usually presents the user with a
graphical user interface, and allows specific models that the
software is designed for to be developed. Some examples are:
[0003] (a) A database modeling tool, which allows the database
designers to model entities, relationships between these entities,
constraints like participation constraints, cardinality of
relationships and such other aspects as weak entities, key
attributes, composite attributes, identifying relationships, etc.
See, for example, "Visual DBM" from YR Soft, Inc. described at
www.yrsoft.com. See also, "ERwin" for database modeling and design
from Blue Ice, Inc. at www.blueice.com/erwin.htm.
[0004] (b) An object-oriented CASE tool, which allows the user to
create classes and relationships between them, and capture them as
class diagrams. It also facilitates the modeling of objects at
run-time in the system, allows modeling of dynamic behavior like
state transition diagrams and architecting the software by means of
component diagrams and deployment diagrams. An example of this is
"Rational Rose 98", from Rational Software Corporation, described
at www.rational.com.
[0005] (c) A procedural CASE tool, which allows the user to develop
data flow diagrams and structure charts. An example of this is
"FlowCharting PDQ", from Hallogram, Inc, described at
www.hallogram.com/flowpdq/.
[0006] (d) A business Process Re-engineering tool, which allows the
user to create process definitions and specify workflows for the
business processes. There are two convenient examples of this
modeling tool. The first is "BPwin" from Blue Ice, Inc., described
at www.blueice.com/bpwin.htm. The second is "ProVision WorkBench"
from Proforma Corporation, described at www.proformacorp.com.
[0007] The systems mentioned above are built with the knowledge of
the types of models that they will allow the user to develop. Thus,
each tool can support a known, limited set of models to be
developed. This is shown in FIG. 1, which is an illustration of the
general strategy employed by the modeling tools, where the
"knowledge" about the models that the user is allowed to create is
embedded into the software of the modeling system.
[0008] In other words, a user 10 interacts with the modeling system
12 via a Graphical User Interface 14, which presents the user with
interfaces for creating specific models. The GUJ14 interacts with a
Knowledge Base 16 which has knowledge about the type of system
models that this system allows the user to create. Models thus
developed become outputs 18 from the system 12.
[0009] Limitations of such systems include:
[0010] (a) If there are changes in the way the models are created,
the knowledge embedded in the software has to be updated. Since
this knowledge is an inherent part of the software, this needs
modification of the code, recompilation and possibly re-linking,
before the software is rendered for use with the required
modifications.
[0011] (b) There could be a need to support variations in the way
in which the models are created. For example, the workflow modeling
done by company A could be different from the way company B does
it. It depends on the particular company and their specific needs,
although both of them are basically doing the same activity,
namely, defining workflows for business processes.
[0012] In these modeling systems, the focus is not on providing a
modeling system, which allows the user to create different types of
models. The user has no means of controlling the behavior of the
system. There also is no consideration of building a system, which
is adaptable to changes and has high reusability value.
[0013] Meta modeling and method engineering has been the focus of
only few research projects. One such project is known as MetaPHOR.
The acronym MetaPHOR stands for: Metamodeling, Principles,
Hypertext, Objects, and Repositories. The main goal of this
research project is to develop architectures, models and technical
solutions for the next generation of configurable CASE environments
and principles for their effective use through method engineering
(see http://metaphor.csjyu.fi/). This project has yielded tools
like MetaEdit and MetaEdit+, which have been commercialized (see
http://wwwjsp.fi/metacase). This research project has also
developed a meta modeling language called GOPRR (Graph Object
Property Role Relation) (see
http://www.jyu.fi/.about.kelly/meta/algopr.h- tml).
[0014] MetaView is a textual metamodeling language also known in
the prior art. The aim of this project is to develop CASE-shells,
for engineering of SDM (Software Development Methods), support
graphical extensions and automatic transformations (see http
://web. cs.ualberta.ca/.about.softeng-
/metaview/system/guide.shtml). As part of the MetaView project, a
modeling system called EARA/GE (Entity Aggregation Relation
Attribute/Graphical Extension) has been developed (see
http://web.cs.ualberta.
ca/.about.softeng/metaview/eara_ge.shtml)
[0015] Known prior art modeling arrangements such as MetaPHOR,
MetaView, GOPHR and EARA/GE attempt, with various degrees of
success, to overcome the limitations originally discussed. It is an
object of the present invention, however, to provide a generalized
modeling tool that utilizes a novel and inventive specific
implementation that also addresses the limitations originally
discussed.
SUMMARY OF THE INVENTION
[0016] Therefore, the invention discloses a method for modeling a
system, comprising the steps of:
[0017] configuring a metamodel with a specified environment in a
directed weighted multi-graph representation;
[0018] validating said metamodel;
[0019] representing a user-generated model; and
[0020] checking compatibility of the user model with the validated
metamodel.
[0021] The invention further discloses a computer-aided modeling
system comprising:
[0022] input means by which a metamodel having a specified
environment in a directed weighted multi-graph representation can
be input, and by which a user-generated model also can be
input;
[0023] displaying means for displaying the metamodel and by which
the user model can be displayed; and
[0024] processor means, coupled to the input means and the display
means, for validating the input metamodel and for checking
compatibility of the user model with the validated model.
[0025] The invention further discloses a software tool for modeling
a system that is useable to configure a metamodel with a specified
environment in a directed weighted multi-graph representation,
validate the metamodel, represent a user-generated model, and check
the compatibility of a user model with a validated metamodel.
[0026] The invention yet further discloses a computer program
product comprising computer program code means carried on a storage
medium, the program code means including:
[0027] a first program code element for configuring a metamodel
with a specified environment in a weighted multi-graph
representation;
[0028] a second program code element for validating the
metamodel;
[0029] a third program code element for representing a
user-generated model; and
[0030] a fourth program code element for checking compatibility of
the user model with the validated model.
[0031] The metamodel representation may be a definition graph
formed by an ordered pair, where the first element of the pair is a
set of nodes and the second element of the pair is a set of edges.
Each node and each edge may have associated with it a weight, a
node weight indicating a multiplicity value, and an edge weight
indicating directionality and the multiplicity values of each node
associated with that edge. Each node and each edge may also have
associated with it one or more attributes.
[0032] Further, in the metamodel validation step, the definition
graph may be validated by determining whether the multiplicity
value of a node and the multiplicity value of the other node in the
edge correctly determine the multiplicity value of the second node.
In the representing step, the model representation may be an
instance graph formed by an ordered pair, where the first element
of the pair is a set of nodes and the second element of the pair is
a set of edges. The model compatibility checking step preferably
includes extracting a template graph from the instance graph and
verifying the template graph for compatibility with the definition
graph. The extracting step is preferably performed by creating a
skeletal definition graph template from the definition graph,
parsing the instance graph and for every node and edge in the
instance graph, updating the template graph. The model
compatibility checking step may persist a
[0033] user model if determined to be compatible with the
metamodel.
[0034] Contrary to the prior art, which compiles instances to check
for validity of user models, the present invention extracts the
definition from the instance for comparison with a validated
metalmodel.
BRIEF DESCRIPTION OF THE DRAWINGS
[0035] Embodiments of the invention will now be described with
reference to the accompanying drawings, in which:
[0036] FIG. 1 is a block diagram illustrating the general strategy
employed by known modeling tools, where the "knowledge" about the
models that the user is allowed to create is embedded into the
software;
[0037] FIG. 2 is a block diagram illustrating the strategy employed
by the present invention, where the system has only meta-knowledge
and the knowledge about the types of models is acquired dynamically
during the configuration phase;
[0038] FIG. 3 is a block flow diagram showing the broad steps in a
modeling system according to the invention;
[0039] FIG. 4 shows one possible architecture of a generalized
modeling system according to the invention;
[0040] FIG. 5 shows a simple metamodel;
[0041] FIG. 6 is a metamodel of the worked example;
[0042] FIG. 7 is the user created model of the worked example;
and
[0043] FIG. 8 is a schematic block diagram of a hardware/computing
apparatus upon which the invention may be practised.
DETAILED DESCRIPTION INCLUDING BEST MODE
[0044] A. Overview
[0045] The invention has the capability to allow the user to create
models, which have one basic similarity. That is, they can, at some
level of abstraction, be represented as directed weighted
multi-graphs. Directed weighted multi-graph is a strong data
structure, which includes directed multi-graph with no weights,
directed linear graph with/without weights, undirected multi-graph
with/without weights, and undirected linear graph with/without
weights. All kinds of tree structures are also essentially graphs.
Thus, a large class of models is covered.
[0046] Weighted multi-graphs facilitate the implementation of a
generalized modeling system, which has the following behavior:
[0047] (a) Allows the user to configure the modeling system with a
modeling environment, which constitutes a metamodel (or
definitions), describing the kinds of models that can be created by
the tool.
[0048] (b) Once the modeling system is configured for a particular
modeling environment, it allows the user to create models that are
instances of the metamodel (i.e., the models that are created by
the user should conform to the definitions provided).
[0049] (c) Once the user creates the models, they can be validated
to check the integrity of the models and can be persisted if the
validation succeeds.
[0050] (d) The system is reusable at different levels and highly
extensible.
[0051] The strategy employed is to take the "knowledge" of the
types of models out of the system, and let the system only have
"meta-knowledge" (i.e., knowledge about the knowledge of the types
of models), which will be used by the system to dynamically acquire
the knowledge about a particular class of models (i.e., when the
user configures the system), and then let the user create models
conforming to the definitions provided by the acquired knowledge.
Thus, the system behaves according to the configured modeling
environment, which not only includes the semantic information about
the types of models that can be created, but also the visual
aspects of the models.
[0052] FIG. 2 shows a user 10 interacting with a metamodeling
system 20. The system 20 includes a Metaknowledge Base 22, which
has the capability to learn the knowledge of the types of models
that the system will allow the user to create. This is the only
information that is hard-coded into the system 20. Information
about the various modeling environments is given to the system in a
phase called the "configuration phase, represented as the true,
input knowledge" 24 to be used by the system for modeling. The
system 20 further includes a Dynamic GUI 26, which presents the
user with interfaces for creating models, corresponding to the
configured modeling environment. In other words, the GUI 26 renders
models of different modeling environments in different ways based
on the information it gets during the configuration phase. Output
models 28 arise from the system 20 when configured.
[0053] FIG. 3 is a block flow diagram showing the broad steps of
the invention in odeling a user-specified system. Each step will be
subsequently described in greater detail.
[0054] In step 30, a modeling environment is specified, typically
by a user. As an example, the environment can include one or more
of processes, activities, and input and output data, if the
modeling environment is for workflow modeling. In step 32, a
metamodel is configured within the modeling environment as a
directed weighted multi-graph. In step 34 the metamodel is
validated. There can be many such metamodels available to a
user.
[0055] In step 36, a user creates a model, being an instance of a
metamodel. In step 38, compatibility of the validated model is
checked with the relevant metamodel. If compatible, the model can
be persisted, in step 40.
[0056] What follows describes an architecture, which realizes the
above strategy and a method.
[0057] B. System Architecture
[0058] The responsibilities and collaborations of each of the
components of the architecture 50 are depicted in FIG. 4.
[0059] The definition component 52 is responsible for reading-in
the metamodels 54 supplied by the user 56 during the configuration
phase, using its meta-knowledge to build the knowledge required for
the current configuration, and validating that the metamodels 54
supplied by the user 56 are good and conform to the meta-knowledge
that the system possesses. The metamodels, thus validated and
transformed into a usable form by the definition component 52, are
available for use by other components.
[0060] The validation component 58 is responsible for validating
the models created by the user. It takes the currently configured
metamodel (from the definition component 52), and the model created
by the user 56 (from the construction and user interface component
60) as inputs. It then checks whether the user created model
conforms to the metamodel that the system is currently configured
for resulting in validated models 66.
[0061] The construction and user interface component 60 is
responsible for obtaining the currently configured metamodel from
the definition component 52, and allows the user 52 to create
models. It makes as many checks as possible in allowing the user to
create models conforming to the metamodel. However, it cannot
completely validate the conformance of the models created (thus,
there is a separate validation component 58). The other important
responsibility of this component 60 is to provide a user interface
that is configured for the current metamodel. It is noted here that
the modeling environment consists of the metamodel, which gives the
knowledge about the type of models that can be created and also the
user interface components associated with that metamodel.
[0062] The responsibility of the persistence component 62 is to
persist the models given in a suitable form. This may be as XML
files, or in a database, or in any other proprietary format.
[0063] The coordinator component 64 is introduced as a mediator
between the other components 52,58,60,62 in order to reduce the
dependency of the components on one another. Each component exposes
an interface, which the coordinator 64 knows. The logic about the
sequence of activities to be performed in configuring the system,
creating a model, validating it and persisting it is present inside
the coordinator component 64. This provides for maximum reusability
and de-coupling of the other components.
[0064] In order to realise such an architecture, it is necessary to
consider the following issues:
[0065] 1. How to represent the metamodels, supplied by the user, in
the system so that it is convenient for other components to use
it.
[0066] 2. How to validate whether the metamodel given by the user
is correct.
[0067] 3. How to represent the models created by the user in the
system, so that it is easy and efficient to validate the model for
conformance to the metamodel.
[0068] 4. What steps are to be taken by the Construction
sub-component 60, while permitting the user to create models. How
does the User Interface sub-component 60 change depending on the
metamodel configuration.
[0069] 5. How to validate whether the models created by the user
are conforming to the metamodel configured.
[0070] 1. Metamodel Representation
[0071] The metamodel is represented as a directed weighted
multi-graph. This metamodel representation is called a "definition
graph". The model that the user creates using this tool will also
be represented as a graph, which shall be called an "instance
graph".
[0072] A definition graph G.sub.d is defined as an ordered pair
(N.sub.d, E.sub.d) where:
[0073] 1. N.sub.d={N.sub.d1, N.sub.d2, . . . , N.sub.d1} is the set
of nodes in the definition graph, such that:
[0074] Each node N.sub.dj is associated with a unique identifier
n.sub.j
[0075] Given two nodes N.sub.dx and N.sub.dy, in the definition
graph, their identifiers have the following properties
[0076] n.sub.dx.noteq.n.sub.dy
[0077] either n.sub.dx>n.sub.dy or n.sub.dy>n.sub.dx (this
ordering constraint will be useful later)
[0078] Each node is associated with a name. This name of a node in
the definition graph will become a "type" in the instance
graphs.
[0079] Each node is associated with a Node-Renderer Component,
which will be used by the UI component 60 (to be discussed later)
to render nodes of this type in the models created by the user.
[0080] Each node is associated with a vector of attributes. Each
attribute will be associated with an Attribute Editor and Attribute
Validator, which will be used by the UI component. These attributes
represent the attributes that the nodes of this type in the
instance graphs can have when the user creates the models. Each
node has a weight, which has the multiplicity information encoded.
The multiplicity values that are supported by this system are ? (0
or 1), 1 (exactly 1), * (any number), +(1 or more).This
multiplicity value indicates the number of nodes of this type that
can be present in the instance graphs. Three bits will be used to
encode the multiplicity information. Thus, the weight associated
with each node will be one byte. A byte is assumed to be the
smallest unit of information that can be stored in a computer's
memory.
[0081] The encoding is done two times in different manners to
facilitate the validation of the metamodel and then the validation
of the instance models. Initially, before metamodel validation
(i.e., when the metamodel is first taken as input from the user
during configuration), the encoding is done as follows.
1 Multiplicity Bit Pattern ? 001 1 010 + 100 * 111
[0082] The logic behind this kind of encoding will become apparent
when the validation of metamodels is discussed. But, after the
metamodel is validated, the weight encoding is changed to suit the
method for the model validation. The encoding will then be done as
follows:
2 Multiplicity Bit Pattern ? 011 1 010 + 110 * 111
[0083] As can be observed, ORing (logical OR operation) 010 to the
weights of the first table, obtains the weights in the second
table. The reason as to why this is done is explained later.
[0084] 1. E.sub.d={E.sub.d1, E.sub.d2, . . . , E.sub.d1}is the set
of edges in the definition graph, such that:
[0085] Each edge E.sub.dj in the graph is associated with a unique
edge identifier e.sub.dj
[0086] Each edge is associated with an ordered pair of nodes. But,
unlike normal directed graph representation, where an edge (a,b)
means the edge is directed from a to b and that (b,a) is different
from (a,b), a different representation is given to the ordered pair
and the directionality of the edge is captured in a different
manner. So, if an edge is associated with two nodes N.sub.dx and
N.sub.dy, then an ordered pair (N.sub.dx, N.sub.dy) is associated
with that edge if n.sub.dx<n.sub.dy, otherwise, the ordered pair
associated with the edge would be (N.sub.dy, N.sub.dx). Thus,
ordering is necessary, but does not reflect the directionality of
the edge, as in other directed graph representation. The reason as
to why this is done will be explained later.
[0087] Each edge in the definition graph is associated with a name,
which will be the type of the edge in the instance graphs created
by the user.
[0088] Each edge will be associated with an Edge-Renderer, which
will be used by the UI component 60 to render the edge.
[0089] Each edge has a vector of attributes. Each attribute is
associated with an Attribute Editor and Attribute Validator, which
will be used by the UI component 60 during the construction of the
models by the user 56.
[0090] Each edge is associated with a weight, which has encoded
information about the directionality of the edge, and the
multiplicity values for each node associated with this edge.
[0091] The directionality value of an edge in the definition graph
indicates the directions that the edges of this type can have in
the instance graphs. Similarly, the multiplicity values of each
associated node for this edge in the definition graph represents
the number of nodes that can be associated with edges of this type
in the instance graphs. The encoding of the multiplicity values is
similar to the encoding done for node multiplicity above. Here, two
such 3-bit patterns are needed to store the multiplicity values of
each node associated with the edge. Also, note that the encoding of
the multiplicity values changes after the metamodel validation as
indicated previously when the weights for the nodes were discussed.
The encoding scheme is repeated again for completeness.
[0092] Encoding before the metamodel validation
3 Multiplicity Bit Pattern ? 001 1 010 + 100 * 111
[0093] Encoding after the metamodel validation, when the metamodel
is ready for model validation.
4 Multiplicity Bit Pattern ? 011 1 010 + 110 * 111
[0094] In addition to encoding the multiplicity values, it is
necessary to encode the directionality information also for an
edge. For an edge associated with two nodes N.sub.dx and N.sub.dy,
represented by the ordered pair (N.sub.dx, N.sub.dy) such that
n.sub.dx<n.sub.dy, the directionality can be from N.sub.dx to
N.sub.dy, or from N.sub.dy to N.sub.dx or in both directions. Thus
there are three combinations, which can be encoded by 2 bits, as
shown in the following table. Also, the encoding of the
directionality values will remain same before and after the
metamodel validation.
5 Directionality Bit Pattern N.sub.dx .fwdarw. N.sub.dy 01 N.sub.dx
.rarw. N.sub.dy 10 N.sub.dx .rarw..fwdarw. N.sub.dy 11
[0095] Thus need 3+3+2 bits are needed for encoding the
multiplicity values of both the associated nodes and the
directionality value. So, one byte will be needed to encode this
information. Thus, the weight of an edge in the definition graph is
one byte encoded as follows:
6 Multiplicity of Multiplicity of Directionality node 1 node 2 2
bits 3 bits 3 bits
[0096] The reason for encoding the weights in these manners will be
evident once the validation algorithm is discussed.
[0097] 2. Metamodel Validation
[0098] The metamodel supplied to the system during configuration
phase can be in any suitable format. One format would be an XML
file having information about the nodes, edges and their properties
described above. This information will be read in by the definition
component and a definition graph would be constructed as per the
above specifications. It is not enough to simply create a
definition graph from the given information. Not all metamodels
make sense. The metamodel given by the user must be determined to
be a good one.
[0099] Consider the situation shown in FIG. 5. Here the two nodes
N1 and N2 are connected by an edge Ej. The multiplicity of N1 and
N2 are n.sub.m1 and n.sub.m2 respectively. The multiplicity of node
N1 in the edge Ej is e.sub.jm1 and the multiplicity of the node N2
in edge is e.sub.jm2. Although the user is free to give any value
to these multiplicity items in the metamodel that he uses to
configure the system, not all combinations make sense. For example,
consider the following values, n.sub.m1=1, e.sub.jm1=1,
e.sub.jm2=1, n.sub.m2=*. This means that there should be exactly
one node of type N1 in the instance graphs. That node of type N1
has an association with nodes of type N2. The multiplicity values
indicate that this is a one-to-one relation. With this being the
case, the user cannot be permitted to provide a multiplicity value
of * for node N2, because * means that no node of type N2 could be
present in the instance graphs. This is an inconsistent definition.
Hence, metamodel supplied by the user has to be validated before
proceeding. The following algorithm does the same. The logic used
in this algorithm is that the multiplicity value of a node and the
multiplicity value of the other node in the edge determine the
multiplicity value of the second node.
[0100] Algorithm for Metamodel Validation:
7 For all edges in the definition graph (index j=1 to number of
edges) Check if the nodes that this edge Ej refers are present in
the NodeTable of the definition graph. If one or both of them are
not present, report error and quit. Initialize the variables nm1,
nm2, ejm1, ejm2 with the multiplicity values of Nodes 1 and 2
associated with this edge, the multiplicity value of the Node1 in
the edge Ej, and the multiplicity value if the Node 2 in the edge
Ej. If (!match (nm2, estimate (nm1, ejm2))) report error and quit.
If (!match (nm1, estimate (nm2, ejm1))) report error and quit. End
loop
[0101] There are two functions used in the above algorithm, namely,
match( ) and estimate( ). The behavior of these functions can be
understood by the following pseudocode.
8 Function estimate (multiplicity1, multiplicity2) returns
multiplicity value If (multiplicity1 == 001 .vertline..vertline.
multiplicity2 == 001) return (111) Else return (multiplicity1
.vertline. multiplicity2). End function
[0102] Note here that the operation performed above is bitwise OR
operation and all numbers are in binary. Thus, the estimate
function gives an encoded most liberal multiplicity value of the
two multiplicity values that it receives.
9 Function match (secondNodeMultiplicity, estimate) returns Boolean
If (secondNodeMultiplicity == 111) If (estimate == 111) return
true; Else return false; Else if ((secondNodeMultiplicity &
estimate) !=0) return true; Else return false; End function
[0103] The operation performed above is the bitwise AND operation.
The match function finds out if the already existing multiplicity
of the node matches with the estimated multiplicity based on the
multiplicity of the other node and the multiplicity value of this
node participating in the edge.
[0104] The system proceeds further only if it finds that the
metamodel supplied by the user is correct by using the above
algorithm. The above algorithm is very simple and the time
complexity is O(n.sub.e), where n.sub.e is the number if edges in
the definition graph. This simplicity has been achieved only by the
intelligent encoding of information containing the multiplicity
values into the weights of the nodes and the edges in the
definition graph. After validation, the weights of the nodes and
the edges of the definition graph will be updated to change the
encoding of the multiplicity value as shown in the second table
above. The following algorithm easily does this.
10 Function changeEncoding For all nodes in the definition graph
Weight .vertline.= 64; //bit pattern for 01000000 End for loop For
all edges in the definition graph Weight .vertline.=72; //bit
pattern for 01001000 End for loop End function
[0105] NodeTable and EdgeTable, which are both hash tables keyed by
node identifier and edge identifier respectively, are available for
use by other components as shown below.
11 Node Table for Definition Graph Node_id Name Weight Node
Renderer Attribute Vector
[0106]
12 EdgeTable for Definition Graph Edge Attribute Edge_id Name Node1
Node2 Weight Renderer Vector
[0107] 3. Model Representation
[0108] The models created by the user are also represented as
directed graphs, which shall be called "instance graphs". The
representation is similar to the definition graph representation,
with some important changes.
[0109] An instance graph G.sub.i can be defined as an ordered pair
(N.sub.i, E.sub.i) where
[0110] I. N.sub.i={N.sub.i1, N.sub.i2, . . . , N.sub.ik} is the set
of nodes in the instance graph such that:
[0111] Each node N.sub.ij is associated with a unique identifier
n.sub.ij.
[0112] Each node of the instance graph is associated with a node of
its definition graph, which forms the type of this node (this node
of the definition graph will be called the type-node of the node in
the instance graph).
[0113] As a mandatory attribute, every node has a name.
[0114] Each node is associated with a vector of attributes. These
attributes have their corresponding types in the attribute vector
of the type-node, which this node is associated with.
[0115] The nodes in the instance graphs do not have any weights
associated with them. Also, there is no ordering constraint on the
identifiers of the nodes as was imposed on the nodes of the
definition graph.
[0116] I. E.sub.i={E.sub.i1, E.sub.i2, . . . , E.sub.ik} is the set
of edges in the instance graph such that:
[0117] Each edge E.sub.ij in the instance graph is associated with
a unique identifier e.sub.ij.
[0118] Each edge of the instance graph is associated with an edge
in its definition graph, which forms the type of this edge (this
edge of the definition graph is called the type-edge of the edge in
the instance graph).
[0119] As a mandatory attribute, every edge has a name.
[0120] Each edge is associated with an ordered pair of nodes
(N.sub.1, N.sub.2) such that the directionality of the edge is from
N.sub.1 to N.sub.2. Note that this is different from the way the
definition graphs are represented.
[0121] Each edge is associated with a vector of attributes. These
attributes have their corresponding types in the attribute vector
of the type-edge, which this edge is associated with.
[0122] So, the NodeTable and the EdgeTable for the instance graph
are as follows:
13 Node Table for Instance Graph Node_id Name Type Attribute
Vector
[0123]
14 Edge Table for Instance Graph Edge_id Name Node1 Node2 Type
Attribute Vector
[0124] 4. Construction and User Interface
[0125] This component takes the metamodel, i.e. the definition
graph, from the definition component and is responsible to see that
the user can create models for the definition configured. It learns
about the types of nodes and the edges that the user can be allowed
to create. Specifically, the user should not be able to:
[0126] Create nodes of types not present in the metamodel
[0127] Create edges of types not present in the metamodel
[0128] It is not difficult for the construction component 40 to
take care of this. One approach would be to dynamically load the
toolbar with the types of nodes and edges that the user can create
according to the current definition. This way, the user has no
means of creating an invalid node or an edge.
[0129] As already mentioned, every node will be associated with a
node renderer, every edge will be associated with an edge renderer,
and every attribute will be associated with an attribute editor and
an attribute validator. When the user creates a node or an edge,
the UI component asks the registered renderer to draw the node or
the edge on the work panel. It then allows the user to enter the
attributes for the node or the edge by using the attribute editor
registered with the particular attribute. Before saving the
attributes into the instance graph, it calls upon the attribute
validator to check whether the user-entered attribute is proper.
Attribute Editors are separated from Attribute Validators in order
to allow maximum reusability. For example, an Attribute Editor for
strings can be used by several attributes, but the method of
validating them could be different, in which case, they will have
different Attribute Validators. Thus, the UI component 40 maintains
a NodeRenderer Table, EdgeRenderer Table, AttributeEditor Table,
and AttributeValidator Table. These can be maintained as hash
tables keyed by unique names. The nodes and the edges in the
definition graph will refer these keys.
[0130] 5. Model Validity and Compatibility Check
[0131] The validation component 58 is responsible for performing
this check. It gets the definition graph currently configured and
the instance graph created by the user, which needs to be
validated.
[0132] The strategy employed here, to check the integrity of the
model, is to derive a new definition out of the instance graph
provided by the user. This new derived graph is called the
"definition template graph". Once the definition template graph is
obtained to see whether the derived template graph and the
configured definition graph are compatible can be checked.
Normally, in other systems, when a check has to be made to
determine whether a given instance (not necessarily graphs)
corresponds to the definition, the strategy employed is to go
though the instance thoroughly to find out if it violates any rules
in the definition.
[0133] There are three steps in the validation of the model or the
instance graph:
[0134] I. Create a skeletal definition graph template from the
definition graph.
[0135] II. Parse the instance graph. For every node and the edge in
the instance graph, update the template graph.
[0136] III. Match the generated template graph and the definition
graph for compatibility. Report errors if there are discrepancies
between the template graph and the definition graph, otherwise, the
model is ready for persistence.
[0137] The Skeletal Definition Graph Template:
[0138] Due to the fact that the construction component takes care
not to allow the user to create any nodes, edges or attributes that
do not belong to the current definition, model validation can only
be bothered about the multiplicity values of the nodes and the
edges, and the directionality values of the edges. In other words,
the validation component 18 checks to see whether the rules of
multiplicity and directionality specified in the definition graph
are adhered to by the instance graph. Hence, the skeletal
definition graph template that will be created will have two
tables, the node table and the edge table. These tables will have
the information as shown below.
[0139] The edge table for the template graph will also have two
hash tables associated with every edge. The first hash table is for
holding information about the occurrence of the nodes of the `from`
type and the second hash table holds information about the
occurrence of the nodes of the `to` type. As each edge is parsed in
the instance graph, the occurrence information of the relevant
nodes associated with that edge is entered into these hash tables.
We note that since this is a hash table, only one entry per node in
the instance graph will be made here. This information will be used
in deciding whether the promotion of multiplicity for that node in
the edge has to be done or not.
15 Node Table for Definition Graph Template Node_id Weight
[0140]
16 Edge Table for Definition Graph Template Edge_id Weight `From
Nodes` hash `To Nodes` hash table table
[0141] The encoding of the multiplicity and directionality values
into the weights of the nodes and the edges are done in the same
manner as for the definition graphs before the validation of the
metamodel. The encoding is given in the following table.
17 Multiplicity Bit Pattern 0 001 1 010 + 100 * 111
[0142]
18 Directionality Bit Pattern N.sub.1 .fwdarw. N.sub.2 01 N.sub.1
.rarw. N.sub.2 10 N.sub.1 .rarw..fwdarw. N.sub.2 11
[0143] Parsing the Instance Graph and Updating the Definition
Template Graph:
[0144] The following algorithm is proposed, which performs the
validation of the model. The method involves parsing all the nodes
and the edges in the instance graph, and for every node or edge,
the weight of the corresponding type-node or the type-edge of the
definition graph template is updated suitably to reflect the
correct multiplicity and directionality values. Once the parsing of
all the nodes and the edges is completed, the definition graph
template is ready for compatibility check with the original
definition graph, which will be performed in the next step.
19 #define FROM_NODE 224 //the bit pattern for [11100000] #define
TO_NODE 28 //the bit pattern for [00011100] initialize the
definition graph template with default values. The default values
for multiplicity is 0 (001) and for directionality is nil (00) For
all nodes (Ni) in the instance graph Get Ndi from Ni // (which is
the type-node identifier of Ni) Get weight of Ndi from the template
graph Weight = promoteMultiplicity (NODE, weight) End loop For all
edges (Ei) in the instance graph Get Edi from Ei // (which is the
type-edge identifier of Ei) Get weight of Edi from the template
graph If (node1 is not present in `from` hash table in template
graph for this edge) //node1 and node2 are the two nodes associated
with this edge such that the edge is from Node1 to Node2. Weight =
promoteMultiplicity (FROM_NODE, weight) Insert node1 into the
`from` hash table. End if If (node2 is not present in `to` hash
table in template graph for this edge) //node1 and node2 are the
two nodes associated with this edge such that the edge is from
Node1 to Node2. Weight = promoteMultiplicity (TO_NODE, weight)
Insert node2 into the `to` hash table. End if Weight =
promoteDirectionality (node1 < node2, weight) End Loop
[0145] There are two function used in the above algorithm. They
are, promoteMultiplicity( ) and promoteDirectionality( ). Both
these functions are bit manipulation functions which alter the
weights given to them such that the occurrence of one more node or
an edge is accounted for in the weight, and so is the occurrence of
an edge in a particular direction. The behavior of these functions
can be understood by the following pseudocode.
20 Function promoteMultiplicity (byte mask, byte weight) returns
weight StoreWeight = weight & (.about.mask); //all operations
are bitwise logical operations WorkingWeight = weight & mask;
If ((workingWeight & 144) !=0) WorkingWeight <<= 1;
WorkingWeight .vertline.= StoreWeight; Return workingWeight; End
function
[0146] Note that the right shift operation fills up a 0 for the
least significant bit of the weight.
21 Function promoteDirectionality (Boolean correctOrder, byte
weight) returns weight StoreWeight = weight & 252; //bit
pattern for [11111100] Weight &=3; If (correctOrder) weight
.vertline.= 1; Else weight .vertline.= 2; Weight .vertline.=
StoreWeight; Return weight; End function
[0147] Matching the Generated Template Graph and the Definition
Graph for Compatibility:
[0148] The algorithm for this compatibility check is given
below.
22 For all nodes (Ni) in the definition graph Get the weight Wdi of
the current node Ni from the definition graph Get the corresponding
weight Wti from the template graph If ((Wdi & Wti) == 0) report
Node Multiplicity error and quit. End loop For all edges (Ei) in
the definition graph Get the weight Wdi of the current edge Ei from
the definition graph Get the corresponding weight Wti from the
template graph TestByte = Wdi & Wti If ((Wti&3) !=0) If
((Wti&3) != (Wdi&3)) report error in directionality and
quit If ((TestByte & 224) == 0) report error in Node1
multiplicity in edge Ei and quit If ((TestByte & 28) == 0)
report error in Node2 multiplicity in edge Ei and quit End loop
[0149] Note that the time complexity of the validation process is
O(n.sub.d+e.sub.d+n.sub.i+e.sub.i), where n.sub.d and e.sub.d are
the numbers of nodes and edges in the definition graph
respectively, and n.sub.i and e.sub.i are the numbers of nodes and
edges in the instance graph. When this algorithm exits
successfully, the instance graph is validated against the
definition graph. The system can then proceed to persist the model
if the user wishes to.
[0150] C. Encoding of Weights and Algorithms
[0151] The following discussion expands upon steps and processes
discussed above.
[0152] The metamodel is represented as definition graph and the
models created by the user are represented as instance graphs. To
check for the compatibility of these instance graphs with the
configured definition graph, a new graph is extracted from the
instance graph called template graph. Then, the template graph and
the definition graph are checked for compatibility. In particular,
compatibility check includes matching the weights of the template
graph and the definition graph. The weight contains the information
about the multiplicity and directionality values of the nodes and
the edges. By parsing the instance graph, the template graph is
constructed. As each node and edge is parsed in the instance graph,
the weight of the template graph is updated. The template graph
thus constructed may not be identical to the definition graph.
Thus, the two graphs are not necessarily isomorphic. However, it is
necessary to check for compatibility between the two graphs. For
example, the definition graph may say that the multiplicity value
of a node is +, which means that the node may have 1 or more
appearance in the instance graph. Thus the multiplicity of 1 or +
in the template graph is compatible with the multiplicity value of
+ in the definition graph. Because of the above argument, there are
two sets of encoding. Encoding of weights is done differently for
the definition graph than that for the template graph to facilitate
the compatibility check.
[0153] Encoding of Multiplicity Values:
[0154] The following table gives the information about the
compatible multiplicity values for the definition graph and the
template graph. Depending on this table, the encoding of the
weights can be determined, so that it is easy to perform the
compatibility check.
23 Corresponding allowed multiplicity values in the Multiplicity
value in Definition Graph. template graph. ? 0, 1 1 1 + 1, 2, 3, .
. . * 0, 1, 2, 3, . . .
[0155] Begin by considering the encoding of the multiplicity values
in the template graph. As the instance graph is parsed, the
template graph is constructed. Initially, since no nodes or edges
have been encountered yet, the multiplicity values of the nodes and
the edges in the template graph should be 0. As the first node or
edge of that type is encountered, the multiplicity value to 1 is
changed. Then, when the second node or edge is encountered, the
multiplicity value is updated to reflect this, to a different
value. From now on, no matter how many nodes or edges of that type
are encountered, the multiplicity value is not altered. This
encoding is done as follows:
[0156] Encoding for multiplicity values in the template graph
24 0 (initial value) 001 1 (first node encountered) 010 + (Second
node is encountered) 100 (this does not change even if more nodes
are encountered)
[0157] Now, consider how to encode the multiplicity values for the
definition graph. Since ? should accept both 0 and 1, it will be
encoded as 001 010, i.e., 011. Logically ANDing 001 or 010 with
011, gets a non-zero value. This property is utilized in the
validation algorithms. The encoding of the other multiplicity
values is shown below.
[0158] Encoding for multiplicity values in the definition graph
25 ? 011 1 010 + 110 * 111
[0159] By observing the second and third tables, it is possible to
verify easily that the behavior shown by the first table is
satisfied.
[0160] Encoding of Directionality Values:
[0161] The logic behind this encoding is straightforward. There are
three possible directionality values for an edge between two nodes
N1 and N2 as shown below.
26 N1.fwdarw.N2 01 N1.rarw.N2 10 N1.rarw..fwdarw.N2 11
[0162] The encoding for the directionality value is the same for
both the template graph and the definition graph. The initial value
of the directionality will be 00, which also signifies that no edge
of that type has occurred. The logic here is that two
directionality values are compatible if the result of logically
ANDing them will lead to a non-zero result. Observe from the above
table that both N1.fwdarw.N2, and N1.rarw.N2 are compatible with
N1N2, while they themselves are not compatible with each other,
which is the required behavior.
[0163] Promotion of Multiplicity Values:
[0164] Promotion of multiplicity value is done for the template
graph during the parsing of the instance graph. The following
promotions need to be done.
27 Initial value of multiplicity: 001 First node occurred: 001
.fwdarw. 010 Second node occurred: 010 .fwdarw. 100 Any number of
further nodes: 100 .fwdarw. 100
[0165] The simple behavior above is to left shift the bits so that
the 1 gets shifted to a higher significant bit, until it becomes
100. Do not further shift once it has reached 100. The function
promoteMultiplicity given above achieves the above behavior. It is
necessary to be careful in calling this function
promoteMultiplicity. A track of the nodes that have occurred for
each edge is maintained in the form of hash tables for each edge in
the template graph. Verify whether it is correct for us to promote
a particular multiplicity by consulting this hash table.
[0166] Since the nodes have their multiplicity values in the first
three bits (most significant), while parsing the nodes of the
instance graph, the promoteMultiplicity function is called with the
11100000 (224) mask. For edges, depending on the occurrence of the
node in the edge, the corresponding mask 11100000 (224) or 00011100
(28) is sent, so that the correct multiplicity value gets
promoted.
[0167] Promotion of Directionality Values:
[0168] This promotion, which is done to the edges of the template
graph when the instance graph is being parsed, is very simple.
Logically ORing the new directionality into the existing
directionality value obtains the effective directionality. For
example, if the current directionality of a particular edge is 01
(which means that an edge N1.fwdarw.N2 has already been
encountered), and a new edge N1.rarw.N2 is encountered, then the
existing directionality value (01) is logically ORed with 10 (the
code for edges of type N1.rarw.N2). Then the effective
directionality would be 11, meaning that this particular edge is
bi-directional. It is easy to see that this technique works for all
cases.
[0169] Checking for Compatibility Between Definition and Template
Graphs:
[0170] Due to the encoding scheme and the promotion of multiplicity
and directionality values, this task is very simple. The logic here
is to logically AND the two values which are being checked for
compatibility. If the result is non-zero, then everything is
satisfactory. Otherwise, it is necessary to report the
corresponding error and quit. An error in the directionality can
occur only if an edge of that type has occurred in the instance
graph, which will be indicated in the template graph directionality
as non-00 code. So, in the algorithm, a check is first made to see
if at all edges of that type have occurred, and only then, the
directionality error check is made.
[0171] D. Worked Example
[0172] Modeling Environment:
[0173] The user wants to model simple business processes. Each
business process can have one or more activities. The activities
can have zero or more input and output data. Also, the process
itself can have zero or more input and output data. Note that the
actual control flow for this process is not captured in these
models (usually, they are done in separate diagrams called workflow
diagrams. Thus, there could be many workflows for a single process
defined by the models under consideration).
[0174] The system is configured with the metamodel shown in FIG. 6.
This metamodel asserts that
[0175] 1. A process 70 can have "contains" relationship with plural
activities 80.sub.n in the instance graphs.
[0176] 2. This "contains" relationship between process 70 and
activity 80.sub.n is directed from process 70 to activity
80.sub.n.
[0177] 3. There can be only one instance node of type process 70 in
the instance graphs corresponding to this metamodel.
[0178] 4. There can be one or more instance nodes of type activity
80.sub.n in the instance graph.
[0179] 5. The instance node of type process 70 in the instance
graphs can be associated with zero or more instance nodes of type
data 90.sub.n through the relationship "o/p".
[0180] 6. The instance node of type process 70 in the instance
graphs can be associated with zero or more instance nodes of type
data 90.sub.n through the relationship "i/p".
[0181] 7. Since there can be only one instance node of type process
70 in the instance graphs, each instance node of type data 90.sub.n
can be related to only one instance node of type process 70 (either
through the relationships "o/p" or "i/p").
[0182] 8. The instance node of type activity 80.sub.n in the
instance graphs can be associated with zero or more instance nodes
of type data 90.sub.n through the relationship "o/p".
[0183] 9. The instance node of type activity 80.sub.n in the
instance graphs can be associated with zero or more instance nodes
of type data 90.sub.n through the relationship "i/p".
[0184] 10. Each instance node of type data 90.sub.n in the instance
graph can be related to zero or more instance nodes of type
activity 80.sub.n through the "o/p" or the "i/p" relationships.
[0185] Metamodel Representation:
[0186] Initially, when the user configures the system with the
above definition, the following definition graph is constructed in
memory. The renderer of the node or the edge is not considered, nor
the attributes contained by the node or the edge.
28 Node Table for Definition Graph (before metamodel validation)
Node_id Name Weight 001 Process 01000000 002 Activity 10000000 003
Data 11100000
[0187]
29 Edge Table for Definition Graph (before metamodel validation)
Edge_id Name Node1 Node2 Weight E001 p.contains.a 001 002 01010001
E002 activity_i/p 002 003 11111110 E003 activity_o/p 002 003
11111101 E004 process_i/p 001 003 01011110 E005 process_o/p 001 003
01011101
[0188] Metamodel Validation:
[0189] The algorithm presented above, relating to metamodel
validation, is traced here for the above example. The "for" loop
runs for all the edges:
[0190] E001: The nodes that this edge connects are of type 001 and
002. They are present in the node table.
[0191] nm1=010; nm2=100; ejm1=010; ejm2=100;
[0192] estimate(nm1, ejm2) returns 110;
[0193] match(nm2, estimate(nm1, ejm2))=match(100, 110) returns
true;
[0194] estimate(nm2, ejm1) returns 110;
[0195] match(nm1, estimate(nm2, ejm1))=match(010, 110) returns
true;
[0196] Everything is correct with this edge.
[0197] E002: The nodes that this edge connects are of type 002 and
003. They are present in the node table.
[0198] nm1=100; nm2=111; ejm1=111; ejm2=111;
[0199] estimate(nm1, ejm2) returns 111; match(nm2, estimate(nm1,
ejm2))=match(111, 111) returns true;
[0200] estimate(nm2, ejm1) returns 111;
[0201] match(nm1, estimate(nm2, ejm1))=match(100, 111) returns
true;
[0202] Everything is correct with this edge.
[0203] E003: The nodes that this edge connects are of type 002 and
003. They are present in the node table.
[0204] nm1=100; nm2=111; ejm1=111; ejm2=111; estimate(nm1, ejm2)
returns 111;
[0205] match(nm2, estimate(nm1, ejm2))=match(111, 111) returns
true;
[0206] estimate(nm2, ejm1) returns 111;
[0207] match(nm1, estimate(nm2, ejm1))=match(100, 111) returns
true;
[0208] Everything is correct with this edge.
[0209] E004: The nodes that this edge connects are of type 001 and
003. They are present in the node table.
[0210] nm1=010; nm2=111; ejm1=010; ejm2=111;
[0211] estimate(nm1, ejm2) returns 111;
[0212] match(nm2, estimate(nm1, ejm2))=match(111, 111) returns
true;
[0213] estimate(nm2, ejm1) returns 111;
[0214] match(nm1, estimate(nm2, ejm1))=match(010, 111) returns
true;
[0215] Everything is correct with this edge.
[0216] E005: The nodes that this edge connects are of type 001 and
003. They are present in the node table.
[0217] nm1=010; nm2=111; ejm1=010; ejm2=111;
[0218] estimate(nm1, ejm2) returns 111;
[0219] match(nm2, estimate(nm1, ejm2))=match(111, 111) returns
true;
[0220] estimate(nm2, ejm1) returns 111;
[0221] match(nm1, estimate(nm2, ejm1))=match(010, 111) returns
true;
[0222] Everything is correct with this edge.
[0223] Thus the metamodel validation algorithm exits successfully,
meaning that the metamodel supplied by the user is valid and it can
be used to create instance models.
[0224] As an example for erroneous metamodel, assume that the
multiplicity value of the Activity (002) node in the definition
graph is * (instead of +). Now, repeating the algorithm for this
case to see how the algorithm detects the error.
[0225] E001: The nodes that this edge connects are of type 001 and
002. They are present in the node table.
[0226] nm1=010; nm2=111; ejm1=010; ejm2=100;
[0227] estimate(nm1, ejm2) returns 110;
[0228] match(nm2, estimate(nm1, ejm2))=match(111, 110) returns
false;
[0229] Hence, the definition of this edge is not proper. The user
will be informed of this by the system, so that the necessary
changes can be made before the system proceeds to allow the user to
create models for this metamodel.
[0230] ChangeEncoding:
[0231] After the metamodel is validated, the weights of the nodes
and the edges are suitably adjusted to facilitate easy validation
of the model. The function changeEncoding is run on the definition
graph to obtain the following definition graph.
30 Node Table for Definition Graph (after metamodel validation):
Node_id Name Weight 001 Process 01000000 002 Activity 11000000 003
Data 11100000
[0232]
31 Edge Table for Definition Graph (after metamodel validation):
Edge_id Name Node1 Node2 Weight E001 p.contains.a 001 002 01011001
E002 activity_i/p 002 003 11111110 E003 activity_o/p 002 003
11111101 E004 process_i/p 001 003 01011110 E005 process_o/p 001 003
01011101
[0233] Model Representation:
[0234] Assume that the user creates the model shown in FIG. 7 by
using the GUI and the construction component. In this example,
there is a single process 70, termed "Procurement". The process
contains three activities, respectively "approved purchase request
80.sub.1, create purchase request 80.sub.2, and modify purchase
request 80.sub.3. The approved purchase request activity 80.sub.1
has a single output relationship with data "purchase order"
90.sub.1 and an input relationship from data "Purchase Request"
90.sub.2. The create purchase activity 80.sub.2 has a single input
relationship with data "current stock" 90.sub.3 and a single output
relationship with the purchase request data 90.sub.2. Lastly, the
modified purchase request activity 80.sub.3 has input relationships
with the purchase request data 90.sub.2 and the current stock data
90.sub.3. It has a single output relationship with "New Purchase
Request" data 90.sub.4.
[0235] In this particular example, all edges are unidirectional. If
any of the edges are allowed to be bidirectional, as stated in the
metamodel, then one edge for each direction occurs in the instance
models.
32 Node Table for the instance graph: Node_id Name Type NI001
Procurement 001 Process NI002 Create 002 Purchase Request NI003
Modify 002 Purchase Request NI004 Approve 002 Purchase Request
NI005 Current Stock 003 NI006 Purchase 003 Request NI007 New 003
Purchase Request NI008 Purchase 003 Order
[0236]
33 Edge Table for the instance graph: Edge_id Name Node1 Node2 Type
EI001 Contains NI001 NI002 E001 EI002 Contains NI001 NI003 E001
EI003 Contains NI001 NI004 E001 EI004 I/p NI005 NI002 E002 EI005
I/p NI005 NI003 E002 EI006 I/p NI006 NI003 E002 EI007 I/p NI006
NI004 E002 EI008 O/p NI002 NI006 E003 EI009 O/p NI004 NI008 E003
EI010 O/p NI003 NI007 E003
[0237] Model Validation:
[0238] The first step here is to construct a skeletal template
graph, based on the definition graph which is done as follows.
34 Initial Node Table for Template Graph: Node_id Weight 001
00100000 002 00100000 003 00100000
[0239]
35 Initial Edge Table for Template Graph: Edge_id Weight `From`
hash table `To` hash table E001 00100100 Empty Empty E002 00100100
Empty Empty E003 00100100 Empty Empty E004 00100100 Empty Empty
E005 00100100 Empty Empty
[0240] The next step is to parse the instance graph and update the
weights of the template graph. The algorithm given above, relating
to parsing, is executed. The multiplicity and directionality values
are appropriately promoted as explained in Section C, to obtain a
template graph as shown below.
36 Final Node Table for Template Graph: Node_id Weight 001 01000000
002 10000000 003 10000000
[0241]
37 Final Edge Table for Template Graph: Edge_id Weight `From` hash
table `To` hash table E001 01010001 NI001 NI002, NI003, NI004 E002
10010010 NI005, NI006 NI002, NI003, NI004 E003 10010001 NI002,
NI003, NI004 NI006, NI007, NI008 E004 00100100 Empty Empty E005
00100100 Empty Empty
[0242] Matching the Definition Graph and the Template Graph:
[0243] Once the template graph has been constructed, it is ready
for compatibility check with the originally configured definition
graph. The algorithm presented above, relating to matching, does
this. The main idea here is to logically AND the relevant parts of
the weights of the template and the definition graphs and verify
that the result obtained is not zero. If so, the two graphs are
compatible, and hence one can conclude that the instance graph
conforms to the configured definition. The corresponding weights of
the node and edge tables which need to be checked for compatibility
is given below. Also, the parts of the weights that will be
compared have been demarcated, although the whole weight is just
one byte.
38 Compatibility check for nodes: Weight in the definition Weight
in the template Node_id graph graph 001 010 000 00 010 000 00 002
110 000 00 100 000 00 003 111 000 00 100 000 00
[0244]
39 Compatibility check for edges: Weight in the definition Weight
in the template Edge_id graph graph E001 010 110 01 010 100 01 E002
111 111 10* 100 100 10 E003 111 111 01 100 100 01 E004 010 111 10
001 001 00 E005 010 111 01 001 001 00
[0245] It can be noted from the above tables that the weights match
and hence it can be concluded that the instance graph generated by
the user conforms to the definition configured. Note also that if
the directionality value of an edge in the template graph is 00, it
implies that an edge of that type has not occurred at all in the
instance graph. While matching the definition and the template
graph with the algorithm just discussed, the algorithm goes ahead
to ensure the directionality value compatibility only if an edge of
that type has indeed occurred.
[0246] E. Computer Implementation
[0247] The process for modeling can be implemented using a computer
program product in conjunction with a computer system 100 as shown
in FIG. 8. In particular, the modeling can be implemented as
software, or computer readable program code, executing on the
computer system 100.
[0248] The computer system 100 includes a computer 150, a video
display 110, and input devices 130, 132. In addition, the computer
system 100 can have any of a number of other output devices
including line printers, laser printers, plotters, and other
reproduction devices connected to the computer 150. The computer
system 100 can be connected to one or more other computers via a
communication input/output (I/O) interface 164 using an appropriate
communication channel 140 such as a modem communications path, an
electronic network, or the like. The network may include a local
area network (LAN), a wide area network (WAN), an Intranet, and/or
the Internet 120.
[0249] The computer 150 includes the control module 166, a memory
170 that may include random access memory (RAM) and read-only
memory (ROM), input/output (I/O) interfaces 164, 172, a video
interface 160, and one or more storage devices generally
represented by the storage device 162. The control module 166 is
implemented using a central processing unit (CPU) that executes or
runs a computer readable program code that performs a particular
function or related set of functions.
[0250] The video interface 160 is connected to the video display
110 and provides video signals from the computer 150 for display on
the video display 110. User input to operate the computer 150 can
be provided by one or more of the input devices 130, 132 via the
I/O interface 172. For example, a user of the computer 150 can use
a keyboard as I/O interface 130 and/or a pointing device such as a
mouse as I/O interface 132. The keyboard and the mouse provide
input to the computer 150. The storage device 162 can consist of
one or more of the following: a floppy disk, a hard disk drive, a
magneto-optical disk drive, CD-ROM, magnetic tape or any other of a
number of non-volatile storage devices well known to those skilled
in the art. Each of the elements in the computer system 150 is
typically connected to other devices via a bus 180 that in turn can
consist of data, address, and control buses.
[0251] The method steps for modeling are effected by instructions
in the software that are carried out by the computer system 100.
Again, the software may be implemented as one or more modules for
implementing the method steps.
[0252] In particular, the software may be stored in a computer
readable medium, including the storage device 162 or that is
downloaded from a remote location via the interface 164 and
communications channel 140 from the Internet 120 or another network
location or site. The computer system 100 includes the computer
readable medium having such software or program code recorded such
that instructions of the software or the program code can be
carried out. The use of the computer system 100 preferably effects
advantageous apparatuses for constructing a runtime symbol table
for a computer program in accordance with the embodiments of the
invention.
[0253] The computer system 100 is provided for illustrative
purposes and other configurations can be employed without departing
from the scope and spirit of the invention. The foregoing is merely
an example of the types of computers or computer systems with which
the embodiments of the invention may be practised. Typically, the
processes of the embodiments are resident as software or a computer
readable program code recorded on a hard disk drive as the computer
readable medium, and read and controlled using the control module
166. Intermediate storage of the program code and any data
including entities, tickets, and the like may be accomplished using
the memory 170, possibly in concert with the storage device
162.
[0254] In some instances, the program may be supplied to the user
encoded on a CD-ROM or a floppy disk (both generally depicted by
the storage device 162), or alternatively could be read by the user
from the network via a modem device connected to the computer 150.
Still further, the computer system 100 can load the software from
other computer readable media. This may include magnetic tape, a
ROM or integrated circuit, a magneto-optical disk, a radio or
infra-red transmission channel between the computer and another
device, a computer readable card such as a PCMCIA card, and the
Internet 120 and Intranets including email transmissions and
information recorded on Internet sites and the like. The foregoing
are merely examples of relevant computer readable media. Other
computer readable media may be practised without departing from the
scope and spirit of the invention.
[0255] The modeling can be realised in a centralised fashion in one
computer system 100, or in a distributed fashion where different
elements are spread across several interconnected computer
systems.
[0256] Computer program means or computer program in the present
context mean any expression, in any language, code or notation, of
a set of instructions intended to cause a system having an
information processing capability to perform a particular function
either directly or after either or both of the following: a)
conversion to another language, code or notation or b) reproduction
in a different material form.
[0257] In the foregoing description generalised modeling tools,
apparatus and systems have been described in accordance with
preferred embodiments of the invention. It will be apparent to one
skilled in the art, however, that numerous changes and/or
modifications can be made without departing from the spirit and
scope of the invention.
* * * * *
References