This article was downloaded by: [University of Illinois Chicago]

On: 01 December 2014, At: 18:02

Publisher: Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954
Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH,
UK

Cybernetics and Systems: An

International Journal
Publication details, including instructions for
authors and subscription information:
http://www.tandfonline.com/loi/ucbs20

USING REENGINEERING FOR

KNOWLEDGE-BASED SYSTEMS
a b
Anne Håkansson & Ronald Hartung
a
Department of Information Science, Computer
Science , Uppsala University , Uppsala, Sweden
b
Department of Computer Science , Franklin
University , Columbus, Ohio
Published online: 09 Nov 2007.

To cite this article: Anne Håkansson & Ronald Hartung (2007) USING REENGINEERING
FOR KNOWLEDGE-BASED SYSTEMS, Cybernetics and Systems: An International Journal,
38:8, 799-824, DOI: 10.1080/01969720701601122

To link to this article: http://dx.doi.org/10.1080/01969720701601122

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the
information (the “Content”) contained in the publications on our platform.
However, Taylor & Francis, our agents, and our licensors make no
representations or warranties whatsoever as to the accuracy, completeness,
or suitability for any purpose of the Content. Any opinions and views
expressed in this publication are the opinions and views of the authors, and
are not the views of or endorsed by Taylor & Francis. The accuracy of the
Content should not be relied upon and should be independently verified with
primary sources of information. Taylor and Francis shall not be liable for any
losses, actions, claims, proceedings, demands, costs, expenses, damages,
and other liabilities whatsoever or howsoever caused arising directly or
indirectly in connection with, in relation to or arising out of the use of the
Content.
 This article may be used for research, teaching, and private study purposes.
Any substantial or systematic reproduction, redistribution, reselling, loan,
sub-licensing, systematic supply, or distribution in any form to anyone is
expressly forbidden. Terms & Conditions of access and use can be found at
http://www.tandfonline.com/page/terms-and-conditions
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014
 Cybernetics and Systems: An International Journal, 38: 799–824
Copyright Q 2007 Taylor & Francis Group, LLC
ISSN: 0196-9722 print=1087-6553 online
DOI: 10.1080/01969720701601122

USING REENGINEERING FOR KNOWLEDGE-

BASED SYSTEMS
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

ANNE HÅKANSSON
Department of Information Science, Computer Science,
Uppsala University, Uppsala, Sweden

RONALD HARTUNG
Department of Computer Science, Franklin University,
Columbus, Ohio

Reverse engineering, also called reengineering, is used to modify

systems that have functioned for many years, but which can no
longer accomplish their intended tasks and, therefore, need to be
updated. Reverse engineering can support the modification and
extension of the knowledge in an already existing system. However,
this can be an intricate task for a large, complex and poorly docu-
mented knowledge-based system. The rules in the knowledge base
must be gathered, analyzed and understood, but also checked for
verification and validation. We introduce an approach that uses
reverse engineering for the knowledge in knowledge-based systems.
The knowledge is encapsulated in rules, facts and conclusions, and
in the relationships between them. Reverse engineering also collects
functionality and source code. The outcome of reverse engineering is
a model of the knowledge base, the functionality and the source code
connected to the rules. These models are presented in diagrams
using a graphic representation similar to Unified Modeling
Language and employing ontology. Ontology is applied on top of
rules, facts and relationships. From the diagrams, test cases are gen-
erated during the reverse engineering process and adopted to verify
and validate the system.

Address correspondence to Anne Håkansson, Department of Information Science,

Computer Science, Uppsala University, Box 513, SE-751 20, Uppsala, Sweden. E-mail:
[email protected]
 800 A. HÅKANSSON AND R. HARTUNG

INTRODUCTION
Over a couple of decades, a wide variety of systems operating on
knowledge have been developed. These systems support decision-making
across a vast number of areas, with the oldest and the most established
field being medical services. Unfortunately, many of these systems are not
in use any longer as a consequence of the outdated theories, knowledge,
advice or findings. Developing a new system, however, takes a consider-
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

able number of man months and, during this period; changes in the
working environment may have been occurred that will have an impact
on the requirements. Moreover, while the requirements for the system
may have changed, so too may the understanding of the problem, which
may have advanced, or new discoveries might have been made that need
to be incorporated in the system. These changes may have an impact on
the system, and even a system that has just been implemented in an
organization can be instantaneously out of date (Durkin 1994).
Modifying a recently developed system may not be a problem
because the alteration may only require a minor modification of the
source code, the software engineers may still be available, and there
may be an adequate amount of comprehensive well-written system doc-
umentation. On the other hand, it can be a considerable problem if a
profound alteration is required in a large and complex system (Wiratunga
and Craw 2000). If done manually, this is both time-consuming
and requires that a lot of documentation be available for the system.
Moreover, highly interrelated, complex source code may be involved in
the alteration, and changes of such code are difficult and can generate
errors. Any changes to the system can result in verification and validation
problems caused by inconsistency, incompleteness and incorrectness.
An automated assistant, performing reverse engineering can support
the modification of the contents of the knowledge base. Reverse engin-
eering, also called reengineering, is used to collect and understand
source code that is to be maintained and reused (Gall et al. 1996). Beside
source code, we argue that reengineering can be used to extract knowl-
edge in the form of rules, facts and conclusions in a knowledge-based
system (Simmons et al. 1998). However, since reengineering operates
on a large amount of code, it is a cumbersome process and difficult to
handle manually (Gall et al. 1996). As a result of this, automated assis-
tance is needed for reengineering of the domain knowledge and the
functionality of a system.
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 801

In this article, we present an approach to the use of reengineering for

knowledge in knowledge-based systems (KBSs) based on reengineering
principles. The reengineering for KBSs has to be as general as
possible and should work with many kinds of knowledge representation.
Common representations for these kinds of systems are rule-based, fuzzy
rules, frames, neural networks, and hybrid systems that use a mix of these
representations. In our approach, we utilize reengineering to handle
systems developed with rule-based representation techniques.
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Reengineering extracts the knowledge by gathering all the rules

