Adding more “DL” to IDL: towards more knowledgeable component inter-operability

Adding more “DL” to IDL: towards more

knowledgeable component inter-operability

Alex BorgidaDept. of Computer Science

Rutgers UniversityPiscataway, NJ 08854 USA

Prem DevanbuDept of Computer Science

University of CaliforniaDavis, CA 95616 USA

AbstractIn an open component market place, interface de-scription languages (IDLs), such as corba’s, pro-vide for the consumer only a weak guarantee (con-cerning type signatures) that a software servicewill work in a particular context as anticipated.Stronger guarantees, regarding the intended seman-tics of the service, would help, especially if for-malized in a language that allowed effective, auto-matic and static checking of compatibility betweenthe server and the client’s service descriptions

We propose an approach based on a family of for-malisms called description logics (DLs), providingthree examples of the use of DLs to augment IDL:(1) for the CORBA Cos Relationship service; (2)for capturing information models described usingSTEP Express, the ISO standard language used inthe manufacturing domain (and a basis of the OMGPDM effort); and (3) constraints involving methods.

While traditional formal specification techniquesare more powerful, DLs offer certain advantages:they have decidable, even efficient reasoning al-gorithms, yet they still excel at modeling naturaldomains, and are thus well-suited for specifyingapplication- and domain-specific services.

1 IntroductionThe software component market is here, thanks tothe widely accepted standards such as corba andCOM [29]. Now, a vendor can build a software com-ponent (such as a financial calculator) and sell iteither to end-users or to integrators. In addition,independently developed systems, running on dif-ferent platforms, can inter-operate via published in-terfaces. Although the details vary with the specific

standard, a key enabler of this new drive towardsheterogeneous system integration is the ability todescribe interfaces in a programming language in-dependent manner. The core capability needed hereis some interface description language, or IDL [16],which allows a component vendor or user to describethe interface through which two bits of software caninteract. For example, a dictionary component maysupport the following interface:interface dictionary {

exception notFound (String key);exception unInitialized();exception badEntry(String key, String translation);void enter(in String key, in String translation)

raises (badEntry);void setup();void lookup(in String key, out String translation)

raises (notFound, unInitialized);}With this published interface, and the use of variousstub and skeleton generators, as well as “on-the-wire” RPC protocols, it is possible for dictionar-ies to be implemented and (independently) clientsoftware to be built. In principle, dictionaries willbecome a freely replaceable and tradeable unit ofsoftware composition. Besides domain-independentcomponents, such as dictionaries and transactions,domain specific services are also possible, with in-terfaces defined specifically to support applicationsfor manufacturing, health, education, etc. For ex-ample, OMG1 has ongoing standardization effortsin several domains. We focus more on this secondfamily of applications.

IDL descriptions of a service resemble ordinarytype descriptions, and play several roles: (i) rep-resenting agreement on the basic domain termi-nology/identifiers; (ii) guiding the use of the ser-vices in terms of the interface types and the ex-ceptions; (iii) enabling automatic and static com-patibility checks between the client’s requirementsand the services offered by a provider (again, view-

1Object Management Group (OMG) is the standardsbody controlling corba.

1

able as type checks). For languages with weak typesystems, one might even generate run-time tests tovalidate arguments.

But in practice, current IDL descriptions leavemany questions unanswered. For example, in theabove specification: Can more than one value beassociated with the same key? Can one add newwords after the setup procedure sets up an effi-cient access structure, if one calls setup again?This is the problem of service specification. Cur-rently, some of this additional information is pro-vided informally, using comments in natural lan-guage. In addition to the standard problems of in-formal specifications (ambiguity, etc.), this leavesitem (iii) above totally unsupported. It is thereforenatural to consider some formal approach to aug-menting IDL service specifications. Specifically, inthis paper we consider adding the following kinds ofinformation to an IDL interface: (a) data invariants(particularly useful for database-like “integrity con-straints”), (b) procedure pre- and post-conditions,(c) object behaviour models of dynamics.

In addition to expressing formally the domain se-mantics, we want the specifications of a client andsupplier to be matched by some computer program(type checker/theorem prover) just as the IDL ismatched.

What would the ideal formal service specificationlanguage be? Many program specification for-malisms (Predicate Calculus, object oriented Z [28],Larch corba[17], UML OCL [25]) are highly ex-pressive, but pay for this expressiveness by aban-doning any hope of effective reasoning (item iii),since the formalisms have undecidable decisionproblems. Without effective reasoning, one can-not automatically determine if two specificationsare compatible, leaving the unpleasant possibilityof run time exceptions and errors.

