This document discusses adapting principles of software engineering design to the design and analysis of domain descriptions for reasoning about actions. Specifically, it explores how the informal concepts of cohesion and coupling from software engineering can provide criteria for evaluating domain description modules. Cohesion measures how related elements are within a module, while coupling measures interdependence between modules - both aim to minimize interactions and dependencies between modules. The document proposes organizing a domain description into modules for effects, non-effects, executabilities, inexecutabilities, and state constraints based on these software engineering principles.

1. Cohesion, coupling and the meta-theory of actions
Andreas Herzig and Ivan Varzinczak
IRIT – Universit´ Paul Sabatier
e
118 route de Narbonne – 31062 Toulouse Cedex 04 France
¡
e-mail: herzig,ivan @irit.fr ¢
Abstract With this in mind, one can see the specification of domain
descriptions as a task similar to project development in soft-
In this work we recast some design principles com- ware engineering: Item 4 above is what has been called elab-
monly used in software engineering and adapt them oration tolerance [McCarthy, 1988]. In this way a represen-
to the design and analysis of domain descriptions tation is elaboration tolerant to the extent that the effort re-
in reasoning about actions. We show how the infor- quired to add new information (a new action or effect) to the
mal requirements of cohesion and coupling can be representation is proportional to the complexity of that infor-
turned into consistency tests of several different ar- mation [Shanahan, 1997]. Items 1, 2 and 3 reflect the concept
rangements of modules. This gives us new criteria of modularity, which means that different modules have no
for domain description evaluation and clarifies the elements in common. Such a notion of modularity is going to
link between software and knowledge engineering lead us along the present work.
in what concerns the meta-theory of actions.
This paper is an elaboration of the results we have pre-
sented in [Herzig and Varzinczak, 2004]. Here we pursue the
1 Introduction following plan: in Section 2 we recall some important con-
cepts from software engineering; after discussing the ontol-
Among the principles of the object-oriented paradigm are the ogy of dynamic domains (Section 3) we apply the concepts
following: of Section 2 to the design of domain descriptions (Sections 4
1. Work with modules (or components, functions, etc.). and 5) making a step towards formal criteria for domain de-
scription evaluation. In Section 6 we present the main results
2. Minimize interactions between such modules. that follow from our approach, and before concluding we ad-
3. Organize the modules into well-defined layers to help dress related work found in the literature on this subject.
minimize interactions. The goal is to have components
of one layer using only components from immediate 2 Some principles of software engineering
neighbors, wherever possible. One of the first steps in software development is that of ab-
4. Anticipate what kind of extensions or modifications straction. Abstraction consists mainly in rendering lower-
might be made in the future, and support this at design level details invisible to upper levels in order to facilitate the
time so that one can extend the system with minimal dis- understanding and design of complex systems. As an exam-
ruption later. ple, a specification of a data or knowledge base query does
not need to take into account the algorithmic process that will
There seems to be an agreement that such principles for be carried out in order to answer the query.
object-oriented programming or design are the same as for In parallel to abstraction, one of the most important guide-
knowledge representation. To witness, the design of domain lines in project design is that of modularity: dividing the soft-
descriptions in reasoning about actions has much more in ware into modules, based on their functionality or on the simi-
common with software engineering than one might think: in larity of the information they handle. This means that instead
the same way as for software projects, one can talk about con- of having a “jack of all trades” program, it is preferable to
sistency, evolution and correctness of domain descriptions. split it up into specialized subprograms. For instance, a pro-
All the principles above can be applied to the design of do- gram made of a module for querying a database and a module
main descriptions, too. We argue that a good domain descrip- for checking its integrity is more modular than a single mod-
tion should be one whose consistency check and maintenance ule that does these two tasks at the same time.
complexities are minimized, so that any further modification Among the major benefits of modular systems are reusabil-
is localized, with a bounded scope. ity, scalability and better management of complexity.
£
Supported by a fellowship from the government of the F EDER - There is more than one way to split up a program. One
ATIVE R EPUBLIC OF B RAZIL. Grant: CAPES BEX 1389/01-7. of the most used techniques is that of forcing functional in-