implemented in the knowledge base (Håkansson and Hartung 2006). It
also collects facts, both prestored from the development of the system
and those collected during the execution of the system, called user given
facts. These user-given facts are received in response to the questions
posed to the end users. In addition, reengineering can collect the conclu-
sions presented to the users. Besides the knowledge, it is important to
encapsulate the relationships between the different rules, and also
between rules and facts and rules and conclusions. Taken together, these
relationships constitute the reasoning strategy of the system.
When gathering the rules, the reengineering must ensure that there is
correctness, consistency and completeness of the knowledge base. These
terms are given a precise definition in our work. Correctness is a match of
the system’s solution with respect to the opinions of human experts.
Consistency is a knowledge base, cleaned of rules that are conflicting, redun-
dant, subsumed and circular. Completeness is a rule base without dead-end
rules, i.e., without any rules with a premise that can never be reached (Polat
and Guvenir 1993). The outcome of the reengineering is a set of models of
knowledge, functionality and source code, which is presented in the form of
a graphic representation using Unified Modeling Language (Jacobson et al.
1998; Booch et al. 1999; Rumbaugh et al. 1999) (UML)-like diagrams. In
these models, ontology is used to represent the knowledge. Using ontology
on top of the rule provides a way to let the objects of the ontology represent
the rule, different facts, including questions, and conclusions, and the
relationships between these different parts. The models are also used to
verify and validate the knowledge in the system.

RELATED WORK
Reengineering has been popular since the mid 1980s. Since then, several
reengineering models have been developed, some operating on the
 802 A. HÅKANSSON AND R. HARTUNG

source code level, and others recovering the design and specifications
(Antonini et al. 1987; Benedusi et al. 1992; Cimitile and De Carlini
1991; Gall et al. 1996). Many of these frequently use a knowledge-based
approach, also the most popular approach adopted, has been to trans-
form the architecture of a system from one form to another. An example
of such a transformation is a model developed by applying reengineering
on expert systems to obtain an object-oriented architecture (Babiker et al.
1997). This model reengineers non-object-oriented systems into object-
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

oriented architectures by using a knowledge-based approach. Other

examples have used reengineering to change conventional architectures
into object-oriented ones (Gall et al. 1996), and transforming procedural
programs into object-oriented programs, such as CORET (object-
oriented reverse engineering; Mittermeir et al. 1998).
In our approach, we use reengineering in KBSs to encapsulate and
represent the knowledge, functionality and source code contained in
the systems. This approach allows us to modify the knowledge or extend
the knowledge base by adding knowledge, as well as enabling us to verify
and validate the original knowledge base and the extended one. The col-
lected knowledge is presented in the form of models by using graphic
representation similar to the diagrams found in UML. Those models
are utilized to support testing of the correctness, consistency and com-
pleteness of the knowledge base.

REVERSE ENGINEERING
Reverse engineering is the process used to analyze a software system to
identify the components and their relationships with the intention of cre-
ating a representation of the system in another form or at a higher level
of abstraction (Chikofsky and Cross 1990). The purpose of reverse
engineering is to understand software systems to facilitate improvement,
correction, documentation, redesign and recoding (Rugaber 2000; Rugaber
et al. 1992). This might be carried out to maintain and reuse source code,
but it can also be conducted to recover designs and specifications.
The existence of large quantities of undocumented code makes reen-
gineering a common and painful problem in the software industry. This
code needs to be captured, analyzed and understood when it is to be
fixed, modified or incorporated into a new system. Sets of techniques
have been developed to provide support when attempting to understand
code (Carriere et al. 2003). The most common is the ad hoc approach
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 803

adopted by a person reading the code manually and piecing together a

picture, thereby attempting to gain an understanding of the system. Some
tool-based techniques have been applied to make this task easier (Müller
et al. 1993). A great deal of the reverse engineering conducted uses
techniques to analyze a program’s structure (Rugaber 2000), where the
structure is determined by lexical, syntactic and semantic rules for pro-
gram constructions. However gaining an understanding of a program in
its context remains very difficult, so that obtaining a sufficiently deep
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

understanding for code to be modified requires intense work by experi-

enced software professionals. As in developing systems in general and
also for reverse engineering, a problem, in particular, is that of making
mistakes. In the case of knowledge-based systems and rule-based
systems, this is also a severe problem.

REVERSE ENGINEERING FOR KNOWLEDGE-BASED SYSTEMS

When applied to a knowledge-based system (KBS), reengineering
involves the collection of the knowledge required to maintain and reuse
the knowledge incorporated in a system. Knowledge in a system is com-
monly expressed in terms of rules, relationships, facts and conclusions.
Reengineering is about collecting all of the knowledge contained in a sys-
tem, including the special functionality, such as the inference mechanism
and predicates, utilized by the system to make use of the knowledge. One
great advantage in a conventional software system is the modularity of
the code. The modularity, whether it is classes in the form of an
object-oriented code or a classical procedural code, helps to guide the
discovery process. However, it is typical for some of the earliest
developed KBSs to lack modular structure and to be data driven instead
of rule engine driven. These KBSs lack the explicit control structures of
conventional programs and the practitioner is faced with a tangle of
propositions, facts and rules.
Faced with the task of updating, verifying and validating the existing
KBSs, we need to investigate the parts of the systems to be considered by
the reengineering tool. One task is to find all the parts that are involved
in an execution and another is to identify the relationships between them.
A harder task is to find the rules that are mistakenly not used in the
execution and the reason for this. Yet another task is to identify the
mechanism that drives the reasoning and the theorem for quantifying
the certainty (for example Bayesian probability).
 804 A. HÅKANSSON AND R. HARTUNG

Three issues confronting the reengineering tool are:

. to identify the part of the rules set that drives a particular conclusion
. to determine which of the conclusions can be drawn from a set of rules
and inputs
. to find the possible difference set between the sets of rules and=or
inputs from the known conclusions.
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Usually, there are many rules that are involved in arriving at a single
conclusion. The reengineering tool needs to identify the complete set of
rules, facts and questions that drives a particular conclusion to allow
modifications to be made and code to be renewed at the same time as
assuring correctness and completeness of the knowledge base. Making
a change to an incomplete rule set can have unwanted side-effects since
all the rules in the rule set are involved when a modification is made.
Many conclusions can be involved within a set of rules. When a part
of the set of rules is changed, these conclusions may be affected. The tool
needs to identify all of the possible conclusions that can be obtained
from the set of rules to maintain correctness and consistency of the
knowledge base when changing the rules in the set.
Different subsets of rules may exist and there may be many inputs
that are obtained from known conclusions. These different subsets need
to be identified by the tool since changing the conclusions can affect all
of the different subsets. Again, modifying the conclusions involves ensur-
ing correctness, consistency and completeness.

Reengineering for Knowledge in a Knowledge Base

Applying reverse engineering to knowledge bases involves reengineering
the knowledge representation of the knowledge-based system in ques-
tion. There are several different kinds of representation, such as rules,
fuzzy rules, frames, neural networks and hybrid systems. Some of these
can be converted into a different form and, although, unfortunately
not available for all forms, the application of a reengineering tool could
be of tremendous advantage for gathering knowledge from some systems
and for converting between different knowledge representations. In this
article, we propose reengineering for systems based on rule-based
representation techniques.
Reengineering involves collecting all of the knowledge contained
within a system regardless of the form it takes and taking into account
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 805