In any case, complete specifications are likely to betoo onerous and difficult to obtain for large real-world products. But benefits can be obtained evenwith partially characterized services; any incrementover the current IDL description provides a cor-responding benefit! This suggests the use of for-malisms that are expressively limited, but have de-cidable reasoning problems. Some languages in-vestigated in the formal methods literature (e.g.,Wright [2], Inscape [23], etc.) fall in this cate-gory. However, a third desirable feature of ser-vice specification languages is that their basic ’on-tology’ should match the ’object-oriented’ natureof current IDLs, and they should be well-suited to

describe application domains in the natural world.The aforementioned formalisms are, however, bettersuited for capturing mathematically clean abstrac-tions and special notions such as concurrency.

In this paper, we propose to augment IDLs withconcepts specified in Description Languages/Logics(DLs), whose roots are in AI knowledge representa-tion and reasoning. DLs have several features thatmake them good candidates for enhancing IDLs.First, decades of research have identified a variety ofDLs that admit decidable, even efficient reasoners.There are several refined and mature such reason-ers available, and more under development. Second,the basic ontology of DLs involves notions such as“object”, “concept” (unary predicate), “attribute”(binary predicate), which are entirely compatiblewith the basic ideas of object-centered IDLs suchas corba’s. Moreover, as detailed in [3], DLs re-semble in many ways type systems, with DL judg-ments such as “concept subsumption” and “individ-ual recognition” corresponding to “type subsump-tion” and “type inference” respectively. Therefore,DLs are natural candidates to extend the type sys-tem of IDLs to capture more details. Finally, DLsarise from the long tradition of semantic nets andframe systems [8], which are strongly biased to-wards capturing real-world domain knowledge foruse in AI systems. So, while DLs are ill-suitedfor modeling mathematical and algorithmic knowl-edge (e.g., Fast-Fourier transforms and locking pro-tocols), they are by design and tradition well-suitedfor application- and domain-specific services.

We provide three examples of the use of DLs toaugment IDL component interfaces with additionalsemantics: (1) for the corba Relationship service;(2) for capturing information models described us-ing STEP Express — the ISO 10303 language devel-oped to describe product data in the manufacturingdomain; (3) for describing constraints on procedu-ral components. The first two examples are moti-vated by the OMG effort to develop product datamanagement enablers in the manufacturing domain[20], while the last one is meant to show that DLsare useful for reasoning about meta-procedural, aswell as meta-data aspects. But first, we introducebriefly Description Logics. (For further details, see,for example, [5] and the DL web site [12].)

2 Concept Description Languages/LogicsDLs have an object-centered ontology. IndividualDL objects (which have immutable identity) maybe related to other objects via attributes and maybe grouped into concepts. For example, C45 (an

instance of concept CAR) can be related to its maker,Gm (an instance of MANUF and US-CORP) by havingGm be a filler of the madeBy attribute.2 By default,an individual object may be related to zero or moreother objects by an attribute – e.g., ownedBy forC45 may include several entities, indicating multipleownership. Attributes that can have at most onevalue are singled out, and will be called featureshere.

DLs start from primitive concept and attributenames, and combine these into composite conceptsusing concept constructors. Some concept construc-tors are the familiar boolean connectives: (andCAR BLACK-OBJECT) denotes the set of cars that arealso black objects. Other concept constructors aremore specially suited to represent conceptual mod-els of application domains. For example, one canexpress cardinality constraints on attributes usingconstructors at-least and at-most: (at-least 2ownedBy) denotes objects with at least two own-ers. The values of attributes can be restricted invarious ways, including by universal quantification,as in (all ownedBy PERSON) which denotes ob-jects owned only by persons. For readability, all isreplaced by the when dealing with features: (themadeBy MANUF) .

The concept US-CORP may itself have been de-fined as the conjunction of CORPORATION and (fillsincorporatedIn Usa), where the latter expressiondenotes objects that include Usa among the fillers ofthe attribute incorporatedIn. A useful propertyof DLs is the ability to nest composite descriptions,so that

(all madeBy (and MANUF

(the postedProfit (minimum 2.5))))

describes objects made by MANUFs who posted aprofit of at least 2.5 (billion dollars) — (minimumk) denoting the set of numbers greater than orequal to k. Other concept constructors can spec-ify relationships between (chains of) attributes:(and CAR (same-as madeBy hasEngine.madeBy))

describes cars whose maker is the same as the makerof their engine.

One can also define composite attributes, usingattribute constructors. For example, (inversemadeBy) would be the natural definition of the at-tribute makerOf, if madeBy and makerOf were in-verses of each other. Other useful attribute con-structors include relation composition: (compose

2Notational conventions: concept names are all-caps, in-dividuals have first letter capitalized, and attributes beginwith lower case letters. Keywords are bold-face

p q), which is sometimes abbreviated as p.q, andtransitive closure: (transClosure p)

Table 1 contains a subset of DL constructors(mostly ones used in this paper) from the ARPAKRSS standard collection [22]3.

