Introduction

In the previous chapters of this book, we have illustrated the use of the ingredients in our methodology for the description and analysis of reactive systems by means of simple but, it is hoped, illustrative examples. As we have mentioned repeatedly, the difficulty in understanding and reasoning reliably about even the simplest reactive systems has long been recognized. Apart from the intrinsic scientific and intellectual interest of a theory of reactive computation, this realization has served as a powerful motivation for the development of the theory we have presented so far and its associated verification techniques.

In order to offer you further evidence for the usefulness of the theory you have learned so far in the modelling and analysis of reactive systems, we shall now use it to model and analyse some well-known mutual exclusion algorithms. These algorithms are amongst the most classic ones in the theory of concurrent algorithms and have been investigated by many authors using a variety of techniques; see, for instance, the classic papers Dijkstra (1965), Knuth (1966) and Lamport (1986). Here, they will give us the opportunity to introduce some modelling and verification techniques that have proved their worth in the analysis of many different kinds of reactive system.

In order to illustrate concretely the steps that have to be taken in modelling and verification problems, we shall consider a very elegant solution to the mutual exclusion problem proposed by Peterson and discussed in Peterson and Silberschatz (1985).

Abstract

In most natural language processing applications, Description Logics have been used to encode in a knowledge base some syntactic, semantic, and pragmatic elements needed to drive the semantic interpretation and the natural language generation processes. More recently, Description Logics have been used to fully characterize the semantic issues involved in the interpretation phase. In this chapter the various proposals that have appeared in the literature about the use of Description Logics for natural language processing will be analyzed.

Introduction

Since the early days of the Kl-One system, one of the main applications of Description Logics has been for semantic interpretation in natural language processing [Brachman et al., 1979]. Semantic interpretation is the derivation process from the syntactic analysis of an utterance to its logical form – intended here as the representation of its literal deep and context-dependent meaning. Typically, Description Logics have been used to encode in a knowledge base both syntactic and semantic elements needed to drive the semantic interpretation process. One part of the knowledge base constitutes the lexical semantics knowledge, relating words and their syntactic properties to concept structures, while the other part describes the contextual and domain knowledge, giving a deep meaning to concepts. By developing this idea further, a considerable part of the research effort has been devoted to the development of linguistically motivated ontologies, i.e., large knowledge bases where both concepts closely related to lexemes and domain concepts coexist.

Abstract

This introduction presents the main motivations for the development of Description Logics (DLs) as a formalism for representing knowledge, as well as some important basic notions underlying all systems that have been created in the DL tradition. In addition, we provide the reader with an overview of the entire book and some guidelines for reading it.

We first address the relationship between Description Logics and earlier semantic network and frame systems, which represent the original heritage of the field. We delve into some of the key problems encountered with the older efforts. Subsequently, we introduce the basic features of DL languages and related reasoning techniques.

DL languages are then viewed as the core of knowledge representation systems, considering both the structure of a DL knowledge base and its associated reasoning services. The development of some implemented knowledge representation systems based on Description Logics and the first applications built with such systems are then reviewed.

Finally, we address the relationship of Description Logics to other fields of Computer Science. We also discuss some extensions of the basic representation language machinery; these include features proposed for incorporation in the formalism that originally arose in implemented systems, and features proposed to cope with the needs of certain application domains.

Introduction

Research in the field of knowledge representation and reasoning is usually focused on methods for providing high-level descriptions of the world that can be effectively used to build intelligent applications.

Introduction

In Sections 11.1 and 11.2, we introduced some notions of behavioural equivalence over real-time systems specified by means of timed automata. These equivalences are based on various adaptations to the timed setting of the classic notions of trace equivalence and bisimilarity over LTSs – as presented in Sections 3.2 and 3.3 of this book – and may be used to perform implementation verification for real-time systems. This is useful because, at least in principle, a formalism like that of timed automata can be used to describe both actual systems and their specifications and, as we saw in Section 11.6, these notions of behavioural equivalence are decidable over (networks) of timed automata, with the notable exception of timed trace equivalence.

However, as we have already noted in the setting of modelling and verification for classic untimed reactive systems, when establishing the correctness of our system with respect to a specification using the methodology of implementation verification, we are forced to specify in some way the overall behaviour of the system under consideration. In a real-time setting, this often means that our specifications need to take into account many details pertaining to the timing behaviour of the implementation under analysis. This may lead to overly complex and subtle specifications. Moreover, sometimes we are interested only in specifying the expected behaviour of the system in certain specific circumstances.