any special functionality related to the knowledge, such as procedural

code, and the inference mechanism. The knowledge is often presented
as rules, i.e., production rules and heuristics, and facts, which are
prestored or user-given. The reengineering needs to collect the different
types of rules together with the relationships to all other rules necessary
to be able to cover all knowledge contained in the knowledge base. Since
prestored facts are incorporated within rules, these must be encountered
and extracted because the execution of the rules depends on these facts
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

being incorporated in the rules. In addition to this, the user-given facts

need to be tracked down. These facts are in the form of answers given
by the users or alternative responses associated with the questions posed.
In addition to the rules and facts, the reengineering must collect all the
information involved in the reasoning in the system. Finally, for com-
pleteness of the rules, the conclusions to be presented for the different
responses are captured by reengineering.
An average sized knowledge base contains several thousand rules
and a couple of hundred facts and all the relationships that these rules
and facts imply. Thus, the reengineering must automatically collect
the knowledge and make it manageable through graphic presentation.
The collection process will inevitably be affected by the structure of
the code, the use of names or words, and the existence of any patterns.
Reengineering uses different search methods to locate the different
kinds of knowledge in the system. Reengineering for KBSs searches
for knowledge using different search criteria, where each set of criteria
depends on the system’s contents, i.e., the knowledge representation
and syntax. Consequently, we need to use different approaches to
track down the rules and the facts, searching for rules as predicates
using known words, searching for syntactic forms with a well-known
pattern and searching for rules without any words or patterns being
assumed.
The first and simplest approach is that of searching for rules as
predicates in the representation. Reengineering can easily pick up rules
using whatever keyword is used to denote them, and often this is, quite
simply, ‘‘rule.’’ Investigating different systems reveals that the word
‘‘rule’’ is, in general, used to represent rules in the source code, as found
in a knowledge base for handling environmental impact assessment for
hydropower development and river regulation in tropical environments.
This expert system was developed to provide advisory and educational
support for end users using the environmental impact assessment
 806 A. HÅKANSSON AND R. HARTUNG

method within developing countries (Håkansson 2004:2). See the

example, which shows rule number 32:
In this example, the search approach has picked up the rule for
‘‘recent large object.’’ It provides the user with the conclusion ‘‘recent
large text’’ and certainty factor 1000 (as this is usually a number between
0 and 1 in ordinary knowledge-based systems but we use numbers
between
1000 and 1000), the conclusion can be considered to be
drawn with confidence. The rule will also have relationships to other
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

rules and facts, some prestored and others might be user-given.

The reengineering procedure continues by collecting the rules by
using a search for all predicates referenced in the rule. As shown in
the example, many of the associated rules can be found by using the con-
tent of the rules and relationships to other rules. One rule will reference
several others and can, therefore, be found by investigating the content of
the predicate, i.e., by utilizing ‘‘check.’’ Since this keyword constitutes a
relationship to another rule, that rule is added to the collection of rules
and, thereafter, investigated. In general, the relationships between the
rules result in a complex graph of dependencies.
By searching the internal contents of these rules, many of the
prestored facts can be found, i.e., those labeled ‘‘fact’’ in the example
given, see Figure 1. In this case, the object named ‘‘environment’’ is
tested against normal, where the prestored fact is set to ‘‘Tropical
climate (A).’’ These prestored facts are often stored in a database and
are therefore always present, even though the system does not necessarily
execute commands involving them.
Another part of the knowledge used by the system is composed of
the user-given facts given by the end user during a session with the
system, and denoted by ‘‘reply.’’ In this case, the reply to the question
‘‘map tools’’ with the answer ‘‘yes’’ and the to the question ‘‘map tools’’
cannot have the answer ‘‘Modern topographical maps.’’ Unfortunately,
the user-given facts can only be found in the database during a session

Figure 1. Example of keywords used and source code in a rule.

 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 807

because such facts are only available when the system is being executed.
Commonly, some facts that are used by the rules will not be given at all
by the users because the facts that need to be inserted into the system
will depend on what the consultation is about. If the user-given facts
are not collected from the rules, the reengineering must reconstruct
the user-given answers hypothetically. This is accomplished by inspecting
the rules and determining what possible values might be given. This step
is required because the values obtained will vary from one session with
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

the system to another.

Despite conducting a comprehensive search of all of the rules, there
is no guarantee that all kinds of rules will be identified and collected
because, for example, some rules take on different structures depending
on their purpose. In the example with environmental impact assessment,
some rules are connected to both questions and conclusions, and have a
rule number, whereas others are only connected to other rules and a con-
clusion. Different rules accept different numbers of arguments depend-
ing upon the call to the rule, i.e., some use three arguments and some
use four arguments. For example ‘‘check (‘‘maps largeobject,’’ ‘‘modern
maps small area3,’’ 200)’’ and ‘‘rule (32, ‘‘recent largeobject,’’ ‘‘recent
large text’’, 1000)’’ where the second statement does include the rule
number.
The second, and more complicated, approach is to search the
syntactic form of the rules. This approach is used to identify rules when
they have a different appearance from that mentioned above, i.e., ones
that are not labeled by a particular word. Rules frequently have a prede-
termined pattern that can be used by the interpretation engine when
reengineering is to track down the rules in a knowledge base. This is
referred to as the pattern of antecedent-consequent rules. Thus, deter-
mining the structure of the rules is the starting point for a search of this
type, for which it is necessary to identify the first rule and then use the
pattern revealed to find the rest of the rules.
The interpretation engine can use an in-built predicate for interpret-
ing antecedent-consequent rules. The reengineering utilizes this predi-
cate by tracking the interpreter while forcing the system to execute the
engine as though someone were consulting the system. The predicate
available in Prolog, called Clause, separates the predicate head from
the body, then the clause predicate check each part, head and body, sep-
arately. This clause predicate uses the predicate’s internal structure, also
referred to as the predicate body; to interpret the rules, prestored facts
 808 A. HÅKANSSON AND R. HARTUNG

and user-given facts to reach a conclusion or conclusions. The relationships

to other rules are found in the body of the rules. This search works for a
couple of KBSs, namely, those with predetermined patterns. However,
some systems use other kinds of custom developed interpreters, and
therefore require a different approach.
In the third approach, the reengineering tool looks for the rules with-
out utilizing wither any presumed word or pattern. In a system, rules are,
usually, the most common predicates and the number of occurrences of
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