CONCEPTTERM

TRANSLATION TO PCψ(x) is shown for λx.ψ(x)

TOP TrueBOTTOM False(and C D) C(x) ∧D(x)(all p C) ∀z p(x, z) ⇒ C(z)(at-least n p) ∃z1, ...,∃zn

p(x, z1) ∧ . . . ∧ p(x, zn)∧zi 6= zj

(at-most n p) ∀z1, ..., zn, ∀zn+1

(p(x, z1) ∧ . . . ∧ p(x, zn+1) ⇒(z1 = z2 ∨ . . . ∨ zn = zn+1)

(same-as p q) ∀z p(x, z) ⇐⇒ q(x, z)(fills p I) p(x, I)(set I1,...,Im) x = I1 ∨ . . . ∨ x = Im(minimum k) x ≥ k

( maximum k) x ≤ k(not C) ¬C(x)(overlap p q) ∃z p(x, z) ∧ q(x, z)(notsameas p q) ∃z ¬(p(x, z) ⇐⇒ q(x, z))

ATTRIBUTETERM

TRANSLATION TO PCψ(x, y) is shown for λx,y.ψ(x)

identity x = y(inverse p) p(y, x)(compose p q) ∃z p(x, z) ∧ q(z, y)

(role-or p q) p(x,y) ∨ q(x,y)(transClosure p) transitive closure

of binary predicate p

Table 1: Some concept and attribute constructorsand their semantics in Predicate Calculus

DLs (just like UML [25], for example) can expressinformation about a domain of discourse; but DLsare also logics that provide reasoning services. Abasic operation is determining if some concept C issubsumed by another, D (C v D). For example, inevery possible state of the world, an object satisfy-ing (all ownedBy (set Alicia Roma)) also satis-fies (at-most 2 ownedBy) as well as (at-most 3ownedBy).

3The list of constructors in [22] was arrived at empiri-cally, in efforts to express the meaning of natural languagesentences and other Artificial Intelligence tasks. Subsets ofits constructors have been used to develop a number of sub-stantial ontologies, in areas such as medicine, botany, etc. —see [12].

In some situations, the question of subsumption isasked in the context of a number of other stated“declarations” of subsumption and equality (calleda knowledge base/ontology). For example, (and AC) v (and B E) holds if one is already given thatA v B and C .= (and E F).

Another logical deduction is determining whethera concept or set of concepts is coherent (an inco-herent concept can never have an instance — itcorresponds to the predicate False). And, thoughnot relevant to this paper, there is more logic deal-ing with individuals, facts, and their connection toconcepts.

The various DLs investigated so far have differentkinds of implementations: the most widely used, in-cluding classic[7] and loom[18], are implementedin a “normalize then compare” approach, whichis quite different than standard theorem proving,and relies on finding a normal form for descrip-tions that detects nested incoherences, explicatesimplicit concepts, and removes redundancies. A sec-ond family of DLs, typified by crack[12], is imple-mented with tableaux-like refutation theorem prov-ing techniques, albeit ones specially made for DLs.Recently, several powerful decidable DLs [10] havebeen identified, which are closely related to Propo-sitional Dynamic Logic; therefore theorem proversof the later could be used for reasoning, althoughthe prefered trend is to extend tableaux techniquesto handle them.

It is important to note that a key focus of rea-soning research, especially for DLs, has been thetrade-off between expressiveness of a language andthe cost of reasoning with it. Specifically, there aredetailed results about the decidability and compu-tational complexity of reasoning with various sub-sets of constructors (and restrictions of them). Forexample, through judicious choice of concept con-structors (versions of the first 11 in the first tableon page 3) classic [7] has a complete subsump-tion algorithm that is O(n3). Also, recent empiri-cal evidence [14] suggests that special optimizationsmake the other theorem-proving techniques workquite fast on “normal” knowledge bases, though theproblem is worst-case exponential.

Since the full KRSS DL is still known to expressonly a very limited subset of Predicate Calculus (the“3 variable subset”), for practical purposes, systemssuch as classic and loom offer “escape hatches”:ways of describing concepts using either procedures(test-concepts) or full first order logic ((satisfiesψ)). Their reasoners tend to treat these as black

boxes, although the most recent release of classic

supports language and reasoner extensibility, whichcan allow one to customize the DL and its deduc-tions to specific applications [6].

Let us turn now to applications of DLs in describingthe semantics of interfaces.

3 The CORBA Relationship ServiceThe OMG common object services framework de-fines a relationship service (called CosRelation-ship [1]), which is used to model entities and re-lationships that arise in application software, in thestyle of Entity-Relationship models. The serviceis widely referenced because it is compatible withother corba services such as naming, lifecycle, se-curity, etc.; it also includes useful operations fortraversing the graph of a relationship.

The service is formally specified in pure corba IDL;but the limitations of IDL force many modeling de-cisions to remain implicit in the implementation ofthe clients and servers. In this section, we brieflyintroduce the service using the example of a pub-lic school, and illustrate how DL-based modelingcan explicate such decisions, and (through reason-ing) statically determine whether there are incom-patibilities that could appear during actual inter-operation.

Consider a system dealing with public schools. In-formally, a school is located in a district, and per-sons reside in a district, which funds the school.Students can enroll in a school in their district.To model this, one starts with classes for PERSON,

Figure 1: Example binary relationships

SCHOOL, DISTRICT, and then establishes relation-ships according to a general approach illustrated inFigure 1. An object then participates in a relation-ship via a role; e.g., a PERSON object is connectedwith a role object student to the Enrollment bi-nary relationship. A fragment of the correspondingIDL would be

module PS {interface PERSON { . . . }interface SCHOOL { . . . }interface DISTRICT { . . . }interface student :

CosRelationship::Roleinterface attended :

CosRelationship::Roleinterface enrollment :

CosRelationship::Relationship;etc.

Consider enrolling a child in a school using theabove service. First, the createRole method of animplementation of a CosRelationship::RoleFactoryis invoked to create an attended role for the SCHOOLobject. The semantics of the domain require thatthere must be only between 50 and 200 attendees ata school. If the latter upper bound is violated, theMaxCardinalityExceeded exception (which is prede-fined for CosRelationship) is signaled. Second, astudent role is created for the child, and if thechild tries to attend more than one school then acardinality exception is also raised. Suppose that inaddition, a student must be an instance of PERSONhaving age under 21, and living in the same dis-trict that supports the school. These translate intochecks made by the software.The violation of theseconstraints is signaled by raising additional kindsof exceptions. Finally, the createRelationshipmethod of a CosRelationship::RelationshipFactoryobject is invoked to create the Enrollment relation-ship between the above two roles.

The problem is that while IDL can represent theexistence of the exceptions, it cannot specify theprecise conditions under which these exceptions areraised. The constraints noted above can howeverbe expressed in classic by declaring concept iden-tifiers for class-like interfaces (SCHOOL, DISTRICT,PERSON), attribute/feature identifiers for the roles(resident, residence, student,...), and thenadding restrictions on the concepts:

PERSON v (the residence DISTRICT)

PUPIL.= (and PERSON

(the age (maximum 21))

(same-as residence

attended.supporter))

SCHOOL v (and(at-most 200 student)

(all student PUPIL)

(the supporter DISTRICT)

(at-least 1 supporter))

These concept descriptions can be explicitly en-tered into the interface description as annotations(perhaps in comments, as in [24]). These asser-tions amount to an explicit representation of do-main knowledge that would otherwise be implicit inthe implementation, or would appear in comments.For example, the interim OMG PDM Enabler pro-posal [21] uses stylized comments to capture cardi-nality constraints.

Consider two software systems desirous of commu-nicating over a school module, such as the oneabove. As long as their IDL formulation is thesame, they can communicate. In addition, each IDLdescription will now include the constraints on thevarious relationships in the form of DL concepts. Inthis case the two interfaces can be statically com-pared for consistency using the subsumption infer-ence.

For example, suppose that two components definean interface COMPLIANT-SCHOOLdifferently. Assumingthe following additional semantics

SCHOOL v (the class-size Integer))

supporter.= (inverse supportedBy)

RICH-DISTRICT.= (and DISTRICT

(the supportedBy

(the class-size (maximum 30))))

maybe one district defines COMPLIANT-SCHOOL as:(and SCHOOL (the class-size (maximum 30))

while another describes it as:(and SCHOOL (the supporter RICH-DISTRICT))

classic will quickly infer that these two definitionsare in fact equivalent, and declare the componentscompatible. Hence updates to the various relation-ships can be carried out between these components,without fear of CosRelationship cardinality or otherexceptions.

Note that in order to deal with non-binary relation-ships, ”recursive” constraints, and to detect certainkinds of modeling errors, it is probably better to usea more expressive DL [9], instead of classic.

Of course, many/all of the above constraints can beexpressed in the plethora of object-oriented modelsof the last decade, of which UML [25] and Cataly-sis [15] are just some of the latest. However theseeither lack a formal semantics, or are so powerful(usually at least full first-order logic) as to excludeautomatic analysis for compatibility.

4 Capturing express in DLThe Object Management Group (OMG) standard-ization efforts for manufacturing software [20] have

strong ties to the established ISO Standard for theExchange of Product Model Data (step), whichhelps manufacturers share product data. A keyelement of step is the language express, usedto present “information models” for different kindsof applications (e.g., CAD designs, electrical prod-ucts). Hardwick et al [13] provide an introduction tostep and express. They also describe a mappingfrom express features to IDL, which can be used tosupport distributed information sharing. express

[27] is a powerful object-centered data specificationlanguage. It is more expressive than most object-oriented modeling languages and supports severalspecial features. We show a partial mapping fromexpress to classic to demonstrate the latter’ssuitability for application-specific domains. In addi-tion, our mapping provides a formal semantics forpart of express which, to our knowledge is notavailable elsewhere. We use part of an example from[27] to illustrate express, and describe its transla-tion to classic. This allows partial reasoning withexpress.

The example concerns the registration of cars, andis summarized informally thus:Cars are objects, which have features such as model,serial number, ownedBy. The car is made by amanufacturer, who is said to make the model aswell, and the manufacturer of the car plus its se-rial number distinguish this car from all other cars.A car also can have up to 100 options, and a tempo-rally ordered history of transfers, recording the date,seller and buyer.

The following is the express syntax capturing someof this information.1. entity CAR;

2. model : CAR-MODEL;

4. options : set [0:100] of CAR-OPTIONS;

5. serialNo : INTEGER;

6. ownedBy : OWNER;

7. history : list of TRANSFER;

derive

8. madeBy : MANUFACT := model.madeBy

where

9. datesOK(self.history) // checking history

10. exchangeOK(self.history) // for correct ordering

unique

11. (madeBy, serialNo)

end entity;

entity TRANSFER;

...

The only non-self-explanatory material are lines 9and 10, which illustrate express’s “escape mech-

anism”: for material that cannot be captured us-ing the special dictions of express, there is afull-fledged programming language for writing func-tions.

To begin with, here is the limited model that couldbe captured in OMG IDL:

interface CAR {attribute CAR-MODEL model;

attribute set<CAR-OPTIONS> options;

attribute OWNER ownedBy;

attribute seq<TRANSFER> history;

attribute MANUFACT madeBy;

}The DL translation of the express model is moreaccommodating. First, we use DL primitive at-tribute names for express attributes that have ag-gregation domains like set or list (options andhistory in this case); the rest become features,having at most one value. Also, all entity namesare translated into primitive concept names. Types(not shown) are translated to corresponding con-cept definitions. For example, the express

type GENDERS = enumeration of (’masc,’fem);

becomesGENDERS

.= (set ’masc ’fem).

The basic attribute domain and cardinality con-straints (lines 2 to 7) are immediately translatedto DL as subsumption constraints on concept CAR:CAR v (and

(the model CAR-MODEL) (at-least 1 model)

(all options CAR-OPTIONS)

(at-most 100 CAR-OPTIONS)

(the serialNo INTEGER) (at-least 1 serialNo)

(the ownedBy OWNER) (at-least 1 ownedBy)

(all history TRANSFER)

(all madeBy MANUFACT) (at-least 1 madeBy) )

In addition, express has derive and where con-straints. Derive provides a way to ’compute’ thevalue of the attribute. Many of the simple derivesconstraints can be expressed directly in DL: e.g.,line 8 adds (same-as madeBy model.madeBy)to the above. As another example, the express

line madeBy: MANUF := Ford would add (fillsmadeBy Ford). The remaining kinds of derivationsare encoded in a catch-all(test-concept derive “≺Attrib�” “≺Expression�”)

As in express these cannot usually be reasonedwith statically.

The express where conditions are used to statecomplex boolean constraints. In fact, line 8 couldhave also been stated aswhere madeBy :=: model.madeBy . Again, some

where constraints can then be directly capturedby DL constructs; and concept constructors and,or, etc. can be used to combine them to get com-plex boolean expressions. Lines 9 and 10 againbecome “black-box” DL terms like (test-conceptdatesOK history). The final constraint, unique,is common in computer-based information systemsand man-made worlds (though in the natural world,there are no really unique external identifier). Re-cently, classic has been extended with constructorkey that expresses this as (key [madeBy,serialNo]

CAR).

A simple program can translate abstract syntaxtrees for express declarations (using a slightly dif-ferent grammar that generates the express lan-guage) to DL terms, yielding, after some simplepost-processing, a set of concept and role specifica-tions. In fact, for most cases classic was sufficient,and hence reasoning is very efficient, as mentionedearlier.

We remark that the recent trend to extensible DLreasoners [6], allows specialized, possibly incom-plete reasoners to be customized for applications.For example, probably the only important rea-soning with keys is like (key [madeBy,serialNo,α]

CAR) v (key [madeBy,serialNo) VEHICLE) for anyattribute list α. The classic 2.3 release allows thiskind of inference to be added to the basic implemen-tation so that (test-concept key ≺FeatureList�≺ConceptId�) will behave appropriately.

The facility of DLs to state definitions is a majormissing feature of express, which can only declareprimitive concepts, with necessary conditions, andthen add sufficient conditions as assertions. So, forexample, the classic definition ofADULT

.= (and PERSON (the age (minimum 22)))

would require the use of procedures/queries in ex-

press:entity ADULT

age/PERSON : INTEGER

where

necessaryCond: (self.age ≥ 22);

suffCond: query(p <* PERSON | p.age ≥ 22)

⊆ query( c <* ADULT | true);

end entity;

5 Modeling dynamicsThe above examples illustrate the modeling of staticaspects of a domain. We now turn to dynamic as-pects. In AI, actions (verbs) are modeled using a“case frame” approach where the participants of the

activity are linked to it via attributes. So, for ex-ample, one can have the primitive concept DELIVER,with features object, src, dest and when:DELIVER v(the object CAR) (the src MANUFACT)

(the dest DEALER) (the time DATE)

This corresponds to the IDL specificationinterface CAR{

...

deliver(in CAR object, in MANUFACT src,

in DEALER dest, in DATE time)

...

}Note how the formal parameters of methods corre-spond to the attributes of reified actions.

However, to capture additional constraints on theparticipants (for example, that the object and srcmust be located in the same place at the beginning)one can no longer use IDL — the only trace of itwould be an exception NOT-SAME-PLACE raisedby the method. We can however also model someof the initial and final conditions associated with amethod using DLs as follows:(i) For each method (e.g., deliver, sell) associ-ated with an interface (e.g., CAR), declare a corre-sponding feature in the DL concept:

CAR v (the deliver DELIVER)

(ii) Express preconditions as descriptions relatingparameter features, as in

;; object delivered is co-located with the source

CAR v (same-as deliver.object.location

deliver.src.location)

Preconditions can also involve the attributes of theconcept itself (recall that in OO methods, the datamembers of a class can be accessed by a method);for example,

;; the car’s maker delivers it to the dealer

CAR v (same-as madeBy deliver.src)

Similarly, it is the owner of the car who is supposedto sell it, so we need precondition

CAR v (same-as ownedBy sell.src)

The specification can also indicate that the lattercondition is checked, by associating an exceptionwith its violation; in contrast, if the condition doesnot raise an exception, then it is an assumption – aproof obligation for humans to discharge.

(iii) Final conditions are treated similarly. So forexample, the effect of selling the car is to give it anew owner

;; the destination of sell is the new owner

CAR v (same-as ownedBy sell.dest)

Some initial and final conditions may be too hardto express in DLs so they can be either stated in-formally, as comments, or as argument formulas tosatisfies .

The expression of state invariants and pre/post con-ditions of actions is, of course, an idea that goesback to beginnings of data abstraction research,and has found eloquent exposition in Meyer’s “pro-gramming by contract” [19], for example. However,the assertions in [19] are either checked at run-time or are thought about by humans – there isno automatic computer support for reasoning withthem. In fact, even though the assertion languagelacks quantifiers, automatic checking of implicationis once again undecidable, if integer attributes andfull arithmetic are permitted.

As a final example, we consider the possibil-ity of representing sequencing constraints on themethods of a service. In the CAR example, as-sume methods to deliver it to the dealer, to sella car, and to destroy it. The usual valid se-quence would be captured by the regular expressiondeliver (sell)∗ destroy . Interestingly, the examplein [27] actually states that “after destruction, earliertransfers (sales) can still be recorded”. This meansthat the server might specify the regular expressiondeliver (sell)∗ destroy (sell)∗ , with suitable restric-tions on the sell method’s time.A client desiring the first service could use the sec-ond one, but not vice versa. How can we verifythis? As it happens, one large family of decidableDLs is based on a close correspondence with “con-verse propositional dynamic logic” [10]. The basisof this correspondence is model-theoretic: objectsare states (hence concepts are state-predicates),attributes are state transitions (hence programs).Therefore, all we have to do is view the above regu-lar expressions as complex attribute-expressions ina concept definition, e.g.,(at-least 1

(compose deliver

(compose (transClosure sell)

destroy)))

We can then use the usual subsumption engine.Moreover, the correspondence to PDL allows muchmore complex “programs” to be written, describingcomplex local conditions under which methods canbe invoked.

Alternatively, one could use the plan-based DLclasp [11], which can be added onto classic usingthe extensibility features [4]. Plans are constructedthrough sequence, alternation and looping from ac-

tions, with the additional benefit of checking theconsistency of sequencing: preconditions of actionscannot conflict with postconditions of their prede-cessors.

In many OO methods, including UML, one can pro-vide a description of the valid sequences of oper-ations using some notation such as state charts.Model checking does permit decidable reasoningabout state charts, but state charts require the in-troduction of new identifiers (for the state names),while our approach lives within the already existingframework of objects with attributes whose valuesare activities.

6 DiscussionWe have argued that IDLs, such as that of OMG,provide only limited type information as a basis ofthe agreement about the services provided or de-sired, and this limitation can easily lead to run-timeerrors (at best) or worse, unintended effects that re-main undiscovered.

The obvious solution is to increase the power of theservice “type description language” to include as-sertions about aspects such associations, invariants,and actions. Sticking to the OO paradigm conge-nial to corba, one might then consider formalismsuch as Larch corba [17], ADL [26], UML and itsOCL assertion language, etc. However, we also de-sire effective compile-time “type checking”, whichinvolves deciding whether one set of assertions im-plies another, and which, incidentally, can currentlybe performed efficiently for corba IDL. However,the above mentioned specification languages are soexpressive/powerful (they support full quantifica-tion or arithmetic over integers) that no such typechecker/theorem prover can be expected since theproblem is usually undecidable. And even if weconsider a more limited languages, such as that in[19], little is known about the effect of minor vari-ations on the complexity of computing implication,simply because this has not been the focus of re-search in software engineering. In contrast, therehas been more than a decade of work on the com-plexity of computing with various combinations ofconcept and role constructors. So, for example, al-though same-as with features is tractable in clas-

sic, if one uses full attributes or if one tries to allow”recursive constraints” with them (e.g., a TRANSFERhas an attribute, next, whose value is supposed tobe a TRANSFER), it is known that this renders sub-sumption undecidable.

Therefore, we can view DLs as type-like formalisms

[3], where subsumption can be used in ways simi-lar to type signature matching. In fact, DLs seemto form a nice middle ground between signaturematching [30] and specification matching [31]. DLswere designed for modeling application domains inthe natural world. Many such domains arise fromthe standardization efforts of the OMG subcom-mittees in manufacturing, medicine, etc., where wehave observed the need for capturing additional ser-vice semantics being met by the stylized use of com-ments. We note that an IDL service specificationalready provides us with a valuable commodity: aconsensus on primitive terms (concept and attributenames for DLs), from which composite terms andassertions can be built using the DL constructors.This contrasts with the harder task of merging mul-tiple data sources (e.g., heterogeneous database in-tegration) — a problem to which DLs have also beenapplied.

In specific terms, we have shown how DL conceptscan be used to capture some of the (i) data invari-ants related to interface attributes for services thatare data/relationship centered; (ii) pre- and post-conditions needed to describe methods; (iii) condi-tions under which exceptions will be raised; (iv) as-pects of event dynamics. We have argued that DLsare well suited especially for the first task by usingactual services (CosRelationship) or languages likeexpress, which have been originally developed tospecify services in special domains.

It may be worth reiterating that the significance ofour examples lies in showing that DLs can performsome of these tasks despite the fact that they areexpressively limited in order to allow more effectiveautomatic reasoning.

In addition to checking for exact matching of theabove 4 kinds of information between the client andserver, the formal assertions and DL reasoning allowus to perform additional tasks:

Compatibility testing of the specifications:Even if the client’s requirements do not matchthe provider’s specifications exactly, if the client’sneeds are stronger, (e.g., an extra initial condition),then the client can be warned, and it might evenbe possible for the language translation to auto-matically add “wrapper code” for run-time checks.This would require us to be given methods to ac-cess primitive concept and attribute instances, butwould generate code for complex descriptions.(Local) consistency checking:Formal interface specifications can be checked forself-consistency. For example, the initial conditions

of a method should not be inconsistent with thedata invariants for its interface class.More thorough treatment of exceptions:By associating IDL exceptions with formal asser-tions we obtain, to begin with, some validationbenefits if we discover assertions that did not haveIDL exceptions, and vice-versa. For example, thetakesSpouse CosR relationship may specify that(a) it is anti-symmetric, (b) one person’s spousescannot overlap with another person’s, (c) a personhas at most one spouse, etc. For each of these con-straints, a different exception would be specified.Variability in services provided:Interestingly, if the checking of some assertions isleft to be generated automatically from the aug-mented IDL (as mentioned earlier), with the choiceof which assertions are to be checked left to theclient, but the code being generated/used at theserver site, we get a much more flexible kind ofinter-operation. For example, the takesSpouse re-lationship server could then be used in a polyan-drous society, by omitting constraint (c).

Additional open research problems include investi-gating ways in which DL processing can be inte-grated more tightly with the corba infrastructure.corba IDL might itself be extended with DL con-structs — a significant issue here being whether onehas to settle on a particular set of constructors (e.g.,classic) or whether there is some way to leave thechoice open.

To conclude, we repeat that DLs provably cannotcapture all the possible things one might want tosay about a service – but then neither can anythingelse that is decidable. And for certain services (e.g.,ones involving numeric computing, or distributedprogramming) DLs are simply not suitable. That iswhy we have emphasized the kind of services thatwe see DLs being particularly well suited to dealwith.

AcknowledgmentBorgida’s research was supported in part by NSFGrant IRI-9619979.

REFERENCES

[1] corba Relationship Service.http://www.omg.org/corba/sectrans.htm

[2] R. Allen, D. Garlan, “A formal basis for ar-chitectural connection”, ACM TOSEM, July1997.

[3] A. Borgida, “From type systems to knowl-edge representation: natural semantics spec-

ifications for description logics,” Int. J. of In-telligent and Cooperative Information Systems1(1), 1992.

[4] A. Borgida, “Towards the systematic develop-ment of terminological reasoners: clasp re-constructed”, Proc. KR’92,

[5] A. Borgida, “Description Logics in Data Man-agement”, IEEE Trans. on Knowledge andData Engineering, vol.7, no.5, October 1995,pp. 671–682.

[6] A. Borgida, “Extensible knowledge represen-tation: the case of Description Reasoners”, J.AI Research, to appear.

[7] A.Borgida, R. J. Brachman, D. L. McGuin-ness, and L. A. Resnick “CLASSIC: a struc-tural data model for objects,” Proc. SIG-MOD’89 pp. 59–67.

[8] R. Brachman, H. Levesque, Eds, “Readingsin Knowledge Representation”, Morgan Kauf-man, 1985.

[9] D. Calvanese, M. Lenzerini, and D. Nardi, “Aunified framework for class-based representa-tion formalisms”, Proc. KR’94, pp.109–120.

[10] G. De Giacomo and M. Lenzerini. “A uniformframework for concept definitions in descrip-tion logics.” Journal of Artificial IntelligenceResearch , 6, pp.87-110, 1997.

[11] P. Devanbu and D. Litman, “CLASP - a planrepresentation and classification scheme”, Ar-tificial Intelligence, 84(1-2) 1996.

[12] Description Logics, http://www.ida.liu.se/labs/

iislab/people/patla/DL/

[13] Hardwick, M., D.L. Spooner, T. Rando, K.C.Morris. “Sharing Manufacturing Informationin Virtual Enterprises”, CACM 39(2), Febru-ary 1996.

[14] I. Horrocks, P.F. Patel-Schneider, “Optimiz-ing description logic subsumption”, J. Logicand Computation, to appear.

[15] Icon Computing Inc., The Catalysis Web page,http://www.iconcomp.com/catalysis

[16] D. A. Lamb, “IDL: Sharing Intermediate Rep-resentations” ACM TOPLAS, July 1987

[17] G. Leavens and Y. Cheon, “ExtendingCORBA IDL to Specify Behavior with Larch”,Iowa State University, CS-TR-93-20, 1993.

[18] R.M. MacGregor, “A deductive patternmatcher”, in Proc. AAAI’87, pp.403–408.

[19] B. Meyer, ”Object-oriented software construc-tion”, Prentice Hall, 1988.

[20] OMG TC, “Product Data Management En-abler RFP”, August 1996.http://www.omg.org/library/schedule/PDM Enabler RFP.htm

[21] OMG TC, “PDM Enablers – Joint proposalto OMG in response to [20]”, ftp://ftp.omg.org/-pub/docs/mfg/98-01-01.pdf

[22] Patel-Schneider, P. and W. Swartout, eds.,“Description Logic Knowledge Representationsystem specification from the KRSS Groupof the ARPA Knowledge Sharing Effort”,http://www-db.research.bell-

labs.com/user/pfps/papers/krss-spec.ps, November1993.

[23] D. Perry, “The inscape environment” Pro-ceedings, ICSE 1989.

[24] D. Rosenblum “A Practical Approach to Pro-gramming with Assertions” IEEE TSE, Jan.1995.

[25] J. Rumbaugh, G. Booch, I. Jacobson, ”Uni-fied Modeling Language Reference Manual”,Addison-Wesley, 1998

[26] S. Sankar, R. Hayes “Specifying and TestingSoftware Components using ADL” SunlabsTechnical Report, Sun Microsystems, Inc.,TR-94-23 (April 1994) http://www.sunlabs.com/-techrep/1994/mli tr-94-23.pdf, 1994.

[27] Schenk, D.A., and Wilson, P.R. InformationModeling the EXPRESS Way, Oxford Univer-sity Press , 1994

[28] S. Stepney, R. Barden and D. Cooper (eds),Object Orientation in Z, (Workshops in Com-puting Series), Springer Verlag, 1992.

[29] C. Szyperski, “Component Software”,Addison-Wesley, 1994.

[30] Zaremski, A., and Wing, J., “Signaturematching: A tool for using software libraries.”ACM TOSEM, 1995.

[31] Zaremski, A., and Wing, J., “Specificationmatching of software components,” ACMTOSEM 6(4), 1997.