Ivo Van Horebeek

An exception handling method for constructive algebraic specifications

This paper describes an exception detection and exception handling method for constructive algebraic specifications. A notation that supports exception handling is introduced. First, a safety function is provided for every sort. This function characterizes each object as being safe or unsafe. Secondly, axioms may contain markers that indicate when they are applicable.

A Case Study: the Mini-PABX

One of the most interesting case studies we made is the formal specification of a substantial part of a call handling system, the ITT 5400 BCS (Business Communication System) [Bell85b]. The ITT 5400 BCS is a modern Private Automatic Branch Exchange (PABX for short), which has been developed and produced by Bell Telephone Mfg. Co. Geel (Belgium) in the context of ITT’s Office 2000 concept. Because voice communication accounts for some 80% of all office communications [Bell85a], the ITT 5400 BCS is supplied with a wide range of features. These features considerably improve the flow of information, provide more ease of operation and save time and costs. The range of features for voice communications includes extension features (i.e. features for the ordinary users), operator features and system features.

A Case Study: the Ferry Problem

In most articles on algebraic specifications trivial examples like stacks, queues and sets are used [Goguen78, Guttag78]. As an unbounded stack does not exist in reality, it seems cooked up by the algebraicists because it suits their approach so well. Actually, examples like stacks, queues and sets are useful to illustrate the basic principles of algebraic specifications to those who want to have a first impression. As for programming in the small versus programming in the large, techniques and notations for designing small specifications do not necessarily apply to large ones. In Chapters 5 and 6, we deal with examples of a degree of complexity which is representative for large specifications. It is our intention to show that algebraic specifications, as described in the previous chapters, are appropriate not only for small examples but also for non-trivial case studies.

An Algebraic Specification Language

In Chapter 2 we dealt with the mathematical foundations of algebraic specifications. These foundations are important for gaining insight into the underlying concepts of the specification formalism. From these foundations it became clear that, unlike informal specifications, algebraic specifications can be made in a precise and unambiguous way.

Abstract Data Types as Initial Algebras

Because software is structured around data rather than around services of a system, abstract data types (ADTs) play a central role in the search for an appropriate structure of modularity during the design phase of the software life cycle. Intuitively speaking, an ADT is characterized by a set of data structures together with a number of services (functions) available on these data structures. To deal with ADTs in a rigorous way, we first model ADTs by means of algebras. Many algebraic models can be chosen as underlying mathematical foundation. In this book, the initial model is used. It is one of the most widespread models in literature. Other models will be briefly discussed in Section 2.19. As an algebra may define several abstract data types (called sorts), the term many-sorted initial algebrais used. A description (notation) of an algebra, e.g., of a many-sorted initial algebra, is called an algebraic specification.