that rule-associated predicates generally exceeds the number of times the

other predicates occur. Therefore, when the relevant word or pattern to
be sought is unknown, the rules can be found by counting the number of
occurrences of a predicate with the same name. The search will find
predicates that occur frequently in the code and utilize the keyword=the
keywords that it finds in this way. Again, the reengineering uses the
method described in the first approach, where a keyword was sought
and the method adopted in the second approach where a pattern intrinsic
to the rule was identified, and other rules with the same pattern were
sought in an attempt to find all the other rules in the knowledge base.
After obtaining the reference count of the predicates, these are sorted
in the order in which they are to be considered.
However, it is not certain that the reengineering procedure will find
the rules on which the system is based. Instead, the reengineering tool
may find a predicate that is the code for the functionality of the system
rather than rules or facts and, therefore, the knowledge engineer
must determine whether the predicate belongs to the knowledge or the
functionality.
In addition to obtaining the rules, the other predicates, in the form
of facts, questions used to obtain the user-given facts and conclusions all
need to be found by the reengineering using the same kind of searching
procedures as mentioned above. The first method adopted when search-
ing for rules is to find the questions and the conclusions by investigating
the rules using the keywords ‘‘reply’’ in the predicate body and ‘‘recent
large’’ text in the predicate head. Therefore, to find the questions and
the conclusion, the rules must be investigated. The second method is
to search for patterns to identify facts, questions and conclusions. Com-
monly, the prestored facts are in the form of statements without a body.
In Prolog, few statements are expressed as a statement, with the excep-
tion of the base cases. The questions, generally, consist of many strings
that can be utilized to give the alternative answers. The conclusions,
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 809

on the other hand, usually use only one statement in the predicate body,
i.e., the text to be presented to the user. If any of these are hard to find,
the third search method will be used. Beside rules, the other predicates
that exist in large numbers are facts, questions and conclusions. More-
over, the connections between the rules, questions and the conclusions
must also be collected.
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Relationships in the Set of Rules

The outcome of the reengineering is knowledge, partitioned into rules
and facts, which can be either prestored or user-given, and conclusions
included into different sets. Each of these can be considered to be dis-
tinct sets, thus there will be one set of rules, one set of prestored facts,
and so on. Since, a knowledge base can contain several thousand
rules, the set of rules will be huge and will involve a complex network
of relationships. As a result of this, collecting the rules into a rule set will
have an impact upon the comprehensibility of the rules. The rule set also
contains the relationships between rules and the relationships to facts.
Reengineering can determine the relationships by traversing the net-
work of rules. Almost every rule utilizes another rule and therefore there
is a need to simplify the complex knowledge in the system and, hence, a
complex structure of rules is created during the development of a knowl-
edge base. Rules are built based on the domain expert’s expertise, but
these experts usually express knowledge in terms of facts, and sometimes
rules, but they do not clarify their knowledge in a sense where they are
reusing other rules. The origin of metaknowledge is when the knowledge
engineer transfers the domain knowledge from an expert to a system and,
in so doing, learns how to devise problem-specific rules. Thereby,
the engineer gradually creates a new body of knowledge in his or her
own mind. This knowledge concerns the overall behavior of the system
(Negnevitsky 2002). Thus, the knowledge gained will concern the devel-
opment of the knowledge base, for which different rules will be generated
to facilitate the handling of the production or heuristic rules, e.g., meta-
rules, inferred rules and derived rules. These rules are highly interrelated
to the existing rules in the knowledge base.
Some rules are not really related to the domain problem (Merritt
1989) at all, like, metarules. Metarules are used to direct the problem
solving and to determine how best to solve problems. These metarules
are used when deciding which rules to apply to avoid a conflict within
 810 A. HÅKANSSON AND R. HARTUNG

the reasoning strategy (Jackson 1999). A metarule devises a strategy for

the use of task-specific rules in the system (Negnevitsky 2002) and is,
therefore, dependent on other rules.
Some rules are specially constructed to enable them to be utilized by
many other rules. The most commonly constructed rules are inferred.
Inferred rules are derived from the initial rules and represent the process
of deriving new information from that existing previously (Merritt 1989).
An inferred rule links several different rules, e.g., A ! B, B ! C, which
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

means that A implies B and B implies C, by concluding that rule A

implies rule C., i.e., A ! C. In the inferred rules, the antecedent of the
initial rule appears in the body of the rule. When the relationships
between inferred rules and initial rules are found, it is important that
they are preserved since they are affected by changes to the rule base.
Derived rules, as their name suggests, are rules that are derived from
other rules. They are similar to inferred rules since they involve the pro-
cess of linking new information, however, instead of being inferring, they
are derived from other rules, with the result that the derived rule com-
presses several lines of primitive rules into one new rule. For example,
if D ! A, B and C, then the use of D alone represents a short-cut. The
derived rules may have direct relationships to the rules that produced
them, e.g., to the rules for which they are short cuts. These relationships,
too, are important and must be retained.
As mentioned above, in the rule set, the rules have relationships to
other rules, to facts, both prestored and user-given ones supplied in answer
to the questions, and to conclusions. A relationship in a rule can lead to one
question being posed, but several following ones might need to be asked
also. A question can be used in several rules and will be likely to have many
relationships. Moreover, the majority of the rules are connected to the con-
clusions presented to the end users, and the connections to the facts and
conclusions must be taken into consideration throughout. The search mech-
anism will assemble a complex network of relationships, and handling these
relationships, requires that the search mechanism be able to traverse this
network of rules.

Reengineering for Functionality

Reengineering must operate on the source code that implements the
functionality, by identifying the code. Examples of functionality are the
functions and the predicates that handle the knowledge in the system.
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 811

The functionality is essential for working with the knowledge, e.g., for
using the interpretation engine, performing calculations and for con-
sideration of factors relating to uncertainty.
The interpretation engine may either be an in-built function or be
developed by a knowledge engineer or programmer. The reengineering
procedure collects the functionality for the interpretation engine by
searching the source code. It follows the code and searches for the first
occasion on which the engine invokes any rules. Other functionality is
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

evident when the rules need to perform calculations as they do, for
example, when they need to find an average. In these cases, the reengi-
neering searches for the functionality by searching for and identifying
the rules that invoke the required functionality. An additional type of
functionality is the certainty factor. If certainty factors are used by the
system, the interpreter usually calculates them at the end of a session.
When collecting this functionality, the reengineering procedure must
again search in the source code. Hence, the engineering operates on
the code for the interpretation engine.

Reengineering for Problems of Consistency and Completeness

