Cohesion, Coupling and the Meta-theory of Actions
Upcoming SlideShare
Loading in...5
×
 

Cohesion, Coupling and the Meta-theory of Actions

on

  • 781 views

IJCAI'05 paper

IJCAI'05 paper

Statistics

Views

Total Views
781
Views on SlideShare
781
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cohesion, Coupling and the Meta-theory of Actions Cohesion, Coupling and the Meta-theory of Actions Document Transcript

  • 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-
  • 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.
  • Inexecutability laws The design of domain descriptions For parsimony’s sake, we define , csqqcS V T S r p T p ubt&W 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 ˆt&W 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
  • † laws but also inexecutability laws. Therefore drink is not T cS walking ) (   alive & '   x{i„df p r g h g as cohesive as one might have expected. dead | ) '  0 alive    ‡ One step towards augmenting cohesion of a module of ef- Observe that to derive the domain constraint walking ( } '  fect laws can be by completely specifying the preconditions 0 dead one only needs    , i.e., no other module is re- r ih %f g g of effects of actions. For example, the weaker effect laws quired for that. On the other hand, to conclude dead } (   ” Poss drink  ( )   0 Poss tease one needs both  and    . ~ih %f r g g tb`RW r a Y X ’ sugar salt d —   0 A! ' (   happy do drink   F!     Totally decoupled descriptions are not common in appli- ™cS ˜ T drink ‰‘‘ p ‘‘• cations of real interest. For the example above, it seems to Poss drink  ( )   – be impossible to diminish the interaction between and ~e„df r g h g salt sugar %' —   0 A! ' (   0 happy do drink   3    ‘‘“ r bt&W ‘ a Y X ‘ without abandoning the concept of state constraints. guarantee a higher cohesion of module ˜ in comparison On the other hand, if in our example contained ydUS r Y a T cS drink to that of drink . T US Poss tease , things would be different: in this case, with     `bt&W r a Y X one would be able to infer the state constraint alive ,    By the definition of , it is easy to see that from the e„df g h g but such a law cannot be derived from alone. A higher {ih %f r g g state constraints we can derive formulas of any type, so g ih %f g degree of interaction between this set and the others is nec- is by nature a lowly cohesive module. essary in order to do that. In such a case one would say that We are thus interested in refining even more our principle there is a high coupling among ’s modules. r € of high cohesion P1’ by the following ones: The principle of minimal coupling P2’ can be refined in P1’-1. If @e©dbt&W    8 ¨ a Y X , then @e©gf    8 ¨ . two more specific design principles: P1’-2. If ( x'@e©db`&W    8 ¨ a Y X Poss 165    4 , then ( x@e©gf    8 ¨ P2’-1. No implicit inexecutability laws: Poss  65   4 . if Poss ( , then H '@©€€   8 ¨ 0 165    4 P1’-3. If @e©‚dcS    8 ¨ Y a , then '@e©If    8 ¨ . ( Poss ) '@e©i„dƒbt&W   8 ¨ g h g f  a Y X 0 165    4 P1’-4. If v@e©hdcS (    8 ¨ Y a 0 Poss 16    4 , then i@e©gf (    8 ¨ P2’-2. No implicit state constraints: Poss 0 j    4 . if , then  '@©€€   8 ¨ . '@zp gih %f    8 ¨ g g P1’-5. If ©hdUS ¨ Y a Poss Dlc@9kcj  B (    8  (    4 do !3165      4 , then ©gf ¨ Poss DCA@97A16  B (    8  (    4 do 3! 65     4 . P2’-2 is a useful feature of descriptions: beyond being a reasonable principle of design that helps avoiding mistakes, P1’-6. If @e©mcS    8 ¨ T , then @e©gf    8 ¨ . it clearly restricts the search space, and thus makes reasoning P1’-7. If ( n@e©mcS    8 ¨ T Poss 165    4 , then ( o '@e©If   8 ¨ easier. To witness, if satisfies P2’-2, then its consistency € Poss  65   4 . amounts to that of : g ih %f g P1’-8. If ( x'@e©pUS    8 ¨ T 0 Poss 165    4 , then ( x@e©gf    8 ¨ Theorem 5.1 If € has no implicit state constraints, then Poss 0 j    4 . ‚ e©n€ ¨ iff gxp gi„df Q ‚ ¨ g h g All these principles say is that a formula of a given type entailed by a module of a different type must be a theorem of 5.1 No implicit inexecutability laws the logic. Consider the following domain description t ƒ€ : ” 5 Coupling ’ Poss tease  )1 (   walking do tease   F3     As we have seen, coupling evaluates how much a module is UcS p t T ‰ Poss shoot  ) (   • – tied to or dependent upon other modules. We take as coupling loaded  0 A (   alive do shoot   33     of two or more sets of different types of action laws how much “  interaction among them is needed to derive a formula of a c„ih %)i„cbdU„Uwb`RW p t g g f  f p t Y a S p t a Y X walking )' (   alive F    given type. Interaction here means sharing logical formulas. From Poss tease walking do tease  H (     !1    it follows with Now we refine our second design principle: that Poss tease i„df t g h g alive do tease  ( H     31    , i.e., in every P2’. The less new consequences two or several modules situation, after teasing the turkey is alive: have, the less coupled they are. ©™t e„d{…cS ¨ g h g f  t T Poss tease  )1 (   alive do tease   31    (The new consequences of modules and are those r sq t uq consequences of that are not consequences neitherq v wr q t Now as alive ©™P€ ¨ t alive do tease 0 , the sta- ( †   0   !1    ofr pq nor of alone.) t uq tus of fluent alive is not modified by the tease action, For instance, consider the domain description : r w€ and we have t ih %F t US g g f Poss T alive  x©¨ d1b‡ yˆ5 —     4 ‡ E 0 )3' (    ” alive do  0 alive do &!1b‡ yˆ5 —      4 ‡ E . From this it fol-   33ˆ‡ iˆ‰       4 ‡ E ’ Poss tease  )1 (   walking do tease   F3     lows alive 0 ) (   Poss tease , i.e., the turkey can- 0 ©™P€ ¨ t     T cS r p Poss shoot  ) (   • not be teased if it is dead. But alive t i„d t b`RW g h g f a Y X ©¨Š 0 H (   ‰ loaded  0 A (   alive do shoot   33     – 0 Poss tease , hence Principle P2’-1 is violated. The for-     “  mula alive 0 Poss tease is an example of what we H' (   0  1   x`bt&W p r a Y X 0 alive A (   0 Poss tease  f zxydU1ˆ p r Y a S     call an implicit inexecutability law.
  • In the literature, such laws are also known as implicit qual- Checking whether a domain description satisfies Princi- ifications [Ginsberg and Smith, 1988], and it has been argued ple P2’-2 can be made with little adaptation of the material that it is a positive feature of reasoning about actions frame- on the subject present in the literature [Zhang et al., 2002; works to leave them implicit and provide mechanisms for in- Lang et al., 2003; Herzig and Varzinczak, 2004]. We do not ferring them [Lin, 1995; Thielscher, 1995]. The other way deepen into further details here, and just present the main re- round, one might argue as well that implicit qualifications in- sults that we obtain when considering descriptions that satisfy dicate that the domain has not been described in an adequate the design principles that have been proposed (due to space manner: inexecutability laws have a form simpler than that of limits no proof is given). effect laws, and it might be reasonably expected that it is eas- Theorem 6.2 Let be the translation into Situa- € ier to exhaustively describe them. (Note that nevertheless this tion Calculus of a domain description in . ™GŽ   ‘ is not related to the qualification problem, which basically If has no implicit state constraints, € then says that it is difficult to state all the executability laws of a ©n€ ¨ Poss 165do    4 iff ( '@'    8 (  DB 33j      4 domain.) Thus, all the inexecutabilities should be explicitly ©…i„dbwbt&!i…cS Poss ¨ g h g f  V a Y X W  V T do . DCA@97)165  B (    8  (    4 33j      4 stated, and this is what Principle P2’-1 says. This means that under P2’-2 one has modularity inside , T US 5.2 No implicit state constraints too: when deducing the effects of action we need not con- 4 Executability laws increase expressive power, but might con- sider the action laws for the other actions. Versions for exe- flict with inexecutability laws. For instance, let be such ‹ Œ€ cutability and inexecutability can be stated as well.  that T US , ‹ U„p T S  t alive Poss tease ‹ ˆt&W a Y X , p 0 ) (   0  F    Theorem 6.3 There exist descriptions € not satisfying P2’-2 ‹ dcS Y a Poss tease p , and  . (Note 1    ‹ ih %f g g t i„dp g h g f such that Poss ©€€ ¨ ( †j    4 ( †@'    8 do  DB and 33j      4 that Principle P2’-1 is satisfied.) We have the unintuitive Š ©…i„dbwbt&!i…cS Poss ¨ g h g f  V a Y X W  V T DCA@97)165  B (    8  (    4 do . 33j      4 ©@bdU1~dbt&W alive : the turkey is immortal! This is ¨ ‹ Y a S  ‹ a Y X    an implicit state constraint because alive does not follow    For example, just take as before: ‹ ƒ€ from alone: P2’-2 is violated. ‹ i„df g h g € Poss shoot ‹ ©¨ alive   ª  (  0 ( g '  alive do shoot   3!1     , The existence of implicit state constraints may thus in- however shoot shoot cS ‹ T wbt&! ‹ a Y X W Š ©…„ih %F ¨ ‹ g g f Poss shoot  ( «1   dicate too strong executability laws: in our example, one alive  0 alive do shoot . A (     3!     wrongly assumed that tease is always executable. It may also indicate that the inexecutability laws are too strong, or that 7 Related work the state constraints are too weak. Pirri and Reiter [1999] have investigated the metatheory of the Situation Calculus. In a spirit similar to ours, they use 6 Results for a dependence based solution to executability laws and effect laws. Contrarily to us, their the frame problem executability laws are equivalences and are thus at the same time inexecutability laws. There are no state constraints, i.e., Given an axiomatic theory of actions with a solution to the f ­¬i„df p . For this setting they give a syntactical con- g h g frame and the ramification problems, we are interested in dition on effect laws forcing them not to interact with ex- knowing whether domain descriptions encoded in it satisfy ecutability laws, which precludes implicit state constraints. or not our set of design principles. Here we chose to use the Basically, the condition says that when there are effect laws modal framework of [Castilho et al., 1999], which …™GŽ ‘   Poss ( u165    4 do and Poss ( u@9    8  @8 3! 65     4 ( uj    4 has been shown to support Reiter’s solution to the frame prob- 8 ' do 8 ®} ' ˜ (  , then and  ˜ are inconsis- !316      4 @8    8  ˜   lem [Demolombe et al., 2003] and also proposes an assess- tent (which essentially amounts to having in their domain de- ment of the ramification problem. scriptions a kind of “implicit state constraint schema” of the Let be a translation of a domain description in œ36‰—• {'’ ›š ™ ˜ – ” “ form ). 0 ƒw@9 8 —    8 3 ˜    …HŽ   into the Situation Calculus. Dependences ‘  „4 ž This then allows them to show that such descriptions are al- are translated into predicates , meaning that action 165A9ˆŸ  ž  4  ¡   4 ways consistent. Moreover they thus simplify the entailment may cause literal to be true. The extension of dep is then cir- ž problem for this calculus, and show for several problems such cumscribed (cf. Schubert’s explanation closure assumption). as consistency or regression that only some of the modules of As examples, shoot walking means that shoot may A¢~Ÿ  ¡    0  a domain description are necessary. cause walking to be false, and the absence of tease alive A9ˆŸ  ¡     induces the frame axiom alive alive do tease . 0 A (   0   31    Amir [2000] focuses on design and maintenance of ac- tion descriptions applying concepts of the object-oriented Theorem 6.1 If w`eP€ ¦ ¥ ¤ £ is a domain description in , ……HŽ ‘   paradigm in the Situation Calculus. In that work, guidelines then ¦ `eP5©¨36§—• {’ ¥ ¤ £ €  ›š ™ ˜ – ” “  satisfies Principles P1’-1—P1’-7. for a partitioned representation of a given description are pre- Even in , however, it is possible to derive inexe- ™GŽ   ‘ sented, with which the inference task can also be optimized, cutabilities from (see the example in Section 4), which T US as it is restricted to the part of the domain description that is violates Principle P1’-8. Establishing maximal cohesion of really relevant to a given query. This is observed specially T cS in this case involves weakening of preconditions of ac- when different agents are involved: the design of an agent’s tion effects. Anyway, conceiving an algorithm to accomplish description can be done with no regard to others’, and after this task is not difficult (due to space limitations we omit its the integration of multiple agents, queries about an agent’s presentation here). beliefs do not take into account the belief state of other agents.
  • In that work, executabilities are as in [Pirri and Reiter, [Castilho et al., 1999] M. A. Castilho, O. Gasquet, and 1999] and the same condition on effect laws is assumed, A. Herzig. Formalizing action and change in modal logic which syntactically avoids implicit state constraints. I: the frame problem. J. of Logic and Computation, Despite of using many of the object-oriented paradigm 9(5):701–735, 1999. tools and techniques, no mention is made to the concepts of [Demolombe et al., 2003] R. Demolombe, A. Herzig, and cohesion and coupling. In the approach presented in [Amir, I. Varzinczak. Regression in modal logic. J. of Applied 2000], even if modules are highly cohesive, they are not lowly Non-classical Logics (JANCL), 13(2):165–185, 2003. coupled, due to the dependence between objects in the rea- soning process defined there. We do not investigate this fur- [Doherty et al., 1996] P. Doherty, W. Łukaszewicz, and ther here, but conjecture that this could be done there by, dur- A. Szałas. Explaining explanation closure. In Proc. Intl. ing the reasoning process, avoiding passing to a module a Symp. on Methodologies for Int. Systems, 1996. formula of a type different from those it contains. [Finger, 1987] J. J. Finger. Exploiting constraints in design synthesis. PhD thesis, Stanford University, 1987. The present work generalizes and extends Pirri and Reiter’s result to the case where z¯ih %f f Šp g g and both [Pirri and Reiter, [Ginsberg and Smith, 1988] M. L. Ginsberg and D. E. Smith. 1999; Amir, 2000] where the syntactical restriction on effect Reasoning about actions II: The qualification problem. Ar- laws is not made. This gives us more expressive power, as we tificial Intelligence, 35(3):311–342, 1988. can reason about inexecutabilities, and a better modularity in [Herzig and Varzinczak, 2004] A. Herzig and I. Varzinczak. the sense that we do not combine formulas that are conceptu- Domain descriptions should be modular. In Proc. ally different (viz. executabilities and inexecutabilities). ECAI’04, pages 348–352, 2004. [Lang et al., 2003] J. Lang, F. Lin, and P Marquis. Causal 8 Conclusion theories of action – a computational core. In Proc. IJ- We have established a link between knowledge engineering CAI’03, pages 1073–1078, 2003. and software engineering showing that many of the concepts [Lin, 1995] F. Lin. Embracing causality in specifying the in- and techniques developed for the latter are useful in the de- direct effects of actions. In Proc. IJCAI’95, pages 1985– sign and maintenance of domain descriptions. In particular, 1991, 1995. with the concepts of cohesion and coupling we get better cri- [McCain and Turner, 1995] N. McCain and H. Turner. A teria for domain description evaluation. causal theory of ramifications and qualifications. In Proc. Our central hypothesis is that the different types of axioms IJCAI’95, pages 1978–1984, 1995. should be neatly separated and only interfere in one sense: state constraints together with action laws may have conse- [McCarthy and Hayes, 1969] J. McCarthy and P. J. Hayes. quences that do not follow from the action laws alone. The Some philosophical problems from the standpoint of ar- other way round, action laws should not allow to infer new tificial intelligence. In Machine Intelligence, volume 4, state constraints, effect laws should not allow to infer inexe- pages 463–502. 1969. cutability laws, etc. [McCarthy, 1988] J. McCarthy. Mathematical logic in artifi- At first glance, because of i„df g h g’s interaction with other cial intelligence. Daedalus, 1988. modules, it could be said that domain descriptions described [Pirri and Reiter, 1999] F. Pirri and R. Reiter. Some contri- in our way do not completely minimize coupling. However, butions to the metatheory of the situation calculus. Journal given the intrinsic nature of g , observe that we cannot do ih %f g otherwise: in the same way it is not possible to write com- of the ACM, 46(3):325–361, 1999. pletely decoupled methods (or the program will not work!), [Pressman, 1992] R. S. Pressman. Software Engineering: A we cannot have totally decoupled domain descriptions (un- Practitioner’s Approach. McGraw-Hill, 1992. less, of course, we constrain ourselves to domains without [Schubert, 1990] L. K. Schubert. Monotonic solution of ramifications like in [Pirri and Reiter, 1999]). the frame problem in the situation calculus: an efficient It could be argued that unintuitive consequences in domain method for worlds with fully specified actions. In Knowl- descriptions are mainly due to badly written axioms and not edge Representation and Defeasible Reasoning, pages 23– to the lack of modularity. True enough, but what we have 67. Kluwer, 1990. presented here is the case that making a domain description [Shanahan, 1997] M. Shanahan. Solving the frame problem: modular gives us a tool to detect at least some of such prob- lems and correct it. (But note that we do not claim to correct a mathematical investigation of the common sense law of badly written axioms automatically and once for all). Besides inertia. MIT Press, Cambridge, MA, 1997. this, having separate entities in the ontology and controlling [Thielscher, 1995] M. Thielscher. Computing ramifications their interaction help us to localize where the problems are, by postprocessing. In Proc. IJCAI’95, pages 1994–2000, which can be crucial for real world applications. 1995. [Zhang et al., 2002] D. Zhang, S. Chopra, and N. Y. Foo. References Consistency of action descriptions. In PRICAI’02, Topics [Amir, 2000] E. Amir. (De)composition of situation calculus in Artificial Intelligence. Springer-Verlag, 2002. theories. In Proc. AAAI’2000, pages 456–463, 2000.