Visual Modeling of Problem Solving Methods using Annotated Flow Chart and

Executable Conceptual StructuresDickson Lukose and Robert Kremer

Knowledge Science InstituteDepartment of Computer Science

University of Calgary2500 University Drive N.W.

Calgary, Alberta, Canada T2N 1N4

Email: lukose@peirce.une.edu.au, kremer@cpsc.ucalgary.ca

Abstract In this paper, the authors describe a user modeling notation called the Annotated Flow Chart

(AFC) (i.e., a form of "extended" flow chart) that is highly intuitive and very easy for the

domain experts to use. Modeling constructs represented in AFC are then mapped to MODEL-

ECS (this is an executable conceptual modeling language based on Conceptual Graphs and

Actors formalisms), to enable rapid prototyping of executable knowledge models by domain

experts instead of experienced knowledge engineers. This paper describes in detail the mappings

between constructs in AFC and MODEL-ECS. Examples in visual programming, and knowledge

modeling are used to illustrate the application of AFC in rapid prototying of knowledge models.

1. Introduction

In the last 10 years, researchers in the field of Visual Languages and Knowledge Modeling have been

developing both informal and highly formal visual (and non-visual) languages for the purpose of

explicating the process modeling tasks. The visual programming community have identified several

taxonomies of visual languages, but most focus on specific domains. For example, Price et al. (1993)

focus only on programming visualization languages, while Mayers (1990) concentrated on the area of

visual programming and program visualization and described three separate taxonomies: programming

systems; specification techniques; and program visualization techniques.

There are a large number of visual knowledge representation languages. Some of the visual knowledge

representations languages have much in common with visual programming languages in that they are (or

can be) "executable". These include Knowledge Representation Server (KRS) (Gaines, 1991) and

Conceptual Graphs (Sowa, 1984). KRS is the visual version of the CLASSIC language (Borgida, 1989) in

which the user can specify and run a complete expert system (Kremer, 1997). Sowa (1993) also

demonstrated the mapping between most of the conventional graphical notations used in Computer

Science (e.g., petri nets, E-R diagrams, etc.) to Conceptual Graphs. The need to be able to visually model

process is well acknowledgded as fundamental for dealing with large and highly complex modeling tasks.

Some of the efforts of the Knowledge Modeling Community is outlined in Table 1.1.

MODEL-ECS is one of the graphically based modeling languages. It is a powerful and flexible graphical

tool in the hands of a competent knowledge engineer (Kremer, Lukose, Gaines, 1997). But, the graphical

notation used in MODEL-ECS is fairly complex, difficult to understand by non-knowledge engineers,

and somewhat cumbersome to handle. Since knowledge modeling languages could be usefully employed

by (non-knowledge engineer) domain experts, simplicity and ease of use are two primary requirements

for a knowledge modeling language. It is therefore worthwhile to investigate the possibility of combining

the power of a language like MODEL-ECS with the simplicity and ease of use of a simpler, but not-

Knowledge Engineering Methodology Modeling Language

Algorithmic

KADS (Wielinga, Schreiber and Breuker, 1992) MODEL-K (Karbach and Voß, 1993)

Component of Expertise (Steels, 1990) TroTelC (Vanwelkenhuysen et al., 1990)

