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

Abstract

In an open component market place, interface description languages (IDLs) such as CORBA's provide for the consumer only a weak guarantee (concerning type signatures) that a software service will work in a particular context as anticipated. Stronger guarantees, regarding the intended semantics of the service, would help, especially if formalized in a language that allowed static checking of compatibility between the server and the client's service descriptions.We propose an approach based on a family of formalisms called description logics (DLs), providing three examples of the use of DLs to augment IDL: (1) for the CORBA Cos Relationship service; (2) for capturing information models described using STEP Express, the ISO standard language used in the manufacturing domain (and a basis of the OMG PDM effort); and (3) constraints involving methods.DLs, while being less powerful, do offer certain advantages over traditional formal specification techniques. First, they typically support decidable (sometimes even efficient) reasoning algorithms. Second, DLs excel at modeling natural domains, and are thus well-suited for specifying applicationand domain-specific services.

Consistency and interoperability checking for component interaction rules

“…This idea originates from [15,16]. The work [5] follows a similar approach, but it uses description logics for rule specification and lacks a detailed study of the consistency of interaction rules. The idea of using multiple models to specify the component protocol was also present in [1,2,22].…”

“…A considerable number of formal language based approaches have been proposed in the literature to overcome the ambiguity of informal documentation used in the industry. For example, [7,9,22,24] use finite state machines (FSMs), [2,8] interface automata, [1,4,6] process algebra, [21] regular expressions, [3] Petri nets, and [5] description logics. The benefit of using a well-developed language is that many analysis In contrast, our specification approach is designed for use by software practitioners.…”

Specifying Interaction Constraints of Software Components for Better Understandability and Interoperability

“…More specifically, any occurrence of call/return events of it 2 is possible only when a return event in it 1 has occurred but any call event in it 3 has not yet occurred afterwards. The acceptable event sequences are described by Fig.…”

“…[1,2,3,4,5,16,17,18]. Most of them require that the user have an expertise or sound knowledge in formal languages, e.g.…”

“…A body of work has been proposed to explicitly and precisely describe component interaction protocols, including [1,2,3,4,5,8,9,16,17,18]. Most of these approaches employ formalisms with a strong mathematical flavour.…”