As mentioned previously, certain concepts must be adhered to if the
reengineering process is to be successful. Before continuing with the dis-
cussion, some previously mentioned concepts must be explained. That is
done in this section, namely, consistency, redundancy, and subsumed and
circular rules Consistency is acquired when a knowledge base has no
conflicting, redundant, subsumed or circular rules. Conflicting rules
are those that, for the same set of data, reach conclusions that are both
true and false at the same time, e.g., concluding that it is true that a dam
site is both large and small. One of these conclusions must be omitted or
overridden, but the reengineering should not make such a decision, the
appropriate course of action is to identify the source of the duplication.
Redundancy occurs when two identical rules exist in the knowledge base.
One of these can be cut out of the knowledge base by the reengineering.
Subsumed refers to the case where one rule contains the same premises
as another, but adds one more premise. When reengineering finds a sub-
sumed rule, it should keep the rule that contains more premises. The
final piece of nomenclature concerns circular rules; if a knowledge base
has circular rules, the reengineering tool will run into an infinite loop,
which must be addressed during the reengineering. The structure of
 812 A. HÅKANSSON AND R. HARTUNG

circular rules must be recognized if one is to be able to avoid the

potential loops.
Completeness means that a rule base has been obtained without any
dead-end rules being included, i.e., problems caused by having an
unreachable premise or being dependent on a non-existent premise.
When a rule base is incomplete the reengineering process would try to
find a missing rule, but the search would fail. The tool works through
the code until it finds the rule corresponding to a premise, but if a prem-
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

ise is lacking, the reengineering tool will be searching for a non-existent

rule. The reengineering tool keeps track of all the rules it has encoun-
tered, allowing a certain time limit for each search, and when this is
exceeded, it concludes that the rule in question is missing. Since the rules
are finite, the system will stop executing the search when all the rules
have been checked out.
The definition of the correctness of a system is that correctness
corresponds to a match between the conclusion produced by the system
and the opinions of the domain experts. Since correctness relies on
human judgment, reengineering cannot make this kind of check.
Graphic modeling is used to make knowledge more accessible, and
experts can use such models to check the rules and facts that are involved
in arriving at a conclusion. If the models are easy to follow and under-
stand, then together with automated tools it will be more straightforward
and easier for the users to judge the consistency, completeness and cor-
rectness of the knowledge base.

PRESENTING THE SETS PRODUCED BY THE REENGINEERING

As mentioned above, the outcome of the reengineering is expressed into
different sets. Presenting the sets needs a means for giving the users a
simpler view of the contents that the reengineering has produced. We
propose using ontology because it is one method used when modeling
knowledge. The term ontology has been used in the AI-community (Gruber
1993). One commonly used definition of ontology is that: ‘‘it is a speci-
fication of a conceptualization.’’ Thus, ontology is a set of definitions
and descriptions of concepts and relationships that exist in a domain.
Ontology can be formulated as a metalevel viewpoint of a set of possible
domain theories (Wielinga et al. 1994). The term ‘‘domain theory’’ is
used in this context to indicate a knowledge base that contains knowl-
edge about a certain domain.
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 813

The many-to-many relationship implies that an ontology can be used

to describe a number of domain theories and, similarly, that several
ontologies can express different viewpoints on the same domain theory.
Furthermore, ontologies can be defined at different levels of abstraction
and can have a recursive structure. This means that a single ontology can
illustrate a viewpoint on another.
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Using Ontology in Knowledge-Based Systems

Ontology can be used to indicate the types of elements in the knowledge
base of a knowledge-based system or as a template for instantiation of
the domain theory. When ontology is used for instantiation, the elements
in the domain theory (i.e., corresponding to the facts in the knowledge
base) are instances of the generic structures defined in the ontology.
The ontology describes the instances in the domain theory. For example,
the concept ‘‘fever object’’ in a medical ontology describes the instances
‘‘fever object (37)’’ (for 37C, i.e., 98.6F) in the domain theory.
It is important to retain the links or mappings between these different
levels of abstraction to ensure the quality of the knowledge base and to
facilitate maintenance. Instead of just storing the instance ‘‘fever object
(37),’’ we keep the link from the ‘‘fever object’’ to the more general con-
cept ‘‘fever’’ and perhaps to a concept at an even higher level of abstrac-
tion. In this way, we can obtain a much deeper understanding of what is
actually in the knowledge base (Håkansson and Widmark 1996).
Ontology is used for defining concepts, properties of concepts and
values of attributes. In a knowledge base, rules can be regarded as a
means by which different pieces of knowledge can be combined to form
a knowledge network. The intentions of the rules are not usually evident
and the execution of rules can be regarded as a kind of ‘‘black-box’’
reasoning, i.e., it is not possible to see the action itself, only the conse-
quences of the execution. Although we think we know the sequence in
which the rules are applied, the consequence of using rules may not be
known until they have been executed. Therefore, the knowledge network
is incomplete and, in particular, is deficient in connections between the
isolated pieces of knowledge. Thus, when the users are to get a grip of the
knowledge base, they usually investigate the entire contents of the base
(Håkansson et al. 2000).
In addition to the complex interaction between them, the facts and
the rules are difficult to explore because of their internal complexity.
 814 A. HÅKANSSON AND R. HARTUNG

The complexity of the production rules can be attributed to the

information contained in the conclusion and within the internal rules,
i.e., the premises-part. The premises-part is usually comprised of rela-
tionships to other rules and facts, and thus constitutes a complex knowl-
edge space. This complexity influences the search in the bases and
affects the information retrieval. The developer must consider the con-
nections between rules and usually these have to be kept in mind and
it is usually important to keep them in mind when modifying the system.
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

If a small number of rules with little internal content are used, the pro-
cessing of the rules is effortless, but generally the processing is time-
consuming and labor intensive.
In a knowledge base, concepts can be applied to rules with the inten-
tion of grasping the interpretation of the rules by adding some semantic
information, i.e., a meaningful concept. The semantics may change the
comprehension of the physical structure of the rules to obtain a concep-
tual knowledge management structure (Håkansson 2004). The users’
mental model may change from being centered around the physical
structures usually forced on the user, to harnessing the users’ own knowl-
edge space. The users can define their own concepts and then utilize and
apply these self-defined concepts to the rules. This would change the way
in which the users conceive of the rules and also relieve their workload
since they would no longer need to cope with the contents of the rules
and learn the syntax. Instead, they would define concepts and apply
them in a conceptual content, without any knowledge of the physical
structure being required. This would imply a change: from displaying
rules in antecedent-consequent syntax (i.e., a rule with an if . . . then part)
into semantics by utilizing appropriately chosen concepts. Thus, the
concept would correspond to the conclusion of the rule by applying a
semantic meaning to the rule, which corresponds to its interpretation
(i.e., the achievement of the rule).
It is preferable for the concept to correspond to a rule used by the
interpreter to solve a task, however, a concept can be applicable to sev-
eral other rules in the knowledge base. This relationship can be utilized
to give the user supplementary support in revealing the relevant infor-
mation concerning that concept. This means that it is possible to apply
a single concept to an overall task concept, and thereby collect the
knowledge related to that concept.
One benefit of using meaningful and informative concepts and of
hiding information that is not of current relevance is that this gives a
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 815