Generic Tasks (Chandrasekaran and Johnson, 1993) TIPS (Punch and Chandrasekaran, 1993

KADS (Wielinga, Schreiber and Breuker, 1992)COMMET (Steels, 1990)

LISA

Graphical Modeling

DESIRE (Langevelde, et. al., 1992) CG-DESIRE (Möller and Willems, 1995)

KADS (Wielinga, Schreiber and Breuker, 1992) [CG]->(ON)->[KADS] (Möller, 1995)

KADS (Wielinga, Schreiber and Breuker, 1992) MODEL-ECS (Lukose,1995)

Table 1.1: Knowledge Engineering Methodologies and associated Modeling Languages

quite-so-expressive, language. If one could combine the simplicity of a language like this with the

processing power of MODEL-ECS, one would achieve a very useful knowledge modeling language

indeed.

In this paper, the authors describe a user modeling notation called the Annotated Flow Chart (AFC) (i.e.,

a form of "extended" flow chart) that is highly intuitive and very easy for the domain experts to use.

Modeling constructs represented in AFC are then mapped to MODEL-ECS (this is an executable

conceptual modeling language based on Conceptual Graphs and Actors formalisms), to enable rapid

prototyping of executable knowledge models. This paper describes in detail the mappings between

constructs in AFC and MODEL-ECS.

Section 2 of this paper describes AFC (Subsection 2.1) and MODEL-ECS (Subsection 2.2). Section 3

describes the translation of AFC models into its equivalent counterpart in MODEL-ECS, and Section 4

describes two examples using this technique. The first example (Subsection 4.1) describes the translation

of a simple program (with conditionals and iteration) into MODEL-ECS. The second example

(Subsection 4.2) describes the translation of a Propose and Revise knowledge-level model to MODEL-

ECS. Finally, Section 5 concludes this paper with a summary and an outline of future work.

2 Knowledge Modeling Notations

In this section, the authors describe the two types of graph formalisms that are used for building this

knowledge engineering environment. These two graph formalisms are: AFC and MODEL-ECS. Domain

experts use AFC to model problem solving methods as it is intuitive and easy to use, and MODEL-ECS is

a graphical based executable conceptual modelling language that is based on conceptual graphs and

actors. The following two subsections will describe each of these formalisms, respectively.

2.1. Annotated Flow Chart There exist a large number of graphical modeling languages. Which one of these is most appropriate

depends on the application, task, domain, and the particular user. Certainly, no one notation will suffice

for every modeling case.

Annotated Flow Chart (AFC) is a graphical language that can be used to model problem solving methods

(PSMs). AFC is used to model process, but also annotates the processes with input and output objects. In

addition, AFC allows processes to be annotated with "performers" (i.e., entities charged with the

responsibility of actually carrying out the process). The core of AFC (just the process part, without the

input, output, and performer annotations) is very similar to a simple flowcharting language, so it is fairly

intuitive to a wide audience. (It should be noted that AFC has an important part-of relationship that

doesn't normally occur in flowcharting languages.)

The entire AFC language might be somewhat confusing and intimidating to some users. For this reason, a

subset the AFC graphical language elements can be used as a very simple flowcharting tool which may

be far more appropriate in some cases. AFC is capable of modelling the following control structures: for

loop, while loop, repeat loop, if-then-else, and case switch. Figure 2.1.1 depicts the AFC modeling

constructs.

Propose and Revise is a simple generic problem solving method that us used in the development of many

knowledge based systems. Figure 2.1.2 shows a version of Propose and Revise problem solving method

that is modeled using the AFC modeling constructs outlined in Figure 2.1.1.

while f do A

for x = y to z do A

Figure 2.1.1: AFC Modeling Constructs

Figure 2.1.2: The annotated process model for a "Propose and Revise" PSM (adapted from Jonker and Motta (1993))2.2. MODEL-ECS MODEL-ECS is composed of two forms of abstractions,

and a set of complex modeling constructs. The two forms

of abstractions are: the Primitive Conceptual Structures;

and the Executable Conceptual Structures. There are two

types of Primitive Conceptual Structures. They are:

Conceptual Graphs; and Actors. There are also two types of Executable Conceptual Structures. They are:

Actor Graphs; and Problem Maps. The following subsections will elaborate each of these abstractions

and describe the complex modeling constructs.

2.2.1. Primitive Conceptual Structures

Conceptual Graphs. Conceptual graphs are finite, connected, bipartite graphs. They are bipartite

because there are two different kinds of nodes (i.e., concepts and conceptual relations), and every arc

links a node of one kind to a node of the other kind (Sowa, 1984, pp. 72). In diagrams (i.e., display form),

a concept is drawn as a box, a conceptual relation as a circle, and an arc as an arrow that links a box to a

circle or a circle to a box. A generalization hierarchy is defined over all the conceptual graphs

Actors. There are two types of actors (objects) (Lukose, 1993). They are: the class (type) actor; and the

instance actor. Class actors are defined as abstractions while instance actors are defined as concrete

objects. An actor hierarchy is defined over all the class actors. An actor responds to an incoming

message by executing a method corresponding to the message.

2.2.2. Executable Conceptual Structures

Actor Graphs. Actor Graphs are the most primitive Executable

Conceptual Structures. Actor Graphs use conceptual graphs to represent

the declarative knowledge associated with an inference step, and an actor

to represent the procedural knowledge (Lukose, 1993). An actor graph hierarchy is defined over all the

actor graphs

Problem Maps. A Problem Map is an Executable Conceptual Structure which can be used to represent

task knowledge in a KADS model (Lukose, 1995). A Problem Map is formed by specifying a partial

temporal ordering of the Actor Graphs, which represent the primitive inference steps (Cross and Lukose,

1994). A problem map hierarchy is defined over all the problem maps

From the representational point of view, Actor Graphs are represented as a referent to a second order type

called Knowledge Source (i.e., written as [KS: *x], where x is the Actor Graph), and the Problem Map is

represented by a second order type called Problem Map (i.e., writen as [PM: *y], where y is a partially

ordered set of Knowledge Sources.

3. Mapping From AFC to MODEL-ECS

In this section, the authors will describe the mapping between AFC constructs and its equivalent

MODEL-ECS constructs. There are five AFC construct types that have a direct mapping to its equivalent

counterpart in MODEL-ECS. They are the conditional construct, the while construct, the repeat

construct, the case construct, and the for construct. The following subsections will discuss the mappings

between these five control structures in AFC to its equivalent representation in MODEL-ECS.

3.1. Conditional Construct The conditional construct representation in AFC can conventionally be written as if f then A else B,

where f is a condition and both A and B are actions (possibly composite) (see Figure 3.1). The conditional

construct maps to MODEL-ECS in the following manner: condition f maps to knowledge source [KS:

[TRUE_TEST: f]], as well as [KS: [FALSE_TEST: f]], and both action A and action B map to two

problem maps, [PM: A] and [PM: B], respectively. There is a conceptual relation (FBS) that links [KS:

[TRUE_TEST: f]] to [PM: A] (which indicates that is f is true then perform A. There is also another

conceptual

relation (FBS)

that links [KS:

[FALSE_TEST:

f]] to [PM: B]

which indicates

that if condition

f is false then

proceed to

execute problem

map [PM: B].

This two

constructs are

then represented

in a set within a

problem map

[PM:{....}].

AFC Representation MODEL-ECS Representation

Table 3.1: Mapping of the conditional construct from AFC to MODEL-ECS

AFC Representation MODEL-ECS Representation

Table 3.2: Mapping of the while construct between AFC and MODEL-ECS

3.2. While Construct The while construct representation in AFC is commonly written as while f do A , where f is a condition

and A is an action (possibly composite). The while construct maps to MODEL-ECS, as depicted in

Figure 3.2, in the following manner: condition f maps to [KS: TRUE_TEST: f ]] and [KS:

[FALSE_TEST: f]], and action A maps to problem map [PM: A]. There is a conceptual relation (FBS)

that links [KS: TRUE_TEST: f]] to [PM: A], and from this problem map there is another conceptual

relation (FBS) that links to another pseudo problem map [PM: *], where there is a co-referent link

between this problem map and the problem map that represents the while construct. This implies that,

whenever control arrives at the pseudo problem map [PM: *], it is equivalent to arriving at the beginning

of the while construct. In this way, the control iteratively performs action A until condition f is no longer

true.

3.3. Repeat Construct The repeat construct representation in AFC is conventionally written as repeat A until f, where f is a

condition, and A is an action (possibly composite). The repeat construct maps to MODEL-ECS

representation in the following manner: as before, condition f maps to [KS: TRUE_TEST: f ]] and [KS:

[FALSE_TEST: f]], and action A maps to problem map [PM: A], but, in this construct, there is a

conceptual relation (FBS) that links [KS: [FALSE_TEST: f]] to a psuedo problem map [PM: *] (i.e.,

which represents the repeat construct). In this way, action A is executed first, and as long as condition f is

false, action A will be iteratively repeated. On every iteration, the condition f is check. When condition f

is true, control

exits from the

AFC Representation MODEL-ECS Representation

Table 3.3: Mapping of the repeat construct between AFC and MODEL-ECS

repeat construct. The repeat construct and its equivalent MODEL-ECS representation is depicted in

Figure 3.3.

3.4. Case Construct The case construct representation in AFC, which is conventionally written as switch (case f:A; case

g:B; ....), is basically an extension of the if f then A else B construct. Here, f and g are conditions, and A

and B are actions, maps to MODEL-ECS representation in the following manner: all conditions (i.e., like

f, and g) map to [KS: [TRUE_TEST: f]], etc., and a conceptual relation (FBS) links each of these

knowledge source to a problem map (which should be executed if the condition is true). The case

construct and its equivalent MODEL-ECS representation is depicted in Figure 3.4.

switch (case f:A; case g:B; ....)

AFC Representation MODEL-ECS Representation

Table 3.4: Mapping of the case construct between AFC and MODEL-ECS

3.5. For Construct The for construct representation in AFC, which is usually written as for x = y to z do A, maps to

MODEL-ECS (see Figure 3.5) in the following manner: firstly, the variable predicate is initialize using

the following knowledge source:

[KS: [ASSERT: [VARIABLE: x] ->(EQ)-> [NUMBER: y] ] ]

There is also another knowledge source to increment / decrement the value of this variable predicate. The

increment knowledge source is used when y < z, and the decrement knowledge source is used when y > z.

The control exits from the "body" of the for construct whenever the following knowledge source returns

true:

[KS: [GT] -> (OP1) -> [NUMBER: x]

AFC Representation MODEL-ECS Representation

Table 3.5: Mapping of the for construct between AFC and MODEL-ECS

(OP2) -> [NUMBER: z]

]

Otherwise, the problem map [PM: A] is executed, followed by the increment / decrement knowledge

source, and finally, control is passed to a pseudo problem map [PM: *] which is coreferenced to the

"body" of the for construct. On exit from the "body" of the for construct, control will be passed to the

following knowledge source to retract the variable predicate from the memory:

[KS: [RETRACT: [VARIABLE: x] ->(EQ)-> [NUMBER] ] ]

3.6. Modeling the Process Using the AFC notation to model "processes", one must be able to illustrate the inputs and the outputs of

a process, as well as be able to illustrate the (possible) inter-relationships between these inputs and

outputs that may form the link between two processes. Figures 3.6 (a to c) depicts the mapping between

AFC and MODEL-ECS for the input, output, and link, of processes.

q is-input-to AAFC Representation MODEL-ECS Representation

Table 3.6a: Mapping process input between AFC and MODEL-ECS

q is-ouput-to AAFC Representation MODEL-ECS Representation

Table 3.6b: Mapping process output between AFC and MODEL-ECS

q is-output-of A and is-input-to BAFC Representation MODEL-ECS Representation

Table 3.6c: Mapping process link between AFC and MODEL-ECS

4. Modeling Example

4.1. Visual Programming Example Using all the various types of abstractions outlined in this Section 2.2, one can represented the complex

control structure outlined in Figure 4.1.1 in AFC, as depicted in Figure 4.1.2. In the two figures, A, B,

and C are boolean variables, D and E are integer variables, and P1, P2, P3, and P4 are procedures.

The AFC representation of the complex control structure is depicted in Figure 4.1.2. From the MODEL-

ECS prespective, the AFC representation can be transformed into a problem map as depicted in Figure

4.1.3. Within this problem map, there is a IF-THEN-ELSE construct, within which there is a WHILE-

DO, CASE, and REPEAT-UNTIL construct. P1 to P4 also form PMs (which are simply treated as PMs;

no details are provided).

4.2. Knowledge Modeling Example In Subsection 2.1 (see Figure 2.1.2), the AFC representation of the Propose and Revise PSM as outlined

in (Jonker and Motta, 1993) is presented. Using the transformations (mappings) between AFC and

beginif A then

· {while B do

· {P1; P2}}

else

· {case D is

· 1: {for E = 1 to 10 do P3};

· 2: {repeat P4 until C};

· end; }

end;

Figure 4.1.1: Complex Control Structure

Figure 4.1.2: AFC Representation

Figure 4.1.3: Complex Control Structuring using MODEL-ECS Figure 4.2.1: MODEL-ECS Representation of the Propose and Revise PSM

MODEL-ECS outlined in Section 3 of this paper, one is able to transform the AFC model in Figure 2.1.2

into its equivalent representation in MODEL-ECS, as depicted in Figure 4.2.1.

The two AFC conditions (Constraint Violation Empty?, and Model Complete?) map to two MODEL-ECS

conditional constructs (TRUE_TEST/FALSE_TEST). The four AFC processes (Propose, Verify

Constraints, Revise, and Update Model) map to MODEL-ECS knowledge sources (KS).

6. Conclusion and Future Work

This paper described a highly intuitive modeling language called the Annotated Flow Chart (AFC). It is a

form of "extended" flow chart. This notation is then mapped to MODEL-ECS (a formal, executable,

conceptual structure-based language). This enables the domain experts to do rapid prototyping of

"executable" domain process models -- a task whose complexity would normally require considerable

effort on the part of an experienced knowledge engineer.

The main contributions of this paper are: (1) AFC notation; (2) mapping between AFC notations to its

counterpart in MODEL-ECS; and (3) demonstration of how models represented in AFC can be

transformed to MODEL-ECS representation. Two examples serve to illustrate the principles: Visual

Programming; and Knowledge Modeling.

The next stage of the development in this research is towards automating the mapping process between

AFC and MODEL-ECS. Currently, this process is done manually. Automation will enable the domain

experts to instantly view the execution of the model they constructed in AFC. Another required extension

is the incorporation of more sophisticated temporal relationships between the processes in both AFC and

MODEL-ECS languages.

Acknowledgements

The authors take this opportunity to thank the members of the Knowledge Science Institute for all the

constructive discussions which has contributed very much towards this paper.

References

Chandrasekaran, B., and Johnson, T. (1993). Generic tasks and Tasks Structures: History, Critique and New Directions, in J.M. David, J.P. Krivine, and R. Simmons (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany.

Cross, T. and Lukose, D. (1994). The representation of non-linear hierarchical executable plans, in Proceedings of the 1st Australian Workshop on Conceptual Structures, Armidale, N.S.W., Australia.

Fensel, D., Angele, J., and Landes, D. (1991). Knowledge Representation and Acquisition Language (KARL), in Proceedings of the 11th International Workshop on Expert Systems and Their Applications (Volume: Tools and Techniques), Avignon, France.

Jonker, W., and Motta, E., (1993). Functional design activity using KBSSF and VITAL-OCML. VITAL Project Report DD221 (part III), PTT Research, Groningen, March 1993.

Karbach, W., and Voß, A. (1993). MODEL-K for prototyping and strategic reasoning at the knowledge level, in J.M. David, J.P. Krivine, and R. Simmons (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany.

Kremer, R., (1996). Toward a Multi-User, Programmable Web Concept Mapping "Shell" to Handle Multiple Formalisms, in Proceeding of the 10th Banff Knowledge Acquisition for Knowledge-Based Systems Workshop. Banff, Canada. October, 1996.

Kremer, R., (1997). A Graphical Meta-Language for Knowledge Representation. (In Progress.) PhD Dissertation. University of Calgary, Canada.

Kremer, R., Lukose, D., and Gaines, B., (1997). Knowledge Modeling using Anootated Flow Chart, in Proceedings of the International Conference on Conceptual Structures (ICCS'97), Seattle, August 4 - 8, 1997 (also to appear as LNAI).

Langevelde, I.A., van, Philipsen, A.W., and Treur, J. (1992). Formal specification of compositional architectures, in B. Neumann (ed.), in Proceedings of the 10th European Conference on Artificial Intelligence, ECAI'92, John Wiley & Sons, Chichester.

Linster, M. (1993). Using OMOS to Represent KADS Conceptual Model, in Schreiber, G., Wielinga, B., and Breuker, J., (Eds.), KADS: A Principles Approach to Knowledge-Based System Development, Academic Press, London, UK.

Lukose, D., (1991). Conceptual Graph Tutorial, Technical Report, Department of Computing and Mathematics, School of Sciences, Deakin University, Geelong, Australia, 3217.

Lukose, D. (1993). Executable Conceptual Structures, in G.W. Mineau, B. Moulin and J.F. Sowa (Eds.), Conceptual Graphs for Knowledge Representation, Lecture Notes in Artificial Intelligence (699), Springer- Verlag, Berlin, Germany.

Lukose, D. (1995). Using Executable Conceptual Structures for Modeling Expertise, in Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop (KAW'95), Banff Conference Centre, Banff, Alberta, Canada.

Lukose, D., (1996). MODEL-ECS: Executable Conceptual Modeling Language,in Proceedings of the Knowledge Acquisition for Knowledge Based Systems Workshop (KAW'96), Banff, Canada, 9 - 14 November, 1996.

Lukose, D., (1997). Complex Modeling Constructs in MODEL-ECS, in Proceedings of the International Conference on Conceptual Structures (ICCS'97), Seattle, USA, August 4-8, 1997 (also to appear as LNAI).

Möller, J-U. (1995). Operationalisation of KADS Models by using Conceptual Graph Modules, in Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop, Banff Conference Centre, Banff, Alberta, Canada.

Möller, J-U., and Willems, M. (1995). CG-DESIRE: Formal Specification Using Conceptual Graphs, in Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop, Banff Conference Centre, Banff, Alberta, Canada.

Munday, C., Cross, J., Daengdej, J., and Lukose, D., (1996). CGKEE: Conceptual Graph Knowledge Engineering Environment User and System Manual, Research Report No. 96-118, Department of Mathematics, Statistics, and Computing Science, University of New England, Armidale, N.S.W., Australia, 2351.

Punch, W.F., and Chandrasekaran, B. (1993). An Investigation of the Roles of Problem-Solving Methods in Diagnosis, in David, J.M., Krivine, J.P., and Simmons, R., (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany.

Schreiber, G., Wielinga, B., and Breuker, J. (1993). KADS: A Principled Approach to Knowledge-Based System Development, Academic Press, London, UK.

Sowa, J.F. (1984). Conceptual Structures: Information Processing in Mind and Machine, Addison Wesley, Reading, Mass., USA.

Steels, L. (1990). Components of Expertise, AI Magazine, 11(2).

van Harmelen, F., and Balder, J. (1993). (ML)2: A Formal Language for KADS Models of Expertise, in G. Schreiber, B. Wielinga, and J. Breuker (Eds.), KADS: A Principles Approach to Knowledge-Based System Development, Academic Press, London, UK.

Vanwelkenhuysen, J., and Rademakers, P. (1990). Mapping a Knowledge Level Analysis onto a Computational Framework, in Proceedings of the 9th European Conference on Artificial Intelligence, London, Pitman Publishing.

Voß, A., and Karbach, W. (1993). MODEL-K: Making KADS Run, in G. Schreiber, B. Wielinga, and J. Breuker (Eds.), KADS: A Principles Approach to Knowledge-Based System Development, Academic Press, London, UK.

Wielinga, B., Schreiber, A.T., and Breuker, J.A. (1992). KADS: A Modeling Approach to Knowledge Engineering, in The KADS Approach to Knowledge Engineering Special Issue, Knowledge Acquisition, 4(1), Academic Press, London, UK.

Wetter, T. (1990). First-order logic foundation of the KADS conceptual model. in B. Wielinga, J. Boose, B. Gaines, G. Schreiber, and M. van Someren (Eds.), Current Trends in Knowledge Acquisition, Amsterdam, The Netherlands, IOS Press.