This appendix describes three selected student projects. All these projects involve the use of software tools for verification and validation. In our lecture courses we have usually introduced the students to the Concurrency Workbench (CWB) and to Uppaal, but other tools could be used just as well. Further information on the following projects and more suggestions for student projects are available from the web page for the book at www.cs.aau.dk/rsbook/.

Alternating-bit protocol

In this project you are asked to model the alternating-bit protocol in the CCS language and verify your model using the CWB. The alternating-bit protocol is a simple yet effective protocol for managing the retransmission of lost messages. Consider a sender S and a receiver R, and assume that the communication medium from S to R is initialized, so that there are no messages in transit. The alternating-bit protocol works as follows.

• Each message sent by S contains an additional protocol bit, 0 or 1.

• When S sends a message, it does so repeatedly (with its corresponding bit) until it receives an acknowledgment (ACK) from R that contains the same protocol bit as the message being sent.

• When R receives a message, it sends an acknowledgment ACK to S and includes the protocol bit of the received message. When a message is received for the first time, the receiver delivers it for processing, while subsequent messages with the same bit are simply acknowledged.

Abstract

We present lower bounds on the computational complexity of satisfiability and subsumption in several Description Logics. We interpret these lower bounds as coming from different “sources of complexity”, which we isolate one by one. We consider both reasoning with simple concept expressions and reasoning with an underlying TBox. We discuss also complexity of instance checking in simple ABoxes. We have tried to enhance clarity and ease of presentation, sometimes sacrificing exhaustiveness for lack of space.

Introduction

Complexity of reasoning has been one of the major issues in the development of Description Logics. This is because such logics are conceived [Brachman and Levesque, 1984] as the formal specification of subsystems for representing knowledge, to be used in larger knowledge-based systems. Since using knowledge also means deriving implicit facts from the given ones, the implementation of derivation procedures should take into account the optimality of reasoning algorithms. The study of optimal algorithms starts from the elicitation of the computational complexity of the problem the algorithm should solve. Initially, studies about the complexity of reasoning problems in Description Logics were more focused on polynomial-time versus intractable (NP- or coNP-hard) problems. The idea was that a knowledge representation system based on a Description Logic with polynomial-time inference problems would guarantee timely answers to the rest of the system. However, once systems based on very expressive Description Logics with exponential-time reasoning problems were implemented [Horrocks, 1998b], it was recognized that knowledge bases of realistic size could be processed in reasonable time.

The model of timed automata, introduced by Alur and Dill (1990, 1994), has by now established itself as a classical formalism for modelling real-time systems with a dense representation of time. The development of the timed-automata formalism was carried out largely in parallel with – and independently of – the work on timed extensions of process algebras. Roughly speaking, whereas the development of timed process algebras was driven by their (relative) expressiveness, their revealing of new behavioural equivalences and their axiomatizations, the development of the timed-automata formalism was largely driven by the goal of obtaining decidability results for several important properties (Dill, 1989). By now, real-time model checking tools such Uppaal (Behrmann, David and Larsen, 2004) and Kronos (Bozga et al., 1998) are based on the timed-automata formalism and on the substantial body of research on this model that has been targeted towards transforming the early decidability results into practically efficient algorithms.

Motivation

Timed automata are essentially nondeterministic finite automata equipped with a finite number of real-valued clocks, so that transitions can be conditioned on clock values and the performing of a particular transition can reset selected clocks. We shall now introduce the formalism intuitively, showing how the light switch from the start of the previous chapter can be described using the formalism of timed automata without recourse to assumptions such as the urgency of some actions or maximal progress. Graphically, we could model the light switch as in Figure 10.1.

Abstract

This chapter considers, on the one hand, extensions of Description Logics by features not available in the basic framework, but considered important for using Description Logics as a modeling language. In particular, it addresses the extensions concerning: concrete domain constraints; modal, epistemic, and temporal operators; probabilities and fuzzy logic; and defaults.

On the other hand, it considers non-standard inference problems for Description Logics, i.e., inference problems that – unlike subsumption or instance checking – are not available in all systems, but have turned out to be useful in applications. In particular, it addresses the non-standard inference problems: least common subsumer and most specific concept; unification and matching of concepts; and rewriting.

Introduction

Chapter 2 introduces the language ALCN as a prototypical Description Logic, defines the most important reasoning tasks (like subsumption, instance checking, etc.), and shows how these tasks can be realized with the help of tableau-based algorithms. For many applications, the expressive power of ALCN is not sufficient to express the relevant terminological knowledge of the application domain. Some of the most important extensions of ALCN by concept and role constructs have already been briefly introduced in Chapter 2; these and other extensions have then been treated in more detail in Chapter 5. All these extensions are “classical” in the sense that their semantics can easily be defined within the model-theoretic framework introduced in Chapter 2. even to undecidable ones), all the Description Logics obtained this way can only be used to represent time-independent, objective, and certain knowledge.