better understanding of complex information spaces and complex knowl-

edge bases. Moreover, if the rules are applied with explanatory concepts,
indicating the contribution of the rules in a certain context, the concepts
can simplify the handling of large information spaces. For instance, this
technique can provide a quicker understanding of a rule’s purpose or its
applicability to other rules without it being necessary to examine the
internal content of the rule. Furthermore, utilizing concepts can facili-
tate clustering of similar rules. Ideally, the correspondence between clus-
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

tered rules is associated with the similarity of the task performed by the
rules. The person who develops the knowledge base decides the relevant
similarity between the rules, and then clusters the rules (Murphy and
Pazzani 1994; Wiratunga and Craw 2000). This clustering is done
according to how the rules handle a certain task. In this way, concepts
can simplify and speed up the search for rules dealing with similar tasks
or topics and, in so doing, decrease redundancy. Moreover, conceptuali-
zation by using clustering can support the definition of concepts on a
higher level of abstraction. Recognizing similar rules at this level may
allow them to be generalized.
In a structured conceptual knowledge base, clustering rules with the
same concept in the knowledge base may assist in finding and reusing
existing and meaningful rules. Concepts can assist searching facilities
in the process of finding relevant and meaningful rules by identifying a
rule utilizing a specified concept. This searching mechanism can also
support the search for related rules, by using a semantic concept corre-
sponding to the subtasks or conclusions of these rules. Searching for
related rules is also useful when the task is to reuse rules.
It is desirable to apply the concepts for classifying the rules into
several individual groups whose members are semantically related. The
possibility of using general concepts for a composed group of rules
allows new rules to be developed and modeled by using existing con-
cepts. When the contents of the knowledge base are unknown, users
who are unfamiliar with expert systems define every rule at the lowest
level without taking advantage of the reusing facility, which was revealed
in a study of shells for knowledge-based systems (Håkansson 2002).
Allowing the visualization of the structures of the rules at different
levels of abstraction can be beneficial for the domain expert when
engaged in reengineering. The concepts or topics should be actively used
as a support for expanding the knowledge base. These should be con-
stantly presented to the developer, who may continuously interact with
 816 A. HÅKANSSON AND R. HARTUNG

the concepts to avoid problems arising, e.g., with verification. The con-
cepts and their relationships need to be continuously updated as the
knowledge base changes.

PRESENTING THE OUTCOME OF REENGINEERING

IN UML DIAGRAMS
The outcome of the reengineering tool is presented in a manner that is
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

comprehensible for the engineer, facilitating the maintenance of the system

and the reuse of the knowledge. Nevertheless, the use of the reengineering
approach, i.e., using keywords, the syntactic form of rules and=or a search
for common predicates, the knowledge base should contain the rules
in such manner that they are comprehensive. The ontology is applied to
rules, facts and relationships, which are then used for visualization.
When a graphic representation is required, UML diagrams can be
used to present knowledge, such as rules, facts, conclusions and reason-
ing strategies in KBSs, as has been shown in some references (Håkansson
2001, 2003), however in this article, the UML diagrams are used to
present the outcome of the reengineering.
By combining the first and second approached discussed above, i.e.,
the use of a keyword with the antecedent-consequent approach, the
visualization of the structure becomes fairly straightforward. Both of
these uses a structure, which can be applied in a diagram similar to
the sequence diagram of UML, see Figure 2. The keywords, like rules
and facts, are used with the name of the rules, facts and with the
conclusion. Furthermore, the structure of the rules is employed in the
diagrams.
In the example presented in Figure 2, the engineering operates on
rule number 32 with the ‘‘recent large object rule.’’ This is used as
ontology for the dam site size with recent large object. Within that rule,
another rule is implemented, that of ‘‘maps large object.’’ It also incor-
porates facts such as ‘‘environment,’’ indicating an environment that is
tropical climate, the answer ‘‘Yes’’ to the question ‘‘map tools,’’ which
means that map tools exists, and not the answer ‘‘Modern topographical
maps’’ to the question ‘‘Map tools.’’ Connected to this rule is the con-
clusion ‘‘Recent large text.’’ If a rule has been investigated, it can be
folded into a package, which is a feature of UML. See ‘‘recent large
object’’ in the figure. Inside this package, the internal content of rule
is represented.
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 817
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Figure 2. Sequence diagram for illustrating the rule.

If a user is to be able to grasp the outcome of the reengineering, the

tool must generate diagrams to answer specific questions posed by the
user. For example, to reveal how a specified conclusion can be obtained
from the rules. The diagrams provide a graphic view of the answers.
The relationships between the rules, together with the order that the
system invoked the rules, are presented along a lifeline. This lifeline
illustrates the order with arrows, presenting the rules, the prestored facts
and the user-given facts. At the end of the lifeline, the conclusion is
presented, in this case, the ‘‘Recent large text’’ shown in Figure 2. In this
example, the two conclusions that can be obtained are in the package
‘‘maps large object rule,’’ which is not shown in this figure, and the
conclusion displayed at the end of the lifeline.
The sequence diagram handles the relationships in the rules, but we
also need to focus on the data used to reach conclusions. The rules, facts
and relationships are presented in a collaboration diagram to illustrate
the inputs used to obtain a particular output, see Figure 3. This collab-
oration diagram illustrates the same knowledge as the sequence diagram
in Figure 2, but in this diagram, drawn from the interpretation of the sys-
tem, the answers to the questions are at the beginning of the diagram.
 818 A. HÅKANSSON AND R. HARTUNG
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Figure 3. Collaboration diagram for the rule.