2. dependence of its modules. One ensures functional indepen- is illustrated by Figure 1, where we can see the relationship
dence in a project by defining modules with only one pur- among the different types of entities.
pose and “aversion” to excessive interaction with other mod- A domain description consists of a description of effects
ules [Pressman, 1992]. of actions, their non-effects, executabilities, inexecutabilities
Among the criteria commonly used for evaluating func- and also state constraints that do not depend on any particular
tional independence of modules (and thus how modular a action.
piece of software is) are the informal notions of cohesion and
domain description
coupling. ¤ ¤ ¤¥ ¤¥ ¦§
¦§ § §
¤ ¤ ¥ ¦ § §
¤ ¥ ¦ §
Cohesion is how closely related pieces of a single compo- ¤ ¤ ¤ ¥ ¦ § § §
nent are to each other. A module is cohesive when at the high effects non-effects exec. inexec. state constraints
level of abstraction it does only a single task. The more a
module is focused on a precise goal the more it is cohesive. Figure 1: “Class diagram” of modules in designing domain descrip-
A highly cohesive module will be simpler to understand, tions. Edges represent has-a relations.
having to do only a single task, while a lowly cohesive mod-
ule, performing so many tasks, will be difficult to understand. Among the effects of actions, we can distinguish direct ef-
It is difficult to reuse a task-overloaded module, while a fects and indirect effects (ramifications).
highly cohesive module is simpler to reuse and to extend. Non-effects of actions are related with the frame prob-
Coupling is the interdependency between a method and the lem [McCarthy and Hayes, 1969], and indirect effects with
environment (other methods, objects and classes). Low cou- the ramification problem [Finger, 1987]. In this work we
pling means to keep dependencies (communication, informa- abstract from these problems and assume we have a con-
tion sharing) between components at a minimum. sequence relation powerful enough to derive the intended
A design that has low coupling is more amenable to conclusions. We suppose given a ‘doped’ consequence re-
change, since it reduces the probability of changes cascading lation , which encapsulates some traditional approach in
©¨
and affecting a larger part of the system. the literature (e.g., [Schubert, 1990; Lin, 1995; McCain and
Turner, 1995]), with which all intended frame axioms and in-
Unanimously in object-oriented development, the best way direct effects can be derived, and we use it henceforth. As
to design a software is to have low coupling and high cohe- examples we have
sion. We sum this up in two informal design principles:
loaded ©
¨ loaded do wait !
P1. Maximal cohesion: Every module should be conceived
in such a way that it is maximally cohesive. (i.e., waiting does not change the status of loaded) and
P2. Minimal coupling: All modules should be conceived in walking %
$ #
such a way that they minimize coupling. walking alive )'
(
©¨
0
walking do shoot 3%1
$ #
alive do shoot
0
!1
2
3 Natural modules in domain descriptions Hence shooting has the indirect effect that the victim will no
Like in object-oriented programming, in describing a domain longer be walking.
different entities should be separated in different modules. We use small letters to denote variables, and capital letters
Moreover, each module should be conceived in such a way to denote constant symbols. Free variables are supposed to
that it has no direct access to the contents of the others. In be universally quantified.
reasoning about actions, accessing a module means using it To sum it up, our main concern here will be with direct
to perform reasoning tasks like prediction, postdiction, plan- effects (henceforth effects), inexecutabilities, executabilities
ning and others. This amounts to using its logical formulas and state constraints. We introduce this in what follows.
in inferences. In this section we establish the ontology of do- Effect laws Logical frameworks for reasoning about ac-
main descriptions and present the way we arrange in different tions contain expressions linking actions and their effects. We
modules the axioms commonly used to describe them. suppose that such effects might be conditional, and thus get a
third component of such axioms. An effect law for action is 4
Every domain description contains a representation of ac- of the form
tion effects. We call effect laws formulas relating an action
to its effects. Statements of conditions under which an ac- Poss DCA@97)165
B ( 8 ( 4 do 3! 65
4
tion cannot be executed are called inexecutability laws. Ex- where is a simple state formula about situation , and
@8
ecutability laws in turn stipulate the context where an action do
DB is a simple state formula about situation do
!165
4 . 165
4
is guaranteed to be executable. Finally, state constraints are A simple state formula about a situation term contains no E
formulas that do not mention actions and express constraints Poss-predicate and no situation terms other than [Lin, 1995]. E
that must hold in every possible state. These are our four in- An example of effect law is
gredients that we introduce more formally in the sequel. Poss shoot loaded alive do shoot
7)
( A
(
0
F!31
If we think of a domain description as a software appli- saying that whenever shoot is executable and the gun is
cation, we can imagine its organization in an object-oriented loaded then after shooting the turkey is dead. Another one
view and attempt to have a kind of class diagram for it. This is Poss tease walking do tease : the result of teas-
G1
( 3
ing is that the turkey starts walking.

3. Inexecutability laws The design of domain descriptions For parsimony’s sake, we define , csqqcS
V T S r p T p ubtW
a Y X
must also provide a way to express qualifications of actions, , and
wb`vr
V a Y X W . We suppose all these sets are
ydcvxDdcS
V Y a S r p Y a
i.e., conditions under which an action cannot be executed consistent.
at all. An inexecutability law for action is of the form 4 A domain description

is a tuple of the form €
.
i„d6dc!ƒb`R!‚cS
… g h g f Y a S a Y X W T
( H '@8
0
Poss 165
4
Once the information contained in a module is not mixed
where is a simple state formula about .
'@8
with others’, it can be expected that undesirable side effects
For example, HasGun 0
Poss shoot states that
I
(
0
due to further modifications are less likely to propagate to
shoot cannot be executed if the agent has no gun. other parts of the domain description. The same thing can be
State constraints (alias domain constraints) Frameworks obtained for the consistency check if beyond of being sepa-
allowing for indirect effects make use of formulas that link rated the modules are designed in such a way that their inter-
invariant propositions about the world. Such formulas char- action is minimized. This is what we address in this section.
acterize the set of possible states. A state constraint is a sim- As we have seen, in software engineering functional inde-
ple state formula about the situation term that is consistent.
pendence is evaluated by means of two criteria: cohesion, a
An example is walking alive , saying that if a turkey
)
( '
criterion for evaluating the relative functional strength of a
is walking, then it must be alive [Thielscher, 1995]. module, and coupling, an assessment of relative interdepen-
dence among different modules. Both these notions are quite
Executability laws With only state constraints and effect informal, even in software engineering, and cannot be mea-
laws one cannot guarantee that action shoot is executable if sured in an objective way.
the agent has a gun. An executability law for action is of 4 Here we explore these concepts when applied to domain
the form P'@8
( Poss , where is a simple state
65
4 @8
descriptions and show how the informal requirements of soft-
formula about . For instance HasGun
Poss shoot @
( 1
ware engineering can be turned into tests of consistency of
says that shooting can be executed whenever the agent has a several different arrangements of modules.
gun, and Poss tease that the turkey can always be teased.
1
Whereas all the extant approaches in the literature that al- 4 Cohesion
low for indirect effects of actions contain state constraints
and effect laws, the status of executability laws is less con- Normally cohesion comes with modularization, and its eval-
sensual: some authors [Schubert, 1990; Doherty et al., 1996; uation depends mainly on the entities that one takes into ac-
McCain and Turner, 1995; Thielscher, 1995] more or less tac- count when describing a domain.
itly consider that executability laws should not be made ex- In talking about sets of logical formulas we take cohesion
plicit but rather inferred by the reasoning mechanism. Others as how simple or well-defined a logical module is, consider-
[Lin, 1995; Zhang et al., 2002] have executability laws as first ing the different types of formulas that can be derived from it.
class objects one can reason about. We thus refine our first design principle:
We nevertheless would like to point out that maximizing P1’. The less types of laws a given module entails alone, the
executability, as usually done in the literature, is not always more cohesive it is.
intuitive: suppose we know that if we have the ignition key, As an example consider the following module:
the tank is full, , and the battery tension is beyond 10V,
RRQ
Q Q †
then the car (necessarily) will start. Suppose we also know
0
HasGun ( ) '
0
Poss shoot
F1
that if the tension is below 8V, then the car will not start. What HasGun A'
( Poss shoot
1
‡
should we conclude in situations where we know that the ten- From such a set alone one can derive both HasGun 0
( D '
sion is 9V? Maximizing executabilities makes us infer that it 0
Poss shoot and HasGun
Poss shoot , which are
1
A
( 1
will start, but such reasoning is not what we want if we would formulas of two different kinds. In this case we say that such a
like to be sure that all possible executions lead to the goal. set is a lowly cohesive module, for alone it functions to derive
It seems a matter of debate whether one can always do executabilities and inexecutabilities. A better approach would
without executabilities. We think that in several domains one be to decompose such a module into the following ones:
wants to explicitly state under which conditions a given ac-
tion is guaranteed to be executable, such as that a robot should ˆtW
a Y X shoot p
0
HasGun A
(
0
Poss shoot
never get stuck and should always be able to execute a move shoot HasGun
dcS
Y a Poss shoot p ( H '
1
action. In any case, allowing for executability laws gives us
Total cohesion is not always easy to achieve. Suppose, for
more flexibility and expressive power.
instance, a hypothetical situation in which we reason about
Domain descriptions Given the four types of entities de- the effects of drinking a cup of coffee:
”
fined above, we arrange them in the following way: for a Poss drink )1
(
given action , 4 is the set of its effect laws,
IUS
V T is the `b`W
V a Y X ’
sugar happy do drink )
( F3
set of its inexecutability laws, and is the set of its ex- edcS
V Y a T US drink ‰‘‘ p
Poss drink )1
(
‘‘•
ecutability laws. denotes the set of all state constraints
g ih %f
g
salt happy do drink )
(
0
31
–
of a given domain. Thus, , and T , for each
cS V V dUS
Y a V b`RW
a Y X ‘‘“ ‘‘
action , and
4 gare the natural modules we consider here
ih %f
g Then, drink entails sugar
T cS salt Poss drink . F '
— H3
(
0
1
in designing a domain description. This means that from drink alone we do not get only effect T cS