The problem of sharing resources between processes was briefly discussed in Chapter 3. Two requirements were identified as being essential: mutual exclusion and condition synchronisation. This chapter discusses various ways in which these requirements can be met in Ada without having to encapsulate the resource in a server task and without having to use the rendezvous. Ada gives direct support to protected data by the protected object feature, the discussion of which is the main focus of this chapter. However, the language does also support the notions of atomic and volatile data, which are covered in Section 7.13.

Protected objects

A protected object in Ada encapsulates data items and allows access to them only via protected subprograms or protected entries. The language guarantees that these subprograms and entries will be executed in a manner that ensures that the data is updated under mutual exclusion. Consequently, they are rather like monitors found in previous concurrent programming languages (as described in Chapter 3).

A protected unit may be declared as a type or as a single instance; it has a specification and a body.

The development of the Ada programming language forms a unique and, at times, intriguing contribution to the history of computer languages. As all users of Ada must know, the original language design was a result of competition between a number of organisations, each of which attempted to give a complete language definition in response to a series of documented requirements. This gave rise to Ada 83. Following 10 years of use, Ada was subject to a complete overhaul. The resulting language, Ada 95, had a number of significant changes from its predecessor. A further 10 years of use has produced another version of Ada, known as Ada 2005, this time the changes are less pronounced and yet there are some key extra facilities, especially in the areas of real-time programming.

Closely linked to the development of Ada has been this book on its concurrent features. Starting out as ‘Concurrent Programming in Ada’, it became ‘Concurrency in Ada’ when the Ada 95 version of the language was defined. There were two editions of this title. With the new features of Ada 2005, it has been decided to broaden the focus of the book to include real-time issues – hence this first edition of the new title ‘Concurrent and Real-Time Programming in Ada 2005’. No prior knowledge of concurrent programming (in general) or of Ada tasking (in particular) is assumed in this book. However, readers should have a good understanding of at least one high-level sequential programming language and some knowledge of operating system principles.

This book is aimed both at professional software engineers and at students of computer science (and other related disciplines).

The Ada language addresses many aspects of software engineering, but it is beyond the scope of this book to discuss in detail its support for such topics as programming in the large, reuse and so on. Rather, the goal of this book is to discuss, in depth, the Ada model of concurrency and how it is affected by other areas of the language, for example exception handling. This chapter explores the interaction between the object-oriented programming (OOP) facilities and tasking.

Ada 83 was defined long before object-oriented programming became popular, and it is a credit to the Ada 95 language designers that they managed to introduce OOP facilities without having to alter the basic structure of an Ada program. However, the Ada 95 model had several limitations. In particular, it did not support the standard prefix notation (also called the distinguised receiver syntax), Object_Name.Method_Name(Params), found in most OOP languages. Instead, it required the object name to be given as part of the parameter list of the method. Although this had some advantages, it caused some confusion when programmers moved from languages like C++ and Java to Ada. Ada 2005 now allows the standard OOP notation with the object name prefixing the subprogram name when it is called.

Ada 95 also didn't attempt to integrate the language's support for concurrent programming directly into the OOP model. Instead, the models were orthogonal and paradigms had to be created to allow the benefits of OOP to be available in a concurrent environment.

Ada is a high-level programming language; it provides abstract constructs that allow programs to be constructed easily and safely. However, it is recognised that one of the intended application areas for Ada is the production of embedded systems. Often these (and other) systems require the programmer to become more concerned with the implementation, and efficient manipulation, of these abstract program entities. Ada resolves this conflict in two ways:

1. by allowing the programmer to specify the representation of program abstractions on the underlying hardware, for example by specifying the layout of a record or the address of a variable; and

2. by having extra facilities in the Systems Programming Annex for interrupt handling, controlling access to shared variables, unique identification of tasks, task attributes and the notification of task termination. As with all Ada annexes, these features need not be supported by all compilers.

The areas that are of concern in this book are those which relate directly to the tasking model. These are:

• device driving and interrupt handling – covered in this chapter;

• access to shared variables – previously covered in Section 7.12

• task identification – motivated in Section 4.4 and covered fully in this chapter;

• task attributes – covered in this chapter;

• task termination (notification thereof) – covered in Section 15.7.

Other relevant embedded systems issues such as access to intrinsic subprograms, control over storage pools and data streams, and the use of machine code inserts are not dealt with.