This is useful for testing the knowledge base to validate it and for
verification.
The user-given answers are collected from the reengineering of facts.
The answers used in a specific rule are distinguished and set as inputs or
calls to the diagram. In this example, there is a call to the rule ‘‘recent
large object’’ and the data are ‘‘tropical climate,’’ ‘‘map tools’’ and
‘‘not modern topographical maps.’’ These are used as values for the facts
(see check answers in the figure) ‘‘environment’’ is ‘‘tropical climate,’’
‘‘map tools’’ is ‘‘yes’’ and ‘‘map tools’’ is not ‘‘modern topographical
maps.’’ When the rule ‘‘maps large oject’’ is checked together with the
facts, the output is produced, i.e., the text ‘‘recent large.’’ These inputs
and the output can be used when testing the knowledge base.
In addition, all kinds of relationships between the sets of rules or
inputs that produce two conclusions will be presented in a sequence diagram.
However, to illustrate this more clearly, we use an UML object diagram.
Figure 4 presents the connections between the questions, rules and
conclusions using object diagrams. This example illustrates the same rule
as was presented in Figure 2, revealing how an object diagram presents the
connections between different parts more clearly than a sequence diagram.
The user-given facts are presented to the left of the figure, the rules and
prestored facts in the middle and the conclusions to the right.

Testing by Using Test Cases

Testing is often associated with verification and validation; however, its
primary purpose is to ensure correctness and completeness and to check
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 819
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Figure 4. Object diagram for the rule.

the quality of the system. It is the process of executing the system with
the intention of finding errors or bugs in the software. Unit testing and
software integration testing can be used to test the source code (IPL
2006). Unit testing is testing each unit to verify that it has been correctly
implemented and software integration testing is the testing of progres-
sively larger groups of software components.
For testing systems, test cases are built. A test case is used to specify
how to test the implementation of a particular requirement or a design
decision and to determine the criteria to be used to define success. We
use test cases to test the individual units of software contained within
the knowledge base. The set of test cases specifies the exact process to
be followed, which is conducted by the test cases. The diagrams in where
a series of inputs give a specific output specify the test cases. This is like
designing units of code from descriptions.

Test Cases in Knowledge-Based Systems

Test cases are adopted in knowledge-based systems to ensure the
correctness of the knowledge base. This is especially important when
the rules are modified because a modification may involve many rules.
The rule interactions are hard to detect and to correct, which is
why the test cases ensure that any changes that affect existing knowledge
are detected. The test cases are built through the process of reverse
engineering.
A collaboration diagram for rules illustrates the inputs, sequence of
executing the rules and the output. We use these diagrams to generate
test cases. Starting from the inputs, the diagrams are ‘walked through’,
i.e., a process involving the content of the rules, and, during this process,
code is produced to generate a test case. All the diagrams are processed
 820 A. HÅKANSSON AND R. HARTUNG

to build a complete set of test cases. One can argue about the complete-
ness of the test cases, but the assumption has to be made that the knowl-
edge base is as correct as possible when we apply reengineering to it. If
the knowledge base is correct, the set of test cases should be complete for
the knowledge base.
The collected test cases are put in a directory for use when executing
all the cases. Each execution of a test case is noted in a test log that will,
therefore, contain information of all the test cases that have been exe-
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

cuted and any errors obtained. The errors are the outcome of the
execution of the test cases and the result of comparing the test case on
the modified rules with the original rules.
The next step is to make the test-case generator for the rule engine
run automatically. After a change has been made to the knowledge base,
the developer can run all the test cases to ensure that the rules produce
the same output with the same inputs when using the modified rule set.
By using these test cases, the rules are detected and verified either as
being correct or as producing errors. There are two different kinds of
failure that test cases can be subject to, either some of the rules have
been affected by the modification made, in which case the test case error
indicates that the system is not correct, or the failure to produce the
same result is indicative of the changes being correct, and the old result
no longer correct for the modified system. In the first instance, the reen-
gineering process can be applied to produce new diagrams showing how
the incorrect result was obtained and, after correcting the problem, the
tests can be rerun until the errors are removed. In the second instance,
however, a new test case needs to be generated.

CONCLUSIONS AND FURTHER WORK

Some of the problems with current KBSs and expert systems are associa-
ted with outdated theories and poor documentation. This is complicated
by the fact that not all expert systems have a modular structure; some are
developed without applying architecture, and other lack of structured
code into different modules.
In this article, we have shown that reverse engineering can be used for
knowledge-based systems. Reengineering has been applied to problems
related to knowledge, relationships and consistency. The first and sim-
plest approach is searching for rules using a keyword. This approach
has been tested in the KANAL-system, an intelligent rule editor system
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 821

used to support a domain expert during the development of knowledge-

based systems (Håkansson et al. 2000). The second approach is searching
for the syntactic form of the rules, which has a pattern of antecedent-
consequent pattern. The third and most difficult approach is to identify
rules from the number of occurrences of predicates with a certain name.
We have presented the results of the reengineering of the first and second
approaches visually. The examples illustrated in this article are taken
from an expert system, EIA-system that was developed to provide advis-
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

ory and educational support for end users using the environmental
impact assessment method for hydropower development and river regu-
lation in tropical environments within developing countries (Håkansson
2004:2)
The outcome of the reengineering has been presented by using
ontology in graphical representations, such as UML sequential
diagrams, collaboration diagrams and object diagrams to be enable the
knowledge to be modified. The concepts in the ontology correspond to
the rules and facts; the relationships between concepts correspond to
the relationships between the rules and facts. Through the sequence dia-
gram we can show the relationships between rules and facts in a rule set
and relate these to the conclusions. In the collaboration diagram we
show the inputs from the user that are needed by a rule set for it to be
executed correctly and, finally, the object diagram illustrates the inputs,
i.e., the user-given facts, facts stored in the database, rules and conclu-
sions. However, we have not yet worked with the application of reengin-
eering to the source code handling the interpretation engine. It has
previously been shown that the UML activity diagrams and state-chart
diagrams can be used to illustrate source code in KBSs (Håkansson
2001), which explains why they also might be suitable for illustrating
the outcome of the reengineering of the functionality.
Moreover, testing has been applied to diagrams to develop test cases.
These test cases are used in the modification mode to check the correct-
ness, and to check for consistency and completeness. This will assure the
quality of the knowledge base after changing the contents.
Further work is needed to extend our reengineering tool to enable it
to handle reverse engineering for the source code. The outcome from this
will also be illustrated in diagrams. As long as the predicates have a pat-
tern of antecedent-consequent, the UML diagrams can be used. If not,
other diagrams must be investigated and tested for their ability to visually
present the outcomes. Moreover, we would like to distinguish between
 822 A. HÅKANSSON AND R. HARTUNG

the different kinds of rules, i.e., heuristics, metarules, inferred and

derived rules because these have been implemented for different
purposes.
Reengineering operates on rule-based systems, but it can easily be
expanded to handle knowledge representations such as fuzzy rules and
frames. Moreover, the principle of reengineering can be extended to deal
with neural networks and hybrid representation.
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

REFERENCES
Antonini, P., Benedusi, P., Cantone, G., and Cimitile, A. 1987. Maintenance and
reverse engineering: Low level design documents production and improve-
ment. Proc. conference on software maintenance, IEEE, 91–100.
Babiker, E., Simmons, D., Shannon, R., and Ellis, N. 1997. A model for reengi-
neering legacy expert systems to object-oriented architecture. Expert Systems
with Applications 12(3): 363–371.
Benedusi, P., Cimitile, A., and De Carlini, U. 1992. Reverse engineering pro-
cesses, design document production, and structure charts. Journal of Systems
and Software 19(3): 225–245.
Booch, G., Rumbaugh, J., and Jacobson, I. 1999. The unified modeling language
user guide. New York: Addison Wesley Longman, Inc.
Carriere, J., O’Brian, L., and Verhoef, C. 2003. Reconstruction software architec-
ture. In Software architecture in practice (2nd edition), edited by L. Bass,
P. Clements, and R. Kazman. ISBN 0-321-15495-9, Boston: Addison-Wesley.
Chikofsky, E. J. and Cross, J. H. 1990. Reverse engineering and design recovery:
A taxonomy. Software, IEEE 7(1), ISSN: 0740-7459, pp. 13–17.
Cimitile, A. and De Carlini, U. 1991. Reverse engineering: Algorithms for
Program Graph Production. Software—Practice and Experience 21(5):
519–537.
Durkin, J. 1994. Expert system design and development. Prentice Hall Inter-
national Editions. New Jersey: MacMillian Publishing Company.
Gall, H., Klösch, R., and Mittermeir, R. 1996. Using domain knowledge to
improve reverse engineering. International Journal on Software Engineering
and Knowledge Engineering, World-Scientific Publishing, 6(3): 477–505.
Gruber, T. B. 1993. A translation approach to portable ontologies. Knowledge
Acquisition 5(2): 199–220.
Håkansson, A. 2001. UML as an approach to Modeling Knowledge in Rule-
based Systems. (ES2001) The Twenty-first SGES International Conference
on Knowledge Based Systems and Applied Artificial Intelligence. Peterhouse
College, Cambridge, UK; December 10th–12th.
 USING REENGINEERING FOR KNOWLEDGE-BASED SYSTEMS 823

Håkansson, A. 2002. Comparing two knowledge based system shells using usabil-
ity testing. Technical report. TRITA-NA-, NADA, KTH, Stockholm,
March, IPLab-199.
Håkansson, A. 2003. Supporting Illustration and Modification of the Reasoning
Strategy by Visualisation. (SCAI’03) The Eighth Scandinavian Conference
on Artificial Intelligence, Bergen, Norway, November 2th–4th.
Håkansson, A. 2004. An expert system for the environment impact assessment
method. Research Report, ACTA, Sweden 2004:1: Department of Information
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Science, Division of Computer Science, University of Uppsala, Sweden.

ISSN 1403–7572, p. 2.
Håkansson, A. 2004. Visual Conceptualisation for knowledge acquisition in
knowledge based systems. In Expert update (SGAI) specialist group on
artificial intelligence, edited by Frans Coenen. 7(1), ISSN 1465–4091.
Håkansson, A. and Hartung, R. 2006. Reengineering for Knowledge in
Knowledge Based Systems. (KES2006) The Tenth International Conference
on Knowledge-Based & Intelligent Information & Engineering Systems,
Bournemouth, UK, October 9th–11th.
Håkansson, A. and Widmark, A. 1996. The KANAL system—a Tool for Knowledge
Acquisition. Masters Thesis. Computing Science, Uppsala University,
Sweden, No. 28=96.
Håkansson, A., Widmark, A., and Edman, A. 2000. The KANAL-system, an
intelligent rule editor supporting the knowledge acquisition process.
(SAIS2000) The Swedish Artificial Intelligence Society Annual Workshop
2000. Linköping, Sweden.
IPL Information Processing Ltd. Software Testing White Papers and Newsletter.
http://www.qcsltd.com/papers/pubs.htm (2006-12-06).
Jackson, P. 1999. Introduction to expert systems. London: Addison-Wesley
Longman Limited. ISBN 0-201-87686-8.
Jacobson, I. Rumbaugh, J., and Booch, G. 1998. The unified modeling language
user guide. Reading, MA: Addison-Wesley.
Merritt, D. 1989. Building expert systems in prolog. New York: Springer-Verlag,
ISBN 0-387-97016-9.
Mittermeir, R., Rauner-Reithmayer, D., Taschwer, M., Gall, H., and Weidl, J.
1998. CORET object-oriented re-structuring. CORET methodology and
tool. In CORET methodology and tool 1 Klagenfurt, Wien, edited by
Mittermeir, et al. (Hrsg.): Inst. für Informatik-Systeme 26. November.
Müller, H., Orgun, M., Tilley, S., and Uhl, J. 1993. A reverse engineering
approach to subsystem structure identification. Journal of Software Mainte-
nance Research and Practice 5(4): 181–204.
Murphy, P. and Pazzani, M. 1994. Revision of Production System Rule-Bases,
Proceedings of the 11th International Conference on Machine Learning, New
Brunswick, NJ, pp. 199–207.
 824 A. HÅKANSSON AND R. HARTUNG

Negnevitsky, M. 2002. Artificial intelligence—a guide to intelligent systems.

London: Addison-Wesley, Pearson Education ISBN 0201-71159-1.
Polat, F. and Guvenir, H. A. 1993. UVT: A unification-based tool for knowledge base
verification. IEEE Expert: Intelligent Systems and Their Applications, 8(3): 69–75.
Rugaber, S. 2000. The use of domain knowledge in program understanding.
International Journal on Annals of Software Engineering 9: 143–192.
Rugaber, S., Shikano, T., and Stirewalt, K. 1992. Program comprehension
for reverse engineering. International Journal on AAAI Workshop on AI and
Downloaded by [University of Illinois Chicago] at 18:02 01 December 2014

Automated Program Understanding, San Jose, California, pp. 106–110.

Rumbaugh, J., Jacobson, I., and Booch, G. 1999. The unified modeling language –
reference manual. London: Addison-Wesley Longman Inc.
Wielinga et al. 1994. Framework and Formalism for Expressing Ontologies. ESPRIT
Project 8145 KACTUS, Deliverable DO1b.1, University of Amsterdam.
Wiratunga, N. and Craw, S. 2000. Informed selection of training examples for
knowledge refinement. Proceedings of the EKAW2000, pp. 233–248.