Object-Oriented Behavioral Specifications

OBJECT-ORIENTED BEHAVIORAL SPECIFICATIONS

THE KLUWER INTERNATIONAL SERIES IN ENGINEERING AND COMPUTER SCIENCE

OBJECT-ORIENTED BEHAVIORAL SPECIFICATIONS

WKAP ARCHIEF by Haim Kilov IBM T.J. Watson Research Center William Harvey Institute for Information Management, Robert Morris College

t4

w KLUWER ACADEMIC PUBLISHERS Boston / Dordrecht / London

Distributors for North America: Kluwer Academic Publishers 101 Philip Drive Assinippi Park Norwell, Massachusetts 02061 USA Distributors for all other countries: Kluwer Academic Publishers Group Distribution Centre Post Office Box 322 3300 AH Dordrecht, THE NETHERLANDS LIMITS OF LIABILITY AND DISCLAIMER OF WARRANTY The authors and publisher of this book have used their best efforts in preparing this book, but the authors (including their employers) and publisher make no warranty of any kind, express or implied, with regard to the contents of the book. The authors (including their employers) and publisher shall not be liable in any event for damages to persons or property from any use or operation of any methods, products, instructions, or ideas contained in this book. Many of the names used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those names appear in this book, and the authors were aware of a trademark claim, the names have been printed in caps or initial caps.

Haim Kilov - [email protected] William Harvey - harvey@robert~morris.edu

Library of Congress Cataloging-in-Publication Data A CLP. Catalogue record for this book is available from the Library of Congress. The publisher offers discounts on this book when ordered in bulk quantities. For more information contact: Sales Department, Kluwer Academic Publishers, 101 Philip Drive, Assinippi Park, Norwell, MA 02061 Copyright © 1996 by Kluwer Academic Publishers All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher, Kluwer Academic Publishers, 101 Philip Drive, Assinippi Park, Norwell, Massachusetts 02061 Printed on acid-free paper. Printed in the United States of America

CONTENTS Preface

vii

1 Exactness and clarity in a component-based specification language Doug Bryan 1 2 A formal basis for specifying object behaviour Antony Bryant, Andy Evans

17

3 Information refraction Bill Harvey, Karen Bilotta, Cynthia Grese

31

4 A pragmatic approach to formal specification Maritta Heisel

41

5 Anecdotes on making a specification simpler Iain Houston

63

6 Invariants in the trenches Haim Kilov, Helen Mogill, Ian Simmonds

77

7 Fundamentals of object-oriented specification and modeling of collective behaviors Reino Kurki-Suonio

101

8 An overview of Larch/C++: behavioral specifications for C++ modules Gary T. Leavens

121

9 Structural active-object systems fundamentals Toshimi Minoura

143

10 Organizational culture: an object-oriented framework Joseph Morabito, Anilkumar Bhate

163

11 Specifying and reasoning about business rules in a semantic network Leora Morgenstern

177

12 Dynamic and multiple classification James J. Odell

193

13 Specifying business policy using agent-contract meta-constructs John Palmer 197 14 Architectural specifications: Modeling and structuring behavior through rules Carlos Paredes, Jose Luiz Fiadeiro, Jose Felix Costa 221 15 The search for the linking invariant: behavioral modeling versus modeling behavior David Redberg 241 16 Automata describing object behavior Bernhard Rumpe, Cornel Klein

265

17 Enterprise modeling with use cases Jean Stanford

287

18 Formal object-oriented method — FOOM Paul Swatman

297

Index

311

Preface To build complex systems that satisfy customers' needs, we have to understand the customers' business and their needs. We also have to precisely specify this understanding. These precise specifications are needed by subject matter experts (SMEs), modelers, and developers. The SMEs have to be assured that they are understood by the "computer people"; the modelers have to understand the SME's needs and to convey those to the developers; and the developers have to satisfy precisely those needs, no more and no less. The ultimate goal is to solve business problems rather than just to produce some code. Many existing approaches to specifications — to analysis — often emphasize only the signatures (syntax) of information structures and operations, leaving semantics either unspecified or described by means of examples, pictures (cartoons), etc. As a result, computer systems often do not satisfy customers' needs because these needs have not been properly understood and specified. In addition, a computer system cannot be tested for conformance to its specification if the specification is nonexistent or imprecise. And finally, different computer systems are often not interoperable, leading to redundant and inconsistent information. Ultimately, the program code is the precise specification. However, it cannot be used by SMEs or modelers: it is too detailed to be understood by then. It introduces many implementation choices irrelevant at the specification level; and it uses computerbased concepts that distract from understanding the enterprise. A specification should explain what is to be done rather than how it is to be done: there may be a number of implementations ("hows") for a given "what". The situation in analysis now seems to be close to the one in programming in the second half of the 1970s when, in Dijkstra's words, programming was in the process of moving from a craft to a scientific discipline [D77]. Most — if not all — observations made by Dijkstra then for programming are valid (and often reinvented) now for analysis. We also see that in analysis, as in programming (an observation made by Dijkstra [D62] in 1962!), elegance is of utmost importance: elegant specifications are liked by all, and thus successfully used and reused. It seems clear that for a specification to be of use (and to be produced in a reasonable manner — as any artifact produced by Professional Engineers, to quote Parnas [P95]), it needs to describe semantics rather than syntax, and to do that in an abstract and precise manner. Indeed, precise specifications of the "what" have been successfully formalized for a number of commercial applications. The components of these specifications will be reusable, leading to savings of intellectual effort, time and money. The papers in this book show various ways of doing just that.

Vlll

Preface

Precise semantics Precise specifications of semantics are essential to understand business rules and to create software systems satisfying these rules. We use them "to describe properties of a system which does not yet exist in the real world; but some client, with money to pay, would like to see it brought into existence. ... [The system should be described] as clearly and directly as possible, in terms of what behavior is to be exhibited and what is to be avoided. The specification may be part of a formal contract between the client and the team engaged to implement the product" [H94]. The object-oriented (OO) approach to information management provides a good way of solving these problems. Properly applied, it shows how to specify collective behavior in business rules and software transactions, leading to semantic integration of complex systems. However, certain OO methodologies still split a specification into such components as "data", "process" and "behavior", without precisely defining them, only to merge these components afterwards. In this manner, "thingless events" [W89] are often merged with "eventless things"...

From traditional to better OO approaches The object-oriented paradigm has solved many problems related to software packaging, but has created its own. Some traditional OO methodologies preclude us from seeing different user viewpoints separately and lack the means to describe their interactions formally. The past few years have witnessed two emerging trends in OO modeling: a "refunctionalization" of data models, and a "subjectification" of objects. Various activities, both in OO analysis and programming, are related to collective behavior in generalized object models. Two major directions may be identified in this area: unification of definitions and notations in behavioral modeling, and explicit declarative specification of interobject behavior. The issue of viewpoints also comes up under different forms, both along the lines of Open Distributed Processing [RM-ODP 95] viewpoints (e.g., enterprise and information viewpoints versus computational viewpoint), and in terms of different aspects of object behavior being of interest to different kinds of users (different domain experts, analysts, developers). Obviously, proper approaches are needed to acquire and express behavioral requirements (e.g., business rules) in a way that domain experts can understand and validate, and in a way that modelers can verify and map to an object information model. Many authors of papers presented in this book participated in four successful OOPSLA workshops (1992-95) on behavioral semantics (and some ideas presented here have been extensively discussed at these workshops). The workshops have attracted wide international participation, including well-known OO experts from industry and academia. The papers show that abstract and precise specifications of behavioral semantics are being successfully used in industry, both for requirement

Preface

IX

(elicitation and) specification and for program development. This industrial experience is encouraging: as shown below, both diverse industrial application areas and international standardization documents (re)use the same small set of fundamental concepts. These concepts provide a good framework for precise and abstract specification of the collective state (invariants) and collective behavior (pre- and postconditions for operations) of several objects. The approaches discussed in these papers will help to substantially reduce the amount of reinvention — and corresponding frustration.

Reusable specification patterns Although the authors of these papers have quite different backgrounds, their approaches concentrate on a small number of the same important — and methodology-neutral — conceptual issues. Some papers discuss general properties of specifications; others provide examples and lessons of their use in particular application areas. Our work in specifications can be thought of as the analogy to software design patterns in the information perspective. An information modeling construct is an information modeling pattern defined in an abstract and precise manner; it is reusable in application-specific models. It is an abstraction, it solves a real, general problem, and it precisely describes the things (the objects participating in relationships) and how the things work (the behavior based on the relationships). Software patterns are used to architect software systems by abstracting code. Information modeling constructs are used to specify business information systems by abstracting collections of real-world entities. There exists an obvious need to relate the two viewpoints, and implementation libraries with clearly specified linking invariants (C.A.R.Hoare) can be used for this purpose.

Abstraction Important challenges in the specification area are related to abstraction and understandability. "Being precise" is not the same as "being detailed": precision is applicable at all levels of abstraction. A precise, but not abstract, specification is unmanageable and therefore not understandable. A human, not a machine, maps the specification onto an implementation. A specification, after all, is needed to facilitate communication among people. Problems in this area include requirements provided in terms of solutions; "thousands of event traces; and no common vocabulary", etc. As there is more to real world than just software, requirements need to be formulated in terms the customer can understand. Therefore constructs like message sending are not an appropriate way to write these requirements: they overspecify (perhaps, they are as low-level as, in other

X

Preface

contexts, goto's, pointers, or hypertext links are). The customer has to verify requirements because otherwise the system to be built may be quite different from what the customer wants. Therefore the concerns of the business enterprise should be clearly separated from the concerns of the system development. The fundamental purpose of a specification is to communicate intent rather than pseudocode. A good specification should be correct, complete, and be in the language of the consumer; and one appropriate sentence is preferable to many pages describing what the wrong thing is. Some customers prefer to present requirements in terms of external interfaces to currently existing systems. Although these presentations do not use system development terms, they reuse forms, charts, etc. from current legacy systems. This viewpoint on requirements does not properly represent the concerns of the business. As an example from the document management business, paper and electronic documents have quite different external interfaces, but solve the same business problems, and therefore the description of a business should not be based on a particular (legacy or otherwise) electronic document management system.

Analysis vs. design How do we keep users from presenting requirements in terms of solutions? The user at times does design instead of analysis, and in these cases we have to distinguish between what the user says ("how to implement") and what the user wants ("what to do"). We also have to distinguish a system for hire from a system for sale. Analysis deals with things about which you have no choice; design is everything else. These things have to be discovered, and walkthroughs are essential for this: they break people out of a box by getting them into a meeting room where different viewpoints are merged. Sometimes different people get to know about each other because there is a lot of replication of like functions across different lines of responsibility. And multiple projections from the same specification may have to be used for multiple consumers. A contract "happens" because a meeting of the minds is assured; the same is needed for creating specifications. Precision is needed for the minds to meet (not just in adversarial situations), and then the specification is created cooperatively, as a team effort. A specification should provide a deterministic answer to a user's questions, although at times the question may have no answer at that abstraction level.

Being explicit and rigorous A useful specification is abstract, precise, and explicit. A good declarative specification satisfies these conditions. It includes invariants for (collections of) objects, as well as pre- and postconditions for operations. Declarative specifications have also

Preface

XI

been promoted by such ISO standards as the Reference Model for Open Distributed Processing [RM-ODP 95] and the General Relationship Model [GRM 95]. Precise and rigorous specifications using a stylized natural language (like legalese...) are not always sufficient. Specifications in English, even in stylized English, may be incomplete (e.g., do not contain information "evident" to the subject matter experts), ambiguous, or both. Therefore we need to have a formal specification which may be referred to in cases of doubt or misunderstanding. Several papers show how such formal specifications help to understand business and improve the understanding of constructs used in international standardization documents. The need to write a formal specification leads to the need to ask questions and specify explicitly those things, relationships and properties that have never been made explicit because they were considered obvious. Explicit specifications are essential for both the SMEs (e.g., to avoid misunderstandings due to different viewpoints — such as having 12 different kinds of customers in the same company) and for developers (otherwise they will have to supplement an incomplete specification, i.e., to invent what they consider to be missing business rules). Business "rules" invented in this manner do not necessarily correspond to business rules actually in use in the organization, and the implementation of such "rules" is not properly authorized and validated. Unfortunately, some people may not be used to this kind of precision as there seems to exist a contention between formality and clarity. Many customers (and modelers) will be more comfortable in using precise specifications translated from a formal notation like Z or Object Z into stylized English. Almost all of us have encountered precise specifications in real life: think about legal documents, e.g., contracts like the one for buying a house. Terse specifications are difficult for end users, and so explanatory comments — as recommended by mature Z users, for example — may be very useful. Visual formalisms may augment or be otherwise used in the specification, provided that each element and relationship between elements of this formalism has been precisely and explicitly defined. If these precise definitions do not exist — as too often happens — then a set of "cartoons" (diagrams) does not help much. And quite a few users understand that informal integrity constraints are difficult to enforce. Is a precise specification really that complicated? Not necessarily, as shown in Lewis Carroll's quote about compositions: "Alice had begun with 'Let's pretend we're kings and queens;' and her sister, who liked being very exact, had argued that they couldn't, because there were only two of them, and Alice had been reduced at last to say, 'Well, you can be one of them then, and I'll be all the rest.' " {Through the Looking Glass) Another related problem deals with terminology. The same names may denote very different things (even "altitude" has different meanings in different systems, and all of us know that more generic terms like "customer" are context-dependent). The approach taken by the Reference model for Open Distributed Processing provides a

Xll

Preface

solution: a name is usable for denoting entities only within a particular, explicitly specified, context, so that the same entity may have different names in different contexts, and the same name may denote different entities in different contexts.

Collective behavior No object is an island. We need to describe relationships explicitly by providing an abstract specification of aggregate behavior and separating it from inner object behavior. Early allocation of behavior to classes often promoted because of legacy OO language constructs leads to overspecification: attributes and isolated object operations are not appropriate for understanding (they are too detailed and impose unnecessary choices), although they may be quite precise. There exist various approaches to specifying collections of objects. Collective state, for example, is specified in the ISO General Relationship Model using an invariant for a relationship. This approach is supplemented by specifying pre- and postconditions for operations applied to collections of objects (collective behavior). As shown in the papers below, it has been successfully used to create understandable and reusable specifications. For example, the same generic relationships (composition, dependency, symmetric relationship, and so on) have been precisely defined and reused in very different application areas. As a result, attribute-based models without easily understandable semantics have been replaced with much more understandable and reusable specifications using precisely defined generic relationships like dependency and composition. In such cases these models were provided both to users and developers. Thus, a library of rich and expressive information modeling constructs specified in a precise and abstract manner can be standardized and successfully reused in analysis, design, and programming. Operations and invariants jointly owned by several objects can be (if there is such a desire!) implemented using messages attached to particular objects.

Use and reuse of software over time A useful specification serves an organization well over time. When changes in an organization's business rules occur, it must be possible to determine, without loss of precision or understandability, that the specifications have been revised, so that they correctly represent the new collection of rules. When the reuse of software is proposed (for example, as a cost-cutting measure), it must be possible to determine whether the existing specification also applies to the new context of use. If not, then the integrity of the business is compromised, and the enterprise in endangered by such reuse.

Preface

Xlll

Paper classification As usual, there exist several (mutually orthogonal or not) classification criteria for the papers included in this volume. Instead of choosing a particular semantic-oriented criterion, and thus making unhappy those authors and readers who disagree with its importance, we chose the least semantic way to classify papers: alphabetically, by the first author's last name. References [D62] E.W.Dijkstra. Some meditations on advanced programming. In: Proceedings oj the IFIP Congress 1962 (ed. by Cicely M. Poppeweli;, North-Holland, 1963, 535-538. [D77] E.W.Dijkstra. Programming: from craft to scientific discipline. In: International Computing Symposium (ed. by E.Morlet and D.Ribbens), North-Holland, 1977,23-30. [GRM 95] ISO/IEC 10165-7, Information Technology - Open Systems Interconnection - Management Information Systems - Structure of Management Information - Part 7: General Relationship Model. [H94] C.A.R.Hoare. Mathematical models for computing science. Oxford, UK, August 1994. [P95] D.L.Pamas. Teaching programming as engineering. In: ZUM'95: The Z Formal Specification Notation (Lecture Notes in Computer Science, Vol. 967) (ed. by J.Bowen and M.Hinchey), Springer Verlag, 1995,471-481. [RM-ODP 95] ISO/IEC JTC1/SC21/WG7, Open Distributed Processing - Reference Model: Part 2: Foundations (IS 10746-2 / ITU-T Recommendation X.902, February 1995). [W89] Y.Wand. A proposal for a formal model for objects. In: Object-oriented concepts, databases, and applications (ed. by Won Kim and Frederick H. Lochovsky), Addison-Wesley, 1989, 537-559.

1 EXACTNESS AND CLARITY IN A COMPONENT-BASED SPECIFICATION LANGUAGE Doug Bryan* Center for Strategic Technology Research, Andersen Consulting 3773 Willow Road, Northbrook, IL 60062, USA. [email protected]

Abstract We are investigating software architectures in general and component-based software development in specific. Our goal is to be able to specify architecture so that largegrain reuse can take place in a plug-and-play manner. To facilitate our investigation we have developed a new specification language that is an extension of CORBA's interface definition language. Our extensions include specification of the behavior of interfaces. This paper addresses the problem of designing and implementing a specification language that is formal enough to express exact specifications, yet clear enough to be used by real designers who are not mathematicians. It is our thesis that underlying, mathematical formalisms must be used to achieve exactness, and that given exactness, clarity can be achieved by building tools that hide much of the formalisni from users. This paper presents three tools we are developing to hide a formal specification method from the average user. f

This work is supported in part by the U.S. National Institute of Standards and Technology's ATP project on component-based software.

2

Chapter 1

Introduction As hardware costs decrease and network bandwidths increase, large, heterogeneous distributed systems are becoming the norm in many application areas. Major concerns in the development of such systems include understanding how to use a software component, defining an architecture of component instances, and getting the instances to inter-operate. To investigate these concerns we are designing and implementing a new, high-level architecture specification language [KLN95, KN96]. The working name of our language is simply ASL. Before we present ASL, we feel obligated to define "software architecture." Software architecture is currently the subject of a great deal of research [GP95]. Consensus on the meaning of the term has not yet been reached. For the purposes of this paper, a software architecture is simply a set of components including specifications of their behavior and use, a set of component instances, and a set of connections defining which components interact. This is sometimes referred to as the topology of a system. ASL is an extension of OMG's interface definition language (IDL) [095]. We began with OMG-IDL for a number of reasons. Firstly, we are interested in investigating the semantics of software architectures at a rather high-level. Thus we do not see a need to develop our own syntax for such programmatic features as operator and type declarations; those provided by OMG are sufficient. Secondly, many low-level technical details must be addressed in order to manufacture heterogeneous, distributed systems. These include inter-operability between different machines, operating systems and programming languages, remote procedure calls, and distributed name spaces. We informally refer to this myriad of details as the "plumbing" of a system. We know that we will need plumbing but are not interested in inventing it. CORBA [095] provides sufficient plumbing. Thirdly, CORBA has generated a good deal of interest lately [HS96]. It has a good chance of making a positive impact on our industry in the near-term. By basing our work on CORBA, our work will be accessible to CORBA users. (OMG-IDL is based on C++ for similar reasons.) The remainder of this paper is in three sections. First an overview and rationale of ASL is given to introduce the formalisms used in our specification language. Then our major use of specifications—determining subtyping relationships between interfaces—is presented. The third section presents the three ways we have addressed clarity of specifications.

ASL overview ASL extends OMG-IDL in three ways: (1) behaviors of objects are specified in interfaces, (2) components are declared to aggregate objects into higher-level units, and (3) configurations of components constrain how components are implemented and distributed. The behavior of an object is specified by pre- and post-conditions of

Exactness and Clarity in a Component-based Specification Language

3

operations, invariants of interfaces, and protocols of interfaces. Pre-, post-conditions and invariants are common to many formal methods. In ASL these conditions are simply boolean-valued, C++ expressions or sequences of C++ statements that yield boolean values. We use C++ for the aforementioned reason of accessibility: our target users know C++. Note that these conditions may not contain quantifiers. Full first-order logic is undecidable, and as explained later, automatic verification is an important goal of our work. Also, our target users just don't know first-order logic. Protocols specify allowed sequences of operation invocations. In ASL protocols are defined using simple state machines. A list of abstract states is added to an interface's definition. The preconditions of operations then specify which states an object may be in when the operation is called, and post-conditions specify which states the object may be in upon return. We reuse pre- and post-conditions to specify state transitions because we want to keep ASL small, and because other formalisms, like regular expressions and event structures, are not accessible to our target (CORBA/C++) audience. As an example of an ASL specification, consider a file interface where file names must begin with a back-slash: interface File { states {opened, closed (init)};

// closed is the initial state

void Open(in string name) precondition { name[0] == 'V; closed;} postcondition {opened;}; char Read() precondition {opened;} postcondition {same; }; void Close() precondition {opened;} postcondition {closed;}; }; This specification says that Open must be called first: the initial state is closed and Open is the only operation that can be called in that state. Read must be called from the opened state and does not change the state of the interface. Lastly, Close is called from the opened state and changes the state of the object back to closed. The corresponding state machine is as follows:

4

Chapter 1

/ ^ :=

/f**

|

^\ ^Open

closed jjjf

\^==^/

Read

/^~^^\ \

Close^

)

opened V ^ \ ^ ^ y ^

In ASL, a component is the unit used to specify architectures. Components specify the interfaces they provide to clients, and the interfaces they require from other components. An interface provided by a component is implemented by the component so that others may call it. This relationship is similar to that between a public function and a class in C++. An interface required by a component is implemented elsewhere but called by the implementation of the component. For example, a World Wide Web browser might provide a hyper-text viewer but require a PostScript™ viewer. This relationship is sometimes captured in C++ using template or constructor parameters. A component may provide multiple interfaces, or even multiple objects of the same interface. Similarly a component may require multiple interfaces. For example, a database management system might provide interfaces to a query processor and a log manager, and require an interface to a file system. The typical user, however, is only concerned with the query processor. By specifying a component using multiple interfaces, we allow such users to "see" only that interface and ignore the others. This distinction between interfaces and components gives us large-grain reuse while preserving understandability for the average user. In the development of reusable components, some implementation decisions are best left to the user. Delaying such decisions allows a component to be reused in a variety of architectures [GA095]. ASL's required interfaces facilitate this approach. A component exports abstracted details of its implementation via a required interface. The user of the component then decides how to bind it. To use a toy analogy, during assembly one connects tab A to slot B, and so on. Previous languages supported tabs (functions and objects) but lacked slots. Required interfaces are like slots. Components may also contain instances of sub-components. In this case, a component defines an architecture by connecting required interfaces to provided ones. Consider as a simple example a payroll component that requires a database: interface database {...}; interface log {...}; interface managment_utilities {...};

//operations on the database //operations on the DBMS log

Exactness and Clarity in a Component-based Specification Language

5

component DBMS { provide database db; provide log I; provide managmentjjtilities mng; };'" component payroll { require database db; provide ... }; component payrolLsystem { payroll p; DBMS d; bind p.db to d.db; };

We chose to use components as our building blocks, rather than using just interfaces and objects, for a number of reasons. Firstly, "objects" have many meanings to many people and we didn't want to carry that baggage with us as we investigated architecture. More importantly, we feel that objects, as they are commonly used today in object-oriented programming, are just too small to facilitate architectural design and wide-spread reuse. The problems with reuse at the class-level are becoming well-known [LVC89, H93, GA095]. These problems include the cost of modifying base classes that have many subclasses,1 and the use of multiple run-time models in the same class hierarchy. Couplings looser than those between a base- and subclass are needed [K92, K94]. Components are intended to be large-grain units, say, 20,000 lines of code or more. The business systems we have looked at contain only 10—20 components. One could, of course, think of components simply as big objects. However, the ideas of base- and subclasses are essential to objects, while they are not essential to components; the idea of required interfaces and connections are essential to components. Required interfaces, and connections at the interface- rather than the operation-level, are ASL's main contribution to architecture definition languages. The third area in which ASL extends OMG's IDL is with configurations. While components specify the logical architecture of a system, configurations specify the physical architecture. A configuration is associated with a component. It constraints the following mappings: components to object code, object code to executables, executables to processes, and processes to machines. Generally speaking, a configura-

1

This is sometimes referred to as the "fragile base class" problem.

6

Chapter 1

tion defines a component's implementation. Again consider the payroll system given above. An example configuration for it is: implementation NT_Solaris of payroll_system { p {language VB, operating_system NT, machine "thumper.andersen.com"}; d {language C++, operatingLsystem Solaris2, machine "mocha.andersen.com"}; }; The configuration attributes that may be associated with a component include the programming language it is implemented in, file names of its sources, its CORBA naming service name, target hardware architecture, target operating system, logical host and absolute host name. In ASL, configurations are syntactically separated from their components. A major goal of architecture design is to explicitly state system structure in a way that is clear, understandable, and thus separate from other system properties. Configurations address many of these "other" properties, including site-specific properties. We are in the process of building a "packager" [CP91, C93] that will automatically generate much of the adapter and CORBA code needed to build a system that is consistent with its specification and configuration. This will allow users to focus on the implementation of individual interfaces and operations.

Composition and subtyping of components Components are composed by binding required interfaces to provided interfaces. ASL includes an innovative definition of subtyping to support a wide variety of bindings and to eliminate unnecessary details when specifying architectures.2 Our subtyping is defined by three relations over interfaces: structural subtyping (<s), behavioral subtyping (
2

Subtyping defines the cases where an object of type S can safely be substituted for an object of type T; if S can be substituted for T we say that S is a subtype of T. For the purposes of this paper, an ASL interface is a type.

Exactness and Clarity in a Component-based Specification Language

interface S { void F(); long G(); string H(); };

7

interface T { long G(); void F(); };

More formally, structural subtyping is reflexive and transitive, all types other than void are structural subtypes of any, and all types are structural subtypes of void:3 for all t (t <s t) for all t, s, and r (t <s s and s <s r implies t <s r) for all t except void (t <s any) any <s void OMG-IDL's numeric types have the following structural subtyping relationships: short <s long unsigned short <s long unsigned short <s unsigned long float <s double Strings, arrays and sequences are related as follows:4 string <s string<m> iff n < m for all n (string <s string) t[n] < s u[m] iff t < s u a n d n < m t[n][x] <s u[m][y] iff t[n] <s u[m] and x < y sequence <s sequence ifft< s u sequence <s sequence iff sequence <s sequence and n < m sequence <s sequence ifft< s u For two struct types s and t, s <s t iff for each field in t of type ft there is a field in s of type fs with the same name, and fs <s ft. Specifically, fields must have the same names. (The definition of structural subtyping for enumerations and unions is omitted for brevity.) For interfaces s and t, s <s t iff for each operation ot in t there is an operation os in s with the same name5 and os
Void and any are defined by OMG-IDL [095]. String is the type of strings that contain n or fewer characters while "string" is the type of all strings. T[n] is an array, length n, of T objects. Sequence is an unbounded sequence of objects of type t, while sequence is the type of sequences of objects of type t that contain n or fewer objects, "iff means "if and only if." 5 OMG-IDL does not allow overloading of operations within an interface. 4

8

Chapter 1

the same number of parameters, the n-th parameter of g is a subtype of the n-th parameter off, the return type of f is a subtype of the return type of g [CW85], and for all exceptions ef in the raises-expression of f, there is an exception eg in the raisesexpression of g with the same name and ef <s eg.6 Given types s and t, operation parameter subtyping is based on parameter mode and defined as: (ins)<s(int)iffs<st (out t)< s (outs) iff s < s t (inout s) <s (inout t) iff s <s t and s <s t Note that only operations of interfaces are considered. Constants and local type declarations are ignored. Also, the names of operation parameters are ignored. Lastly, attributes are treated as their equivalent "get" and "set" operations. Behavioral subtyping [A91, LW93, ZW95] takes into account the specifications of interfaces. S can be substituted for / if the contract between / and its users still holds when / is replaced with S [M88]. Fs users ensure Ts preconditions and in exchange assume Fs post-conditions and invariants. Conversely, / assumes its preconditions and ensures its post-conditions and invariants. S can work under this contract if S's assumptions hold: the preconditions of I imply those of 5. Users can continue to work under the old contract when S replaces / if their assumptions still hold: the post-conditions and invariants of S imply those of I. That is, a subtype's preconditions are weaker than those of its supertype, and its post-conditions and invariants are stronger than those of its supertype. Formally, for interfaces s and t, s (pre(ot) => pre(os)), and context(os) and context(ot) => (post(os) and pre(ot) => post(ot)) Trace extension (
Exceptions are equivalent to struct's in OMG-IDL. => denotes logical implication.

Exactness and Clarity in a Component-based Specification Language

9

These definitions of subtyping are used to check bindings in ASL components at compile-time. Users are allowed to bind a required interface r to a provided interface p if p <s r and p
Maintaining clarity Much of the discussion at the 1994 workshop on behavioral semantics [KH94] focused on the definition of "precise" in "precise specification," and what it means to users and customers who are not mathematicians. It was observed that precision requires exactness and clarity, and that the two often conflict.8 Indeed, a risk of any formal method is that users will not be able to understand and use it (i.e., the technology transfer problem [BH95]). We address this risk in four ways: familiar expressions, graphical notations, automatic verification, and natural language paraphrasing. The first is linguistic and involves the design of ASL, while the other three involve tools for ASL. The behavior of an ASL interface is specified using C++ expressions. ASL is based on OMG-IDL, which is based on C++. We assume that our users are familiar with C++ and think that that is a safe assumption. By using C++ expressions, we minimize the intimidation and learning curve that users experience when exposed to a new formal method. Graphical notations and paraphrasing address the problem of understanding a specification, while automatic verification simplifies the task of writing a specification. The main goal of component-based development is high reuse. When reuse is high, reading specifications is much more common than writing specifications, and thus reading must be encouraged over writing. We feel that graphical notations and paraphrasing will significantly help users in understanding specifications. We use graphical notations in two ways. Firstly, like most design languages and development methods these days, we have developed a visual syntax for a subset of our language. Graphical notations are well-known and have become a prerequisite to the acceptance of many new design methods. Simple directed graphs, for example, offer the user a great deal of information about the architecture of a system within a little space. Such notations abstract the system (i.e., hide or lose details) but offer great power in browsing and navigation. The following is an example ASL fragment together with its visual representation:

The difference between "precise" and "exact" lead to a number of humorous discussions. For the purpose of this paper, precision is the degree of ambiguity in a specification, while exactness is the closeness to the desired system. For example, specifying that a function returns 3.1415927 is precise, but not very exact if the function is cosine.

10

Chapter 1

component DBMS { provide database db; provide log I; provide managment_utiljties mng; }; component payroll { require database db; provide update ud; }; component payrolLsystem { payroll p; DBMSd; bind p.db to d.db; };

payrolLsystem payroll 3

d DBMS

• 5

Secondly, we are developing a window-based, syntax-directed editor for ASL. The user is presented with small windows containing forms. Each form represents a construct in ASL's syntax. Some fields in the forms (i.e., those representing nonterminals) expand into other windows containing another form. Using this editor the user needs to know very little of ASL's textual syntax. The user is guided through the syntax one form at a time. Many novice and intermediate users find this helpful. It is widely understood that experienced programmers tend to dislike such editors; they slow them down. However, ASL is designed for software architects, not programmers. An architect deals with only 10-20 components per system. Architectural design tends to be a small part of the development life-cycle. As a result we expect that our users will use the system irregularly over long periods of time. Thus they may never wish to learn the ASL textual syntax in detail, and prefer the guidance of syntax-directed editors over the freedom of general-purpose text editors. Our second approach to maintaining clarity is to simplify bindings using subtyping, and to folly automate verification of subtyping. Structural subtyping allows the user to ignore minor details such as the order of operation declarations within an interface; two interfaces can be connected if they are "close enough", as defined by subtyping. Behavioral subtyping and trace extension then verify that the two interfaces are semantically, as well as syntactically, related. Conceptually, structural subtyping gives the user flexibility while behavioral subtyping checks that it is being used safely. This has typically come at the cost of requiring the user to understand how behavioral subtyping is verified. We propose to folly automate verification and hide the underlying proof system from the user. We strongly feel that if we require our users to assist in proofs, we will lose them. To verify subtyping relations we have decided to use a powerful simplification mechanism rather than a foil theorem prover. We want a mechanism able to prove

Exactness and Clarity in a Component-based Specification Language

11

simple formulas and able to reduce a formula that it cannot prove to a simplified form. The simplified form then reveals the part of the formula that cannot be proved. Further, when it can be proved that subtyping does not hold, it is important that the tool tell the user why, in the user's own vocabulary. Thus, we believe that the simplified form of formula should not be a normalized, machine-oriented form, but rather a formula as close to the original as possible. A deduction mechanism satisfying these requirements is reductive deduction by Bronsard and Reddy [BR92, B95]. This mechanism uses classical deduction rules but controls their application using an order over terms so that deduction steps can only produce smaller formulas. The mechanism relies on "contextual information" during simplification and thus never normalizes expressions to a form unrecognizable to the user. Natural language paraphrasing, we hope, will make our formal specifications accessible to reviewers and customers without loss of information. The challenge is to generate paraphrases that are more accessible than the original specification. English can be just as complicated as first-order logic or C++ expressions, and ten pages of cryptic English can be harder to read than ten pages of good C++ code [M95]. Another project underway in our lab is generating English paraphrases for class definitions that include relations [C95]. For example, given the following definitions written in the programming language they have developed, class employee : person {...}; class professor: employee { relation set<section> teaches inverse section::is_taught_by; }; class TA { relation section assists_in inverse section::has_TA; }; class student { relation set<section> takes inverse section::is_taken_by; }; class section { relation professor is_taught_by inverse professor::is_taught_by; relation TA has_TA inverse TA::assists_in; relation set<student> is_taken__by inverse student::takes; };

they automatically generate the following text:

12

Chapter 1

A professor is a type of employee which is a type of a person. A professor may teach zero or more sections. Each section has at most one TA and is taken by zero or more students. Conceptually, the above class definitions are not linearly ordered: section could have been declared before TA and TA before professor. Similarly a user may enter the English text at any point and begin browsing from there. The text is generated in a hyper-text environment to facilitate browsing. For example, from the above paragraph describing the professor class, the user can jump to paragraphs describing employee, person, section, TA or student. We have found that the effort of generating paraphrases for a design language has a positive feedback on the language itself. Small inconsistencies are found, and extensions suggested. A construct that was added to the above language, as the result of paraphrasing, allows designers to give example names of class instances. Programmers tend to use terse names for instances, like "cs240." Designers, on the other hand, do not use instance names throughout their code and thus are more likely to pick expressive example, such as "Introduction to Compilers."

Related work and contributions Early work on software architecture specification and configuration includes configuration languages such as Durra [BW86, BWD93], Conic [MKS89], Polylith [CP91, P94] and Rex [KMS92]. More recently architecture definition languages such as Wright [AG94], Rapide [LV95, LKA95] and UniCon [SDK95] have been developed. The configuration languages specified software architectures and configurations, but didn't apply formal methods. The architecture definition languages apply formal methods to the problem but don't address configurations as well. Our contribution is ASL's component model: formal specification of interfaces, multiple interfaces per component, and using provided and required interfaces to connect components. The goals of our language and tools are very similar to those of Inscape [P89]. Inscape addressed the usability of formal methods by applying them to just interfaces (rather than entire programs), and by restricting the formalism to predicates. A simple definition of behavioral subtyping was also given, and used to define version control of interfaces. Our work differs from Inscape in that we use a more complex subtyping relation and that subtyping is used to define connections in software architectures. Also we use additional tools, like structured editors and paraphrasing, to address usability. Our work on specifications and formal methods was inspired by the pragmatic work of Meyer in Eiffel [M88, M92] and by the testing work of Sankar [SH94]. Our definition of structural subtyping is based on Rapide's type system [KLM94]. Our work on behavioral subtyping relies largely on C++-like expressions. America's specifications [A91] were written in first-order logic and thus are generally undecidable. As a result America used simple text tags to define and implement

Exactness and Clarity in a Component-based Specification Language

13

behavioral subtyping. Zaremski [ZW95] uses a "proof debugger" that requires user assistance when proving behavioral subtyping relationships. We feel that userassisted proof systems simply are not accessible to real software designers. Sivaprasad [S95] recently added Larch specifications [GH93] to OMG-IDL. So far this is largely a paper exercise; it doesn't address subtyping or consistency checking. But given the documentation and tools that previously have been developed for Larch, it is promising. We are also investigating automatic generation of adapters [P91, T94, YS94] as a way of hiding formal methods from the average user. If the user binds x to y, and y is not a subtype of x, then either the user has made an error or we must generate an adapter that makes the binding consistent. Generating adapters also reduces the need to explain to the user why x cannot be bound to y.

Summary Two goals of precision are clarity and exactness. They conflict. We feel that precision is needed in order to give value to that which is clearly understood, yet clarity is the more important of the two when it comes to large-scale reuse. We obtain exactness through our use of preconditions, post-conditions, invariants and state models in our specification language. Given exactness, we obtain clarity through tools for graphical notations, paraphrasing and automatic verification.

Acknowledgments Francois Bronsard co-authored the work on behavioral subtyping and developed the algorithm for trace extension. I would also like to thank the other members of my group for their discussions and inputs: Voytek Kozaczynski, Jim Ning, Asgeir Olafsson, Edy Liongosari, and John Wetterstrand.

References [A91] P. America, "Designing an object-oriented programming language with behavioural subtyping," Lecture Notes in Computer Science, Vol. 489, pp. 60-90, Springer-Verlag, 1991. [AG94] R. Allen and D. Garlan, "Formalizing architectural connection," in Proc. of the 16'h Intl. Conf. on Software Engineering, IEEE Computer Society Press, pp. 71-80, May 1994. Also as http://www.cs.cmu.edu/afs/cs.cmu.edu/project/compose/www/paper_abstracts/wright-icsel6.html. [B95] F. Bronsard, Using term ordering to control clausal deduction, Ph.D. thesis, University of Illinois, Urbana, tech. report UIUCDCS^R-95-1910, 1995. [BH95] J.P. Bowen and M.G. Hinchey, "Ten commandments of formal methods," IEEE Computer, 28(4):56-63, April 1995. Also as http://www.cl.cam.ac.uk/users/mghl001/10comms.html. [BR92] F. Bronsard and U.S. Reddy, "Reduction techniques for first-order reasoning," Conditional Term Rewriting Systems, Lecture Notes in Computer Science, Vol. 656, pp. 242-56, Springer-Verlag, 1992. [BW86] M.R. Barbacci and J.M. Wing, Durra: a task-level description language, Carnegie-Mellon University, Software Engineering Institute, tech. report SEI-86-TR-3, December 1986.

14

Chapter 1

[BWD93] M.R. Barbacci, C.B. Weinstock, D.L. Doubleday, M.J. Gardner and R.W. Lichota, "Durra: a structure description language for developing distributed applications," Software Engineering Journal, 8:2(83-94), March 1993. [C93] J. Callahan, Software Packaging, University of Maryland Computer Science Department, tech. report CS-TR-3093, June 1993. See also file://thumper.cs.umd.edu/files/docs/umcp-cs.html. [C95] CoGenTex, Inc., "ModelExplainer User Manual," CoGenTex, Inc., 840 Hanshaw Road, Ithaca, NY 14850, USA, October 1995. See also http://www.cogentex.com/modex.html. [CP91] J. Callahan and J. Purtilo, "A packaging system for heterogeneous execution environments," IEEE Trans, on Software Engineering, 17(6):626-35, June 1991. [CW85] L. Cardelli and P. Wegner, "On understanding types, data abstraction, and polymorphism," Computer Surveys, 17(4):471-522, December 1985. [GA095] D. Garlan, R. Allen and J. Ockerbloom, "Architecture mismatch, or, why it's hard to build systems out of existing parts," in Proc. of the 17th Intl. Conf on Software Engineering, pp. 179— 185, ACM Press, April 1995. Also as http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_abstracts/archmismatch-icse 17.html [GH93] J.V. Guttag and J.J. Horning, Larch: Languages and Tools for Formal Specification, SpringerVerlag, 1993. See also http://larch-www.lcs.mit.edu:8001/larch/. [GP95] D. Garlan and D. Perry, "Introduction to the special issue on software architecture," IEEE Trans. on Software Engineering, 21(4):269-74, April 1995. [H93] Urs Holzle, "Integrating independently-developed components in object-oriented languages," in Proc. of the European Conf. on Object-Oriented Programming, Springer-Verlag, July 1993. Also as http://www.cs.ucsb.edu/oocsb/papers/oop-components.html. [HS96] T. Halfhill and S. Salamone, "Components everywhere: Microsoft's Network OLE and OMG's CORBA are competing to distribute components on your network," Byte, pp. 97-104, January 1996. [HU79] J.E. Hopcroft and J.D. Ullman, Introduction to Automata Theory, Languages and Computation, Chapter 3, Addison-Wesley, 1979. [K92] G. Kiczales, "Towards a New Model of Abstraction in Software Engineering," in Proc. of the IMSA '92 Workshop on Reflection and Meta-level Architectures, 1992. [K94] G. Kiczales, "Why are black boxes so hard to reuse?," invited talk at OOPSLA '94 and ICSE '95. See also http://www.parc.xerox.com/spl/projects/oi/. [KH94] H. Kilov and B. Harvey, ed., "Precise behavioral specifications in 0 0 information modeling," in Addendum to the proceedings (of OOPSLA '94), OOPS Messenger, 5(4): 137-142, SIGPLAN ACM, October 1994. [KLM94] D. Katiyar, D. Luckham, and J. Mitchell, "A type system for prototyping languages," in Conf. Record of POPL '94: 21s' ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, ACM Press, January 1994. [KLN95] W. Kozaczynski, E. Liongosari, J. Ning and A. Olafsson, "Architecture specification support for component integration," in Proc. of the 7th Int. Workshop on Computer-Aided Software Engineering, pp. 30-39, IEEE Computer Society Press, July 1995. [KMS92] J. Kramer, J. Magee, M. Sloman, and N. Dulay, "Configuring object-based distributed programs in REX," IEE Software Engineering Journal, 7(2): 139-^9, March 1992. See also http://www-dse.doc.ic.ac.uk/. [KN96] W. Kozaczynski and J. Ning, "Concern-driven design of a specification language supporting component-based software engineering," a position paper to appear in Proc. of the 8th Intl. Workshop on Software Spec, and Design (at ICSE-18), March 1996. [LKA95] D.C. Luckham, J.J. Kenney, L.M. Augustin, J. Vera, D. Bryan and W. Mann, "Specification and analysis of system architecture using Rapide," IEEE Trans, on Software Engineering, 21(4):336-55, April 1995. See also http://anna.stanford.edu/rapide/rapide.html. [LV95] D.C. Luckham and J. Vera, "An event-based architecture definition language," IEEE Trans, on Software Engineering, 21(9):717-34, September 1995. [LVC89] M. Linton, J. Vlissides and P. Calder, "Composing user interfaces with Interview," Computer, 22(2):8-22, February 1989.

Exactness and Clarity in a Component-based Specification Language

15

[LW93] B. Liskov and J. Wing, "Specifications and their use in defining subtypes," in Proc. ofOOPSLA '93, ACM SIGPLAN Notices, 28(10): 16-28, October 1993. Also as http://www.mit.edu:8001/afs/cs.cmu.edu/project/venari/www/oopsla93.html [M88] B. Meyer, Object-oriented software construction, Prentice-Hall, 1988. [M92] B. Meyer, "Applying design by contract'," Computer, 25(10):40-51, October 1992. See also http://www.eiffel.com/doc/manuals/technology/contract/. [M95] Daryl McCullough. Personal conversation. CoGenTex, Inc., 840 Hanshaw Road, Ithaca, NY 14850, USA, [email protected], December 1995. [MKS89] J. Magee, J. Kramer and M. Sloman, "Constructing distributed systems in Conic," IEEE Trans, on Software Engineering, 15(6):663-75, June 1989. [095] Object Management Group, Inc. The Common Object Request Broker: architecture and specification, Revision 2.0, OMG Headquarters, 492 Old Connecticut Path, Framingham, MA 01701 USA, July 1995. See also http://www.omg.org. [P89] Dewayne Perry, "The Inscape environment," in Proc. of the ll'h Intl. Conf. on Software Engineering, IEEE Computer Society Press, pp. 2-12, May 1989. [P91] J.M. Purtilo, "Module reuse by interface adaptation," Software—Practice and Experience, 21(6):539-556,Junel991. [P94] J.M. Purtilo, "The Polylith software bus," ACM Trans, on Programming Languages and Systems, 16(1): 151-74, January 1994. See also file://thumper.cs.umd.edu/files/docs/tr.html. [S95] G.S. Sivaprasad, Larch/CORBA: specifying the behavior of CORBA-IDL interfaces, Iowa State University, Department of Computer Science tech. report TR-95-27, November 1995. Also available as http://www.cs.iastate.edu/tech-reports/TR95-27a.ps. [SDK95] M. Shaw, R. DeLine, D.V. Klein, T.L. Ross, D.M. Young and G. Zelesnik, "Abstractions for software architecture and tools to support them," IEEE Trans, on Software Engineering, 21(4):314—35, April 1995. Also as http://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/www/paper_abstracts/Un iCon. h tm 1. [SH94] S. Sankar and R. Hayes, "Specifying and testing software components using ADL," Sun Microsystem Labs, tech. report SMLI TR-94-23, 2550 Garcia Ave., Mountain View, CA 94043, April 1994. See also http://www.smli.com/research/adl. [T94] S. Thatte, "Automated synthesis of interface adaptors for reusable classes," in Proc. of 21s' Annual ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, pp. 174-87, ACM Press, January 1994. [YS94] D. Yellin and R. Strom, "Interfaces, protocols, and the semi-automatic construction of software adaptors," in Proc. ofOOPSLA '94, ACM SIGPLAN Notices, 29(10): 176-190, October 1994. [ZW95] A. Zaremski and J. Wing, "Specification matching of software components," in Proc. of 3rd Symposium on the Foundations of Software Engineering, ACM SIGSOFT, October 1995. Also as http://www.cs.cmu.edu/afs/cs.cmu.edu/project/venari/www/sigsoft95.html.

2 A FORMAL BASIS F O R S P E C I F Y I N G O B J E C T BEHAVIOUR Antony Bryant School of Information Management, Leed Metropolitan University, Beckett Park, Leeds, LS6 3QS, UK. email: [email protected] Andy Evans Department of Computing, University of Bradford, Bradford, BD7 1DP, UK. email: [email protected]

1

Standards for Object Orientation

In an earlier article [BE95] we outlined a project for formalizing some of the key concepts of object orientation ( 0 0 ) as defined in the OMG's (Object Management Group) core object model. Since 0 0 is premised on interoperability and compatibility it is important that central aspects of the 0 0 perspective provide a consistent basis for development and augmentation. In effect the 0 0 world needs to have standards not only in the sense that there has to be some basis for effective but constrained development, reducing uncertainty and risk [95B]; but also because the essence of 0 0 is cross-platform compatibility and reuse. The OMG's core object model is one attempt to present a set of self-sufficient and consistent concepts which can act as a firm basis for the interdependence and further development of 0 0 products and services. There are alternative approaches to the core object model, some of which may prove to be complementary; but given the size and visibility of the OMG it is likely that some version or variant of the core object model will continue to figure in the 0 0 world. 0 0 demands universality and compatibility in some form, and it is more likely that it will be formed and sustained through a standard founded on cross-industry agreement than by monopoly or overwhelming cartel. The OMG has sought to control change and variety through numer-

18

Chapter 2

ous standards and similar consensus-building activities. This has proved difficult, given the time needed to establish consensus, and the immediate and pressing demands of the market. The idea of a conceptual core model was proposed early on in 0 0 development, and OMG have sought to establish it at the heart of its programme and perspective. In recent years, however, the development of models such as CORBA, and the growth of areas such as 0 0 analysis and design, business object modelling and so on have gone far beyond the scope of the original set of core concepts. This is inevitable in a developing field such as 0 0 ; but rather than jettisoning the idea of a core object model, it is better to analyse the key concepts to see which retain central validity and to inter-relate them in a fashion which will provide the basis for constrained development and innovation. The OMG Object Model Subcommittee has itself started to seek a revised and more rigorous statement of its key concepts, in order that future 0 0 innovations and extensions can be inter-related and reconciled through an agreed and unambiguous standard: Although to date this project has failed to gain sufficient resources and impetus from the OMG constituency. Our earlier paper established the background to this project, and explained the rationale and benefits of this form of standardization. We now wish to restate some of our ideas and exemplify and extend the use of formal notation in OO standardization. A standard, of any form or type, represents a statement by its authors that their work will be understood, accepted and implemented by the market [C89]. The OMG, which claims to be the largest IT consortium in the world, was founded to promote the theory and practice of 0 0 technology in software development. The OMG charter specifies the need for the establishment of industry guidelines and object management specifications to provide a common framework for application development. An important part of the OMG's work has been the development of a standard model of object technology concepts. This aims to serve as a basis for the standardized implementation of object technology, rather than its currently ad hoc usage. But the OMG itself has no power to sanction standards, and must rely on voluntary adherence to such initiatives. This bears out the argument of authors such as Carl Cargill who sees voluntary standards as appropriate to volatile areas with competing technological and application solutions available; where there are intense user and provider dynamics. As a consequence, any such standard will only survive if it can attract and sustain the support

A Formal Basis for Specifying Object Behaviour

19

of contending and potentially divergent interests. A firm business case has to be made for resourcing the development of such a standard. Given the rapid development of 0 0 , a standard in the form of a product specification would be a futile and short-lived gesture. But standards do not have to be product based; conceptual standards are an alternative and certainly more appropriate form in this context. Conceptual standards arise increasingly in fragmented, non-monopoly markets where different networks of products and services must be integrated; but where it is extremely improbable that any single supplier can exert dominance. This is presently the case with 0 0 . Competition between different networks of products and services is unlikely to result in the emergence of a de facto standard, and the only feasible solution is for all the main providers to co-operate in promoting a common and neutral basis requiring minimal migration costs for users of their specific commodities. For 0 0 , such a conceptual foundation is critical since it will be needed to provide a basis to support the portability and interoperability of object systems across a wide variety of technologies. The OMG's core object model is an initial element of this in identifying and defining a small set of key 0 0 concepts that characterize the object technology domain. The core model is meant to represent the essential basis of object orientedness, distinguishing the OO view from other views. In addition, the core model ought to be common to all OO products, methods, tools and the like. If this essence of 0 0 can be well established, and unambiguously specified, then other 0 0 developments in a variety of disparate dimensions can be reconciled and understood, being seen as verifiable extensions emanating from the core. The OMG has been successful in initiating several 0 0 standards-type projects. Its most notable development has been CORBA, the Common Object Request Broker Architecture for object communication. This is already starting to be applied in practice, although some would contend that it is not yet fit for full application, and remains more a marketing device. Other emerging specializations include, Object Analysis & Design, PCTE, Object Databases and Business Object Modelling. In fact the OMG can be seen to be in the business of producing and managing a range of conceptual standards: All voluntary, and all aimed at future developments, rather than at stabilizing the present or immediate past. As one commentator put it (albeit in a slightly different context) A standard ... can be envisaged as a plan that represents the proposed activities of the industry in dealing with an issue.

20

Chapter 2 .... a standard is the written solution to a future industry problem - [C89,28/9]

Unfortunately attempting to stabilize and develop from a core model has proved difficult, with the rapidly expanding range of products, services, and varying supplier and consumer interests. The result has been that the core model has become tangential to many developments of 0 0 technology. Yet there is still the need for some fundamental statement of object orientedness, and the benefits of a rigorous foundation for the overall programme of 0 0 developments should not be underestimated: Not least because it can contribute to arbitration between competing innovations, and offer a range of assurances for information systems investment strategies. There ought, therefore, to be a good deal of interest in a realignment of 0 0 developments against a restated and revised core model. If the set of central 0 0 concepts is to act as a standard, in the sense of being a consistent and predictable expectation, then it must be restated in a form which is both rigorous and verifiable. In addition, if it is to help in ensuring the soundness of extensions into other aspects of 0 0 , a formal definition would appear essential. Earlier work illustrated that the core model contained several ambiguities and redundancies in its informal definition. The core object model is the responsibility of a subcommittee of the OMG, who undertook a number of related projects designed to clarify the models concepts and its relationships to the emerging, and possibly diverging, variety of OO technologies. Reconciling these was becoming a complex task, and by late 1994 it was becoming recognized that the core object model had to be revised and expanded to define a common object semantics for specifying the characteristics of objects in a standard and implementationindependent way. 'Only in this way could the model define a set of requirements that must be supported by all OMG-compliant systems' [OMG94], The 1992 version of the model (core92) consisted of a small number of concepts and their inter-relationships, representing the minimum, but essential, view of 0 0 . The present objective is to revise this primary statement of object orientedness so that it is as succinctly and consistently specified as possible. The intention being to provide [concept] descriptions that can be used to underpin a substantial part of the information technology industry. For this reason it is imperative that such descriptions are as clear and unambiguous as possible. Once this has been accomplished, the subcommittee will be able to decide

A Formal Basis for Specifying Object Behaviour

21

whether additional 0 0 profiles (i.e. applications of and extensions to object technology) are technically sound; compatible with core, compatible with other profiles, and not redundant. These four properties cannot be assured without a formal statement of the model; although this may in itself not be sufficient.

2

The Concepts & Their Formal Specification

The formal, mathematically expressed notation will be used as an additional expression of the model itself. The concepts of the model can be translated into the selected notation Z [S92], which is widely recognized as a standardized notation, and is available in tool-supported forms which include automated checking facilities - i.e. a Z specification can be run through a type-checker in much the same way as source code can be run through a compiler, and with similar forms of error reporting. This is not to say that everything that can and should be said about the core object model can be restated in formal terms; but as a minimum, the meaning of the concepts, and their inter-relationships ought to be restated in this unambiguous and testable format. Since most practitioners are not able to understand the formal notation, a further step must be to produce an enhanced, textual restatement of the model, based on the Z version. (This mimics the use of database query languages by people who have no need to understand the relational calculus or tabular representation of the data, but who do know about their own field of competence, and the ways in which the stored data needs to permit and control facilities for specific enquiries, updates and dependencies.) With a view to the necessity for a more rigorous and standardized statement of the core object model, the Object Modelling Subcommittee decided that four levels of description will be required: English language description - the concepts and relationships between them Formal specification - formally defining the concepts and relationships Glossary - brief description of all terms used Translation of terms - agreed translations into languages other than English

22

Chapter 2

For the 1992 version, the concepts which the Object Modelling Subcommittee offered as core, and requiring precise definition were as follows: object operation signature operation name parameter parameter type result non-object object interface type - only a partial definition - i.e. interface type interface inheritance request In addition, a number of less precise terms were included: object identity exception behaviour values denotable values type - full definition supertyping subtyping refinement

A Formal Basis for Specifying Object Behaviour

23

collective behaviour response information substitution As these two groups of concepts illustrate, one of the problems of trying to give a complete list of the fundamental 0 0 concepts is that it is almost impossible to gain a consensus for any resulting set of terms. There will be arguments for the inclusion or exclusion of individual terms; and also unresolved arguments concerning the meaning of individual/ items. It is therefore unwise to try to derive a complete formal specification for these concepts at the first attempt. There must be an incremental approach, which works from a small subset of concepts, gradually expanding to include others. One early and noteworthy effort by Houston &; Josephs [HJ95], sensibly sought to evade the issue by singling out four higher-level concepts deemed fundamental to 0 0 : Type Inheritance Hierarchy Operation. In our earlier paper [BE95] we likewise did not attempt to offer a fully-fledged formal model of all concepts in the core object model; but instead concentrated on outlining a strategy aimed at producing a formal syntax and semantics for the constituents of the model. As such we only sought to develop formal specification of a limited subset of 0 0 structural concepts. We now wish to extend our work to include the key concepts that specify object behaviour, and so our approach must be able to encompass aspects such as operation, state and behaviour. We accomplish this by adopting a message passing model.

3

Formalising Object Behaviour

This section describes how the Core Object Model can be extended to include the aspects required to specify object behaviour. Although a valuable starting point, Houston and Josephs' specification of the Core Model does not fully describe the behaviour of an

24

Chapter 2

operation in terms of the state changes it causes. In addition, an operation may be invoked by the environment or other objects in the model. These are both requirements of the Core '92 model. A further requirement of the Core '95 model is that it will improve the portability and interoperability of systems by describing the behaviour of objects; presumably by describing the allowable behaviours of collections of objects over time. In order to incorporate behaviour in the standard model, two extensions will need to be made. The first is to introduce the notion of state in order that the actions caused by operations can be described. The second is to incorporate the concept of operation behaviour so that the overall behaviour of the system can be determined. We shall consider these two aspects in turn and and examine their requirements in detail l

3.1

State

We first specify the object types that are available in the Core Object Model as presented in [HJ95]. We assume that there is a given set: [TypeName] from which the names of all types can be drawn. The types available in the model consist of object types, non-object types (e.g. numbers) and abstract types. To express this three finite sets of type TypeName are declared in the schema Types: Types oTypes, nTypes, abstract : F TypeName disjoint(oTypes, nTypes) abstract C o Types The constraints of the schema state that: an object type cannot have the same name as a non-object type; and that any abstract types must be object types. 1

Note that for reasons of space we will not attempt to prove that these concepts are compatible extensions of the Core. However, this should not be a difficult task to prove.

A Formal Basis for Specifying Object Behaviour

25

The concept of state can now be specified. This is an extension of the Core Object Model as defined in [HJ95]. We assume that there is a given set: [State] which is the set of all possible states that an object type may be in. The schema States can now be written. It expresses the fact that every object type has a state: States o Types : F TypeName states : TypeName -+• State dom states = oTypes The constraint of the schema is that every object type (and nothing else) has a state.

3.2

Operation Behaviour

We assume that there is a given set: [OpName] from which the names of all operations can be drawn. Before we can define the schema Operations we specify the signature of an operation. It consists of an operation's name, a parameter list and a returned list: Signature name : OpName parameters : seq TypeName returned : seq TypeName We are now in a position to specify the schema Operations. This expresses the fact that every object type provides an interface. This is similar to that defined in [HJ95]. Operations oTypes : F TypeName interface : TypeName -+> F Signature dom interface = oTypes

26

Chapter 2

However, the schema Operations does not fully describe the behaviour of an operation in terms of the state changes it causes. In addition, an operation may also be invoked by the environment or other objects in the model. Before extending the above schema we must first describe an invocation. It consists of a list of parameter values that are to be sent to the invoked operation and an id and name which identify the invoked object and operation: [Parameter Val] Invocation parameters : seq Parameter Val id : TypeName name : OpName The extended schema Operations! can now be specified. It includes Operations but extends it with a relation next which describes the allowable actions that the operation may perform. This relates a list of input parameter values and a 'before' state with an 'after' state, a set of other operations to be invoked and a returned value list: [Return Val] Operations! Operations next : TypeName -+> ((seqParameterVal x State) <-* (State x Invocation x seq Return Val)) dom next = oTypes The constraint of the schema expresses the fact that every object type (and nothing else) has a next relation.

3.3

System Behaviour

At any point in time there may be a number of requests to invoke an operation that are pending. The schema Pending describes this fact: Pending invocations : seq Invocation

A Formal Basis for Specifying Object Behaviour

27

Before we can define the meaning of operation invocation we need to introduce the complete Core Object Model. This is described by the schema CoreObjectModel which includes the four concepts described above: _ CoreObjectModel Types States Operations! Pending We are now in a position to describe what it means to invoke an operation. This is expressed by the schema Invoke. It selects a pending invocation, and applies it to the selected object instance (obj) and appropriate operation (op). The state of the invoked operation is changed and the pending request is deleted from pending: _Invoke CoreObjectModel CoreObjectModel' obj : TypeName op : Op Name return : seqReturnVal invl, inv\ : Invocation pos : N newstate : State (pos, invl) G invocations obj G oTypes obj = invl.id op G {i : interface (obj) • i.name} op = invl.name ((invl.parameters, states(obj)), (newstate, invl, return)) G next(obj) invocations' = ({pos} < invocations) ^ (invl) states' = states © {obj ^ newstate} o Types' = oTypes interface' = interface next' = next

28

Chapter 2

Because an invocation of an operation may result in a change of state, two copies of the Core Object Model have been introduced. The first copy, containing undashed components, describes the before state of the system. The second copy, containing dashed components, describes the state after the invocation. Finally, the overall behaviour of the model can be specified by describing the sequences of computations (state changes) that would be generated by the repeated execution of the system over time. This is described by the schema Behaviour: Behaviour E : P(seq CoreObjectModel) E = {a : seq CoreObjectModel | a ( l ) G {Initial • 9CoreObjectModel} A (Vn:Ni« a(n + 1) £ {Invoke \ 9CoreObjectModel = cr(n) • 9 CoreObjectModel'})} where Initial is a schema describing the valid initial states of the model. The schema states that: a computation a is a valid behaviour of the file model, if its first step belongs to the set of initial states, and each of its subsequent members belongs to the set of possible states resulting from the application of Invoke to the previous state. 3.4

Concurrent Behaviour

A further advantage of the above specification is that it could be used to describe concurrent behaviour. For example, if there are a number of invocations pending, then Invoke will non-determinstically choose one of the pending operations and invoke it. However, any one of the other invocations could have been chosen resulting in a set of possible execution orders. Thus, the concurrent behaviour of the model is described by a non-determinstic interleaving of allowable invocations. This specification approach builds on recent work which shows how concurrent systems can be specified and developed using the standard Z notation [E96] and [N95]. As noted by other authors in the standards field [B95b], there is a lack of formal notations which are suitable for specifying both state and behaviour. The majority of notations are either good at specifying state, e.g. Z, VDM, etc or good at specifying behaviour, e.g. LOTOS, CSP. Thus, describing properties of standards

A Formal Basis for Specifying Object Behaviour

29

such as ODP, which encompass both state and behaviour requires the use of a hybrid notation, e.g. LOTOS and Z [ST95]. 2 Thus, by using the specification approach outlined here it should be possible to specify and develop both the static and behavioral aspects of the Core Object Model within a single, standardised notation.

4

Conclusion

Although we would not accept that the development of 0 0 technology is the panacea many believe (see [BE94]), the sheer volume and interest provoked by 0 0 ensures that all those involved in software development must pay it some attention. Whatever its limitations prove to be, the current pace of innovation and take-up of 0 0 technology mean that it is crucial for the overall 0 0 project to appear well supported and rigorously defined: And even well-understood. Now that any initial exploratory phase has passed, innovation must be constrained to some extent, in order that suppliers and customers alike can base their systems strategies on 'consistent and predictable expectations' - i.e. on standards: And these conceptual standards must be specified along the lines detailed above if they are to have any resilience and claim to credibility.

5

References

[ABS94] Aujla, S., Bryant, A., & Semmens, L., 'Applying Formal Methods within Structured Development', IEEE Journal on Selected Areas in Communications, February 1994, volume 12, no 2 [B95b] Bowman, H., et al, 'FDTs for ODP', Computer Standards and Interfaces, vol 17, nos 5-6, 1995. [B95] Bryant, A., Standardizing SSADM: Methods, Standards & Maturity, McGraw Hill, 1995 [BE94] Bryant, A., & Evans, A., c 0 0 Oversold', Information & Software Technology, vol 36, no 1, 1994 [BE95] Bryant, A., & Evans, A., 'Formalizing the Object Management Group's Core Object Model', Computer Standards and Interfaces, vol 17, nos 5-6, 1995, [C89] Cargill, C, Information Technology Standardization, Digital Press, 1989 2

It has been pointed out that the demand for notations other than Z emanates from the computational rather than the informational perspective.

30

Chapter 2

[E96] Evans, A., 'Z for Concurrent Systems', PhD Thesis, Leeds Metropolitan University, April, 1996. [HJ95] Houston, L, & Josephs, M., The OMG's Core Object Model and compatible extensions to it, Computer Standards and Interfaces, vol 17, nos 5-6, 1995. [OMG94] OMG, Object Models, draft 0.2, October 1994 [S92] Spivey, J.M., The Z Notation, 2nd Edition, Prentice Hall, 1992. [ST95] Sinnott., R. O. & Turner., K. J. 'Applying Formal Methods to Standard Development. The ODP experience', Computer Standards and Interfaces, vol 17, nos 5-6, 1995.

3 INFORMATION REFRACTION William Harvey Karen Bilotta Cynthia Grese Institute for Information Management Robert Morris College harvey@robert-morris. edu INTRODUCTION Gartner Group Consultants have estimated that a typical mid-size company could spend as much as $3 to $4 million in personnel and computer resources to make the "turn-ofthe-century" (01-01-00) transition [IBM96]. According to the most recent studies conducted by the American Bankers Association (ABA), incidents of check fraud have more than doubled over the past few years (over 1.3 million cases are documented) and industry losses are mounting rapidly - ranging from $568 million to $815 million [BSY96]. In April, 1994, a major financial consulting firm alleged that a government bond trader had created $350 million dollars of "nonexistent profits" with the misuse of a decision support system [M95]. In all of these cases the properties of information technology play a key role. Many more such examples can be accumulated easily. In each case above, we may assume that as decisions were made to automate certain transactions and to utilize the tools of information technology, the kinds of damage described were not anticipated. Given the complexity of the technology and the applications task, and the volume of data to be processed and the volume of programming code making up the applications, the organizations involved discovered that attractive solutions were associated with threatening, as well as beneficial, effects. To comprehend the nature of such circumstances, and to help organizations comprehend and embrace the techniques and strategies described in this volume, a framework is needed in which the properties of information technology can be described for purposes of decision making. CONCEPT OF INFORMATION REFRACTION Because we employ information technology extensively today, our risk for encountering distortion and misinterpretation as we use this technology, amplified by the power of automated information systems, is substantial. Many users of the tools offered by information technology take the accuracy of a computer-generated report for granted and routinely omit to consider the possibility of erroneous results of processing. The refined hardware and software resources, which, when taken together, combine to support an application we might like to use, present a level of complexity which no single person is likely to comprehend beyond a general sense.

32

Chapter 3

We understand that common tools, such as shovels, are constructed according to a certain model of behavior in use and for appropriate modes of use which have been taken into account in the development of the model. Shovels, as compositions, have certain properties and the components of the shovel, made of different materials and each with a certain physical design, have certain properties. The concept of information refraction is proposed here in an effort to facilitate the understanding of the properties of tools offered by information technology, and their components, and thereby make easier the task of avoiding misuse (or inhibiting abuse) that produces harmful results. Just as shovels and other common tools are understood within the context of their use, we want to consider the properties of information technology within proper societal and organizational contexts. The failure to address issues relating to proper use and behavior of any technology can have negative impacts for users. The failure to address such issues relating to a powerful technology in wide use can impact large numbers of people, large organizations, and even society. According to Nancy Leveson, author of Safeware, "treating technology apart from its impact on society can lead not only to negative social consequences, but also to unrealistic and unusable technology" [L95]. The idea of reusing, in information technology, some components from refraction in optics focuses on the following: Information transfer between any two environments involves a boundary between the two environments, each of which has respective distinct representational and operational properties; environments are divided into users (endpoints of purposeful information use operations in which information transfer occurs; originators or consumers capable of defining, determining, and understanding purpose) and processing media (technological or human) other than users. All use of information requires transfer of information across a boundary between a user and a processing medium, or between two processing media. Information technology involves at least one user and a processing medium, thus, minimally, transfer of information across at least one boundary; a single user may originate and consume information transfer, as part of a single, possibly temporally extended, information use operation. In the simplest model, the processing medium has different properties from the user environment with respect to the representation and manipulation of data that determine, within the context of a given information use operation, what data should be used for what purposes, and how those data come to signify information. The properties of a given environment, or processing medium, are determined by design, by the properties of the logical structures employed (such as models and algorithms) and the inherent artifacts of the logical systems used in logical constructions, and by the limitations of computational (technological) implementation of logical structures and of the operations which are utilized in designing algorithms. Both procedural and declarative strategies or processing are vulnerable to impact. There is a boundary between user environment and processing medium. The most obvious manifestation of this boundary is the human-

Information Refraction

33

machine interface (terminal). In an organizational context of use of information technology, a processing medium may be understood as the composition of at least one technological processing medium and any non-technological processing media, i.e. people, required to transfer information between a user and a technological medium. Therefore the boundary may in effect be wherever a user "turns something over to the computer." Any boundary may effectively be associated with an encapsulation of properties which results in obscuring or concealing unintended processing effects. In using computer-based information technology, information must be organized in a certain way to be communicated (transmitted, transferred) to it. The representation in the information system will not be exactly like what the user imagines. The model used to control the representation must be represented in ways the computer can use. Information refraction is not the occurrence of error itself, but the effect of one or more properties of automated information technology which contribute to error, possibly because of a failure to appraise the properties correctly. Some information which is intended to be transferred into a system for some purpose does not reach the computer system, but appears to do so. The intended content of the representation of output may be misinterpreted in the process of using it. The semantic integrity of information may be lost. Information refraction consists of certain properties of information systems which are present, through design or inherently and whether intentionally present through correct design or accidentally present through incorrect design, and must be dealt with carefully to obtain intended results. Among the causes of information refraction are variations in representation (external for input, internal, external for output) that guarantee changes ("deviations in path") which may be sufficient to prevent equivalence in meaning. Common computational artifacts of information technology, such as the use of binary representation of fractions, some of which have no exact equivalent in decimal fraction representation, have the potential to affect meaning. People communicate every day through languages. A language is a means of conveying messages and information. The vocabulary of a language reflects everyday differentiations regarding a person's environment. It is in the boundaries of these environments that the potential for information refraction arises. Furthermore, in recent years there has developed an increased awareness of and a need for information systems. These systems fulfill the role as the interface between organizations and their environments. To deal with information technology problems that have developed, an approach to computer information systems has been proposed, semantic analysis. This approach addresses responsibilities and norms in business decision-making and focuses on the interaction between information systems design and organizational design. Semantic analysis leads to a representation of the responsibility structure and addresses problems of meaning. Webster's Dictionary has multiple definitions for information. The following is closely related to the phenomenon of information refraction. "Information: when data are filtered through one or more processors it takes on meaning and value to a person"

34

Chapter 3

Webster's Dictionary defines information as "when data are filtered through one or more processors it takes on meaning and value to a person"[G87]. This definition helps distinguish data from information, with data being raw facts, without any organized meaning. Information is also defined as what is known, believed or alleged to be true and has a capacity for increasing knowledge. Refraction, as defined by Webster, is the bending of a ray or wave of light, heat or sound as it passes from one medium to another. As a ray or wave passes through the boundary between two media, passage between the media is associated with a deviation from the original path through the first medium.

Information refraction can be understood to signify that as processed data/information takes on value and meaning, it passes through a medium and deviates from its intended path. The original value/meaning becomes distorted as it is processed through a medium resulting in an unintended perceived value/meaning. The meaning/value of information is imperceptibly altered as the aggregate data/information are reconfigured by a marginally imperfect processing system/routine. With information refraction, data are processed, but the actual output varies from the intended results to a degree that the meaning of the information is regarded as distorted or incorrect.

INFORMATION REFRACTION AND ITS EFFECTS To understand the consequences of computer technology for people, it is useful to see computers as artifacts of human activity, as educational environments, as work tools, and as a medium for communication [C94]. It is important when analyzing and designing a model, that a suitable approach be formulated when transforming or constraining the context of user activity. In most organizations, this method is the only way to preserve control over a model's design and usefulness.

Archiving or preserving the content, structure, context, and meaning of electronic information is important. Disaster can occur if control mechanisms are not implemented in organizations to prevent key records from being destroyed. Because physical records contain patterns that give this electronic information its content and context, it is critical to determine a set of protocols to capture, maintain, and use electronic records. If reliable methods are not adopted by an organization, the long-term memory of modern institutions will be in jeopardy if the records are destroyed or distorted through the record transformation.

Information Refraction

35

citizens... with every conceivable kind of information...from a lyric poem to a Newspeak dictionary" and there are "vast repositories where the corrected documents were stored, and the hidden furnaces where the original copies were destroyed," large-scale data manipulation can, of course, be implemented electronically with today's technology. Proper safeguards are needed to eliminate blatant or subtle and accidental as well as intended impacts of information refraction. As computer technology progresses, the probability of unpredicted significant effects from information refraction increases. The complexity of advanced computing systems is outpacing the user's ability to take advantage of the systems. Researchers are racing to develop more efficient computing concepts and ways to improve existing systems. Challenges lie in the ability to take advantage of that computer power and to manage effectively the complexity of computer technology and in understanding the behavior of software interfaces. Information modeling, formalization and specification are complex. Formalization and specification are the "infrastructure" or the underlying foundation for object-oriented approaches. Formal methods play an essential role in making a system specification explicit and understandable. As a result, these methods are often taken for granted. Information refraction effects are encountered when formal methods are not used, leading to inconsistent or ambiguous models. Providing clear, explicit models and designs will help convey precise and relevant data, initially and over time. Accurate specification and validation of information requirements is critical to the development of organizational information systems. Semantic DBMS models were developed to provide a precise and unambiguous representation of organizational information requirements and therefore serve as an interactive vehicle between analysts and users. Object modeling attempts to find order and patterns so object collections are created. In mathematical theory, these collections may be referred to as classes. The objects belonging to the class are referred to as elements. To be useful, the class and objects must be predefined. It must be possible to categorize object properties to be able to distinguish which elements belong to which sets. Change is a major contributor as to bringing the philosophy of object-oriented design and object modeling to the forefront of business information prototyping. The objects that are to be used in business modeling are dealing with "complex sequences that involve multiple objects interacting in unpredictable ways." [P96]. This unpredictable impact of imperfect models will cause adverse affects to all types of business and industry computer applications. A seamless transition must be made between object analysis and object design. The properties of the objects of these systems must be defined. While defining these properties the boundaries of these transmission systems are created. A common boundary of these systems is the graphical user interface (GUI). A GUI is a software feature that allows a user to use screen icons, dialogue boxes, drop-down menus, and scroll bars by pointing and clicking a mouse. This is less intimidating for some individuals than typing commands from a keyboard.

36

Chapter 3

In today's technological society, tasks are accomplished through a collaborative effort of man and machine. For a given model the machine is "unaware" (possesses no manipulatable representation) of the capabilities of the operator and the operator is unaware of the complexities of the system. Information must be organized in a certain way to be communicated (transmitted, transferred). The representation in the information system will not be exactly like what the user imagines. The model to control the representation must itself be represented in the ways the computer can use. One must remember human thought does not easily transfer to binary code. The valuable function of the interface is to bridge the gap between man and machine, just like an interpreter translating between two people speaking different languages and an interface exists potential for information refraction. The possibility for impacts from information refraction lies in the transmission of data across such boundaries as from user to user, machine to machine, and user to machine. As two different interpreters may translate the same conversation with different perceived meanings, computers translating from one software to another will encounter similar difficulties. The most obvious boundary manifestation is the human-machine interface (terminal). Often the mistaken goal is to reduce keystrokes and from earlier generations of technology we inherit a preoccupation with conserving storage. The ultimate goal should be to avoid distortion through information refraction. Information refraction effects can occur with the use of another "time-saving" technique. This technique is the use of defaults. Any system that uses defaults should have some type of mechanism that makes the user aware of this built-in hidden complexity. A potential problem for information systems is the use of two digits to record dates in computers. A prime example of this default is programming the date with MM-DD-YY instead of MM-DD-YYYY. This complexity is now resulting in the "turn-of-the-century" or "millennium bug" confusion for information systems. However, in the year 2000, when the arithmetic is performed on these 2-digit dates by computers the results may be unpredictable. Errors will have to be corrected line by line, system by system in a timeconsuming process to get systems back into production EXAMPLES OF INFORMATION REFRACTION EFFECTS Information refraction can occur in the treatment of data, the model used, and the user's perception. Often situations occur where information refraction overlaps in these three areas. An individual needs to understand that no matter how sophisticated an input system is and no matter how well thought out the input methods are, the risk of generating inaccurate or useless information remains. The completeness and accuracy of information produced by a computer system depends on how much care was taken in capturing the raw data that served as input to the processing procedure. GIGO Garbage In, Garbage Out is a term that summarizes this point. If the user inputs incomplete and inaccurate data (Garbage In), then expect the information that is produced to be correspondingly incomplete and inaccurate (Garbage Out). Therefore, the quality of output is dependent on the quality of input.

Information Refraction

37

Opportunities to provide repackaged information are unlimited. Individuals take data from various sources, reorganize it and sell the resulting package as a solution [W88]. One such example is Physician's Alert which was a solution to the problem of increasing malpractice litigation. Physicians using this service could obtain information regarding whether or not a current patient had previously filed a malpractice suit. Statistical studies had produced results that indicated that patients who previously filed suit against one physician had a higher probability of filing suit against another physician. Use of this package resulted in refusal of service to individuals who had no intention of filing a second lawsuit as intention could not be represented by these means. In today's time-conscious society, individuals want access to data right now when they need it, whatever time, day or night. In response to these needs, corporations attempt to gain a competitive edge with instant access. Here lies another potential for effects from information refraction. In a banking environment, there can be delays in processing an electronic transaction. From time-to-time the bank will need to halt operations to perform a batch update. Therefore, an accurate account balance may not be given to the customer. Information refraction can deliver the antithesis of WYSIWYG, What-You-See-IsWhat-You-Get, when the wrong model is utilized: WYSINWYG - What-You-See-IsNot-What-You-Get. This can occur due to a special case constraint that was not brought to the attention of the model developer. This "I forgot to tell you" syndrome is a common business occurrence. It is possible for a model to be misused, leading to misinterpreted results. A user is unaware of complexities that occur with a simple touch of a screen or a key. The risk of using such a model entails the possibility of an unacceptable outcome. The use of a model should match the decision maker's level of risk tolerance. The saying, "if it's not broke, don't fix it," applies in these situations. When the results have a positive affect, the user does not question the model which produced these results. For example, on some occasion in a purchasing environment, an encumbrance may not be not posted to the system properly. A person viewing a cost center report will believe there is more money in the cost center than there actually is. The effects stemming from the incomplete specifications used in building the model could result in the company not meeting its financial obligations. Erroneous use of technology may occur in using software where there are hidden complexities in the system because the model is not appropriate for all situations of use and a user in certain cases may invoke unintended properties. In some circumstances it may not be clear whether the user of the software is aware of apparently inappropriate actions caused through the use of the software. The bond trading case study is a prime example of this situation. A government bond trader "pushed a touch-sensitive screen" and the computer displayed a transaction as a profit [M95]. However, this transaction was considered an even trade with the Federal Reserve, known as reconstitution, in which case no profit should have been realized. The auditors reviewed these profitable transactions for two years before information refraction was detected. There are

38

Chapter 3

different viewpoints in this case as to whether the profits were generated by the software user without awareness of the impact of the special case, whether management was aware of the limitations of the software and failed to restrict use of it in accordance with these limitations, and whether the specification recognized the potential for using the software to execute transactions of a class for which no profit would be realized. Many remember the Challenger disaster. Dianne Vaughan, a professor of sociology at Boston College, spent nine years investigating the organizational culture at NASA [W96]. Ms. Vaughan retraced the disaster to years before when NASA began a decision-making process hinging on the concept of "acceptable risk - the idea that danger is inherent." One such example is the O-rings which seal the joints and contain the engine gases of the solid rocket boosters. Documentation dating back to 1977 cites increasing charring of the O-rings from one flight to the next. Each time the O-ring conditions were reviewed by NASA, this problem was allowed to continue, as the extent of acceptable risk was reinterpreted, based on the single instance of deviation from the prior interpretation of risk. Consequently, the O-ring situation escalated as erosion was repeatedly determined on successive occasions to be normal and therefore, acceptable. Absolute deviance was obscured. Furthermore, as deviance became the norm for NASA, or as NASA accepted some damage for components that were not to have any damage, decisions as to whether to launch the space shuttle or not were based on this acceptable risk process. The eve of the Challenger launch presented circumstances that affected NASA's decision-making procedure. Accounts indicate that manufacturers of the solid rocket boosters recommended against the launch due to record cold temperatures. The launch team had never encountered such critical technical concerns right before a mission. Furthermore, a late night conference call discussing whether or not to launch the Challenger added only more confusion, especially when some empirical data contradicted the reasons given not to launch. As a result, the intended meanings of some of the comments were not received by people hundreds of miles away and the comments were misunderstood. Using guidelines and measures which had been so altered that they were rendered inappropriate, NASA's managers followed the acceptable risk theory. The potential for error was unrecognized. Over time as more managers bought into the "acceptable risk theory," what was or was not acceptable became ambiguous, leading to a deviation from the intended meaning of data. CONTROLLING INFORMATION REFRACTION Quality is a key buzzword for businesses in the 1990s. Businesses focus on computerized information systems as strategic, and therefore mission-critical, assets in gaining a competitive edge. This results in the need for an improving formal specification. By adhering to formalization, information refraction effects can be reduced, and possibly even eliminated in most cases. The first step is developing a process/problem definition, understanding precisely what the user needs. This is essential because the most sophisticated system is rendered useless if the user is unable to access pertinent information. In many instances, sufficient time is not spent incorporating user's ideas, expertise, and feedback. To help

Information Refraction

39

alleviate the potential for bad effects from information refraction, contemplating the use of the information provided by the system is needed. The following are a few areas to consider: verification of the accuracy of the source generating the data; the importance/necessity of the information; timeliness of the information; data security; and usefulness of the data in achieving the business' strategic goals. The second step should be specifying the invariant or the rules of the particular business. The invariant is a set of rules that remains constant or does not change throughout the process. An example of an invariant is, "only an available, open bank teller can serve the next customer from the waiting queue." Now, for each process that is required for complete specification, the preconditions and postconditions must be developed. Precondition is the assertion that should be true before the process is permitted to start. Postcondition is the assertion that should be true as a result of the process. For example, the precondition is "the teller is open and available to take the next customer waiting in the queue." The postcondition is the customer completes the transaction. Step three is to design a model to simulate the "real world" invariants. During this process it is key to keep defect prevention and continuous improvement systems a part of the model. This should include such items as part/transaction characteristics, precondition and postcondition parameters, the level of importance, risk-benefit analysis (acceptable risk), control methods, sampling plan, applicable indexes and some type of measurement precision. Software reliability is of extreme importance in the model development. "Reliability is probably the most important of the characteristics inherent in the concept of software quality" [MIO90]. Recently the flying of commercial aircraft has come under scrutiny: should it be man or machine? Leveson reports that "an F-18 (fighter plane) crashed when the computer assumed it couldn't get into a certain attitude." She comments that most software glitches "are not coding errors. They're really errors in the software requirements." Step four should require testing of the model. Usability testing is a valuable tool to uncover and deal with problems. The objectives of a usability test are to debug, if necessary, critical parts of the user interface and to discover how programmers view the system capabilities. This testing method or the utilization of a similar technique will help eliminate bad effects from information refraction CONCLUSION As information filters through a medium it can be altered or refracted. The value of characterizing this phenomenon as information refraction lies in helping to gain increased awareness of the steps that should be taken to control the phenomenon, which provides an image for better understanding the properties of computer information systems. Prior to the introduction of information technologies with data storage capabilities, such as writing systems or, more recently, automated information systems, society utilized rhyming or singing to help eliminate distortion and information refraction in conveying messages. With the evolution of information technology, it is apparently

40

Chapter 3

necessary to place greater emphasis on formalization and specification in order to minimize, or in most cases, control the negative affect of information refraction. Information refraction consists of certain properties of information systems which are present and must be dealt with properly. One must remember that information refraction is not the occurrence of error itself, but a property which may contribute to error. Information refraction is encountered in our lives in countless ways. By defining and recognizing it, we can increase awareness. The development of any system should assure control of information refraction. References [BSY96] [C94] [IBM96] [F83] [G87] [KR94] [L95] [M95] [MIO90] [077] [P96] [V96] [W88] [Wa96] [We96]

Karen Bilotta, Sanober Sahukar, Wei Yan: Preventative Measures Against Check Fraud. Technical Report, Robert Morris College, 1996. JM Carroll: Making use: a design representation. Comm ACM, 1994. Frequently asked questions about the year 2000 challenge. IBM Corporation, 1996. N Frude: The Intimate Machine: Close Encounters with Computers and Robots. New American Library, 1983. DB Guralnik: Webster's New World Dictionary of the American Language. Warner Books, 1987. Haim Kilov, James Ross: Information Modeling: An Object-Oriented Approach. Prentice Hall, 1994. NG Leveson: Safeware: System Safety and Computers. Addison-Wesley, 1995. M Mayer: "Joe Jett: did the computer make him do it?" People, March 1995. JD Musa, A Iannino, K Okumoto: Software Reliability Measurement Prediction McGraw-Hill 1990. G Orwell: 1984. Harcourt Brace Jovanovich, 1977. J Palmer: "Process objects: back from programming Siberia" Object Magazine. January 1996. D Vaughan: The Challenger Launch Decision, 1996. HS Weitzen: Infopreneurs: Turning Data Into Dollars John Wiley & Sons, Inc., 1988. T Wanat: "The organizational breakdown behind the Challenger disaster" Chronicle of Higher Education, 1996. B Webster: Pitfalls of Object-Oriented Development. M&T Books, 1996.

ACKNOWLEDGMENTS Special thanks are due to Greg Holtz, Chemist Technician, Research and Development, Calgon Carbon Corporation for his valuable insights and analysis in optical methods, and also for his encouragement and enthusiasm regarding information refraction. Thanks also to the many people who commented on the early drafts of this article, including Seth Finn, Dave Wood, Fred Kohun, Robert Skovira, Haim Kilov, Fr. Vernon Holtz, Keith Colledge, and Dianne Jackson. We would like to acknowledge the helpful comments and suggestions of the many students of the following Robert Morris College Computer and Information Systems courses: Winter 1995 CI613 Microcomputer Systems and Applications and Spring 1996 CI650 Database Theory/Applications.

4 A PRAGMATIC A P P R O A C H TO FORMAL SPECIFICATION Maritta Heisel Technische Universitat D-10587 Berlin,

Berlin

Germany

email: heisel@cs. tu-berlin. de

ABSTRACT We propose a pragmatic approach to overcome some difficulties arising in the practical usage of formal specification techniques. We argue that the transition from informal requirements to a formal specification should not be made too early, that it is not necessary to formally specify every detail, that different formalisms should be combined where appropriate, and that sometimes it may be useful not to adhere to limitations imposed by the formal specification language. This pragmatic approach also helps to deal with legacy systems.

1

INTRODUCTION

In theory, the advantages of formal specifications over conventional methods are well known: •

The problem is analyzed in more detail and thus better understood.

•

The formal specification is an unambiguous and (hopefully) complete starting point for the implementation of the system.

•

The formal specification documents the behavior of the system.

•

It can be used to choose test cases and to determine if the results of the test cases coincide with the expected behavior.

•

It makes maintenance and evolution of the system easier.

•

Systems implemented from formal specifications often contain fewer defects.

In practice, however, formal specification techniques are not widely applied for the following reasons: 1. The formal nature of specification languages may make their use difficult, especially if the semantics is not easily comprehensible.

42

Chapter 4

2. Formal specification languages can be as rich as p r o g r a m m i n g languages and have a similar learning curve. 3. There is no single specification language t h a t is equally well suited for all kinds of systems and all aspects of an individual system, j u s t as there is no one true programming language for all tasks. 4. It takes longer and is more expensive to develop a formal specification t h a n to specify a system with conventional m e t h o d s . Are these really valid arguments against formal specification 1 , and if so, w h a t can be done to lessen their disadvantages? Point 4 cannot be regarded as a drawback because a greater effort in the earlier phases of software development may pay off in later phases and need not lead to an overall increase of costs [HK91]. T h e difficulties mentioned in points 1 and 2 cannot be completely overcome. But p r o g r a m m i n g languages are formal languages too, and there is no a r g u m e n t against p r o g r a m m i n g j u s t because one has to learn one or more p r o g r a m m i n g languages with non-trivial semantics. Specification languages with useful, semantically clean and intuitively clear concepts are needed. Such languages would make the introduction of formal specification techniques into software engineering practice much easier. Existing specification languages are not altogether bad, b u t all of them leave something to be desired, and unnecessarily so, as we have argued elsewhere [Hei95b]. Even carefully designed languages have their strengths and weaknesses. We cannot expect to find one single general-purpose specification language t h a t suits all needs equally well. Hence, point 3 is a very serious one. One idea is to use several formalisms instead of one. W h e n such a combination is done with care, a "hybrid" specification will be clearer, shorter and more comprehensible t h a n a specification in only one language t h a t is clumsy in p a r t s because the language does not allow some relevant p a r t s to be expressed elegantly and concisely. We would even go further and recommend not using formal specification techniques at all for those aspects of a system t h a t j u s t cannot be formally specified in a satisfactory way 2 . These aspects need not necessarily be non-functional, as in the example of Section 2. W i t h these ideas, we seek to bridge the gap between the theoretical advantages and the practical disadvantages of formal specification techniques. T h e choice 1

By formal we mean all those specifications where the language is given a formal semantics. What "satisfactory" exactly means depends not only on the problem and the language but also on the individual specifier. 2

A Pragmatic Approach to Formal Specification

43

is not to either apply them in a puristic way or not at all. Instead, there are varying degrees of formality. However, to make formal specification techniques more widely applicable, it does not suffice to consider only those activities in software development that deal with formal objects. Before we can write down some formal text, we should have an idea of what we want to write down. This means that a detailed requirements elicitation is a very important prerequisite to making the application of formal specification techniques successful. In Section 2, an overview is given of what we understand to be a pragmatic approach to formal specification when a new system is built. More often, however, legacy systems have to be used and maintained. Here, formal specification techniques can be of help, too, as explained in Section 3. In Sections 4 through 7, the various activities that make up the approach are presented in more detail and illustrated by examples. The main focus is on demonstrating how formal specification discipline can be relaxed in order to overcome the intrinsic problems of formal specification techniques as mentioned above. Finally, we discuss what is gained by using this pragmatic approach.

2

SPECIFYING N E W SYSTEMS

In the following, we list the activities that make up the approach. They should not be considered as isolated phases with no feedback between each other. They should be partially carried out in parallel and are likely to be repeated, as in the spiral model of software engineering. A "later" activity can reveal errors or omissions in an "earlier" phase. Phase 1 Define all relevant notions of the application domain. It must be possible to talk about all relevant aspects of the system. For this purpose, all phenomena that might be of interest must be given names and be informally described as precisely as possible. Jackson and Zave [JZ95] call this a designation set. In the context of software architectures, one may define criteria that are relevant for a given architectural style, see Section 4. Phase 2 Define the requirements for the system to be built. The notions defined in Phase 1 provide a language in which the requirements can be expressed. If some requirement or some phenomenon concerning the system cannot be expressed, then the application domain was not investigated carefully enough, and we have to go back to Phase 1. Conversely, in order not to forget some requirements, we should make sure that for each of the relevant notions a statement for the new system is made (this may be the statement that some phenomenon will not be treated at all).

44

Chapter 4

Phase 3 Convert the requirements in a pragmatic way into a formal specification. By "pragmatic" we mean that we should not always adhere to the ideal of purely formal specification but take the freedom to make a specifier's life easier. In our past work on and with formal specification, we applied the following relaxations of formal specification discipline3. 1. Combine different formal or semi-formal specification techniques if one formalism alone is not powerful enough to express all relevant parts of the specification elegantly. 2. If the specification would be as low-level as program code, refrain from specifying these details formally but use conventional specification techniques and document the code in a particularly detailed way. 3. Ignore restrictions of the specification language if it is clear how to give the requirement a semantic. Of course, all the above relaxations must be applied with great care because they are potentially dangerous: a specification where several formalisms are combined may be inconsistent. Incomplete formal specifications may result in an insufficient understanding of the parts not formally specified and thus lead to a wrong implementation. Indeed, this relaxation should mostly be applied for legacy systems, see Section 3. Finally, when we write down illegal expressions of a specification language, we must make sure that these expressions have a welldefined semantics, which should be explained carefully in the accompanying text of the formal specification. Section 5 presents some examples and sketches how to apply the relaxations "safely". Phase 4 Set up a mapping between the requirements and the formal specification. Such a mapping shows where and how each requirement is reflected in the formal specification. It helps to make the specification complete. When the system must be adjusted to new requirements, the specification should be changed before the code. The mapping shows where the changes have to be made. An example is given in Section 6. Phase 5 Validate the specification. This step is very important because, usually, customers only have a vague idea of what the system should do. Formal specifications can be validated more rigorously than informal ones because they can be checked for inconsistencies 3

Other persons may come up with different relaxations, according to their experience.

A Pragmatic Approach to Formal Specification

45

or incompleteness with formal proof techniques. Possible techniques to apply are animation, proof of properties, and testing. Again, the different phases are not independent of each other. Especially Phase 5 will have an effect on Phases 1 and 2. After several rounds in a spiral consisting of the above phases, the specification should stabilize, with a high probability that the requirements are complete, the specification captures them adequately, and that customers and developers understand equally well what the system is supposed to do.

3

DEALING WITH LEGACY SYSTEMS

Building a new system entirely from scratch is more the exception than the rule. More often, legacy systems have to be used and maintained. But also for existing code, it is very useful to have a formal specification. It documents the behavior of the system and helps in maintenance and evolution. If the legacy system exhibits some unexpected behavior, it is more feasible to seek the explanation for the behavior in a formal specification than in the code because the specification is more abstract and usually much shorter. Using reverse engineering techniques, the formal specification can help in locating code that deals with a certain aspect of the given system. Thus, when a formal specification is available, it is no longer necessary to search through the entire code to make changes in a legacy system, see [HK95a] and Section 6. To deal with legacy systems, the approach described in the previous section has to be adjusted. Phase 1 does not change. In Phase 2, not the requirements are formulated but the behavior of the system as far as it is known. Phases 3 and 4 are as before. In Phase 5, the formal specification is used to generate test cases. Horcher and Peleska describe how this can be done systematically [HP95]. These test cases should be run in order to check if the results of Phases 2 and 3 coincide with the actual behavior of the system. Phase 1 Define all relevant notions of the application domain. Phase 2 Describe the behavior of the legacy system as far as it is known. Phase 3 Convert this description in a pragmatic way into a formal specification. Phase 4 Set up a mapping between the description and the formal specification. Phase 5 Use the formal specification to generate test cases and validate the assumptions.

46

Chapter 4

As when building new systems, it can be expected t h a t the last phase reveals errors in earlier ones and t h a t several iterations are necessary. We see t h a t specifying new systems and dealing with legacy systems are quite similar activities. T h e following sections t h a t explain the various phases in m o r e detail can thus serve to illustrate both of t h e m . Of course, the specification of the legacy system exclusively d o c u m e n t s its behavior. To u n d e r s t a n d t h e implementation with all its possible optimizations and "tricks", more effort is necessary.

4

PHASES 1 A N D 2: DEFINITIONS A N D REQUIREMENTS/BEHAVIOR

These phases consist solely of informal activities. T h e resulting d o c u m e n t s m a y be informal or semi-formal. They serve to form a basis for the development of a formal specification. Their purpose is to gain a thorough u n d e r s t a n d i n g of the problem d o m a i n and relate this to the requirements for or the description of a concrete system. W i t h o u t such an understanding, it is hopeless to work on setting up formal specifications. But of course these phases are also i m p o r t a n t when traditional methods are applied. We illustrate the informal definition of the notions relevant for a software system by the characterization of architectural styles via sets of criteria. Software architectures characterize software systems by describing sets of c o m p o n e n t s and relationships between t h e m . Several architectural styles can be identified, e.g. pipe/filter, transaction processing, or event-action. In order to describe these styles, sets of criteria can be set u p t h a t (informally) define the notions relevant for a given architectural style 4 . As an example, we consider event-action systems. Such systems wait for events to occur (e.g. it is Friday 5 p . m . and the boss is logged in) and then take an action (e.g. send an email to all group m e m b e r s t h a t there will be a g r o u p meeting at 5.30 p . m . ) . Such a pair, consisting of an event p a t t e r n and a corresponding action, is called specification and is not to be confused with formal specifications. T h e areas of application of event-actions systems include calendar and notification systems, computer network m a n a g e m e n t , and software process a u t o m a t i o n . Some of the criteria t h a t characterize the event-action style [HK95a] are: •

Matching style Matching event patterns against occurring events is the heart of each event-

4 It would be a rewarding task to investigate if for design patterns [GHJV95] a similar approach is feasible.

A Pragmatic Approach to Formal Specification

47

action system. Event p a t t e r n s can be complex expressions of so-called primitive events. When an event p a t t e r n is only partially m a t c h e d , it is possible to either consider the whole event p a t t e r n as u n m a t c h e d (transient matching) or m a r k the matched events and only wait for those events t h a t were not yet matched (perpetual m a t c h i n g ) . •

Context This m e a n s t h a t not only the event itself but also the context in which it occurs is taken into account, e.g. the event must be caused by a certain user or a certain machine.

•

Grouping specifications Is it possible to group logically related specifications together and refer t o t h e m as a whole?

•

Handling unmatchable specifications Can the system detect and eliminate specifications t h a t can never be matched?

These criteria provide a language in which the requirements for newly designed event-action systems can be expressed (e.g. the system should consider context and allow for grouping specifications, but u n m a t c h a b l e specifications are not considered). They also contribute to make the requirements complete: for each criterion, a decision should be m a d e . If the set of criteria is complete, then so are the requirements. We will come back to this example and show some of t h e formalizations of the criteria in Sections 5.2 and 6.

5

P H A S E 3: P R A G M A T I C A P P R O A C H

T h e purpose of relaxing formal specification discipline is to show t h a t formal methods need not be straightjackets t h a t leave little freedom to their users. T h e relaxations m a y convince potential users to start experimenting with t h e m .

5-1

Combining Different Specification Techniques

T h e combination of different specification techniques is certainly the m o s t imp o r t a n t m e a n s to make a specifier's life easier. It directly addresses the drawback mentioned in Section 1 t h a t there is no single ideal specification language. We illustrate it by two examples. In the first one, algebraic and model-based specifications are combined; in the second, different formalisms (Z and real-time CSP) are used to specify different aspects of a single system.

48

Chapter 4

Specification of Security

Constraints

T h e European Commission has defined the so-called Information Technology Security Evaluation Criteria, I T S E C [ITS91]. These criteria define security levels against which information technology systems can be evaluated. As an example, we consider the formalization of the I T S E C functionality class F - C l . Its description in natural language is as follows: "The TOE shall be able to distinguish and administer access rights between each user and the objects which are subject to the administration of rights, on the basis of an individual user, or on the basis of membership of a group of users, or both. It shall be possible to completely deny users or user groups access to an object." Here ' T O E ' means Target of Evaluation, i.e. the product to be evaluated. For the formal specification of security functionality classes, the clearest and most abstract specification is algebraic. For the systems to be certified, however, Z [Spi92] is more appropriate. It must be shown t h a t the Z specification of a particular system is a correct "refinement" of the algebraic one. This can be established by working ^from both ends: doing algebraic refinements of the abstract specification, and performing "abstractions" on the Z specification until the refined algebraic specification and the abstracted Z specification can be related by a one-to-one m a p p i n g of the involved constructs. To formally specify F - C l , we use the algebraic specification language P L U S S 5 [BGM89]. This language was designed to make formal specifications resemble natural-language text. Accordingly, names of functions or predicates m a y consist of several words. T h e argument positions are indicated by "_". Q u a n tifiers and connectives have a nonstandard, yet obvious, syntax. T h e keyword p r o c indicates t h a t the specification is generic, and the symbol "*" denotes the Cartesian product. Each axiom is given a n a m e for later reference. T h e semantics of a PLUSS specification is loose, i.e. it consists of all E-algebras t h a t satisfy the axioms, where E is the signature of the specification. Taking the above description of the functionality class F - C l as a starting point, we come up with the following PLUSS specification: 5 Any other algebraic specification language could be used as well, as long as it allows for genericity, first-order formulas as axioms, and has a loose semantics.

A Pragmatic Approach to Formal Specification

49

proc F — Cl(object, user, group) predicate user—allowed access to— : user * object user—denied access to— : user * object group—allowed access to— : group * object group—denied access to— : group * object -associated with- : user * group grant—access to— : user * object axioms uc : (user u allowed access to o &; user u denied access to o) is false gc : (group g allowed access to o & group g denied access to o) is false ga : grant u access to o => ((user u allowed access to o or ( e x i s t s gi : group.(u associated with g\ &; group g\ allowed access to o))) Sz user u denied access to o is false &; ( exists #2 • group.(u associated with g^ &; group #2 denied access to o)) is false ) where u : user, g : group, o : object end F - C\ This specification clarifies the ambiguities contained in the n a t u r a l language description, e.g. what happens if a user is allowed access individually who at the same t i m e is member of a group t h a t is denied access. It defines a global predicate grant-access to- deciding if a user is granted access to an object or not. Access may only be granted if there is positive but no negative information concerning the user. The user must either be granted access directly (predicate user-allowed access toJ) or via a group (predicate group-allowed access to J). Additionally, the user may neither be denied access directly (formalized by the predicate user-denied access to_), nor be m e m b e r of a group t h a t is denied access (predicate group-denied access to-). This formalization represents a "conservative" approach: in case of any d o u b t , access is denied. If the conservative policy is considered too restrictive, it is always possible to define the predicate group-denied access to- to be false everywhere. Let us suppose t h a t the access control mechanism of Unix is to be evaluated against t h e above requirement. In Unix, each file belongs to a user a n d is associated with exactly one group. T h e permission mode of a file consists of three parts: the access rights of the user, the group, and the others. T h e tokens r , w , x stand for the rights to read, write, or execute the file, respectively. T h e token "-" m e a n s t h a t the corresponding access right is denied. This means t h a t the access information is stored locally with each Unix object, not globally as in the PLUSS specification. T h e most n a t u r a l way to specify the Unix access control mechanism is not algebraically but model-based since

50

Chapter 4

the access information is stored in a global system state. A formal specification of the Unix access control mechanism in Z can be found in [Pel95]. Therefore, the task is to show t h a t a model-based specification of a concrete access control mechanism captures security requirements t h a t are specified algebraically, i.e. t h a t it is a correct refinement. For algebraic as well as model-based specifications, there are notions of refinement. However, it is not clear w h a t it means t h a t a model-based specification is a refinement of an algebraic one. To make the transition between the algebraic and the model-based world as s m o o t h as possible, we introduce an intermediate specification. It is s t a t e d in Z and is an abstraction of the Unix access control mechanism. T h e p a r a m e t e r s of the PLUSS specification are introduced as basic types. [USER, GROUP,

OBJECT]

T h e access information is stored together with the respective object, like in Unix. We abstract, however, from the different possible access rights and treat users and groups symmetrically, as in the algebraic specification. T h e information about which groups a user is associated with is also localized.

Z Object o : OBJECT pos _user, neg—user : F USER pos ^group, neg-.group : FGROUP

User user id : USER assoc-with : ¥ GROUP

pos. -user n neg._user = 0 pos. -group n neg—group = 0 T h e following schema specifies when a user is granted access to an object. .

Grant Access ul : User zo? : ZObject (u!.userid £ zol .pos—user V (3 g\ : GROUP • (g\ £ (w?.assoc—with n zol.pos-.group)))) ul .user id £ zo?.neg—user -i (3 #2 : GROUP • (#2 € (u!.assoc—with D zo!.neg—group)))

It must now be shown t h a t if the Z schema grants a user access to an object then this must comply with the abstract predicate grant-access to-. T h e algebraic notion of refinement by model inclusion [Wir90] requires us to do the following: 1. Provide a signature morphism from the abstract entities to the concrete ones.

A Pragmatic Approach to Formal Specification

51

2. Apply the signature morphism to the axioms of the abstract specification. 3. Show t h a t the formulas obtained in this way are theorems of the concrete theory. In this special case, the refinement is relatively simple. T h e algebraic specification consists solely of predicates. All of these except grant-access to- are "auxiliary predicates" t h a t do not belong to the "user interface" of the specification. These auxiliary predicates are represented by sets in the abstract Z specification. This is justified because a predicate and its extension can be regarded equivalent. In the general case, however, more research is needed to define a m a p p i n g between the algebraic semantics based on universal algebras to the Z semantics based on sets. T h e signature m o r p h i s m is as follows: group

»-)•

GROUP

user

*-¥

User

object user—allowed

i-4

Z Object

access to—

H->

A u : User;

zo : ZObject

• u.userid

6

zo.pos—user

zo : ZObject

• u.userid

G

zo.neg—user

user—denied

access to—

h->

A u : User;

group—allowed

access to—

I-)-

\g:

GROUP; zo : ZObject

• g £

zo.pos—group

group—denied

access to—

l->

\g:

GROUP; zo : ZObject

• g £

zo.neg—group

with—

!->>

A u : User; g : GROUP

grant—access to—

!->•

GrantAccess

—associated

• g £

u.assoc—with

In this signature morphism, we have only changed the n a m e of the predicate t h a t makes up the user interface of the specification. T h e internal predicates have been replaced by their extensions. In this way, we have m a d e sure t h a t GrantAccess can be used instead of grant-access to- without any restrictions, provided GrantAccess fulfills the axioms stated for grant-access to-. This can easily be shown to be the case. In this example, the desire to combine different formalisms arose because the formal specifications had different levels of abstraction. For abstract properties, algebraic techniques are the most n a t u r a l , and for the specification of concrete realizations, model-based techniques are appropriate.

Embedded Safety-Critical

Systems

T h e second example where a combination of different specification techniques is desirable are embedded safety-critical systems. Such systems have to react

52

Chapter 4

to their environment in order to perform their function. It must be guaranteed that hazardous states cannot be entered by the system. Since embedded safety-critical systems usually have a state, Z is a suitable notation for their specification. Z also allows the expression of safety requirements in a natural way as state invariants. For the control aspects, i.e. to specify under which conditions which operation has to be executed, Z is not so appropriate [Hei95a]. Without specifying control, however, it cannot be shown that the system cannot enter hazardous states. It is thus natural to combine the Z specification of the state and the state-changing operations with a control specification that defines which operation is executed in which situation. A good candidate for such a control specification is real-time CSP [DS95]. In this language, realtime requirements and parallelism can be expressed. Events offered by the environment are an explicit part of the language. As an example, we consider a simple microwave oven. The oven has a single control button. If the oven door is closed and the button is pushed, the oven will cook (that is, energize the power tube) for 1 minute. Pushing the button at any time when the oven is cooking, gives an additional minute of cooking time. Pushing the button when the door is open has no effect. There is a light inside the oven which must be turned on at any time the oven is cooking. Cooking can be stopped by opening the door. If the oven times out, it turns off both the power tube and the light. It then emits a warning beep. Two hazardous situations can be identified for the microwave oven. First, if the power tube is on while the door is open, there is a severe risk of human injury. Second, if the light is off while the power tube is on, the food may overheat unnoticed and cause a damage of the oven or even set it on fire. This means the safety requirements are that the power tube is always off when the door is open and that the light is always on when the power tube is on. To model the microwave oven, we must decide on the sensors and actuators to be modeled and on the data that are used to represent the internal state of the oven. There is a door sensor that can detect the events door^opened and door-dosed, and a button sensor that can detect the event button-pre s s ed. The actuators, i.e. active components, are the power tube, the lamp, the timer and the beeper. Since real-time CSP offers timeout and interrupt constructs, the timer can be modeled exclusively in real-time CSP. The same holds for the beeper because it always beeps for a constant time. Both the timer and the beeper are not safety relevant. Therefore, they need not occur in the global system state for which the safety requirements must be an invariant. The following definitions

A Pragmatic Approach to Formal Specification

53

(somewhat simplified) are taken from [Suh96]. A version exclusively using Z can be found in [Hei95a]. The global system state is as follows. MicrowaveOven power-tube : MICROWAVE light: LIGHT STATE door : DOORSTATE

STATE

door = open =>• power—tube = de—energized power—tube = energized =$> light = on door = open => light = on door = closed A power-tube = de—energized => light = off All of the components of the oven can take on only two states: the light and the power t u b e can only be on or off, and the door can only be open or closed. T h e first two conjuncts of the state invariant represent the safety requirements, the other two are functional requirements. In the initial state t h a t is defined by a schema MicrowaveOvenlrat, the power tube is de-energized, the light is off and the door is closed. Of the internal operations of the microwave oven, OpenDoor, CloseDoor, PressButtonClosed, PressButtonOpen, TimerHalts and EmergencyShutdown, we only present the first one. OpenDoor AMicrowaveOven tubel : MICROWAVE-STATE light] : LIGHT-STATE door = closed power—tube' = de—energized A light' = on A door' = open tubel = power—tube' A lightl = light' This operation schema states t h a t the operation is only applicable if the door is closed (door = closed). After completion of the operation, the door is open. According to the safety requirements, the power t u b e must be switched off, and according to the functional requirements, the light must be on. T h i s information is given to the processes controlling the light and the power t u b e via the o u t p u t s tubel and lightl. T h e other operations are defined similarly. T h e control component for the microwave oven is a parallel combination of three real-time C S P processes specifying the interface control, the timer, and the beeper, respectively. MicrowaveOvenControl

= Interface Control \\ Timer

\\ Beeper

Control

54

Chapter 4

The Interface Control process first initializes the oven (referring to the corresponding Z schema) and then starts the process Interface that is parameterized with the internal state. This is expressed with the prefix operator —•. Interface Control = MicrowaveOvenlnit

—> Interface (Microwave Oven)

The interface process defines by way of an external choice • how the system reacts to the various events that come from the environment. We only consider the case where the door is opened. Interface(MicrowaveOven) = door-opened —> if DoorlsClosed then OpenDoor —> stop-timer —>• Light Control; TubeControl; Wait e; Interface(MicrowaveOven) else EmergencyShutdown —> stop-timer —> LightControl; Tube Control] Stop fi • door-dosed —>-... • button^pressed —» . . . • timeout —>•... When the door sensor detects that the door has been opened, it is first checked if this is consistent with the internal state. For this purpose, the Z predicate Door Is Closed MicrowaveOven door = closed is evaluated. If the external signal and the internal state are inconsistent, then safety can no longer be guaranteed, and a fail-safe state is entered, where the power tube and the light are switched off. Otherwise, the internal Z operation is executed, the timer is stopped, and the light and the power tube are switched on and off, respectively, by the processes LightControl and TubeControl, according to the output of the Z operation. Afterwards, the Interface process is called recursively. Since in CSP events have no duration, a wait process is needed to guarantee that the Interface process cannot be executed infinitely often in a finite time interval. The treatment of the other events is similar. The combination of Z and real-time CSP is achieved by

A Pragmatic Approach to Formal Specification

•

defining Z operations as events of CSP processes,

•

defining Z predicates that are used in CSP process definitions,

•

parameterizing CSP processes with the current global system state.

55

Many more useful combinations of different specification techniques are conceivable. Weber [Web96] combines Statecharts [Har87] and Z for the design of safety-critical systems. Zave's and Jackson's [ZJ93] multiparadigm specifications are combinations of partial specifications expressed in different languages.

5.2

Leaving out Details

Formal specifications need not be useful in every situation; sometimes it is more important to keep the specification concise and easily comprehensible. In [HK95b], the specification of an existing event-action system called YEAST (Yet another Event Action Specification Tool) is given. As already mentioned in Section 4, matching of events against event-action-specifications is very important for such systems. Starting out from so-called primitive events, the event language of YEAST allows one to build complex event expressions, using the connectors then (sequencing), and (conjunction) and or (disjunction). Matching of composite events can be defined in terms of matching of primitive events relatively easily. A specification of matching for primitive events, however, would be no more abstract than the code itself and would make the formal specification much longer and less comprehensible. Therefore, matching of primitive events is not included in the formal specification but only described in the system documentation. For the formal specification of matching, this means that we declare a matching predicate on primitive events, but do not

define it. | .matches-

: (EVENT

x TIME) <-» {EVENT x TIME)

The further specification of the matching process can now make use of this predicate, even though its meaning is not contained in the formal specification. This relaxation to formal specification discipline can be applied in those cases where a formal specification would not be an abstract description of system behavior but only a different notation for a program.

5.3

Ignoring Restrictions

We expect that almost everybody who has some experience in formal specification techniques has encountered situations of surprise and annoyance, where

56

Chapter 4

it seemed obvious how to write down some formal expression, only t h a t the designers of the formal notation had not foreseen the respective situation and hence excluded this possibility. Sometimes, it is advisable to disregard such language restrictions. We illustrate this by a specification of the Unix file system. T h e Unix file system presents itself to the user as a tree where each node has a n a m e and an arbitrary number of successors. A specification of such trees should be present in some library for re-use, where the content of the nodes (as opposed to their names) should be a generic p a r a m e t e r . It appears straightforward to define such trees as a free type in Z: [NAME] NAMED-TREE[X]

::= If {{NAME x X)) | node{{NAME x seq

NAMED-TREE[X]))

Although it is semantically sound as long as X is not instantiated with a type or set depending on NAMED-TREE, this specification is invalid because free types in connection with genericity are not allowed in Z. For the subsequent specification [Hei95b] it has to be decided if this (unnecessary) restriction of the Z language should be ignored and the rest of the specification should use the generic free type definition. In this case, we decided against it because Z type checkers reject the above type definition; hence, tool support would be lost for the entire specification. Instead, we chose an alternative definition based on sets. N a m e d trees are finite partial functions from sequences of positive n a t u r a l numbers into the Cartesian product NAME x X. NAMED-TREE[X] == {/ i s e q N i ^ NAME x X | () edomf A (V path : seqx Ni | path £ d o m / • front path £ d o m / A (last path ^ 1 => front path ^ {last path — 1) £ d o m / ) ) } This definition models trees as functions m a p p i n g "addresses" to the content of the node under the respective address. Each node consists of a n a m e and an item of the p a r a m e t e r type X. T h e e m p t y sequence is the address of the root. T h e length of an address sequence coincides with the depth of the node in the tree. Hence, an address can only be valid if its front is also a valid address. T h e number i denotes the 2-th subtree. If there is an i-th. subtree for i > 1 then there must also exist an i — 1-th subtree. In comparison to free types, this definition looks quite complicated. A l t h o u g h the operations on named trees can be defined elegantly, this shows how much

A Pragmatic Approach to Formal Specification

57

more incomprehensible specifications can become when the specification language does not support the features best suited for the situation at h a n d . To specify a function selecting a successor of a node with a given n a m e , we gave the following specification:

f=[X] child-named

: NAMED-TREE[X]

x NAME -»

NAMED_TREE[X]

"in :NAME- t : NAMED-TREE[X] • (n G names{subtrees t) =$> (t,n) G dom(child—named)) A child—named (t,n) G children t A name—of—tree(child—named(t, n)) = n Again, there are problems with genericity. T h e above specification of the function child-named is semantically invalid in Z because in the reference m a n u a l it is required t h a t "the predicates must define the values of the constants uniquely for each value of the formal p a r a m e t e r s . " , [Spi92], p. 80. This is not the case here, because if there is more t h a n one child with the given n a m e , child-named selects an arbitrary one. However, we do not see any difficulties with a definition like this. On the contrary, it has the advantage to give an i m p l e m e n t o r the greatest possible freedom: if it is more efficient to search from the back to the front instead of vice versa, it should be possible to do so. "Legal" possibilities would be to either define child-named as a relation instead of a function or give an unambiguous definition. Both of these do not cover our intention, namely to state t h a t of the several functions satisfying the specification we do not care which one is implemented. Since this specification clearly has a a well-defined semantics and no type checker can find the "violation", it is possible to stick to this "illegal" specification without loosing tool s u p p o r t .

6

PHASE 4: M A P P I N G BETWEEN REQUIREMENTS/DESCRIPTION A N D SPECIFICATION

T h e effort to record where in the specification the various requirements or features of a system are reflected is worthwhile, because such a m a p p i n g serves several purposes. First, it helps us understand the formal specification, s t a r t i n g from an intuitive understanding of the requirements or system features. Second, it m a y help to detect misconceptions in case the intuitive u n d e r s t a n d i n g of the system contradicts the corresponding parts in the formal specification. T h i r d , changes in the system usually first manifest themselves in the requirements.

58

Chapter 4

T h e m a p p i n g helps us find out what effects the change in the requirements has on the formal specification and indirectly on the code. If a change is very hard to accomplish in the formal specification, it can be expected t h a t changing the code would be difficult, too. Fourth, in case the correspondence between specification and code is not available, it helps to detect those p a r t s of t h e code implementing a certain feature of the system. To illustrate this m a p p i n g , we come back to the example of Sections 4 and 5.2, the Y E A S T case study. We d e m o n s t r a t e how the criterion of grouping specifications is reflected in the formal specification. T h e schema defining the global system state is SpecState specs : ¥ Spec specMap : LABEL H-» Spec groups : GNAME <-> LABEL specMap = {s : specs • s.label i-> s} ran groups C dom specMap where GNAME is introduced as a basic type intended to denote group n a m e s . Specifications can be referred to using labels. This is reflected by the injective partial function specMap. T h e group component of the schema records which specification belongs to which group via labels. Other components of the formal specification onto which the criterion of grouping specifications is m a p p e d include all operations having a r g u m e n t s or results of type GNAME or changing the groups component. Once we know t h a t GNAME and group represent the grouping mechanism, these other c o m p o n e n t s can be found automatically because they are characterized purely syntactically. In case the grouping mechanism is to be changed, the m a p p i n g gives all p a r t s of the formal specification t h a t have to be considered. Y E A S T was formally specified only after it has been implemented. Therefore, this case study serves well to illustrate the t r e a t m e n t of legacy systems. For these systems, the m a p p i n g between criteria (i.e. the informal description of the system) and the specification is especially useful because it helps to locate the criterion in the code 6 . In order to locate those parts of the Y E A S T code t h a t implement the grouping mechanism, we used the m a p p i n g from the criterion to the formal specification (which points out all relevant user operations) to generate test cases t h a t should 6 For newly designed systems, the mapping between the formal specification and the code could be recorded from the beginning.

A Pragmatic Approach to Formal Specification

59

trigger the code associated with specification grouping. All of these were executed with various inputs. Different reverse engineering tools made it possible to pinpoint the set of functions implementing specification groups. Only 22 functions out of 262 were executed more than once. Some of these were library and other utility functions. This leaves only a handful of functions that need to be considered. For more details, see [HK95a].

7

PHASE 5: VALIDATION OF THE SPECIFICATION

For legacy systems, the validation is easier than for systems that are not yet implemented because the implementation is available. In principle, even a formal verification would be possible that establishes the consistency of the specification and the code. For new systems, specifications can only be validated informally because no formal relation can be established between the necessarily informal requirements and a formal specification. Validating specifications is very important because, as Brooks [Bro87] stated: "For the truth is, the client does not know what he wants". As possible validation techniques we mentioned animation, proof of properties, and testing. For animation, an executable prototype is built that makes it possible to "try things out". This possibility is very helpful in the elicitation of the "real" requirements. Elsewhere [Hei95b], we have argued that formal specifications should be as abstract as possible and that they should not introduce any implementation bias. Such specifications are usually nonconstructive and hence not executable. However, the possibility of animating the specification is so valuable that we consider it worthwhile to perform a few refinement steps in order to make the specification executable. Proving properties of the specification (e.g. that two operations are inverses of each other) or showing that in certain situations something undesirable cannot happen also enhance confidence in the specification and contribute to its understanding. The problem with this technique is to find the relevant properties to be proven. Finally, specifications can be tested almost like code. Test cases (that must be selected anyway) can be used to check if the specification captures the expected behavior of the system for these cases.

60

8

Chapter 4

WHAT IS GAINED B Y THE PRAGMATIC APPROACH?

This work aims at supporting the introduction and application of formal m e t h ods in system specification. It takes a p r a g m a t i c viewpoint of formal m e t h o d s . They should not be applied under all circumstances but only in situations where it is clear what is gained by their application. This aim is achieved (i) by showing how formal specification techniques can be integrated in the traditional software engineering process, and (ii) by showing how the undeniable disadvantages of formal methods can be moderated. I n t e g r a t i o n i n t r a d i t i o n a l s o f t w a r e p r o c e s s e s . T h e application of formal m e t h o d s can only be successful when it is well prepared. This means t h a t those phases of the software process where formal m e t h o d s cannot be applied are not to be neglected. On the contrary, requirements analysis must be performed at least as thoroughly as in a traditional process. Our approach gives a guideline how to proceed: first create a suitable language, and then use it to express all relevant requirements or facts about the system. It clearly does not suffice to hand a formal language description to specifiers and then expect t h e m to be able to write formal specifications. Not only the formal techniques themselves have to be learned, but also how formal m e t h o d s can smoothly be integrated in the process model to be followed. R e l a x a t i o n s o f f o r m a l s p e c i f i c a t i o n d i s c i p l i n e . Our p r a g m a t i c approach to using formal specification techniques directly addresses the problems described in Section 1. •

If a formal specification technique is unsuitable for certain aspects of t h e system to specify and suitable for other aspects, then different formalisms should be combined.

•

If formally defining every detail would blow up the specification disproportionally and make it harder to comprehend, then some aspects of t h e system should not be formally specified at all.

•

If it is clear how some aspect of the system could be specified b u t the chosen formalism is too weak, then appropriately commented "illegal" specifications should be considered.

T h e proposed relaxations are most valuable in situations where formal m e t h o d s would otherwise be rejected because a complete specification using a single formalism would be too long, too complicated, or too expensive to develop. Of

A Pragmatic Approach to Formal Specification

61

course, they have to be used with care. It must always be d e m o n s t r a t e d t h a t the resulting specifications are semantically sound. One might object t h a t such a "pragmatic" specification does not enjoy the advantages of formal specifications as enumerated in Section 1 any longer. Even if this were true, a "pragmatic" specification would still lead to a better analysis of the system, contain fewer ambiguities and better document t h e system behavior t h a n an informal specification. Even in connection with formal m e t h o d s , there are better choices t h a n "all or n o t h i n g " . However, it need not always be true t h a t "pure" specifications are superior t o "pragmatic" ones. Consider the case of the embedded safety-critical systems. Rejecting the combination of Z with another formalism can m e a n t h a t i m p o r t a n t aspects of a safety-critical system can then not be formally specified at all or only in an unsatisfactory way. In s u m m a r y : •

Defining the relevant notions of the problem d o m a i n and using the resulting language to express the requirements for the system is a joint task for developers and domain experts. T h u s , requirements can be formulated in terms b o t h can understand.

•

The relaxations recommended for transformation of the requirements into a formal specification (if necessary) contribute to making the specification less complicated and better comprehensible.

•

T h e validation of the specification helps to make the specification complete and conforming more closely to the wishes of the customers.

•

When requirements change, the m a p p i n g between requirements and formal specification shows where changes have to be m a d e in the formal specification. T h e corresponding code can be found with reverse engineering techniques.

A c k n o w l e d g m e n t . Many thanks to David Basin, T h o m a s Santen, C a r s t e n Suhl and Debora Weber-Wulff for their comments on this work.

REFERENCES [BGM89] M. Bidoit, M.-C. Gaudel, and A. Mauboussin. How to make algebraic specifications more understandable: An experiment with the PLUSS specification language. Science of Computer Programming, 12:1-38, 1989. [Bro87] Frederick P. Brooks. No silver bullet - essence and accidents of software engineering. Computer, pages 10-19, April 1987. [DS95] Jim Davies and Steve Schneider. Real-time CSP. In Teodor Rus and Charles Rattray, editors, Theories and Experiences for Real-Time System Development. World Scientific Publishing Company, 1995.

62

Chapter 4

[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. [Har87] David Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8:231-274, 1987. [Hei95a] Maritta Heisel. Six steps towards provably safe software. In G. Rabe, editor, Proceedings of the 14th International Conference on Computer Safety, Reliability and Security, Belgirate, Italy, pages 191-205, London, 1995. Springer. [Hei95b] Maritta Heisel. Specification of the Unix file system: A comparative case study. In V.S. Alagar and Maurice Nivat, editors, Proc. J^th Int. Conference on Algebraic Methodology and Software Technology, LNCS 936, pages 475-488. Springer- Verlag, 1995. [HK91] Iain Houston and Steve King. CICS project report. Experiences and results from the use of Z in IBM. In VDM'91: Formal Software Development Methods. Symposium of VDM Europe, Noordwijkerhout, LNCS 551, pages 588-596, Berlin, 1991. Springer Verlag. [HK95a] Maritta Heisel and Balachander Krishnamurthy. Bi-directional approach to modeling architectures. Technical Report 95-31, TU Berlin, 1995. [HK95b] Maritta Heisel and Balachander Krishnamurthy. YEAST - a formal specification case study in Z. Technical Report 95-32, TU Berlin, 1995. [HP95] Hans-Martin Horcher and Jan Peleska. Using formal specifications to support software testing. Software Quality Journal, 4(4), 1995. [ITS91] ITSEC. Information technology security evaluation criteria. Commission of the European Union, 1991. [JZ95] Michael Jackson and Pamela Zave. Deriving specifications from requirements: an example. In Proceedings 11th Int. Conf. on Software Engineering, Seattle, USA, pages 15-24. ACM Press, 1995. [Pel95] Jan Peleska. Formal Methods and the Development of Dependable Systems. University of Kiel, Habilitation thesis, 1995. [Spi92] J. M. Spivey. The Z Notation - A Reference Manual. Prentice Hall, 2nd edition, 1992. [Suh96] Carsten Suhl. Eine Methode fur die Entwicklung von Softwarekomponenten zur Steuerung und Kontrolle sichereitsrelevanter Systeme. Master's thesis, Technical University of Berlin, 1996. [Web96] Matthias Weber. Combining Statecharts and Z for the design of safetycritical systems. In M.-C. Gaudel and J. Woodcock, editors, FME '96 — Industrial Benefits and Advances in Formal Methods, LNCS 1051, pages 307-326. Springer Verlag, 1996. [Wir90] Martin Wirsing. Algebraic specification. In J. von Leeuwen, editor, Handbook of Theoretical Computer Science, volume B: Formal Models and Semantics, pages 675-788. Elsevier, 1990. [ZJ93] Pamela Zave and Michael Jackson. Conjunction as composition. ACM Transactions on Software Engineering and Methodology, 2(4):379-411, October 1993.

5 ANECDOTES ABOUT MAKING A SPECIFICATION SIMPLER Iain Houston IBM United Kingdom Laboratories Hursley Park, Winchester, England, S021 2JN iain@vnet. ibm.com

The basic problem in programming is the management of complexity. K. Mani Chandy and Jayadev Misra in Parallel Program Design, 1988

Mathematical notations have the power to simplify programming. Every so often some aspect of my work reminds me of this power. This can be an exciting experience and is especially gratifying as many people, including myself during the first dozen years of my programming experience, would be sceptical that mathematics had any part to play in the subordination of complexity. In this chapter I relate some experiences enjoyed whilst using the Z notation [S95, MP94] to describe the behaviour of a system being proposed as an Object Service to the Object Management Group (OMG) — actually just a single class and its single specialisation. Whilst we rarely have the good fortune to come across systems as simple as this in industry, this specification does serve as a useful example illustrating a style of applying Standard Z to more complex tasks [HJ94].

64

Chapter 5

Although the system was simple, initial attempts to write down a Z description of it were still too complicated until Z schemas were deployed to effect a more elegant and easily communicable presentation. It is always important to communicate an idea clearly and simply, to make it as obvious as we can, but it seems especially important when trying to "sell" the idea to our colleagues; and this was the case with the Object Startup Service. The Object Startup Service The Startup Service was being proposed to the Object Management Group (OMG) to answer requirements which included the following: Work (in the form of Requests) can be remembered (for example with the addRequest operation), forgotten about ( d e l e t e R e q u e s t ) and later invoked (asyncStart). ..., any ... application can create Startup Objects ...and use [them] as part of that application's processing. Work can be ordered in a Startup Sequence Object (for example addAtNth). A Startup Sequence Object is a specialisation of a Startup Object. The proposal that was submitted to the OMG's Object Services Task Force included diagrams with paragraphs of Z and English, some of which have been included in this chapter. Using Z to model classes A natural and effective way of working, I find, is to first use Z to model the behaviour of a system in terms of abstract data types, and to then implement those abstract data types as C++ or Smalltalk classes. I'm sure that implementing the abstract data types in Eiffel or another 0 0 programming language would be just as effective. As a technical point, recall that certain sets in Z can be used as Z types: this includes sets of values in a disjoint union, such as Request below, or sets of situations described by a Z schema—StartupObj would be reused in this way by a specification of a system that had Startup Objects, or relations involving Startup Objects, as part of its state. This means that a set can be described at one level and its members promoted to the next higher level to describe its behaviour in the context of that higher level. Getting the levels right is a major part of the "managing complexity" problem: it often has to be attempted more than once. Using this approach, state schemas become classes and operation schemas become member functions or methods: it has a couple of benefits.

Anecdotes about making a specification simpler.

65

Firstly it separates specification issues—the observed behaviour of the abstract data types—from implementation issues—the problems of making the program conform to that behaviour. The thinking part of the programming job is made a great deal easier by having the invariants written down in the state schemas and the pre- and post-conditions in the operation schemas. Secondly, it is possible to rapidly demonstrate the ideas once they have been written down. The translation of Z into C++ or Smalltalk is usually quite simple. Even if it is not exactly mechanical, this second stage in the development process allows the problems of behaviour to be separated from the inevitable problems of managing storage, understanding the rules imposed by the target platform, the available libraries and other reusable components and so on. In themselves, these problems can often daunt the most determined; but after a clear statement of the system's behaviour has been obtained in the first steps of development, the human mind is less likely to be deflected, or more probably railroaded, by the idiosyncrasies of the implementation platform. Simplification by abstraction The Z extracts I will show you are the results of several iterations of writing and rewriting: a description that in the end became suitably simple to understand, criticise and to implement. The breakthroughs to simplicity came from two notable sources of abstraction. 1.

Doing away with one Z schema. The abstraction came from eliminating some detail that was inappropriate to the specification even though it may have been appropriate to its implementation.

2.

Introducing three extra Z schemas. The abstraction came from using the schemas to give names to some detailed predicates and then later using those names instead of the predicates.

This requires some explanation as, on the face of it, you'd think that introducing extra schemas means extra information to deal with: but, on the contrary, this is where the abstracting power of the Z notation really came into its own. I'll come to the extra schemas in a moment, but first, let's deal with the schema I was able to do away with. This described the properties of a Request, but after scrutiny by a colleague, and his helpful criticism, I could see that not all of those properties were really relevant to the rest of the specification, and it was only necessary to distinguish between a created request and a completed one and say that after a Request has been sent, and processing of the object has

66

Chapter 5

been completed, then that Request is then associated with a Result. This is represented by the following Z. Request

::=created \ completed ((Result))

Startup Objects Startup Object states Soon I will explain how the three extra schemas that I added proved to be so useful in subordinating the complexity (improving the simplicity) of the specification, but first a closely related topic. The disjoint union of values, StartupStatus below, corresponds to the kinds of states a Startup Object can be in. StartupStatus

::= | | |

initial not_started started finished

Figure 1 illustrates the operations which cause the transitions from one state to the next. The state labels are also the StartupStatus values of status. In a sense, the status values are abstractions of the four sets of states described precisely by the schemas InitialStartupObj, NotStarted, Started and Finished. The last three of these schemas are the extra ones that contributed most to the Startup Service specification's simplicity: not only do they put names to the four sets of states, relating status values to the state of the collection requests, but they allow the specification of each operation to be simplified. They do this by making the predicate parts of the operations easier to read by including the name of the concept inherent in the predicate part of the associated schema. For example, we can see in the operation Startup r.addRequest that it takes a NewRequest (whatever that is—and we do say precisely what it is); it must be in either the InitialStartupObj state or the NotStarted state before the operation; and will end up in the NotStarted' state after the operation. And by the way, you can also read the following meaning from the schema: the operation is only defined when the StartupObj is in a valid state, and guarantees to leave it in a valid state after the operation. This introduces some proof opportunities to the specifier and some programming challenges to the programmer. Let me explain that a Startup Object consists essentially of a set of requests and a status. This is represented by the Z schema StartupObj below. The status is used to describe the states of a Startup Object that a client can observe.

Anecdotes about making a specification simpler.

67

A status component is normally something to be avoided if possible. In this case it was required because of the asynchronous nature of the asyncStart operation which allows the getStatus operation to be used before any transition has occurred in the requests component. However, that has not much to do with this discussion; status was required but added complexity. Requests recorded in a Startup Object are indexed by identifiers (Reqlds) in the partial function requests. _StartupOhj status requests

: StartupStatus : Reqld -+-> Request

Figure 1 describes the transition between the states of a Startup Object in terms of the values assumed by the status component in the Z schema StartupObj. I refer to the following four schemas as "partitioning schemas" because they divide the total state space into disjoint parts. JnitialStartupObj StartupObj status = initial requests = 0 Initially, a Startup Object has no recorded requests and its status indicates that it is in the initial state. _NotStarted StartupObj status = not_started requests =£ 0 V r: ran requests • r = created When in the NotStarted state, a Startup Object is ready to be started, because it has at least one created Request ready to be invoked. Started StartupObj status = started requests ¥" 0

68

Chapter 5

A Started Startup Object has one or more requests and each of these may or may not have completed. Finished StartupObj status = finished ran requests Q ran completed

All Requests in a Finished Startup Object have completed with a result. Singular and plural Composition introduces additional constraints As a rule it's easier to talk about an object in the singular than it is to talk about the characteristics of each member of a collection. This is true when writing prose and translates into a method or style of specification. First, we say all we have to say about an object in the singular, without reference to how it may be used. Then we make a collection of such objects and say how they relate together in the plural. The ability to separate these concerns of case is one of the most valuable, perhaps the most valuable structuring feature that both Z and 0 0 programming languages share. Their use in managing structure, and thus complexity, is an essential mathematical property that they both share. Many notations, for example the "Entity-Attribute" ones used in several popular diagrammatic methods, do not permit this style of "reusing the singular in the plural". This seems to be a real weakness of such notations: having to specify the whole system at the same level because it is not possible to define a data type that can be reused elsewhere in the same specification. Small wonder that many people turn to OO programming languages for specification purposes and then have to suffer the consequent muddling of programming concerns with concerns of behaviour. Invariants Looking back at the previous few schemas it is worth noting the way that the properties of collected objects are characterised: as constraints on the collection itself that further qualify the properties of its members. In the schema StartupObj a set of Requests was collected together to be used as the main component requests of the Startup Object system. Each Request in the singular has its own properties: in the plural they have additional properties

Anecdotes about making a specification simpler.

69

or constrains in the way that they are collected together. The constraint that was added in StartupObj was the fact that they form a partial function in the relation between the source set of Reqlds to the target set of Requests. This is an invariant property of each and every Startup Object. Sets of object states The schemas above that follow StartupObj, namely InitialStartupObj, NotStarted, Started and Finished, are not describing properties of a Startup Object that always hold, but situations, or sets of states in which a Startup Object may find itself. For instance, Finished describes those situations in which every composed Request in the collection requests is completed and is accompanied by a Result. So StartupObj defines a set of states and the four schemas that follow partition that state space as shown in the state transition diagram. The resultant simplification of the specification came about by including one or more of these "partitioning schemas" in each of the schemas that describe an operation on a Startup Object. Inputs to, and outputs from operations The schemas KnownRequest and NewRequest are useful for including in

Figure 1: Transition of Startup states StartupFactory : :create \

StartupObject::destroy

f

"N/

(

Initial v.

/

J

^

J

\y\

/

(• Started

/ ^ /asyncStart

\^

]

J?

/

addRequest (...) \ \ // deleteRequest (ReqId)\^J\^-f-L^^ (T NotStarted I addRequest (...) V V / getstatus deleteRequest (Reqld)

\ reset\

getResult(Reqld)

sWcStart ^W X Finished' V y

J getstatus

Chapter 5

70 some of the operation descriptions that follow. _KnownRequest StartupObj reqldl : Reqld reqldl e dom requests

A given request identifier corresponds to a KnownRequest when it indexes a Request in the Startup Object. NewRequest _ AStartupObj reqldl : Reqld reqldl & dom requests reqldl € dom requests' An output request identifier corresponds to a NewRequest when it indexes a Request that was previously not in the Startup Object. Operations in the Startup interface A new request identifier is provided as output from the successful operation of the Startup r.addRequest operation. StartupwaddRequest AStartupObj NewRequest InitialStartupObj V NotStarted NotStarted' requests' = requests U {reqldl •—> created} The Startup r.addRequest operation is defined when the Startup Object is either in its initial or not-started states. The newly created request is added to the set of requests in the Startup Object. The Startup: .deleteRequest operation takes a known request identifier as input.

Anecdotes about making a specification simpler. Startup: \deleteRequest AStartupObj KnownRequest NotStarted NotStarted' V InitialStartupObj' requests'= {reqld?} < requests It is only possible to delete a Request from a Startup Object that contains at least one Request and has not yet started. Observing progress Each Request makes the transition from created to completed. Only progress in this direction — or no progress — can be observed at the Startup interface except in the case of the Startup:.reset operation below. MakesProgress AStartupObj V reqld : dom requests \ requests reqld € ran completed • requests' reqld = requests reqld Once completed, a Request remains unchanged. MakesNoProgress = AStartupObj The operation Startupr.getStatus outputs the status of the Startup Object. _Startup:\getStatus AStartupObj status! : StartupStatus MakesProgress Started V Finished Started' V Finished' statusl = status When it is in a Started state, the Startup Object gives a "snapshot" of its state as it makes progress towards its finished states. Note that this is a AStartupObj rather than a EStartupObj even though it is merely an observation operation. This is because, according to MakesProgress and the fact that it may already have been asyncStarted, getStatus does not prevent contained Requests from completing.

72

Chapter 5 The operation Startup::getResult outputs the result of a known Request. StartupwgetResult S StartupObj KnownRequest result] : Result MakesNoProgress Finished requests reqld? = completed result*

Startup:igetResult is defined only on a Startup Object in a Finished state. It does not change any component of the Startup Object as it outputs the result previously returned by the invocation of the given request. The Startup::reset operation is for the "reuse" of a Startup Object that has previously finished but is to be started again at some later time. Startup:: reset AStartupObj Finished NotStarted' dom requests' = dom requests All Requests are set to their created state. Recall that a Request in its created state has no associated Result. Standard Z and Object Orientation Specifications and proof This chapter argues in favour of Z as an invaluable tool for modelling the behaviour of classes of objects. There are at least two other very important reasons for using a mathematical notation to create a precise description of a system whether that system is represented as a class or a collection of abstract data types that is to be implemented in a non-object-oriented way. Firstly, a mathematical notation is mathematical: that is, it has a sound theoretical foundation which allows us to relate its every symbol to precise semantics and relate one expression to another by appealing to the rules of inference that are part of the logic of the notation. For instance, Z has a welldefined semantic model; and as a consequence it has been possible to write

Anecdotes about making a specification simpler.

73

down a logic with a well-defined set of rules of inference. This logic is built into the tools that support an author conducting proofs like the one in use at IBM's Hursley Laboratory. Secondly, theorems can be stated, or rather conjectures stated and theorems proved. A formal notation is one in which proofs can be conducted: a notation which doesn't support proof is little more than a programming language — it may allow invariants, pre- and post-condition predicates to be written down, but unless it permits theorems — which take those predicates into account — to be proved, it is not strictly speaking mathematical. Of course, a formal notation which is not strictly mathematical is likely to be a good deal more use than plain English or other natural language. It may be that we don't find the time to conduct many formal proofs in our truly mathematical notation, but we do get real value out of a notation if we can state "theorems" in it; and even greater value if we have actually proved — either formally or informally — that those "theorems" or conjectures really are theorems of the specification. For an example of theorems, together with their proofs, included as part of a specification see [HJ95].

Hidden proof obligations In the schema StartupSeqwasyncStart and the others that describe operations on StartupSeqObj that are inherited from StartupObj, it is easy to see that the only additional proof obligations relate to the only additional component requestSeq. A word of caution is appropriate: when we use constructs like the schema inclusion described here we can unwittingly introduce additional proof obligations. Schema inclusion introduces new predicates by conjunction, so there is no real problem here. Consider, however, the difficulty introduced by schema implication or negation in standard Z; then consider the extra complexity of proof in the OO dialects of Z. The warning is that the apparent simplicity you might gain by using powerful constructs to simplify your presentation may introduce hidden proof obligations that are not easily honoured. The price to be paid for "syntactic sugar" can be "semantic obesity". Startup Sequences Startup Sequences specialise Startup Objects A Startup Sequence Object is a specialisation of a Startup Object. It maintains a sequence of sets of requests — requestSeq; the Requests of each set being fired off in parallel. When the Requests of one set have completed, then the Requests of the next set are sent in parallel, and so on until the sequence is

74

Chapter 5

exhausted. This added serial behaviour is reflected in the invariants of the Z schema StartupSeqObj. Startup Sequence states A Startup Sequence Object is like a Startup Object with the additional component requestSeq. StartupSeqObj StartupObj requestSeq : seq (F Reqld) requestSeq partition (dom requests) V /, j : dom requestSeq \i < j • -1 (requests\requestSeq i\j Q ran completed) requests\requestSeq j \ Q {created} The component requestSeq imposes an ordering on the requests of StartupObj. A set of requests can only be making progress if the preceding set, and all preceding sets, are complete. The initial state of a Startup Sequence Object is similar to that of a Startup Object... _InitialStartupSeqObj StartupSeqObj1 InitialStartupObj requestSeq' = 0 ... but with the additional property that the sequence of Request sets is empty. Redefined behaviour _StartupSeq:\deleteRequest AStartupSeqObj StartupObj: ideleteRequest request? € head requestSeq (head requestSeq") = (head requestSeq) \ {reqld?} (tail requestSeq") = (tail requestSeq)

Anecdotes about making a specification simpler.

75

The effect of deleteRequest is to remove the given Request from the first set in sequence. Inherited behaviour Startup operations on Startup Sequence objects — other than those described above — leave the requestSeq in an unchanged state. Inherited AStartupSeqObj requestSeq' = requestSeq This is the case with the following five operations inherited from the Startup interface. StartupSeq: \async Start StartupSeq: \syncStart StartupSeqwkill StartupSeq:: getStatus StartupSeq: :getResult

Inherited Inherited Inherited Inherited Inherited

A Startup: :asyncStart A Startupv.syncStart A Startup::kill A Startupv.getStatus A Startupv.getResult

76

Chapter 5

References [S95] "The Z Notation: A Reference Manual": Spivey J. M.; Prentice Hall International 1992 [MP94] "A Z Guide for Beginners": McMorran, M. and Powell; Blackwell Scientific Publishing 1994; ISBN 0 632 03 117-4 [HJ94] "Specifying Distributed CICS in Z": Houston, I. S. C. and Josephs, M. B. in Formal Aspects of Computing 6(5): 569-5 79 [HJ95] "A Description of the OMG's Core Object Model and the Meaning of Compatible Extension" in Computer Standards and Interfaces Vol. 17 Nos. 5 and 6 North Holland Elsevier pp553-588; Houston, I. S. C. and Josephs, M.B.

INVARIANTS IN THE TRENCHES Haim KiIov\ Helen Mogillb, Ian Simmondsa a

b Insurance Research Center Country Companies IBM TJ Watson Research Center P.O.Box 2020 30 Saw Mill River Road Bloomington, IL 61702-2020 Hawthorne, NY 10532 hmogill@heartland. bradley. edu {kilov, isimmond}@watson. ibm. com

Abstract This paper demonstrates: that business specification ("analysis") can be successfully separated from solution specification ("design"); that a precise, compact, understandable, yet complete, business specification for a non-trivial business problem is possible; that technical terminology (eg "invariant", "generic relationship") essential for writing such a specification can be quickly understood and freely used by all participants; and that a real-life business analyst ("in the trenches") of a non-consulting (in this case, insurance) company can become self-reliant and comfortable with the approach in a reasonably short period of time. It does so by presenting both general observations on business analysis, and specific experience from producing a real business specification.

Introduction Motivation — in non-information-management terms Consider a person who has recently bought an empty lot, with commanding views of both a city and the ocean, upon which she wishes to build a house. The future house will, inevitably, be built by builders, since the buyer lacks the skills necessary to build the house herself. However, the builder needs a specification — an architectural drawing — produced by a specialist — an architect — in order to proceed. Moreover, the buyer has a number of requirements many of which are obvious to her, but may not be obvious to a builder or anyone else.

78

Chapter 6

An architect, in dialog with the customer, produces a specification, in which all the customer's wishes are explicitly addressed. The specification is essential, and is a major part of the contract for the builder. The architectural specification has to be approved by both the customer and the builder, and therefore has to be understandable by both. While the builder will eventually have to produce more detailed specifications dictating more precise details for use by carpenters, brick layers, plumbers, electricians, and so on, these details do not (at least typically) require the approval of the customer; they are solution details left to the builder. Motivation — in information management terms Similarly, when a customer wishes to address a business goal with a partially automated solution, specifications are required of the business needs (the "problem specification" or "business specification"), of a system providing appropriate functionality (the "solution specification"), and of how this system is to be produced (the "implementation"). Whilst these three concerns are naturally and clearly separated in activities other than information management, the practice of information management often fails to separate them — leading to project failure. The goal of a business analyst is similar to the goal of a traditional architect when understanding and eliciting a customer's wishes. It is to provide a business (rather than software) specification that will be unambiguously understood by both business users and developers.1 The business specification can then be used as a basis for projects that enhance or put in place new business processes, some of which are to be partially automated; it is also a sound basis for defining the scope of such a project. In order to be useful for these purposes, the business specification must be abstract (with no implementation details), complete (no gaps for developers to fill), precise (no guesses over ambiguities), simple and concise. Our goal in this paper — as well as in our work — is not to provide a step-by-step methodology for how to perform analysis; traditional architects do not have one either. Rather, we seek to produce and refine methodology-neutral concepts, guidelines, tools and training to empower users and aid consultants in their engagements (compare [PM95]). What we propose to do We emphasize that analysis should be done before, and separately from, the design of any imagined automated support, with coding of such a system a distant third. Business analysis involves understanding the business: elicitation of all written and unwritten business rules, and ensuring that they are documented precisely and in a manner that will be both read and unambiguously understood by all interested parties. It identifies only pure business "things", relationships, rules and constraints, and the 'To quote, "We should not underestimate the semantic gap between actuaries, underwriters and programmers".

Invariants in the Trenches

79

behaviors of collections of these "things". It does not refer to computers, screens, databases, tables, etc. It relies upon explicitly defined concepts and semantics rather than meaning presented only implicitly, either in names or informal descriptions2. The major part of a business specification — the deliverable of business analysis — is a structured representation of all rules that govern the business. Our analysis approach insists on being simple, abstract and concise. Its concepts address primarily: collections of related things (objects); what you can do to these collections (operations); and what is always true, no matter what you do to them (invariants). Most operations and invariants involve several interrelated things (example: milk a cow, buy a house, take money from customer's account). Contracts for operations (elsewhere called use cases) should state: what 'things' are relevant (signature), when you have to do it (triggering conditions), when you can do it (preconditions), what is achieved (postconditions), and what doesn't change (relevant invariants only). Contracts do not say how they are to be fulfilled. It is design that specifies how the contract will be fulfilled.3 In object-oriented approaches, design and analysis share common basic constructs, although things and relationships identified in analysis may be transformed into different things and relationships during design to achieve system objectives (such as performance, scale and concurrency) or to fit into development constructs (such as relational schemas). Additional constructs and issues exist for design, such as design patterns, frameworks, system modularity, database design, GUI, legacy connections, optimization. Design, and the mapping of analysis constructs into design, are not discussed here; however they are being addressed elsewhere, for example in [HKOS96]. This paper This paper presents our business specification approach as applied during one consulting engagement. We present the particular goals and experience of this customer and this project as well as our more general goals for, and experience with, business specification. This approach is fully documented (for example, important aspects are included in international standards) and has been successfully used [GRM95, KR94, RM-ODP2, and other parts of this book]. We start by presenting both project-specific and general goals for business specification, and the specific and general environments in which it is undertaken. Next we introduce key details of the approach as applied in this project, and describe relevant details of the project, including details of our participation. We conclude with a 2

Implicit semantics result in the need for each reader to "interpret" — that is, invent a meaning for — the named or described concepts; each reader inevitably invents a different meaning, and the resulting system fails to meet the needs of the business, which were never explicitly captured. 3 Please note that up to this point we have not used the buzzword "Object-Orientation". This is because our approach for business analysis emphasizes concepts used for understanding businesses, rather than technical solutions. The most important of these concepts are abstraction and precision (leading to eg understanding and reuse), which have been around a lot longer than 0 0 , and were warmly embraced and emphasized by the best 0 0 advocates. Moreover, our approach yields business specifications that can form the basis for system development in a variety of paradigms.

80

Chapter 6

discussion of some specific observations on this project, as well as describing issues and guidelines drawn from this experience and elsewhere.

Goals and environment Project goal The business specification produced in this project was the result of just one of a number of activities performed to meet the customer's objectives for the consulting engagement. The broader, and ambitious goal was to produce a common and reusable application development architecture, incorporating object-oriented approaches and based upon the concepts of IBM's Insurance Application Architecture [IAA95]. The production of the customer's development architecture was to be focused by immediately applying it in the development of a specific application — the Life Underwriting Workstation. Understanding this part of the business, and producing a business specification capturing this understanding, were essential first steps in the development of this application. The customer's goal was to define a long term approach for use by the customer's business analysts as part of their development architecture for other applications. Business specification was managed as a separate subproject and was able to proceed independently of, and in parallel with, other activities such as a more long term, general study to define the technological infrastructure for use by the customer. Only the work related to business specification is presented here. Our role was to help the customer to perform business specification themselves, making them as independent as possible of our involvement. Since the business specification being produced was the basis of a development project to test all other parts of the development architecture, it was essential that there were quick results in the form of written deliverables. Given this, we found it absolutely essential to explain (and use the names of) abstract and non-trivial (however simple and elegant) business specification concepts quickly, and have them rapidly applied and understood by the customer. General goals Our general goal is to ensure the widespread use of rigorous business specifications based on formalisms. We believe that business specifications are an essential, and alarmingly undervalued, basis for the production of solutions to business problems. Moreover, they are undervalued because too often they are not produced, and when they are, they are insufficiently rigorous, incomplete, or presented in terms of solutions. A business specification should be complete, emphasizing explicit semantics rather than relying upon unstated assumptions, and, in particular, upon "carefully selected" names that are deemed "meaningful" by their authors (and will probably mean something different to each of their readers).

Invariants in the Trenches

81

We seek to find a natural approach to analysis, and to be methodology-neutral. The approach should be easy to use from the start. Any advanced or more difficult concepts should be introduced only when and if they are applicable. Simplicity and elegance are essential for acceptance. There should absolutely be no need for a long indoctrination in the approach. The need to juggle large numbers of kinds of deliverables — some have recommended as many as 26 — is clearly counter to our goals. In being methodology-neutral, we maximize the opportunity for our ideas to be incorporated into existing corporate methodologies. We make explicit and seek to strengthen the boundary between analysis and design. It is very important that designers are allowed to concentrate only on design: a need to revisit analysis both delays design and risks the need for rework; a temptation by designers to fill in "missing business details" can lead to the wrong system being developed. Similarly, it is important that analysts produce a complete business specification and no more. Swatman [S94] and others have noted that the strengthening of the analysis-design boundary will be of increasing importance as companies outsource more and more of their software and system development and maintenance. Each participant — service consumer and provider — in the outsourcing relationship should have well defined obligations and responsibilities. The business specification is a natural responsibility of the service consumer. In summary, we subscribe strongly to Dijkstra's opinion that "It is the sole purpose of the specification to act as an interface between the system's users and the system's builders. The task of making a thing satisfying our needs' as a single responsibility is split into two parts: ' stating the properties of a thing, by virtue of which it would satisfy our needs' and 'making a thing guaranteed to have the stated properties," with the first part wholly understandable by, and relevant to, business users of the system [D82]. Project environment — this customer At the start of the engagement the customer had no strong attachment to a particular methodology or toolset, although a decision had been taken to embrace objectorientation. The customer had no strong desire to buy expensive tools. They had identified neither the need nor the funds to buy and train people in an expensive (because of its "26" deliverables and "55" steps) off-the-shelf "methodology". The customer saw flaws in the methodology that they had used with a prior implementation of an object-oriented system. Their experiences led them to actively seek to define an approach that would give them a better and more natural transition from analysis to OO design. They also saw that as they move to a corporate architecture, they need an approach able to produce "end products" (business specifications, business terms, classes, behaviors, etc.) that are concise and clearly defined, and therefore reusable. Our early presentations of our approach were seen to be simple, and therefore attractive and promising, although they were met with a certain degree of skepticism. This

82

Chapter 6

skepticism was partially due to the simplicity of the approach; and partially because it was unusual for the designers to see that things and their collections were not defined in the way to be used for design — for example, analysis-level subtypes might well be represented using attribute values during design. On the other hand, the analysts appreciated the liberation of not having to think (or worry) about design elements. After preliminary discussions, we had seen that the customer could achieve a breakthrough in performing analysis. We promised a simple approach, resulting in business specifications that business users could immediately understand and correct. We promised to impose no artificial constraints on the resulting system or design approach (a perceived weakness of off-the-shelf methodologies and tools). What skepticism that did exist was outweighed by the fact that we were explicitly separating the concerns of analysis and design: business analysis could proceed without the participation of software staff; other engagement activities on development architecture were able to continue in parallel. Project environment—generic The need for, and the possibility of providing, a high-quality, implementationindependent, business specification is of sufficient novelty for some participants of some projects so that it has to be carefully marketed to them. This marketing may mention that absence or poor quality of a business specification may lead to project failures, including: no software being produced, bug ridden software, project delays, extensive system rewriting, budget overruns, or the wrong software being deployed. Business specifications ("requirements") are still too often seen as being a contractually necessary evil ("system documentation"), to be produced by technical writers after the system has been delivered, and with a goal of justifying that the right system has been produced. Too often requirements are expressed in terms of solutions. An opinion that requirements are of little value may be derived from the poor quality of previous business specifications: what was written may genuinely have been of little value, lacking in completeness and precision; or material of genuine value was obscured either by unnecessary details, or by a non-declarative approach that suggested that bad preliminary design work had been attempted. Material considered to be of low value is too often ignored rather than improved. Often the rigor required to explicitly capture business semantics has not been estimated, and has been placed a distant second to the issues of ("making real progress in") developing the system. The fallacy of measuring progress by the KLOC (thousands of lines of code) is still too often present. The production of a business specification is a good way of taking control of a failing project (one in which, for example, "only 300 out of 4000 business rules have been implemented"). Most failures occur due to lack of the very specifications recommended here, and the consequent need for designers to rediscover, or worse invent, missing business knowledge. A well structured, precise, complete and abstract specification removes the need for a constant requirements reassessment, which inevitably

Invariants in the Trenches

83

leads to creeping system scope. As recommended here, a short and understandable (to everyone, including users) deliverable is produced in a timely manner, and this deliverable can be handed over — as a contract — to developers. Fortunately, the project described here was no further along than business analysis, and was ready for, and in need of, a way of presenting and ensuring the completeness of the business requirements. It had not had the opportunity to develop the symptoms described above.

Business specifications Organizational issues Our goal is to produce understandable, and valued, business specifications. We seek a common approach to business specification that is independent of whether solution development will be performed in-house or outsourced [S94]. An approach that makes outsourcing possible also, of course, eases projects that locate business experts and development shops on different sites, and projects that require participation of rarely available business experts. To achieve understandability, we emphasize simplicity, clarity and conciseness. Real and perceived value are ensured by emphasizing completeness as well as understandability. Everything is explicitly recorded, with unstated assumptions and "common knowledge" being elicited and incorporated into the specification. Business analysis is best done by small teams, ideally with no more than three people. (We obviously need to distinguish between gathering business requirements — which might require the participation of many people — and performing business analysis.) Larger projects are best partitioned after high level analysis has been performed. Analysis involves extensive sessions, involving exploration, walkthroughs and discoveries. Scribing is very important. Never rely upon the memory of participants: a project session in which decisions and unresolved issues are not recorded is useless, if not counter-productive since participants not only forget details but can be left with a false sense that territory has been covered, or that open issues have been resolved. A record that agreement was reached is inadequate if the agreement itself has not been completely recorded as each participant will remember a different resolution. In this project, a copying whiteboard proved highly useful when a large group (more than 2 people) was gathered. It is a medium for scribing, and explicitly showing (and recording) agreements and points of contention during debate. It would have been ideal if only the printouts had been automatically date and time stamped! Since we use concepts and constructs similar to those used for design, but adapted to the needs of abstraction, there is a need to train designers, data modelers, and others in how to read the specification. Some notions — such as that a type may be specialized in several orthogonal ways (multiple subtyping), or that a real life business

84

Chapter 6

object can have several useful types, and can acquire and lose types (dynamic typing) — are novel for many designers (even though they are considered essential for specifying and building open distributed systems by ISO [RM-ODP2]), and are not supported by most languages.4 As such, it is important to be able to give designers basic guidelines on how to handle such cases, in the form of implementation libraries and an enumeration of design trade-offs. Technical issues It was essential to have a simple approach, with few concepts and deliverables. Declarative specifications were adopted rather than operational ones. Declarative approaches are simpler to understand, have fewer concepts, and the resulting specifications are smaller and easier to check for correctness. They defer decisions on which agent (machine, person) performs each operation, and remove the need to introduce artificial sequencing of "sub-"operations that can in fact be done in other orders or in parallel. Our approach has just two kinds of deliverable components which are bound together, and interspersed within a single deliverable. These are Operation Specifications (sometimes called Use Cases) capturing what can be done in the business, and Objects and Relationships reflecting the non-changing properties of business things and their collections. Both have a sound technical basis — the essential generic relationship concepts have been formalized and are readily available for reuse, and operation specifications are a common feature of many formal declarative specification approaches. The approach is based upon international standards [RM-ODP2, GRM95]. We insist on deferring systems and software discussions until design. We deliberately trade "hints to developers" for "ease and completeness of business analysis", even while introducing into analysis a rigor commonly only applied by programmers. Not even the potential system user interface is discussed. Essential business specification constructs such as multiple subtyping, for which there is currently no obvious design counterpart, still need to be explicitly specified and used as needed; reusable implementation libraries can be applied during design to respond to these constructs. When a legacy system is, and will continue to be used by the business, it (or at least its interface) is considered to be a part of the business. Such a legacy system should be included in the analysis, but should be understood in terms of the semantics of its interfaces and in business terms, and not in terms of its internal design either in the form of code or database definitions. Legacy systems that are to be thrown away should be ignored. 4

A notable exception is the emerging subject-oriented extension to object-oriented programming [H093]. Here, researchers into programming and compiler development have recognized that it is natural to produce designs and code that have a modularity that follows that of the business problem being solved. They have accepted that this means that they must be able to execute programs "composed" from subprograms ("subjects") written from different subjective viewpoints, and therefore with potentially different type hierarchies, and that dynamic typing promises to be of as much use to programmers as it has proven to be in business specification [HKOS96].

Invariants in the Trenches

85

Details of the approach General Our approach is declarative and therefore is concerned with collections of things ("objects"), what you can do to these collections of things ("operations"), and what is true about the things no matter what you do to them ("invariants"). Below we will see examples of all of these, such as: an object for an Underwriting Decision, an operation to Change application for Base Coverage Amount of Insurance, and an invariant saying that a Change to Insurance Application must be either a Change Due to Underwriting Decision or Change Due to Writing Agent Request but cannot be both. In an operation specification, as illustrated below, we list: the things involved in the operation (the "signature"); the outcome of the operation (the "postcondition": that is, what is true after the operation), when you can do the operation (the "precondition"); and when you must do the operation (the "triggering condition")5. It is common practice to factorize out system invariants: conditions that cannot be violated at any time except, perhaps, as an intermediate step in an operation passing between two valid states. While invariants are specified separately, as mentioned later, we adapted our approach during this engagement to allow both references to relevant system invariants and "operation invariants". The latter refers to a condition present in both the precondition and postcondition (that is, to what is referred to, but remains unchanged, in the operation), which is very helpful because of the need to concentrate on, and only on, those things relevant to the operation. When inevitable business changes need to be incorporated in the business specification (and subsequently in the code), a separation between invariants and operation specifications helps to localize the impact of change. In particular, a change to an invariant is less likely than a change to, an addition or a deletion of, an operation. Invariants and generic relationships We are particularly interested in two kinds of invariant: those about the properties of a single object, and those about the properties of collections of objects. The former define the type of the object: for example, they distinguish an object of type Underwriting Decision from an object of type Change to Insurance Application. The latter define the type of a collection of objects and distinguishing, for example, a composition shown in the diagram below, from a reference relationship between an Underwriting Decision and a Change Due to Underwriting Decision. 5

The order of items in an operation specification is not that important; it may well be viewpointdependent. On the other hand, it is quite possible to analyze a viewpoint in accordance with which an operation "starts" with its triggering condition, continues with checking its precondition, "leads" to the postcondition, and triggers condition(s) for other operation(s). Careful consideration of (dynamic!) triggering conditions will probably require dealing with obligations [MW93]; and related issues may be better discussed in the framework of a workflow specification.

86

Chapter 6

A number of highly reusable "generic relationships" [KR94, GRM95] greatly simplify the specification of many, if not most, invariants. Generic relationships about collections of objects include "composition", "dependency", "symmetric" and "reference", some of which appear in the example given below. Each generic relationship has been formally defined (in terms of its invariant) for reuse, and comes with specifications of associated basic CRUD (Create, Read, Update, Delete) operations. Specializations of the generic relationships [KR94] (such as different mutually orthogonal kinds of composition) augment the invariants of the most generic relationships. These specializations are still generic. For example, a composition can be ordered or unordered; orthogonally it can be hierarchical or non-hierarchical; still orthogonally different kinds of composition exist based on whether a component or a composite can exist independently of the other; and so on. Given the limited size of this paper — indeed of the entire book — we will include only small fragments of the specification of the business produced on this engagement. The first of the two diagrams is a higher level view of the detail that follows in the second diagram. In the following diagram, we show that an Insurance Application is a composite which has three components: Original Insurance Application, Change to Insurance Application and Correction to Insurance Application. In particular, this means that on the one hand, there exist properties of an Insurance Application which are independent of the properties of its components, and on the other hand there are other properties of Insurance Application that are determined by properties of the components. The particular way of determining these dependent and independent properties is an application-specific business rule to be defined elsewhere in the specification, but cannot usefully be shown in the diagram. The fact that such properties exist is a generic business rule embodied in the invariant of the generic composition relationship. This particular composition is unordered, hierarchical and is not fixed.

Insurance Application

Original Insurance Application

Change to Insurance Application

Correction to Insurance Application

We neither prescribe nor prohibit the use of diagrams, although they often prove useful. We also do not impose any particular graphical notation, although — if used — it must indicate from which generic relationship it has been derived (in this case the letter C indicates 'composition') and the direction of each relationship (for a composition, the triangle points towards the 'composite' and away from the 'components').

Invariants in the Trenches

87

This diagram shows four object types (rectangles) and one relationship (triangle plus lines linking the triangle and involved object types). Unlike many other graphical notations that we are aware of, we know that diagrams showing instances of these generic relationships have precise semantics: their graphical representation elements are as precisely and explicitly defined as corresponding textual ones. In looking at the details of a Change to Insurance Application — the object capturing details of a change rather than the operation of doing the change — we encounter properties that we want to express as invariants of only some Changes to Insurance Applications. It is natural, therefore to explicitly use subtypes for this purpose. Subtyping Subtyping invariants are modeled using the generic "subtyping" relationship. We have found that the uniform formulation of business concepts as types, and conditions in terms of types, greatly simplifies business specifications. As such, we strongly discourage the enumeration of object "properties" or "attributes" which are more oriented towards addressing design issues. For example, in this project the business concept Source of Change to Insurance Application that was eventually to be coded as an attribute was represented in the business specification (see below) as a subtyping relationship that specialized a supertype Change to Insurance Application into distinct Change Due to Writing Agent Request and Change Due to Underwriting Decision subtypes. This is an example of an "exhaustive, non-overlapping subtyping" (indicated by 'SE' in the diagram), since an instance of type Change to Insurance Application must be either an Change Due to Writing Agent Request or a Change Due to Underwriting Decision, but cannot be both (or neither).

Change Due to Writing Agent Request

Change Due to Underwriting Decision

Change to Insurance Application

Underwriting Decision

Change to Insurance Coverage

Change to Answer to Underwriting Question

Request for Change to Insurance Application

Change to Payment Provision

Expressing concepts in terms of subtyping has interesting consequences. As an object is operated upon it may acquire types and lose types. For example, a Change to Insurance Application object that was of type Change Due to Writing Agent Request

88

Chapter 6

will become a Change Due to Underwriting Decision and cease to be a Change Due to Writing Agent Request after the Receive Adverse Medical Examination Report operation.6 This extremely common business phenomenon, of objects that frequently acquire and lose types (properties), is called "dynamic typing". Equally, frequently there are many motivations for subtyping a given type. A Change to Insurance Application object may also be categorized as either a Change to Insurance Coverage, Change to Answer to Underwriting Question, or Change to Payment Provision, which is another examples of a business rule. This categorization deals with the Kind of Change and is therefore a completely orthogonal business concept and rule to that of the subtyping for the Source of Change to Insurance Application property above. We therefore capture each of these concepts in a separate subtyping relationship, showing that an instance of the supertype should be an instance of a type in each of these subtyping relationships.7 This business phenomenon is also extremely common, and is called "multiple subtyping" [KR94, HKOS96]. Compact specifications The reuse of generic relationships allows the extremely compact specification of many business rules as invariants. Let's consider the combined effect of two relationships shown in the diagram above. If we don't like pictures, we can present those relationships in the following equivalent two lines of specification (where we had to add application-specific relationship names): Source of Change to Insurance Application: Subtyping Exhaustive and Non-overlapping {Change to Insurance Application, {Change Due to Underwriting Decision, Change Due to Writing Agent Request}) Underwriting Decision,

Reason for Change: Reference {Underwriting Change Due to Underwriting Decision)

We can infer, for example, how, in addition to the invariants described in the previous section, the reusable CRUD operations of the generic subtyping relationship — such as "Change of type for an instance" [KR94]) — allow the instance of Change to Insurance Application to switch from being one subtype to being of another subtype. The pre- and postconditions of these CRUD operations are implied by the invariants of the relationships shown in the diagram. Also implied by the diagram, the reference relationship invariant states that when any object instance becomes (or is created as) a Change Due to Underwriting Decision then it must simultaneously acquire a reference association with an Underwriting 6

The invariant of the generic "exhaustive, non-overlapping subtyping" relationship ensures that an instance of the supertype cannot cease to be an instance of one of its subtypes without becoming an instance of another subtype, nor become an instance of a subtype without ceasing to be an instance of another subtype. This invariant states, in particular, that at all times the instance of a supertype is an instance of exactly one of its subtypes. 7 In fact, we recognize subtyping relationships that are: non-exhaustive — that is, an object of the supertype need not be of any of the given subtypes; or overlapping — that is, an object of the supertype may simultaneously have several of the subtypes.

Invariants in the Trenches

89

Decision, and it loses this association when it ceases to be a Change Due to Underwriting Decision. The invariant for the reference association states that some properties of the maintained object (in our case, Change Due to Underwriting Decision) are determined by the appropriate properties of its reference object (in our case, Underwriting Decision), and therefore, in particular, if properties of the reference object change then the properties of its maintained object(s) may also have to be changed. The details of the relationship between the relevant properties of these reference and maintained objects are defined elsewhere by application-specific business rules. Two lines of a rigorous specification capture a lot! The information is clear and understandable because it is at the right level of abstraction, and therefore is concise. An alternative formulation in which the properties considered above were specified as attributes rather than as subtyping and reference relationships, would have been less explicit, much longer and less clear, precisely because it uses constructs appropriate for a different level of abstraction. Operations As mentioned earlier, rigorous definitions of certain elementary and generic CRUD (Create, Read, Update, Delete) operations are implied by the invariants of the (generic) types of relationships. For example, the specification of the operation Change Type is implied by the invariant of an exhaustive and non-overlapping subtyping relationship: the precondition states that the object has one of the permitted subtypes in this subtyping relationship, and the postcondition states that it both no longer has the original subtype, and now has one other of these subtypes. Business operations at a higher level than these generic CRUD ones are defined and precisely specified, somewhat in parallel with object and relationship definition. Indeed, our decision to describe invariants for relationships between objects before operations was somewhat arbitrary; we could have described operations first. Nevertheless, the same invariant may govern several operations (reuse!), so it is productive to seek out and present invariants before operations. An operation usually refers to several objects that 'participate' in the operation, but the operation is not attached to any of these objects. Such an assignment might be needed at a design level but, if needed, this assignment should happen later, during design. Let us look at one of the many operation specifications related to the invariants shown in the diagrams above. Notice how we have made everything explicit in terms of the invariant and pre- and postconditions. Change application for Base Coverage Amount of Insurance Description: Change the Base

Coverage

Amount

of

Insurance

when the change has been requested by the Writing Triggered by: Receive Request Application.

for

Change

to

Agent.

Insurance

90

Chapter 6

Invariant:

Insurance

Application

Base Coverage

Amount of

Insurance

exists Precondition:

A Request for Change to Insurance Application to change the Base Coverage Amount of Insurance exists as received from the Writing Agent Postcondition:

Insurance Application Base Coverage Amount of Insurance has been updated as a Change Due to Writing Agent Request Other related invariants are presented in the form of relationship diagrams (such as the one shown above). Every underlined term in the operation specification corresponds to a type in the diagrams or to a property of such a type. The set of all underlined terms corresponds to the signature of the operation. Notice that the triggering condition, as well as the pre- and postcondition, are each application-specific business rules. Indeed, many organizations would refer even to individual statements within (for example) a precondition as a distinct business rule. Note also that a specification in terms of invariants and operation specifications is a natural and clear way of structuring and categorizing the typically thousands of elementary applicationspecific business rules of even a modest business situation. What is deliberately omittedfrom business specifications As can be seen from the sample fragments taken from the business specification produced by this customer, many constructs often recommended by analysts are not included here. As stated above, we insist on deferring systems and software discussions until design. For example, concerns of database designers, including attributes, field lengths, primary and foreign keys, normal forms, and so on, are for database designer consumption only, and need not be even understood by the customer. Similarly, messages, object collaborations, and so on are concepts imposed by a message-oriented object model derived from languages such as Smalltalk, which should only be the concern of implementors. Synchronization, allocation, persistency, and so on are the concern of system designers. Even the design of a potential system user interface is not discussed since it requires the human factors and ergonomics skills of a user interface designer. Territory that is truly common to both analysis and design is typically presented in a semantically more rigorous and abstract manner during analysis. In particular, cardinalities required for defining design-level relations can in most cases be determined from the invariants of generic relationships, and therefore in most cases do not have to be explicitly included in business specifications.

Invariants in the Trenches

91

Some recommendations We do not recommend separate lists of objects with informal descriptions only since a business has no useful operation-less things or, for that matter, any thing-less operations. However, a glossary with rigorous definitions of business terms is essential for common understanding. In our case, the glossary author participated in business analysis (and she was also an Insurance Application Architecture expert) — if the team cannot define a thing ("object"), and get agreement on the definition, then they will not be able to get agreement on how to model it's relationships. It is also essential to name things correctly — and that cannot be done without a rigorous definition. Not everything can or should be shown in pictures. It was our experience that when we had trouble agreeing on how to model certain relationships, it was because we each had a different understanding of the terms ("words"). We recommend that business analysis is performed by small teams, ideally with no more than three participants. As indicated earlier, a large project may be decomposed to be addressed by several teams once an initial, high-level analysis has been performed. Each team should include both business analysts and subject matter experts. Walkthroughs should involve subject matter experts who were not involved in the original production of the specification. Independently produced sections of the specification should be merged with the participation of analysts involved in the production of each section, with subject matter experts as arbiters. In all sessions there should be a designated scribe. We recommend that business analysis is performed not only for parts of the business that are intended to be automated, but also for related activities that are to be performed by people or automated at a later date, and may include related activities performed outside of the business. It is difficult, if not impossible, to completely define the scope of an automation project until a business specification has been produced, so activities beyond the originally intended scope may well come into scope. What should be automated in a development project is an orthogonal issue to analysis, and could be done afterwards. This may be a business decision, a technical decision based upon availability and maturity of technology, a funding, timescale and scoping issue, or based upon a combination of these and other factors. Indeed, a business specification can be of value even if no automated support is intended, or may show that business activities can be directly eliminated or streamlined with little or no automated support. A high-level, enterprise-wide business specification is an extremely powerful basis for implementing changes in business strategy ("business transformation") or planning future system development efforts. Business process analysis An analysis of the business problem in process terms had previously been performed in this engagement, and was used as an input to the production of the business specification. The production of a quite informative and user-friendly preliminary description of the business process to be automated before developing a business

92

Chapter 6

specification provided a useful, although inevitably incomplete, starting point for business analysis. However, some innovations were introduced in this analysis. Firstly, it was proposed that object-oriented analysis be performed in Use Case terms [J91], a Use Case being produced for, and corresponding to each business operation; business process analysis resulted in workflows and job definitions, each activity of which is a business operation. Given our previous experience in business specification we went beyond the production of Use Cases as originally planned, but the basic principle remains valid. In fact, it may be advantageous to consider a workflow as a partially ordered collection of operations where each operation is precisely defined by its pre- and postconditions, and is performed by a specific agent, be it human or automated. Research leading to a unified approach along these lines would be of immediate practical value, and would show how seemingly different approaches naturally fit together. Secondly, business processes are a traditional product of a business transformation engagement, as are many suggestions for developing new systems. It is frequently the case, therefore, that a high-level business process will have been defined before a business specification is produced for a specific automation opportunity. Thirdly, a well known dimension of change of business systems is workflow. The authors of IBM's Insurance Application Architecture — and we agree — expect explicit support for process/workflow change to become a common feature in all business systems. As such, any methodology should ensure the production of a workflow definition. Fourthly, an important part of any business automation project is to plan for the adoption of the new software solution. In order to do this you must have an accurate picture of not only the new system, but also the way that work was done in the past. Based on both of these things, you are able to plan for and manage the adoption, preparing training courses, allowing for initial dual operation, and so on. Insurance Application Architecture (IAA) The Insurance Application Architecture can be described as a distillation of a vast amount of "application-specific knowledge" about a generic, highly flexible and broad-coverage insurance application. It is a living, evolving architecture that had been developed over more than five years with the participation of 40-50 insurance companies, and is constantly being refined by use by IBM's insurance company customers around the world. IAA was also a key component of the approach used on the project described here. We consider IAA and our approach to business specification to be complementary and mutually supportive. IAA offers the business analyst a strong set of reusable business concepts including "things" and high-level business functions. IAA promotes precision and completeness in both business and system specifications ("a good business specification is 70% of the work"), and extensive reuse from analysis

Invariants in the Trenches

93

through to code. For the designer of insurance systems, IAA promotes system extensibility through parameterization, with a resulting empowerment of business experts to evolve their own systems. In the context of this engagement, IAA was used to solicit knowledge during business process analysis. It provided a road map with paths for driving from identified knowledge about the analyzed problem to typically related concepts, thus contributing towards the completeness of the analysis. We were also able to directly reuse major IAA notions in the business specification such as "party", which is a common abstraction for people and organizations who have legal responsibilities related to the operation of the business or as participants in insurance agreements.

Project Project and people As mentioned above, the development project to produce the Life Underwriting Workstation was part of a larger engagement involving other, system development process and architecture definition, activities. The Life Underwriting Workstation project sought to provide automated support for underwriters in order to reduce the cycle time for underwriting a life insurance policy, and automate those underwriting decisions that do not require human judgment. The new workstation had to work alongside existing parts of the business, including a number of legacy applications including packages bought or leased from third parties. Before our contribution to analysis started, the client's analyst had obtained a significant amount of personal knowledge of how underwriting is performed in the company. However, she was looking for a better way to formally express it, and especially to structure it in a precise and explicit manner accessible to both systems and business colleagues. As mentioned earlier, some progress had been made by performing business process analysis, but much ground remained to be covered. The only software tools used were those already available: a simple graphical editor (for drawing relationship diagrams) and a simple text editor. Admittedly, the text editor did have the capability of producing underlined and boldface text, a capability that we exploited to the full! A copying whiteboard was also available, and proved useful. Our participation It is worth stressing that our participation was mostly in an initial three month period, although we were occasionally contacted after that. The customer's staff spent much more time performing the analysis work than we did — probably only four full weeks of our time was involved (this includes thinking time!), plus frequent, short, telephone conversations, often to discuss faxed materials. This demonstrates that we were truly able to provide a jump start to the analysis process, leaving the bulk of the work to the customer's analysts who successfully completed it themselves.

94

Chapter 6

In total, explicit training in concepts took at most one day, but this was spread out, with each generic relationship type introduced when and as it was needed. There was no need for a five day training course! The first "training session" took about one hour, and was presented as the creation of a common starting point rather than as "training". Modeling guidelines were mixed with the application of concepts in analysis sessions, and this, naturally, took more than one day. We gave a clear and short presentation on why analysis and design are (and should be) distinct. This served to reinforce the boundaries between the separate subprojects of the engagement, but also acted as background training. We also encouraged occasional discussions related to conceptual issues. We provided examples from both the subject area and elsewhere, with no mention to software or computers. We latched onto examples that emphasize that business occurs independently of any computer system, such as: "the yellow form is taken from the blue folder and stapled to the front of a new pink folder". Our engagement manager assured us that "the invention of the manila folder had a much greater impact on the insurance industry than computers, at least so far". Of course, we seek to change that through the careful application of business specification techniques within the insurance industry!

Issues / Observations / Guidelines Getting buy-in to the approach Given the project goal of rapidly producing a business specification, it was absolutely essential to explain abstract and non-trivial concepts quickly, and have them understood and then applied in our absence. The only approach available was to tackle the problem head on, introducing core concepts such as "invariant" and "precondition" by name immediately, while leaving more specific concepts (such as "compositioncontainment") to be introduced as and when they were needed. Key concepts were presented in an understandable and meaningful way (for example, a "postcondition" indicates the outcome of an operation), and were reexplained and clarified during sessions when necessary. Removing the preconceptions of people with a design background (especially for data modelers) was a significant challenge. A typical question was: "how come your subtyping is based on behavioral considerations [and not form]?" Here we chose to repeat our presentation that clarified the different goals of analysis and design, and used an answer such as "a business user simply wishes the system to support them in doing their work, and 'form', for them, is quite arbitrary". Similarly, our choice of "yet another" set of symbols on diagrams to illustrate instances of generic relationships required justification, which was provided and helped substantially. Most designers tend to know, at least subconsciously, that most diagramming techniques are weak on semantics, and (mostly) do not deal with behavior; consequently it is a challenge to get them to accept that good approaches are possible, if only for business specifications.

Invariants in the Trenches

95

Not just on this project but also elsewhere, it is not clear why approaches to business analysis are so much more readily accepted by business analysts and business users than by many programmers / data modelers / designers. Some relevant issues have been presented earlier, including past experience with low value or vast requirements documents. Other possibilities include: that our approach appears simplistic; that we have deliberately decoupled an increased understanding of the business problem from increased understanding of how to implement a system (something, anything!); and that developers are still measured, or measure themselves, in terms of the "weight" of code, or number of data entities, produced. Other observations on the considerable differences in attitude between software developers and "Professional Engineers" have been eloquently presented by Parnas and Madey in [PM95]. As we, as an industry, get better at understanding business problems and increased value and expectation is placed on producing appropriate solutions, this should change. Building, and maintaining, understanding of the approach It proved necessary to refer to parts of our training presentations during sessions. We actively sought to clarify concepts during sessions, and explicitly noted when concepts were used, especially those previously perceived as difficult or obscure ("too abstract"). As one of the important results of this project, the customer's analysts produced a document explaining the approach and its end products, and this document has been (re)used by other people on the project. Particular points that needed to be emphasized included: explaining that things and relationships are not the same, which may be a difficult point for people with a relational database background; and that operation specifications should explicitly refer to these things and relationships, and no other ("there should be no operation-less things, and no thing-less operations" — [W89]). It was also important to maintain the understanding that while in general a diagrammatic technique is not necessarily the same as a specification, the diagrams that we used had a great deal of meaning. In particular they imply behavior: there is a lot more to a "subtyping" relationship than a triangle with an "S" in it, and an "S", "SE" and "SE+" (subtyping; subtyping exhaustive; subtyping exhaustive and overlapping) have significantly different consequences. The same approach obviously applies to different kinds of composition (and so on)! Making sense of legacy approaches The previously performed business process analysis presented an interesting opportunity for investigating the relationship between business specification and business process engineering. It identified candidate business operations; the term "mini-spec" was used, which fortuitously implied a need for precision and explicitness. When we started studying the mini-specs, we adopted a legal contract analogy, with its need for precision and pre- and postconditions (although the latter are not named there in this manner): this was understood and of business importance to all participants. While the results were substantially enriched during business specification, with several

96

Chapter 6

candidate business operations being rejected and missing ones added, the business process results proved to be of considerable value as a starting point. The mini-specs were naturally refined and incorporated into the business specification, which in turn allowed the workflow to be revised and made consistent. As stated earlier, the adopted engagement approach called for a business analysis performed in terms of Use Cases [J91]. Our approach, which complements Use Caselike operation specifications with invariants in the form of instances of generic relationships, is considered to have resulted in a considerably more complete, precise and understandable business specification than would have been achieved with the less precise Use Case notion. Our approach also added precision to the definition of the scope of the development project. A rough, initial project scoping was performed on the basis of both initial and refined business process definitions. Analysis showed that the resultant scope boundaries were indeed rough, including noticing that the preconditions of several inscope operations could never be met because the operations that created referenced objects had been declared out of scope. Feedback was encouraging There was a very satisfying amount, and kind, of feedback from the customer's participants in the analysis process, demonstrating that they understood the approach deeply enough to apply it successfully and independently. This is very significant evidence that notions such as invariants, preconditions and postconditions can be quickly learned and used by business analysts and business people (leading to "invariants in the trenches"). It is interesting to look at two typical questions. Firstly, "If you have 'properties' that have yet to be assigned as either a thing or attributes of a thing, what do you do with them so that you: remember them; but do not overload your specifications?" From this it was clear that the analysts, who had a significant background in data modeling, were in the process of accepting that the enumeration of lists of attributes for a "thing" is of less value to a business specification than are explicitly identified types and relationships. It had become apparent to them that many attributes are, at this level at least, irrelevant details, while others had hidden concepts of considerable importance that had now been represented in terms of types and relationships. Secondly, "When should you use subtyping, and when composition?" This question shows that the customer has understood both that these two generic relationships are different, and that it is frequently possible to formulate a business concept in a variety of different ways, especially while the concept and its scope has not yet been fully understood. Moreover, the relative importance of the concept, and its relationship to other business concepts, together dictate the most natural choice of its formulation. As such it is wrong, in general, to imagine that you can always most appropriately formulate a concept when you first encounter it.

Invariants in the Trenches

97

From analysis to design Analysis leading to a rigorous (and improved) understanding of the business can be an end in itself: for example, "business transformation" (or "business process modeling" used to explore possible "business reengineering" choices) requires rigor provided by business analysis. On the other hand, analysis is often performed as the basis for both scoping and design of a future information system. Therefore, designers and developers must be able to refine the business specifications produced during analysis into specifications of system solutions and, subsequently, implementations. There exists a solid theoretical basis for rigorously performing this refinement [H94]; and, moreover, there exist successful examples of doing so [R96; KR94; HKOS96]. These examples, however, provide only parts of what would be a reasonably complete implementation library of reusable generic refinement alternatives for the generic business specification constructs. The construction of this library is a topic of our current research and consulting engagements. Our own observations A number of possible enhancements to our approach were suggested as a result of this project. The most direct is the idea of an "operation invariant". While an enterprise-wide invariant is preserved by all operations, an operation invariant simply factorizes out conditions that are common to an operation's pre- and postcondition. The notion of a business operation invariant is well known elsewhere; for example the Z formal notation records both the change resulting from an operation (by convention A), and what remains constant (by convention E). It is worth noting that many operation invariants are, in fact, made explicit in the signature of an operation, for example by insisting that an operand is of a particular subtype of some more general type. It is conceivable, therefore, and a subject for future research, that many operation invariants can be moved to the signature by introducing new subtyping of the operation's operands and subsequently refining the signature of the operation.8 Other possible enhancements to the overall engagement approach are mentioned elsewhere, notably because of the considerable value-add to the business specification activity obtained from reusing the insurance domain knowledge embodied in the Insurance Application Architecture. The value of using workflow-like concepts and constructs to elicit business operations has already been recognized. However, we see a need to add substantially more rigor to these concepts and constructs in order to avoid some consequent rework, and the associated need to return back to subject matter experts in order to clarify the details. While the correct use of workflow-like concepts in eliciting business requirements, and the way of combining process and business analysis remains a subject for 8

The same approach is often used in Z schemas: the unnormalized signature ("above the line") includes, in terms of non-basic types, a substantial amount of semantic information such as the "constraint of the declaration" [S92]: for example, that a relation is, in fact, a function.

98

Chapter 6

future research, we would recommend an interim side-by-side application of business specification and workflow analysis, with cross fertilization, as occurred in this engagement. Caveats We explicitly paid attention to avoiding a common source of discontent and conflict within business automation projects. Two kinds of negative perceptions related to the production of a business specification need to be managed and avoided. Moreover, since approaches that recognize and address only one of these perceptions tend to exacerbate the other, a common front needs to be adopted by the leaders of each engagement activity with each repeatedly stating the value and objectives of related activities and the need to protect the boundaries between the activities. Firstly, there is a danger that business users may (correctly) perceive that they are not listened to when traditional approaches (eg data flow diagrams, attribute domains, semantic free "relationships"9, etc) or design or implementation strategies are applied and discussed in their presence. Such technological considerations are beyond the experience of most business users; at best they may be unable to understand the answers to their questions since they are expressed in the wrong terms, and at worse they may feel ignored. Secondly, software people, data modelers, network people, etc may (incorrectly) perceive that they are not being listened to when requirements are discussed in sufficient detail for a full business specification to be produced. Indeed, activities focused on understanding the business problem to be solved do not in themselves result in progress in providing the solution; they merely make it possible for a solution to be provided at all, and avoid the solution rework associated with commencing to provide a solution to the wrong problem. Fortuitous The mix of activities and goals for the engagement proved very helpful. The desire to make progress simultaneously on both a reusable technical architecture and the business analysis necessary for the application that would test this new architecture, kept designers and analysts apart and prevented many problems that have occurred elsewhere. Still, we were very glad of the short presentation that we had prepared underlying the distinct goals of analysis and design and explaining our analysis approach; this pitch was given and referred to repeatedly! On a lighter note, in evenings we explored the local second-hand book stores, and found a manual of procedures for a life insurance company, with full regulations and forms, written in 1835 [MHLIC]. This "business specification" was constantly referred to to show that in the past it has been possible to fully document a life 9

A typical semantic-free relationship is "this box and that box seem to be related, so let's draw a line between them to Formally Identify the relationship". Of courses, quite why we wish to identify the relationship is lost. The temptation to use semantic-free relationships comes from the "pointer" programming construct, which tells you where (in the memory) you can find an object or piece of data.

Invariants in the Trenches

99

insurance company's operating rules and all parameterizable (abstraction!) contract templates in 56 small-sized pages, and that a business was successfully run without automation. Of course times have changed and business rules and products are a little more complex, but such a small manual is still a source of inspiration.

Summary and feedback We hope that we have convinced you of both the value and possibility of separating business specification ("analysis") from solution specification ("design"). The project that we have used as an example naturally cried out for, and presented the opportunity for us to stress, this separation. Additionally, it presented the challenge of requiring quick results, not only in the form of a complete business specification, but in allowing the customer to be self-reliant in business analysis. And, in being successfully concluded, we have been able to show that a precise, compact, understandable, yet complete, business specification for a non-trivial business problem is possible; and more importantly can be produced locally by the customers analysts. Partly as a result of project necessity, we have been able to show that technical terminology (eg "invariant", "generic relationship") essential for writing such a specification can be quickly understood and freely used by all participants including subject matter experts. This is supported by the very pleasing testimony of the customer's business analyst: "We have referenced the [relationship] charts in user reviews of the [operation specifications] to clarify our ([the insurance company's] MIS) understanding of the data and data relationships. The users [the insurance company's underwriters] seem to be very comfortable with, and to understand, the charts. I think this is because the charts are uncluttered, and the concepts are simple and straightforward. I also think that minimizing the number of symbol types [meta-concepts] also helps to keep the charts non-threatening." Not only is this encouraging evidence that our approach is a significant contribution to the understanding of business problems, and particularly as a basis for system development, but it suggests that the business specification will be referred to — and fragments directly reused — when related applications are developed. In addition, it suggests that both we and the customer will continue to reuse these concepts and constructs on subsequent projects, and continue to benefit from the substantial analytical power that they bring. Major problems facing many system development projects result from a failure to properly capture or exploit business requirements. We have illustrated the sources of many of these problems and suggested approaches for avoiding them. In particular, we have stressed the importance of business specifications in separating the tasks of understanding business problems (analysis) and providing solutions to those problems (design). In doing so, we should both allow business analysts to produce complete business specifications understandable and correctable by business subject matter experts, and allow system designers to trust and utilize analysis results, and in

100

Chapter 6

so doing, allow them to concentrate on the many technological challenges of providing the solution.

References [D82] E W Dijkstra, Selected Writings on Computing: A Personal Perspective, Springer-Verlag, 1982. [GRM95] ISO/IEC JTC1/SC21, Information Technology - Open Systems Interconnection - Management Information Systems - Structure of Management Information - Part 7: General Relationship Model, ISO/IEC 10165-7, 1995. [H94] C A R Hoare, Mathematical Models for Computing Science, August 1994. [HKOS96] William Harrison, Haim Kilov, Harold Ossher and Ian Simmonds, From Dynamic Supertypes to Subjects: A Natural Way to Specify and Develop Systems, IBM Systems Journal, Volume 35, Number 2, to appear. [H093] William Harrison, Harold Ossher, Subject-Oriented Programming (A Critique of Pure Objects), Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications, ACM, Washington, D.C., September 1993, pages 411-428. [IAA95] IBM Insurance Application Architecture supporting insurance industry innovations. IBM G326-0591, May 1995. [J91] Ivar Jacobson, Industrial Development of Software with an Object-Oriented Technique, Journal of Object-Oriented Programming, Volume 4, Number 1, March-April 1991, pages 30-41. [KR94] Haim Kilov, James Ross, Information Modeling: an Object-oriented Approach. Prentice-Hall, Englewood Cliffs, NJ, 1994. [MW93] John-Jules Ch. Meyer, Roel J. Wieringa. Deontic logic in computer science. John Wiley and Sons, 1993. [MHLIC] Proposals of the Massachusetts Hospital Life Insurance Company, to make insurance on lives, to grant annuities on lives and in trust, and endowments for children, James Loring printer, Boston, 1835. [PM95] David Parnas, Jan Madey, Functional Documents for Computer Systems, Science of Computer Programming, Volume 25, 1995, pages 41-61. [R96] David Redberg. The search for the linking invariant: behavioral modeling versus modeling behavior. In: Object-oriented behavioral specifications (ed. by H.Kilov and W.Harvey), Kluwer Publishers, 1996. [RM-ODP 2] ISO/IEC JTC1/SC21/WG7, Open Distributed Processing - Reference Model: Part 2: Foundations (IS 10746-2 / ITU-T Recommendation X.902, February 1995). [S92] J M Spivey, The Z Notation: A Reference Manual, 2nd Edition, Prentice-Hall 1992. [S94] Paul Swatman, Management of Information Systems Acquisition Projects, Proceedings of OzMISD'94, First Australian Conference on Modelling and Improving Systems Development, Lilydale, Victoria, 3-4 February 1994, pages 115-131. [W89] Yair Wand, A Proposal for a Formal Model of Objects, in Object-Oriented Concepts, Databases and Applications, edited by Won Kim and Frederick Lochovsky, Addison-Wesley, 1989, pages 537-559.

7 FUNDAMENTALS OF OBJECT-ORIENTED SPECIFICATION A N D MODELING OF COLLECTIVE BEHAVIORS Reino Kurki-Suonio Software Systems Laboratory, Tampere University of Technology P.O. Box 553, FIN-33101 Tampere, Finland e-mail: [email protected]

ABSTRACT Starting from an analysis of the components that an applicable theory of programs needs, the fundamentals of object-oriented specification of collective behaviors are considered. It is shown that incremental derivation of operational models can be supported by a design methodology with a firm theoretical foundation, and that formal reasoning on behavioral properties is possible already in early stages of specification.

1

INTRODUCTION

Instead of fundamental concepts and theories, language notations and constructs often dominate our thinking of software, and precise meanings are analyzed only when problems arise. The same phenomenon appears with language paradigms. In object-orientation, certain ideas for modularity have also been taken as the starting point without much attention to the logical basis for reasoning. When the field matures, it becomes, however, important to analyze the fundamentals more carefully, and to develop better understanding of how our languages, tools and methodologies relate to these. The purpose of this paper is to contribute towards such understanding of reactive behaviors and their object-oriented description. The background of the paper is in experience gained in the development experimental language DisCo (.Distributed Cooperation) and associated and design methods [JKSS90, J92, S91, K92a, K92b, K93a, S95]. Rather explaining the language, an effort is made to present the conclusions

of an tools than in a

102

CHAPTER 7

language-independent form. The main contributions are in combining an intuitive operational model with the advantages of object-oriented design and a rigorous formal method. Incremental modeling is supported in way that allows both animation and formal reasoning on collective behaviors already in early stages of system specification. In the rest of the paper, Section 2 gives a brief survey on the components needed in a comprehensive theory of programs, and introduces the basic philosophy of the approach. The effect of object-orientation on reasoning about behaviors is discussed in Section 3. Sections 4 and 5 give a suitable programming logic and an abstract execution model that is related to it. Some fundamental language concepts, and support for a rigorous design methodology are then discussed. Section 9 describes how the approach can be used to deal with real-time properties, and the paper ends with concluding remarks in Section 10.

2

ON ABSTRACTIONS OF SOFTWARE

The ultimate reality of software, of which a theory should be an abstraction, consists of program executions on real computers. Which properties of reality should be described, depends on the situation. For instance, there is often no need for reasoning on real-time properties, in which case the theory may omit them. In reactive systems, program executions consist of interactions between software and its environment. Since real-time properties are often significant in them, a theory of reactive systems should be able to deal also with these. Within abstractions, an abstract machine, or an abstract execution model for programs, provides a possible first step. Turing machines and Petri Nets are examples of such models. It should be noticed that by themselves such models are not sufficient for a satisfactory theory. Given an abstract program and a particular property of such programs, a formal execution model allows, however, the use of mathematical reasoning to check whether the property holds or not. Programming languages and paradigms are abstractions to which much attention has been paid. In addition to giving linguistically manageable representations for programs, they add important facilities for structuring and modularity. Obviously, syntactic and structural properties are invaluable for the design, maintenance, and reuse of software, but they are not the most fundamental properties on which correctness notions, for instance, could be based.

Fundamentals of Object-Oriented Specification

103

Starting from the other end of abstractions, each theory has an underlying philosophy, which gives some basic principles and concepts. This determines the properties that one wishes to express and formally reason about. For programs, this level is often ignored, as other aspects - like structural properties and modularity - may be considered more critical for software design and maintenance. One of the fundamental distinctions at this level is, whether program execution is thought of as a transformation of input (or the initial state) into output (or the final state) - the "classical" transformational approach - or as a continual reactive behavior in which both a program and its environment participate. The transformational approach can also be used to deal with reactive systems by considering behaviors as sequences of transformations. Such approaches are essentially based on the synchrony hypothesis that the system is "infinitely fast" in comparison to its environment. The philosophy adopted in this paper is that of truly reactive behaviors, where the synchrony hypothesis is not used. Another basic issue is, whether behaviors consist of states or events. In each case, either linear time or branching time can be chosen. In the former, behaviors are considered as sequences that correspond to individual execution histories. In the latter, they are trees that correspond to all potential execution histories. In selecting between such alternatives, decisions are mostly based on intuition. Ultimately, to understand the consequences of the selections, one should compare all aspects of fully developed theories, together with associated languages, tools, design methodologies, and experiences of use. Unfortunately, only little progress has been made in such comparative evaluation. The choices in this paper are state-based and linear time. A suitable programming logic is essential to a theory of programs, to make it precise how those properties are expressed and proved that are of interest. Obviously, precise formulation and a possibility for formal proofs are prerequisites for a rigorous specification and design process. In particular, a programming logic is needed as a basis for a design methodology, which should support the preservation of properties when implementations are derived from specifications, and when specification modules are put together. In industrial practice this has been a neglected part of programming abstractions. In the absence of solid theoretical underpinnings, practical design methods have remained at a level where software is designed to have a manageable structure, but no support is provided for rigorous consideration of whether it conforms to its specification. To sum up, a comprehensive and applicable theory of programs can be seen as a set of abstractions, where the underlying philosophy, programming logic, design methodology, paradigms, languages, and execution models support each

104

CHAPTER 7

object method 1 object Figure 1

m

*

(

method object •* »> \

object

Single-object methods vs. multi-object actions.

other. Starting from the philosophical basis described, some fundamental issues of these abstractions are analyzed in this paper. One of the early attempts to develop such a comprehensive theory for concurrent programs has been Unity [CM88], to which the present approach will be briefly compared in the end of this paper.

3

OBJECTS A N D BEHAVIORS

The idea of object-oriented modeling is intuitively appealing, as the notions of classes, objects, and inheritance seem to reflect the way we organize our understanding of the world. Object-orientation has, however, been developed mainly for programming languages, where the level of abstraction is not the same as in the specification of collective behaviors. A critical look at some fundamental issues is therefore in place. Each object is usually considered an independent entity with a well-defined interface, i.e., an open system that interacts with its environment according to its specification. This requires that all interfaces have been fully defined before one can start reasoning about collective behaviors of objects. That delays rigorous consideration of these behaviors to a stage where also the design decisions on internal interfaces have been made. With this delay, many of the advantages of formal specification are lost. Notice that the definition of internal interfaces may even become useless, if the object structure of an implementation does not directly obey the object structure of the specification. The situation can be simplified by the closed system philosophy, where a system is always modeled together with its assumed environment. Premature interface definitions can then be avoided by replacing single-object methods by multiobject actions. These are actions whose execution does not depend on a single object only, but on a possibly larger number of "participant" objects as illustrated in Figure 1. This notion of joint actions was first introduced in [BK89] in a non-object-oriented framework of interacting processes.

Fundamentals of Object-Oriented Specification

105

In contrast to the conventional "individualistic" view on objects, multi-object actions provide an inherently collective view, which seems appropriate for specification. Decisions on how the participating objects make joint decisions on whether to commit in joint actions, or how they communicate within such actions, can be left to later stages of design. In general, an object may be intended for an environment where an arbitrary number of similar objects exist and cooperate. Therefore, to model all possible collective behaviors, a closed-system specification can give class definitions for objects, but may leave their numbers unspecified. For reasoning this means that properties are quantified over classes, but, whatever is proved, is then valid for any instantiation. Obviously, animation of specifications, or verification by conventional model checking techniques, requires spcecific instantiations.

4

P R O G R A M M I N G LOGIC

The basic philosophy of the approach makes it natural to use linear-time temporal logic, where logical formulas are interpreted over sequences of states. The variant that has been chosen here is Temporal Logic of Actions (TLA) [L94]. A set of program variables is assumed, each variable x having some value s\x\ in each state s. State functions f can be given as expressions over program variables, yielding some value s[/J for each state s. State predicates are truthvalued state functions. Behaviors are infinite state sequences a = (so,si,s 2 , * * •)» w r i e r e terminating behaviors keep repeating the final state. A pair of consecutive states (s^, «i+i) in a is called a step in a. The interpretation of a TLA expression E assigns a truth value a\E\ to each behavior a. For state predicates P this interpretation is given by the value of P in the initial state:

a[P] t so[P]. An action is a truth-valued expression A where program variables can occur both unprimed and primed. For a pair of states (s,t) an action A assigns a truth value s[*4]£, obtained by replacing all unprimed variables x in A by $[#], and all primed variables x' by t[x]. To a behavior • • •)> an action is interpreted to assign the truth value obtained for the first step,
SOIAJSL

106

CHAPTER 7

Each action A determines a state predicate Enabled A, which expresses that action A is enabled, s[Enabled Aj = 3t : 5[-4]*. In addition to ordinary logical connectives, a single basic temporal operator • (box, always) is given. For any TLA expression E, the interpretation of UE for a behavior a = (SQ,S\, 52,...) is defined as the (infinite) conjunction of <Jt[i£]|, i = 0,1, 2 , . . . , where Oi — (si, s;+i, Si+2, • • •)• In particular, for a state predicate P , D P expresses that P holds in all states of a behavior. For an action A and a set of program variables U, let [A]u be defined as [A]u =

AvStutu,

where Stutu denotes the "stuttering" action where all variables in U stay unchanged. A special characteristic of TLA is the restriction that an action A can only appear in contexts of the form d[.4]{/, where U usually is the collection of all program variables of interest. This makes TLA expressions insensitive to stuttering steps. In other words, states where the same values are repeated for all variables in U can be arbitrarily inserted to or deleted from a behavior, without affecting the TLA expressions that it satisfies. The dual of the temporal operator D, O (diamond, eventually), can be introduced as a derived operator, OE = -!•(-.£;). Defining (A)u = ^A]u

=AA(3xeU:xf^x)

one notices that actions can then also appear in contexts of the form

0(A)u-

Another useful derived operator is ^> (leads to), defined by E^F

= D(OE^OF).

Combinations of • and O give compound operators DO and OD for "infinitely often" and "eventually always," respectively. State invariants DP, expressing that a state predicate P will never be violated, are typical safety properties that are of interest in specifications. Liveness properties may, for instance, be given in the form (A)u ^ (B)c/» expressing that an execution of action A always eventually leads to an execution of B.

Fundamentals of Object-Oriented Specification

107

The only liveness properties that any implementation can directly enforce have the form of fairness properties. For instance, weak fairness with respect to an action A, meaning that A cannot stay continually enabled without being eventually executed, is formalized as WFu(A)

=

(UO(A)u)V(nO-iEnabled(A)u).

Some program variables in a TLA specification may be auxiliary specification variables that are not required to be present in an implementation. If x is such an auxiliary variable (or a set of such variables) in E, this is expressed by quantification as 3x : E. To be more precise, a behavior a satisfies 3x : E, if it can be transformed into a behavior r satisfying E, by inserting finite numbers of stuttering steps arbitrarily between any steps in cr, and assigning arbitrary values to variables x in the states of this behavior. In spite of its significance in determining the precise meaning of a specification, the distinction between quantified and non-quantified variables is less important in modeling, and it will be omitted in the following. A formula of the form PAD[^AFiA-AFfc, where F;, i — 1 , . . . &, are fairness conditions, is said to be in the canonical form. This form has an operational interpretation, where P is the requirement for the initial state of variables in U, A describes the possible events in the system, and the fairness conditions F{ give the requirements that a "scheduler" of the events has to obey.1 Based on this operational interpretation, any program can be formalized as a TLA formula in the canonical form. When specifications and implementations are both formalized in TLA, an implementation is correct if and only if it logically implies the specification. This formalization ignores the distinction whether it is the system or the environment that is responsible for a given step in a behavior. This is a price one has to pay for the convenience of reasoning on collective behaviors in closed systems. Obviously, the distinction between system and environment actions can easily be added to a specification model, and this distinction should also be present in a correct implementation. Among the characteristics of TLA, insensitivity to stuttering is important for proper support of a design methodology that allows incremental introduction x To be more precise, this operational interpretation assumes that for a fairness formula F{ = WFu(Bi), for instance, the safety part PAO[A]u of the formula implies D(EnabledBi => Enabled (A A B{)), i.e., whenever B{ is enabled, its execution would be allowed by D[«4][/.

108

CHAPTER 7

of detail, since addition of new variables often induces intermediate states in behaviors. The canonical form also corresponds nicely to an operational model of concurrent and distributed programs. Furthermore, the notion of actions allows convenient reasoning also in terms of the events that take place in actions.

5

EXECUTION MODEL

It can be argued that logic is by itself sufficient as a specification language [L94]. I prefer, however, to separate linguistic and structural aspects of formal modeling from the logic for reasoning. For a specification language it is then an advantage, if it has a simple relationship to the logic that is used for reasoning. Even when the inference rules of the logic are not formally applied, such a correspondence increases the confidence that one can have in informal proofs. In our case, an execution model should conform closely to the operational interpretation of canonical TLA expressions. In particular, it is important that the atomicity of events and the fairness assumptions are unambiguously defined in the execution model. Other than canonical TLA expressions can be used for formulating the required properties that should be proved, and the full power of the logic is available for reasoning. These requirements are satisfied in a natural way by the action-oriented execution model of [BK89]. In it, the dynamic behavior of a program (or an operational specification) is determined by a collection of actions of the form

where gi is a guard that has to be true for a{ to be executed, and Si is the body that can then be executed as an atomic event. Starting from an initial state, an execution consists of a sequence of actions. At any time, any action with a true guard can be chosen, i.e., the execution model is inherently nondeterministic. By fairness requirements with respect to some a{ one can constrain nonterminating executions, and also disallow premature termination. Although this execution model is sequential, one can notice that concurrent execution of independent actions gives the same outcome as their sequential execution in any order. Therefore, the execution model is also suitable as a basis for concurrent implementation. In fact, the main difference to conventional execution models is that there is no built-in sequential control structure, and this is only an advantage in coping with concurrency. With the possibility for

Fundamentals of Object-Oriented Specification

109

arbitrarily complex guards and bodies, the execution model can also be used at high levels of abstraction, which is desirable for a specification language. Similar execution models have also been applied for other purposes in computing. The execution model of production system languages like OPS5 is basically the same, although the problems that are relevant for them are different. The execution model in Unity [CM88] can also be considered as action-oriented, but it has no explicit guards, and it has a simple built-in fairness assumption.

6

BASIC LANGUAGE CONSTRUCTS

An obvious way to use the above execution model in an object-oriented language is to take class and action definitions as basic syntactic entities. As for the state, a class definition gives a pattern for those program variables that are local to each object of the class. With this structuring facility, the global state of a system is no longer an unstructured collection of program variables as in basic TLA and in the execution model. Scalability of specifications is also improved by having the possibility for varying numbers of objects in classes. To support modeling with explicit state transition systems, familiar from many modeling formalisms, the local state of an object can be structured as a finitestate system, allowing also hierarchical states as in statecharts [H87], and with additional variables attached to these states. In terms of TLA, finite-state systems can be understood as shorthand for some program variables that are local to objects. The lack of a built-in control structure in the action-oriented execution model makes finite-state systems important for this approach, since they can easily be used to model control structures within objects. In specifications, relations between objects are another important part of the global state, and graphical notations are used to introduce them in many informal object-oriented design methods. A good specification language needs facilities for describing them at an abstract level, i.e., at a higher level than in terms of explicit local variables in objects. In addition to state-related attributes and relations, each object has a classspecific capability to participate in certain actions, which can be specified in action definitions. For instance, if two objects of classes C\ and C2, respectively, are required for the execution of action a, this can be specified in the form a(x :Cuy:C2)

: 9 -* 5,

110

CHAPTER 7

where g and S can access the attributes and relations of the two participants by the formal names x and y. Notice that for a language it is natural to assume that those attributes that are not touched by S will retain their previous values, while in a logical action it is important to make also such assumptions explicit. Nondeterminism is essential in an execution model for a specification language. Basically, it reflects either lack or deliberate hiding of some information. It is needed, for instance, to describe concurrency, and to avoid overspecification. In incremental construction of specifications it is especially useful, as it allows to describe the effects of an action already at a level where this cannot be done in a deterministic form. In addition to nondeterminism in choosing the next action to be executed, we have nondeterminism in selecting its participants. Of course, the participants must always be ones for which the action is enabled. Furthermore, there is a need for nondeterministic action effects, as mentioned above. A convenient facility for this is to have parameters in actions. With them, this form of nondeterminism can be encapsulated in the selection of parameter values, and the body can still be given in a deterministic form. Constraining the parameters is a convenient way to restrict nondeterminism later, whenever this is needed. As an example, if participants x : C\ and y : C2 need to agree on an integer value i that affects the execution of action a, and both may pose some constraints on the admissible values, this can be expressed in the form a(x : C\,y : C 2 ,i : integer) : g —> 5, where g contains the constraints on i, and the effect of S depends deterministically on i. Later stages of design can then restrict the value of i to be uniquely determined by the participants, and the system can also be refined to have explicit handshake actions by which the participants agree on this value. With object-orientation, inheritance becomes an important facility to be supported by the language. As usual, all attributes (including relations) of a superclass should be automatically taken to subclasses, and additional attributes can also be added. Similarly, the natural default for actions is that a subclass inherits all capabilities to participate in actions. Since actions are not explicitly invoked by calls in the execution model, multiple inheritance causes none of the problems that are normally associated with it. In fact, multiple inheritance becomes an important facility to combine the properties of classes that have been independently derived from a common superclass.

Fundamentals of Object-Oriented Specification

Figure 2

Figure 3

111

Specialization of inherited actions.

Example of combining two actions.

In object-oriented programming it is convenient to be able to replace an inherited method by a totally different one. In specification it is not desirable to allow arbitrary replacement, since it is important to preserve the behavioral properties of all classes. Therefore, modifications to inherited actions should be such that the specialized actions logically imply the original inherited actions, as illustrated in Figure 2. How to guarantee this will be explained below. Further constructions that are needed with actions are different ways to combine them into more complex atomic actions. For instance, given actions a(x : C\) and b(y : C2), one might wish to combine them into a single atomic action ab(x : C\,y : C2) as illustrated in Figure 3. The guard of ab could be taken as the conjunction of the guards of a and b, possibly strengthened by some additional conditions, and the body would have the effect of both bodies. Notice that, compared to sequential execution of a and 6, the intermediate state is missing in the case of ab, which affects some behavioral properties of the system.

7

REFINEMENT B Y SUPERPOSITION

For a design methodology it is important to support stepwise derivation of an implementation from a specification. Since specifications of realistic systems are too complex to be given in one step, a stepwise or incremental method is needed also in their construction.

112

CHAPTER 7

In general, if system S»+i logically implies Si, then Si+i is a refinement of Si. Ideally, SQ in a sequence S o , . . . , S n of refinements would be the first approximation of a specification, and S n would be (a model of) an implementation. In other words, a complete specification can first be constructed incrementally, and the later refinements could introduce design decisions reflecting architectural constraints, implementation policies, etc. Instead of using a purely linear derivation sequence, independent systems and parallel derivation chains can also be combined, as will be described below. For actions we say that action B is a refinement of A, if B => A. At the language level, action refinement means possible strengthening of its guard, and possible additional effects on variables that were not previously present. Ignoring liveness properties and the special role of specification variables, a canonical TLA formula corresponding to our language ideas has the form E = PAD[A!

V---V An]f/,

where P is a satisfiable initial condition, and actions A% correspond to the different syntactic actions a;. If the set of program variables is extended to V, U C V, the initial condition is strengthened to Q that involves this extended set, Q => P , and each Bj, j = 1 , . . . , n, is a refinement of either a given Ai or the stuttering action Stutu, then F =

QAn[B1V--VBn]v

is a refinement of E, F => E. This restricted form of refinement can easily be supported by a language. Starting with a given system, such a refinement can involve the following kinds of modifications: class definitions can be extended with additional attributes; new classes can be introduced; new relations between objects can be introduced; stronger initial conditions involving the new variables and classes can be given; refined actions can have new participants and parameters; refined actions can have strengthened guards and actions can be removed; refined actions can have additional effects on variables not present in the old system; new actions can be introduced that do not modify the variables of the old system. Figure 4 illustrates a refinement where class C is extended, a new class D is introduced, actions a and b are refined in different ways, and new actions are introduced. The refinement relation between actions is shown by dotted arrows. Action refinement is a special case of specialization, which is useful especially for inherited actions. In addition to the kinds of modifications mentioned above,

Fundamentals of Object-Oriented Specification

113

fc^^>^)) Figure 4

Refinement by superposition.

which then guarantee that a subclass does not violate the properties of its superclasses, the guard of a specialized action gets an additonal specialization condition, which constrains a participant to the subclass in question. The original action is also retained, but in a form where its guard is strengthened by the complement of the specialization condition. Obviously, action refinement can be understood as the special case where the specialization condition is identically true, and the original action is therefore completely removed. Action specialization makes multiple inheritance especially useful in specifications. For instance, let C be a class with an action a, and let C\ and C 2 be two subclasses of C with specializations a\ and 02 of a. An object that belongs to both C\ and C 2 possesses the attributes of both, and its action a automatically implies both a\ and (22 • This provides a convenient facility to introduce independent specializations that can be easily combined when needed. The form of transformations described above is called superposition, since it effectively superimposes additional detail on an existing system. The additions do not interfere with the original system in the sense that all safety properties are preserved. This is a major advantage for a language-supported transformation technique. In general, liveness properties may, however, be violated in superposition, and their preservation may therefore require separate proofs. Besides what can be done by superposition, there are also other constructions that are useful in refinement, like the combination of actions already referred to. Since action combination removes intermediate states, also safety properties are then affected. State invariants are, however, preserved also in this case. Also, if it is known that at most one of the component actions modifies other than specification variables, then all safety properties are preserved.

114

CHAPTER 7

For a design methodology the use of superposition has some important consequences. It is often recommended that the object structure be first analyzed in detail, before any dynamic modeling is started. This means that a considerable part of the global state of the system has to be designed before any behavioral properties can be checked or even discussed. Incremental specification with superposition leads to a different principle: only few variables should be introduced at a time, but together with all actions that can modify their values, and with the associated invariants that should be maintained. This is compatible with the view that variables have no independent meaning as such, only in how they affect behaviors. Notice that the requirement to introduce actions at the same time with variables is not restrictive, since this can be done also when the effects cannot be described deterministically. For this reason the possibility for nondeterministic actions is essential for the design method.

8

SUPPORT FOR MODULARITY

The natural units for modularity in this approach are not individual objects or classes, but "complete" systems containing both class and action definitions. In this section we discuss, how superposition provides a suitable basis also for the combination of systems. The systems to be combined may be either independent systems or independent refinements of a common ancestor system. Ideally, combining two systems should correspond to logical conjunction. Let E F

= =

PAD^V-V^li/, (?AD[61V--V6n]v,

be two safety specifications. By simple calculation we get: E A F = (P A Q) A D[(\f At A Bj) V ( V Ai A Stuty) V {\f B3 A i,j

i

Stutu)]uuv.

3

In the action part, the first disjunct consists of synchronized pairs of actions. The other disjuncts give nonsynchronized extensions of actions from one component, where the variables of the other component stay unchanged. When two systems are combined by importing them to a new system, and the combined system is refined further, the above formula gives a basis for considering which kinds of actions the new system may have. For independent systems, i.e., when U D V = 0, all synchronized action pairs, and all non-synchronized action extensions can be immediately constructed from the component actions.

Fundamentals of Object-Oriented Specification

•"

£">

*-

Figure 5

115


^>

Combining independent refinements.

As an example, consider a combination of two systems, where one contains an "output" action give, and the other contains an "input" action take: give(... ,i : integer), take(... ,j : integer). The synchronized combination, with the additional constraint i = j , then models an event where a value is transmitted from one of the subsystems to the other. This is actually the construction illustrated in Figure 3, except that actions a and b now come from different systems, and the safety properties of the component systems therefore remain valid. To illustrate combination of independent refinements, consider a system with logically exclusive and non-stuttering actions a and b. Let these be refined independently in two systems, which also introduce new actions as illustrated in Figure 5. With the notations of this figure, when the two systems are combined, we can have synchronized combinations of a\ and <22, of b\ and 62, and of c\ and C2, and nonsynchronized extensions of C\ and C2. All other possibilities are identically false. Notice that if a class in the uppermost part of Figure 5 has been extended in both refinements, then both extensions are included in the combined system. Therefore, the resulting class behaves like a new subclass with the corresponding classes in the intermediate systems as its superclasses.

116

CHAPTER 7

Part 1

Part 2

^

^

Ql

C y\

^

r^ Jnfacehv Figure 6

•

Q2

>i

K.

J

A system consisting of two communicating parts.

In a design methodology, the possibility for combining independent refinements is important for division of labor. Suppose that a system has been designed to consist of two parts with clearly defined interface objects, as illustrated in Figure 6. A refinement refines only one part, if it leaves the other part intact. Two refinements that independently refine the two parts can always be directly combined into a system that automatically is also a refinement of the original system. In other words, it is possible to work independently on the design of the two parts, with a guarantee that the resulting designs will fit together. In the above situation the original liveness properties are also preserved by the combined fairness conditions. If two arbitrary refinements are combined in the same way, as illustrated in Figure 5, safety properties are always preserved, but liveness properties may be violated. The combination of two systems is, in fact, superposition on both of them. This shows that superposition provides an important conceptual foundation for transformations that are useful in modular derivation of systems. As another example of the possibilities that superposition offers for system structuring, consider a modeling problem discussed by Jackson [J95]. The construction of a CASE tool may be decomposed into implementing operations of various recognisable types, like editing, information system operations, etc. The problem is that reality is not hierarchical, and some subproblems may exhibit multiple characteristics, which is an obstacle for hierarchical modeling formalisms. For instance, while an operation like "insert" is a pure editing operation, and "log on" is a pure information system operation, some, like "save document," are relevant to both subproblems. With superposition it is possible to derive the generic characteristics of the different subproblems independently. In a combined system, nonsynchronized action extensions would then correspond to uniquely classified operations, while operations with multiple characteristics would be represented as synchronized action combinations.

Fundamentals of Object-Oriented Specification

9

117

REAL-TIME MODELING

Real time may or may not be essential in behavioral properties. When it is, real-time properties can be modeled using auxiliary time-related variables, which can be added by superposition [AL94, K93a, K93b]. In mapping action execution to real time, it will be assumed for simplicity that actions are instantaneous. Two special variables are introduced, ft and A. Of these ft always shows the most recent reading of time when an action was executed, and is initialized as 0. Variable A contains a set of unique time values that are used as deadlines, and is initialized as empty. All deadlines are assumed to have different identities, even if their time values are the same. Instead of using separate "tick actions" for advancing time as in [AL94], for instance, an implicit parameter r is added to each action to denote the time when the execution takes place. An additional implicit conjunct ft < r < min(A) in guards, together with implicit updating of ft in bodies, ft' = r, forces actions to be executed in a non-decreasing temporal order and without ever exceeding any of the deadlines in A. No explicit changes of ft are allowed, and changes in A are restricted to adding deadlines and deleting them in the same superposition step. Intuitively, time passes in the model only when something happens in the system, and fairness is still the only "force" that can force actions into execution. Without fairness requirements, time can stop by no further actions being executed. Similarly, if there is a deadline that would be removed only by an action that stays disabled, time can never pass it. Such counterintuitive phenomena are possible in models that satisfy the required safety properties but do not possess all the liveness properties needed. Obviously, if the intuitively natural liveness property is satisfied that ft always grows unboundedly, such phenomena become impossible. For further general discussion on this philosophy of real time, see e.g. [K94]. Unlike for other variables, later superposition steps may invalidate even safety properties involving variables ft and A. This causes no harm, however, since all those safety properties are preserved that do not explicitly refer to them. An advantage of this approach is that it allows reasoning about real-time properties in exactly the same way as about other properties. It should be noticed,

118

CHAPTER 7

however, that since the logic was chosen to be interpreted over individual behaviors, the real-time properties that can be handled are properties satisfied by all behaviors. Statistical efficiency properties, for instance, fall outside them.

10

CONCLUDING REMARKS

The approach presented in this paper is based on a small number of fundamental concepts and principles, but it provides a comprehensive set of abstractions that are applicable in the specification and modeling of reactive behaviors. The different components that are needed in a theoretically satisfactory approach also support each other in a natural way. The components of a comprehensive theory have been addressed to various degrees also in many other approaches. A recent survey of tools for specifying reactive systems [BCN95] classifies them into operational (ones defined in terms of states and transitions), descriptive (mathematical or axiomatic), and dual approaches where the possibilities of the former are integrated. Obviously, only dual approaches can provide a satisfactory set of abstractions, and our approach falls into this category. As a counterexample to a statement in [BCN95] it also demonstrates that an operational model can be suitable for execution already at a stage where the model is only partially specified. A neglected part in many approaches has been support for rigorous design methodologies. An exception is Unity [CM88], with which our approach has also otherwise much in common. However, Unity has not been designed for object-oriented modeling, which makes its integration with currently advocated design practices more difficult. Essential differences in the execution models are Unity's lack of guards, and its fixed fairness assumption. The superposition construct in Unity preserves even liveness properties, which means that it does not allow what would correspond to strengthening of action guards. This prevents such use of superposition that is essential for the design methodology discussed in this paper. On the other hand, combination of systems is not guaranteed to preserve even safety properties in Unity, which restricts also its use in modular development of systems. Superposition-based support for incrementality is an essential aspect in this approach. According to our experiences it is recommendable to start a design with a very primitive model, which only gives some basic notions to build on, and it has proved important that the model can be animated already at this

Fundamentals of Object-Oriented Specification

119

stage. Brooks has reported similar experiences about incremental development - or growing - of software [B87]. In practice, a theory of computing can be used at different levels. In some applications there is already need for computer-supported formal proofs. However, a theory is not only for computers and automated tools, but also for people to use. Therefore, a theory should give a firm but sufficiently simple and intuitively natural basis for thinking about programs, so that also informal argumentations can be theoretically sound. The approach should also be suited for visualization and animation tools that encourage the combined use of informal validation and formal inspection. As supported by experience gained in case studies and small-scale experiments with DisCo, the approach presented here provides a promising basis for all this.

Acknowledgements The ideas presented in this paper have been developed in connection with the DisCo project at Tampere University of Technology. Contributions by other members of the team are gratefully acknowledged, especially those of HannuMatti Jarvinen (language design), Kari Systa (tool development and real-time aspects), Tommi Mikkonen (interface refinement), and Pertti Kellomaki (development of a proof assistant). The ideas have also been influenced by many other people, most notably by Ralph-Johan Back in our joint work on joint action systems, and by Leslie Lamport in his work on TLA and its use in formal specification.

REFERENCES [AL94]

Abadi, M., Lamport, L., "An old-fashioned recipe for real time," ACM Transactions on Programming Languages and Systems 16, 5, September 1994, pp. 1543-1571.

[BK89]

Back, R.J.R., Kurki-Suonio, R., "Decentralization of process nets with a centralized control," Distributed Computing 3, 1989, pp. 73-87. An earlier version in "Proc. 2nd ACM SIGACT-SIGOPS Symp. on Principles of Distributed Computing, 1983, pp. 131-142.

[B87]

Brooks, F.P.Jr., "No silver bullet - Essence and accidents of software engineering," Computer 20, 4, April 1987, pp. 10-19.

120

CHAPTER 7

[BCN95]

Bucci, G., Campanai, M., Nesi, P., "Tools for specifying real-time systems," Real-Time Systems 8, 2/3, March/May 1995, pp. 117-172.

[CM88]

Chandy, K.M., Misra, J., "Parallel Program Design - A Foundation," Addison-Wesley, 1988.

[H87]

Harel, D., "Statecharts: a visual formalism for complex systems," Science of Computer Programming 8, 1987, pp. 231-274.

[J95]

Jackson, M., "The world and the machine," Proc. 17th Int. Conf. on Software Eng., 1995, pp. 283-292.

[J92]

Jarvinen, H.-M., "The design of a specification language for reactive systems," Tampere University of Technology, Publication 95, 1992.

[JKSS90] Jarvinen, H.-M., Kurki-Suonio, R., Sakkinen, M, Systa, K., "Objectoriented specification of reactive systems," Proc. 12th Int. Conf. on Software Eng., 1990, pp. 63-71. [K92a]

Kurki-Suonio, R., "Operational specification with joint actions: serializable databases," Distributed Computing 6, 1, 1992, pp. 19-37.

[K92b]

Kurki-Suonio, R., "Modular modeling of temporal behaviors," in "Information Modelling and Knowledge Bases III" (eds. S. Ohsuga et al.), IOS Press, 1992, pp. 283-300.

[K93a]

Kurki-Suonio, R., "Stepwise design of real-time systems," IEEE Transactions on Software Engineering 19, 1, January 1993, pp. 56-69.

[K93b]

Kurki-Suonio, R., "Hybrid models with fairness and distributed clocks," In "Hybrid Systems" (eds. R.L. Grossman, A. Nerode, A.P. Ravn, H. Rischel), LNCS 736, Springer-Verlag, 1993, pp. 103-120.

[K94]

Kurki-Suonio, R., "Real time: further misconceptions (or half-truths)," Computer 27, 6, June 1994, pp. 71-76.

[L94]

Lamport, L., "The temporal logic of actions," Transactions on Programming Languages and Systems 16, 3, May 1994, pp. 872-923.

[S91]

Systa, K., "A graphical tool for specification of reactive systems," Proc. Euromicro '91 Workshop on Real-Time Systems, 1991, pp. 12-19.

[S95]

Systa, K., "A specification method for interactive systems." Tampere University of Technology, Publication 172, 1995.

8 AN OVERVIEW OF L A R C H / C + + : BEHAVIORAL SPECIFICATIONS FOR C + + MODULES Gary T. Leavens Iowa State

Department of Computer Science. University, Ames, Iowa 50011 USA [email protected]

ABSTRACT An overview of the behavioral interface specification language L a r c h / C + + is presented. The features of L a r c h / C + + used to specify the behavior of C + + functions and classes, including subclasses, are described, with examples. Comparisons are made with other object-oriented specification languages. An innovation in L a r c h / C + + is the use of examples in function specifications.

1

INTRODUCTION

L a r c h / C + + [L95] is a model-based specification language t h a t allows the specification of both the exact interface and the behavior of a C + + [ES90, S91] program module.

1.1

Model-Based Specification

T h e idea of model-based specifications builds on two seminal papers by Hoare. Hoare's paper "An Axiomatic Basis for C o m p u t e r P r o g r a m m i n g " [H69], used two predicates over program states to specify a c o m p u t a t i o n . T h e first predicate specifies the requirements on the state before the computation; it is called the c o m p u t a t i o n ' s precondition. T h e second predicate specifies the desired final state; it is called the c o m p u t a t i o n ' s postcondition.

122

Chapter 8

Hoare's paper "Proof of correctness of data representations" [H72], described the verification of abstract data type (ADT) implementations. In this paper Hoare introduced the use of an abstraction function that maps the implementation data structure (e.g., an array) to a mathematical value space (e.g., a set). The elements of this value space are thus called abstract values [LG86]. The idea is that one specifies the ADT using the abstract values, which allows clients of the ADT's operations to reason about calls without worrying about the details of the implementation. A model-based specification language combines these ideas. That is, it specifies procedures (wrhat C + + calls functions), using pre- and postconditions. The pre- and postconditions use the vocabulary specified in an abstract model, which specifies the abstract values mathematically. The best-known model-based specification languages are VDM-SL [J90] and Z [S92, S89, H93]. Both come with a mathematical toolkit from which a user can assemble abstract models for use in specifying procedures. The toolkit of VDM-SL resembles that of a (functional) programming language; it provides certain basic types (integers, booleans, characters), and structured types such as records, Cartesian products, disjoint unions, and sets. The toolkit in Z is based on set theory; it has a relatively elaborate notation for various set constructions, as well as powerful techniques for combining specifications (the schema calculus).

1.2

Larch

The work of Wing, Guttag, and Horning on Larch extends the VDM-SL and Z tradition in two directions [W83, W87, GHG+93]: •

Although a mathematical toolkit is provided [GHG + 93, Appendix A], specifiers may design their own mathematical theories using the Larch Shared Language (LSL) [GHG+93, Chapter 4]. This allows users, if they desire, to create and use an abstract model at exactly the right level of abstraction; that is, one can either build an abstract model out of readily available parts, or one can build a model from scratch. Clearly, not everyone should be building models from scratch; thus it is convenient that those that do get built can be shared, even among users of different behavioral interface specification languages.

An Overview Of Larch/C++

•

123

Instead of one generic specification language, there are several behavioral interface specification languages (BISLs), each tailored to specifying modules to be written in a specific programming language. E x a m p l e s include LCL [GHG+93, Chapter 5] (for C), LM3 [GHG+93, C h a p t e r 6] (for Modula-3), L a r c h / A d a [GMP90] (for A d a ) , L a r c h / C L U [W83, W87] (for CLU), Larch/Smalltalk [CL94] (for Smalltalk) and L a r c h / C + + .

T h e advantage of tailoring each BISL to a specific p r o g r a m m i n g language is t h a t one can specify both the behavior and the exact interface to be prog r a m m e d [L89]. This is of great practical benefit, because the details of the interface t h a t need to be specified vary among p r o g r a m m i n g languages. For example, because L a r c h / C + + is tailored to the specification of C + + code, it allows uses to specify the use of such C + + features as v i r t u a l , c o n s t , exception handling, and exact details of the C + + types (including distinctions between types such as i n t and l o n g i n t , pointers and pointers to constant objects, etc.). No such details can be specified directly in a specification language such as VDM-SL or Z t h a t is not tailored to C + + . T h e same remark applies to object-oriented ( 0 0 ) specification languages such as Z + + [L92, LH94b], Z E S T [CR92], Object-Z [R92, RD94], OOZE [AG91, AG92, AG94], MooZ [MC92, MCS94], and V D M + + [M94]. However, apparently there are "variants of Fresco" [W91, W92a] t h a t are "derived from C + + and Smalltalk" [W92b, p. 135]; these may permit more exact specification of interface details. T h e remainder of this chapter gives a set of examples in L a r c h / C + + , and then concludes with a discussion. T h e set of examples specifies a hierarchy of shapes t h a t is used as a case study in the book Object Orientation in Z [SBC92].

2

QUADRILATERALS

To write a specification in L a r c h / C + + , one specifies an abstract model in LSL, and then uses t h a t to specify the C + + interface and its behavior. T h i s section specifies the abstract model of quadrilaterals, then the abstract class QuadShape and the class Q u a d r i l a t e r a l .

2,1

Abstract Model of Quadrilaterals

Although LSL has the power to specify abstract models "from scratch," most abstract models are built using tuples (records), sets, and other s t a n d a r d m a t h -

124

Chapter 8

Quad(Q) : trait includes FourSidedFigure, NoContainedObjects(Q) Q tuple of edges: Edges, p o s i t i o n : Vector implies QuadDesugared(Q)

Figure 1 The LSL trait Quad, which specifies an abstract model for quadrilaterals located at some particular position.

ematical tools that are either built-in to LSL or found in Guttag and Homing's Handbook [GHG + 93, Appendix A]. A typical example is given in Figure 1. That figure specifies a theory in LSL, using a LSL module, which is called a trait. This trait is named Quad, and has a parameter Q, which can be replaced by another type name when the trait is used. This trait itself includes instances of two other traits: FourSidedFigure, and NoContainedObjects(Q). The latter of these simply says that an abstract value of type Q has no subobjects [L95, Section 7.5]. The type Q itself is defined next, by using the built-in LSL tuple of notation. What LSL calls a tuple is a record-like value; in this case the tuple has two fields: edges of type Edges and p o s i t i o n of type Vector. The types Edges and Vector are specified in the trait FourSidedFigure. Following this section of the trait Quad, beginning with the LSL keyword implies, is a statement that the theory of the trait Quad contains the theory of the trait QuadDesugared(Q). The implies section illustrates an important feature of the Larch approach: the incorporation of checkable redundancy into specifications. Such redundancy can serve as a consistency check; it can also highlight consequences of the specification for the benefit of readers, as in Figure 1. The trait QuadDesugared, which is shown in Figure 2, is a desugaring of Figure 1 (minus the implies section). This desugaring explains the LSL tuple of notation. In Figure 2, the signatures of the operators on Q values are specified in the lines following introduces, and their theory is specified in the lines following asserts. In the theory section, the generated by clause states that all abstract values of type Q are equivalent to [e9v] for some e and v. (This corresponds to the u no junk" principle of the initial algebra approach [GTW78, BG82, FGJM85]. However, note that uses of this principle are specifiable in LSL; that is, although tuples are generated by default, LSL does not require that all types of abstract values be generated.) The partitioned by clause says that two Q values are equal unless they can be distinguished using the operators .edges and .position.

An Overview Of Larch/C++

125

QuadDesugared(Q): t r a i t i n c l u d e s FourSidedFigure, NoContainedObjects(Q) introduces [ _ _ , _ - ] : Edges, Vector -+ Q .edges: Q —• Edges . p o s i t i o n : Q —• Vector s e t _ e d g e s : Q, Edges —• Q s e t _ p o s i t i o n : Q, Vector —• Q asserts Q g e n e r a t e d by [ , ] Q p a r t i t i o n e d by .edges, .position V e , e l : Edges, v , v l : Vector ( [ e , v ] ) . e d g e s == e; ( [ e , v ] ) . p o s i t i o n == v; set__edges([e,v] , e l ) == [ e l , v ] ; s e t _ p o s i t i o n ( [ e , v ] , v l ) == [ e , v l ] ;

Figure 2 Quad.

The LSL trait QuadDesguared, which is a desugaring of the trait

(This is the opposite of what is done by default in the initial algebra approach.) Following the V (typed as \ f o r a l l by users) are some declarations and equations. Besides the field selectors, a tuple in LSL provides " u p d a t e " operators; in this case they are s e t _ e d g e s and s e t _ p o s i t i o n . Because LSL a b s t r a c t values are purely m a t h e m a t i c a l , these do not make any changes to a tuple, b u t produce a similar tuple with a change to the relevant field. Another example of a trait t h a t uses the tuple notation, but which d e m o n s t r a t e s a bit more about LSL, is the trait F o u r S i d e d F i g u r e . This trait is specified in Figure 3. It includes two other traits: P r e V e c t o r S i g gives an abstract m o d e l of vectors (the type Vec[T] with an approximate l e n g t h operator) and i n t which is an abstract model of the integers (the type i n t with appropriate auxiliary definitions for C + + ) . T h e trait F o u r S i d e d F i g u r e defines the type Edges as a tuple of four V e c t o r values. As a convenience, the trait also introduces the operator, [ ] , which allows one to write e [ l ] instead of e . v l . In t h e a s s e r t s section, the specification defines the condition on four-sided figures from [SBC92] as a predicate. T h e predicate i s L o o p ( e ) holds j u s t when the vectors sum to zero (make a loop). In the i m p l i e s section this property is s t a t e d in an equivalent way. (It would be inconsistent (i.e., wrong) to simply assert t h a t the edges always sum to zero; doing so would assert t h a t all combinations of four

126

Chapter 8

FourSidedFigure: t r a i t i n c l u d e s P r e V e c t o r S i g ( S c a l a r , Vector f o r Vec[T]), i n t Edges t u p l e of v l : Vector, v2: Vector, v 3 : Vector, v4: Vector introduces [ ] : Edges, i n t —• Vector isLoop: Edges •—• Bool a s s e r t s V e: Edges isLoop(e) == ( e . v l + e.v2 + e.v3 + e.v4 = 0: V e c t o r ) ; e [ l ] == e . v l ; e[2] == e . v 2 ; e[3] == e . v 3 ; e[4] == e . v 4 ; i m p l i e s V e: Edges isLoop(e) == ( e [ l ] + e[2] + e[3] + e[4] = 0 : V e c t o r ) ;

Figure 3

The LSL trait FourSidedFigure.

vectors sum to zero. Such properties must be handled by either constructing an abstract model from scratch, or by asserting t h a t the property holds at the interface level, as is done below.) In [SBC92], vectors are usually treated as a given set, meaning t h a t their specification is of no interest. A type of values can be treated as a given set in LSL by simply specifying the signatures of its operators t h a t are needed in other parts of the specification, without giving any assertions a b o u t their behavior. Figure 4 shows how to do this in LSL. (For a more detailed specification of an appropriate model of vectors for this example, see the trait P r e V e c t o r in [L96].) Now t h a t we are done with the initial m a t h e m a t i c a l modeling, we can t u r n to the behavioral interface specifications.

2.2

Specification of QuadShape and Quadrilateral

Following the Z E S T [CR92] and Fresco [W92b] specifications of the shapes example, the first class to specify is an abstract class of four-sided figures,

An Overview Of Larch/C++

127

PreVectorSig(T): trait introduces __ + ._: Vec[T], Vec[T] -• Vec[T] _ _ * _ _ : T, Vec[T] — Vec[T] 0: — Vec[T] - __.: Vec[T] -+ Vec[T] — - —: Vec[T], Vec[T] -+ Vec[T] _ _ • _ _ : Vec[T], Vec[T] -• T 7. inner product length: Vec[T] —• T 7# approximate length

F i g u r e 4 The LSL trait PreVectorSig, which can be used if the type Vec[T] is to be treated as a "given".

QuadShape. The reason for this is that, if we follow [SBC92, Chapter 2], then quadrilaterals are shearable, but some subtypes (rectangle, rhombus, and square) are not. If we were to follow the class hierarchy given on page 8 of [SBC92], there would be problems, because the classes Rectangle, Rhombus, and Square would be subtypes but not behavioral subtypes of the types of their superclasses. Informally, a type S is a behavioral subtype of T if objects of type 5 can act as if they are objects of type T [A87, A91, LW90, L91, LW94, LW95]. Having subclasses not implement subtypes would make for a poor design; it would also make such classes unimplementable if specified in Larch/C++. This is because Larch/C++ forces subclasses to specify behavioral subtypes of the types of their public superclasses [DL96]. Thus we will follow the ZEST and Fresco specifications in using an abstract class without a shear operation as the superclass of Quadrilateral. The Larch/C++ specification of the abstract class QuadShape is given in Figure 5. This behavioral interface specification imports the behavioral interface specifications of the type Vector, which also defines the type Scalar. In Larch/C++, one could also specify QuadShape as a C + + template class with the types Vector and Scalar as type parameters [L95, Chapter 8], but the approach adopted here is more in keeping with the examples in [SBC92]. In the specification of QuadShape, the first thing to note is that much of the syntax is the same as in C + + . Indeed, all of the C + + declaration syntax (with a few ambiguities removed) is supported by Larch/C++. A C + + declaration form in a Larch/C++ specification means that a correct implementation must be C + + code with a matching declaration. (Hence, a Larch/C++ specification cannot be correctly implemented in Ada or Smalltalk.)

128

Chapter 8

To the C + + declaration syntax, L a r c h / C + + adds o r n a m e n t a t i o n for the specification of intent, semantic modeling information, and behavior. Such o r n a m e n tation, at the class level, includes the keywords a b s t r a c t , u s e s , and i n v a r i a n t ; at the level of C + + member function specifications it includes the keywords r e q u i r e s , m o d i f i e s , t r a s h e s , e n s u r e s , e x a m p l e , and c l a i m s . T h e use of the keyword a b s t r a c t in the specification of the class QuadShape, specifies the intent t h a t QuadShape is not to be used to make objects; t h a t is, QuadShape is an abstract class. As such, it has no "constructors" and therefore no objects will exist t h a t are direct instances of such a class. This e x t r a information could be used in consistency checking tool [T94b, T94a, T95]. Traits, including those t h a t define the abstract model, are noted in u s e s clauses. In Figure 5, the u s e s clause follows the C + + keyword p u b l i c . (As in C + + , p u b l i c : starts the public part of a class specification.) In the specification of QuadShape, the trait used is Quad, with QuadShape replacing Q. T h e i n v a r i a n t clause will be explained following the explanation of the m e m b e r function specifications. Each member function specification looks like a C + + function definition, except t h a t the body is replaced by behavioral specification information. This allows all of the C + + function declaration syntax, including v i r t u a l and c o n s t , to be used. It also allows exact C + + type information to be recorded. To illustrate the specification format, the body of Move has six clauses. T h e r e q u i r e s clause gives the function's precondition, the m o d i f i e s and t r a s h e s clauses form a frame axiom [BMR95], the e n s u r e s clause gives the function's postcondition, the e x a m p l e clause gives a redundant example of its execution, and the c l a i m s clause states a redundant property of the specification. T h e postcondition, and the assertions in the e x a m p l e and c l a i m s clauses, are predicates over two states. These states are the state j u s t before the function body's execution, called the pre-state, and the state j u s t before the function body returns (or signals an exception), called the post-state. A C + + object (a location) can be thought of as a box, with contents t h a t m a y differ in different states. T h e box may also be empty. When the box empty, the object is said to be unassigned; an object is assigned when it contains a proper value. C + + objects are formally modeled in L a r c h / C + + using various traits [L95, Section 2.8], and these traits allow one to write a s s i g n e d ( v , p r e ) to assert t h a t the object v is allocated and assigned in the pre-state. (The pre- and post-states are reified in L a r c h / C + + using the keywords p r e and p o s t . ) There is also a

An Overview Of Larch/C++

129

imports Vector; abstract class QuadShape { public: uses Quad(QuadShape); invariant isLoop (self*. edges) ; virtual Move (const Vectorft v) { requires assigned(v, pre); modifies self; trashes nothing; ensures liberally self = set_position(self, self .position + v ) ; example liberally 3 erEdges, pos: Vector (self" = [e,pos] A self = [e, pos + v]) ; claims liberally self . edges = self . edges; } virtual Vector GetVec(int i) const { requires betweend, i , 4); ensures result = self . e [ i ] ; } virtual Vector GetPositionO const { ensures result = self .position; } };

Figure 5

The L a r c h / C + + specification of the C + + class QuadShape.

more useful notation for extracting the value of an assigned object in either state. The value of an assigned object, o, in the pre-state is written o , and the post-state value of o is written o ' . In a member function specification, the object self is defined to be the same as the C + + object * t h i s , which is the implicit receiver of the member function call. Thus the postcondition of Move says that the post-state value of the receiver object is equal to the pre-state value, with the position field changed to the pre-state position plus the pre-state value of the vector v. (Except for constructors, the object self is implicitly required to be assigned in every member function of a class [L95, Section 6.2.2].) The e n s u r e s clause of Move's specification uses the Larch/C-f+ keyword liberally. This makes it a partial correctness specification; that is, the specification says that if v is assigned and if the execution of Move terminates normally, then

130

Chapter 8

the post-state must be such that the position field of self s value is the sum of the pre-state position and v. However, the function need not always terminate normally; for example, it might abort the program if the numbers representing the new position would be too large. If liberally is omitted, then a total correctness interpretation is used; for example, GetPosition must terminate normally whenever it is called. Neither VDM, Z, nor any other 0 0 specification languages that we know of permit mixing total and partial correctness in this manner. A function may modify an allocated object by changing its value from one proper value to another, or from unassigned to some proper value. Each object that a function is allowed to modify must be noted by that function's modifies clause. For example, Move is allowed to modify self. An omitted modifies clause means that no objects are allowed to be modified. For example, GetVec and GetPosition cannot modify any objects. A function may trash an object by making it either become deallocated or by making its value be unas signed. The syntax trashes nothing means that no object can be trashed, and is the default meaning for the trashes clause when it is omitted, as in GetVec and GetPosition. Noting an object in the trashes clause allows the object be trashed, but does not mandate it (just as the modifies clause allows modification but does not mandate it). Having a distinction between modification and trashing may seem counterintuitive, but is important in helping shorten the specifications users have to write. In LCL and other Larch interface languages, these notions are not separated, which this leads to semantic problems [C95, CGR96]. By following Chalin's ideas, most Larch/C-h-1- function specifications do not have to make assertions about objects being allocated and assigned in postconditions. This is because, if an object is modified, it must stay allocated, and if it was assigned in the pre-state, it must also be assigned in the post-state [L95, Section 6.2.3]. An example adds checkable redundancy to a specification. There may be several examples listed in a single function specification in Larch/C-f—h For each example, what is checked is roughly that the example's assertion, together with the precondition should imply the postcondition [L95, Section 6.7]. (The 3 in the example given is typed as \E by users.) As far as we know, this idea of adding examples to formal function specifications is new in Larch/C+-h Another instance of the checkable redundancy idea is the claims clause, which is a feature of Tan's work on LCL [T94b, T94a, T95]. This borrowing from

An Overview Of Larch/C++

131

LCL can be used to state a redundantly checkable property implied by the conjunction of the precondition and postcondition. In the example, the claim follows from the postcondition and the meaning of s e t _ p o s i t i o n (see Figures 1 and 2). Claims, examples, and the trashes and modifies clauses, are optional in a function specification, as illustrated by the specification of GetVec. The specification of GetPosit ion illustrates that the requires clause may also be omitted; it defaults to requires true. In the specification of GetVec, i is passed by value. Thus i is not considered an object within the specification. This is why i denotes an int value, and why notations such as i~are not used [GHG+93, Chapter 5]. The invariant clause describes a property that must hold in each visible state; it can be thought of as implicitly conjoined to the pre- and postconditions of each member function specification. The notation self* stands for the abstract value of self in a visible state. (The glyph * is typed \any by users.) Thus the invariant in Figure 5 says that the edges part of the abstract value of self in each visible state must form a loop. Note that, by using model-based specifications, it is easy to specify abstract classes. One imagines that objects that satisfy the specification have abstract values, even though there are no constructors. Finally, note that the type Vector does not have to be fully specified in Larch/C-f-h in order to be imported by the specification of QuadShape. It can be regarded as "given" by making a specification module for it that simply declares the type Vector, and uses the appropriate traits. An example of how to do this is shown in Figure 6. (The keyword spec says that the declaration does not have to appear exactly as stated in an implementation; an implementation might also define Vector with a typedef, or in some other way.) The specification of the subclass Quadrilateral is given in Figure 7. The C + + syntax ": public QuadShape" is what says that Quadrilateral is a public subclass (and hence a subtype) of QuadShape. In Larch/C+H-, a subclass is forced to be a behavioral subtype of the type of its public superclass. Roughly speaking, the idea is that the specification of each virtual member function of QuadShape must be satisfied by a correct implementation of that virtual member function in the class Quadrilateral.

132

Chapter 8

imports Scalar; s p e c class Vector; uses P r e V e c t o r ( S c a l a r , Vector for Vec[T]), NoContainedObjects(Vector);

F i g u r e 6 This specification module illustrates how to treat the type Vector as a "given" type in L a r c h / C + + .

i m p o r t s QuadShape, Shear; class Q u a d r i l a t e r a l : p u b l i c QuadShape { public: uses QuadSubtype(Quadrilateral, QuadShape); s i m u l a t e s QuadShape by toSuperWithoutChange; Q u a d r i l a t e r a l ( V e c t o r v l , Vector v2, Vector v 3 , Vector v4, Vector pos) { requires isLoop([vl,v2,v3,v4]); modifies self; e n s u r e s s e l f = [ [ v l , v2, v 3 , v4] , p o s ] ; } v i r t u a l void ShearBy(const Shearft s) { requires assigned(s, p r e ) ; modifies self; e n s u r e s informally "self i s sheared by s " ; } };

Figure 7

The L a r c h / C + + specification of the C + + class Quadrilateral.

Technically, in L a r c h / C + + behavioral subtyping is forced by inheriting t h e specification of the supertype's invariant and virtual m e m b e r functions in t h e subtype [DL96]. T h e technical problem to overcome is t h a t the s u p e r t y p e ' s specifications were written as if self were a supertype object. But when applying such specifications to the subtype, s e l f is a subtype object. In most 0 0 specification languages, including Object-Z [R92, RD94], MooZ [MC92, MCS94], V D M + + [M94], Z + + [L92, LH94b], O O Z E [AG91, AG92, AG94], and Z E S T [CR92], there is no problem treating the subtype's abstract values as abstract values of the supertypes (and in deciding how to do t h a t ) , because every object's abstract value is a tuple (i.e., a record or schema) of a b s t r a c t

An Overview Of Larch/C++

133

fields; the subtype's abstract values may have more such abstract fields than the supertype's, and a subtype abstract value can be treated as a supertype value by simply ignoring the additional fields. In Larch-style BISLs, such as Larch/C-f+, LM3 [GHG+93, Chapter 6], and Larch/Smalltalk [CL94], abstract values of object do not have to be tuples. This means that there is a problem in giving a semantics to inherited specifications. In Larch/Smalltalk the problem is resolved by having the user write enough operators in a trait so that the operators used in the supertype's specification are also defined on the abstract values of the subtype. However, because that solution seems to have modularity problems [L94], a slightly less general solution is currently used in Larch/C-f—f. What Larch/C+-\- currently (in release 4.1) requires is that the user specify a simulation function, which maps the abstract values of subtype objects to the abstract values of supertype objects [DL96]. Inheritance of the supertype's specifications is accomplished by applying the simulation function to each term whose type is the supertype. For example, the specification of the member function GetPosition inherited by Q u a d r i l a t e r a l , could be written as follows in Q u a d r i l a t e r a l ' s specification. virtual Vector GetPositionO const { ensures result = toSuperWithoutChange(self) .position; }

Specifying the simulation function is the purpose of the s i m u l a t e s clause. The trait used by Q u a d r i l a t e r a l is the trait QuadSubtype, which is shown in Figure 8. This trait includes the trait Quad twice, once changing the name Q to the subtype, and once changing it to the supertype. It defines the simulation function toSuperWithoutChange that maps the subtype's values to the supertype's values. The "constructor" specified for the class Q u a d r i l a t e r a l has the same name as the class in C + + . Its specification follows the s i m u l a t e s clause. Constructors in C + + really are initializers, and this constructor must set the post-state value of the object to the appropriate abstract value. The r e q u i r e s clause is needed so that the object will satisfy the invariant inherited from QuadShape. The specification of ShearBy illustrates another feature of Larch/C++: informal predicates. An informal predicate looks like the keyword informally, followed by a string constant. Such a predicate can be used to suppress details about a specification. This is done frequently in the specifications in [SBC92] by using comments instead of formal specifications when discussing shearing.

Chapter 8

134

QuadSubtype(Sub,Super): t r a i t i n c l u d e s Quad (Sub) , Quad (Super) ; introduces toSuperWithoutChange: Sub —* Super a s s e r t s V x: Sub toSuperWithoutChange(x) == ( [ x . e d g e s , x . p o s i t i o n ] ) : S u p e r ;

Figure 8

The LSL trait QuadSubtype.

This also illustrates how one can use informal predicates to "tune" the level of formality in a L a r c h / C + + specification. For example, in L a r c h / C + + one could start out by using largely informal specifications, and then increase the level of formality as needed or desired.

3

OTHER SUBTYPES OF Q U A D S H A P E

This section contains the behavioral interface specifications of the other subtypes ofQuadShape described in [SBC92]. As in [CR92], we start with the abstract type P a r a l l e l S h a p e , which is shown in Figure 9. T h e i n v a r i a n t clause in this specification says t h a t the a b s t r a c t values of such objects must have edges with parallel sides. (The operator i s a P a r a l l e l o g r a m is specified in the trait shown in Figure 10.) An interesting aspect of P a r a l l e l S h a p e (apparently overlooked in all the specifications in [SBC92]) is t h a t if all the sides of a quadrilateral are zero length, then the angle to be returned by A n g l e P a r is not well denned. T h e specification of A n g l e P a r illustrates how to specify exceptions to handle such cases. Note first t h a t the body of A n g l e P a r has two pairs of pre- and postcondition specifications. Larch/C-f-f- actually permits any number of these specification cases in a function specification body; the semantics is t h a t the i m p l e m e n t a t i o n must satisfy all of t h e m [W83, Section 4.1.4] [W91, W92b, W92a]. T h u s this specification says t h a t if the object self has an interior, the a p p r o p r i a t e angle must be returned, and if not, then an exception must be thrown. A l t h o u g h the m a t h e m a t i c s of angles is left informal, the specification of the exception is

An Overview Of Larch/C++

135

imports QuadShape, Nolnterior; abstract class ParallelShape : public QuadShape { public: uses QuadSubtype(ParallelShape, QuadShape); simulates QuadShape by toSuperWithoutChange; uses IsaParallelogram; invariant isaParallelogram(selfV edges) ; virtual double AngleParO const throw (Nolnterior) { requires -« (self .edges[1] = 0 V self~.edges[2] = 0); ensures informally "result i s the angle between self .edges[1] and" "self \ edges[2]"; requires self* .edges[1] = 0 V self .edges[2] = 0; ensures thrown (Nolnterior) = theException; } };

Figure 9 The Larch/C++ specification of the C++ class ParallelShape.

IsaParallelogram: trait includes FourSidedFigure introduces isaParallelogram: Edges —• Bool asserts V e: Edges isaParallelogram(e) == isLoop(e)A (e.vl + e.v3 = 0:Vector); implies V e: Edges isaParallelogram(e) == isLoop(e) A (e.v2 + e.v4 = 0:Vector);

Figure 10

The trait IsaParallelogram.

formalized. The term t h r o w n ( N o l n t e r i o r ) denotes the abstract value of the exception result The specification of the type N o l n t e r i o r is in Figure 11. This specification uses the Larch/C++ built-in trait NolnformationExecption [L95, Section 6.9] to specify the abstract model of the type N o l n t e r i o r . This trait is designed as an

136

Chapter 8

class Nolnterior { public: uses NolnformationException(NoInterior), NoContainedObjects(Nolnterior); NoInteriorO { modifies self; ensures result = theException; } };

Figure 11

The Larch/C++ specification of the C++ class Nolnterior.

aid in specifying abstract models for exceptions in which no significant information is being passed; it says that there is only one abstract value: theException. The class specification also specifies the default constructor. Turning to another concrete class specification, the type P a r a l l e l o g r a m (see Figure 12) is a public subclass of both Q u a d r i l a t e r a l and P a r a l l e l S h a p e . (This follows the design in [SBC92]; whether this is a good idea for a design in C + + is debatable.) It inherits the specifications of each, including the ShearBy member function of Q u a d r i l a t e r a l , and the invariant from P a r a l l e l S h a p e (including the inherited invariant from QuadShape). This is done by specifying a simulation function for each supertype. Of course, the constructor of Q u a d r i l a t e r a l is not inherited, and so a constructor must be specified. This specification is a partial correctness specification, which allows for cases in which the vector cannot be successfully negated. Space does not permit the specification of the other shape classes from [SBC92]. However, more details can be found in the Larch/C++ release [L95].

4

DISCUSSION A N D CONCLUSIONS

The shapes example from [SBC92] is perhaps not ideal for illustrating the mechanisms in Larch/C++ used for specification inheritance, as the subtypes all use isomorphic spaces of abstract values. In [DL96], we give more interesting examples, in which the abstract models of the subtype objects contain more information than objects of their supertypes.

An Overview Of Larch/C++

137

imports Quadrilateral, ParallelShape, Shear; class Parallelogram : public Quadrilateral, public ParallelShape { public: uses QuadSubtype(Parallelogram, Quadrilateral); simulates Quadrilateral by toSuperWithoutChange; uses QuadSubtype(Parallelogram, ParallelShape); simulates ParallelShape by toSuperWithout Change; Parallelogram(Vector v l , Vector v2, Vector pos) { modifies self; ensures liberally self = [[vl, v2, - v l , -v2] , pos]; } };

Figure 12

The Larch/C++ specification of the C++ class Parallelogram.

However, the shapes example does permit direct comparison to the 0 0 specification languages presented in [SBC92]. The following are the most basic points of similarity and difference. •

The LSL traits specified in the examples correspond roughly to the Z specifications given in [SBC92, Chapter 2]. This says that LSL is roughly comparable to Z in terms of modeling power. However, LSL includes syntax for stating redundant properties of traits, which may help catch errors in such mathematical modeling.

•

The behavioral interface specifications are roughly comparable to the various OO specifications written in the 0 0 specification languages in [SBC92], in particular to ZEST and Fresco. However, only for Fresco is there even a hint [W92b, p. 135] that it may be able to specify the C + + interface details that Larch/C++ can specify.

It is important that a formal specification language not require one to formalize every detail. By allowing one to leave some types of data, some operations, and some aspects of behavior informal, Larch/C++, like Z and other 0 0 specification languages, allows users to focus on what is important. In LSL, informality is accomplished by omitting specifications, as in Figure 4. In Larch/C++ this can be accomplished by omitting specifications, as in Figure 6, but more finegrained tuning is permitted by the use of the informal predicates.

138

Chapter 8

Larch/C++ is a large, but expressive, specification language. Most of its size and complexity arises from the complexity of C + + , which, for example, has a large and complex declaration syntax, and a large number of low-level, built-in types. Although Larch/C++ has several features that other formal specification languages do not have, these features earn their place by adding much to the expressiveness of the language. For instance, the example and claims clauses in function specifications add syntax, but they allow additional checking and also allow one to convey extra information about the meaning and intent of a specification. The example clause is new with Larch/C++; the idea for the claims clause is due to Tan [T94b, T94a, T95]. More important for expressiveness are some fundamental semantic ideas that, while they also add to the complexity of the language, add new dimensions to the expressiveness of the language. One semantic idea is the distinction between trashing and modification [C95, CGR96], which places the frame axiom of Larch-style specification languages on a firm semantic foundation. In Larch/C++ one can also specify such notions as whether storage is allocated or assigned. More important, allowing the user to specify both total and partial correctness for functions gives to users a choice previously reserved by specification language designers; the use of partial correctness, for example, is necessary for succinct specification of functions that may fail due to the finiteness of various data structures [H69]. Allowing the specification of several specification cases (an idea due to Wing [W83, Section 4.1.4] and Wills [W91, W92b, W92a]) is convenient for the specification of exceptions and for giving a concrete form to specification inheritance [DL96]. Furthermore, when combined with the ability to specify both total and partial correctness, the expressiveness of the specification language becomes much more complete [H92]. When combined with the approach of behavioral interface specification, the expressive features of Larch/C++ make it a step towards the day when formal documentation of C + + class libraries will be practical and useful.

Acknowledgements This work was supported in part by NSF grant CCR-9593168. Thanks to Adrian Fiech for suggestions and comments on an earlier draft. Thanks also to Yoonsik Cheon, who helped design Larch/C++.

An Overview Of Larch/C+4-

139

REFERENCES [A87] America, P. Inheritance and In Bezivin, J. et al., editors, Oriented Programming, Paris, 1987. Springer-Verlag. Lecture

subtyping in a parallel object-oriented language. EC OOP '87, European Conference on ObjectFrance, pages 234-242, New York, N.Y., June Notes in Computer Science, Volume 276.

[A91] America, P. Designing an object-oriented programming language with behavioural subtyping. In de Bakker, J. W., de Roever, W. P., and Rozenberg, G., editors, Foundations of Object-Oriented Languages, REX School/Workshop, Noordwijkerhout, The Netherlands, May/June 1990, volume 489 of Lecture Notes in Computer Science, pages 60-90. Springer-Verlag, New York, N.Y., 1991. [AG91] Alencar, A. J. and Goguen, J. A. OOZE: An object oriented Z environment. In America, P., editor, ECOOP '91: European Conference on Object Oriented Programming, volume 512 of Lecture Notes in Computer Science, pages 180-199. Springer-Verlag, New York, N.Y., 1991. [AG92] Alencar, A. J. and Goguen, J. A. OOZE. In Stepney et al. [SBC92], pages 79-94. [AG94] Alencar, A. J. and Goguen, J. A. Specification in OOZE with examples. In Lano and Haughton [LH94a], pages 158-183. [BG82] Burstall, R. M. and Goguen, J. A. Algebras, theories and freeness: An introduction for computer scientists. In Broy, M. and Schmidt, G., editors, Theoretical Foundations of Programming Methodology: Lecture Notes of an International Summer School directed by F. L. Bauer, E. W. Dijkstra and C. A. R. Hoare, volume 91 of series C, pages 329-348. D. Ridel, Dordrecht, Holland, 1982. [BMR95] Borgida, A., Mylopoulos, J., and Reiter, R. On the frame problem in procedure specifications. IEEE Transactions on Software Engineering, 21(10):785-798, October 1995. [C95] Chalin, P. On the Language Design and Semantic Foundation of LCL, a Larch/C Interface Specification Language. PhD thesis, Concordia University, 1455 de Maisonneuve Blvd. West, Montreal, Qquebec, Canada, October 1995. Available as CU/DCS TR 95-12. [CGR96] Chalin, P., Grogono, P., and Radhakrishnan, T. Identification of and solutions to shortcomings of LCL, a Larch/C interface specification language. In Proceedings of the FME'96 Symposium. FME'96: Industrial Benefit and Advances in Formal Methods, Formal Methods Europe., 1996. To appear. An earlier version of this paper is available as Concordia University, Department of Computer Science TR 95-09. [CL94] Cheon, Y. and Leavens, G. T. The Larch/Smalltalk interface specification language. A CM Transactions on Software Engineering and Methodology, 3(3):221253, July 1994. [CR92] Cusack, E. and Rafsanjani, G. H. B. ZEST. In Stepney et al. [SBC92], pages 113-126.

140

Chapter 8

[DL96] Dhara, K. K. and Leavens, G. T. Forcing behavioral subtyping through specification inheritance. In Proceedings of the 18th International Conference on Software Engineering, Berlin, Germany, pages 258-267. IEEE Computer Society Press, March 1996. [ES90] Ellis, M. A. and Stroustrup, B. The Annotated C+ + Reference Addison-Wesley Publishing Co., Reading, Mass., 1990.

Manual.

[FGJM85] Futatsugi, K., Goguen, J. A., Jouannaud, J.-P., and Meseguer, J. Principles of OBJ2. In Conference Record of the Twelfth Annual ACM Symposium on Principles of Programming Languages, pages 52-66. ACM, January 1985. [GHG+93] Guttag, J. V., Horning, J. J., Garland, S., Jones, K., Modet, A., and Wing, J. Larch: Languages and Tools for Formal Specification. Springer-Verlag, New York, N.Y., 1993. [GMP90] Guaspari, D., Marceau, C , and Polak, W. Formal verification of Ada programs. IEEE Transactions on Software Engineering, 16(9): 1058-1075, September 1990. [GTW78] Goguen, J. A., Thatcher, J. W., and Wagner, E. G. An initial algebra approach to the specification, correctness and implementation of abstract data types. In Yeh, R. T., editor, Current Trends in Programming Methodology, volume 4, pages 80-149. Prentice-Hall, Inc., Englewood Cliffs, N.J., 1978. [H69] Hoare, C. A. R. An axiomatic basis for computer programming. tions of the ACM, 12(10):576-583, October 1969.

Communica-

[H72] Hoare, C. A. R. Proof of correctness of data representations. Acta 1(4):271-281, 1972.

Informatica,

[H92] Hesselink, W. H. Programs, Recursion, and Unbounded Choice, volume 27 of Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, New York, N.Y., 1992. [H93] Hayes, I., editor. Specification Case Studies. International Series in Computer Science. Prentice-Hall, Inc., second edition, 1993. [J90] Jones, C. B. Systematic Software Development Using VDM. International Series in Computer Science. Prentice Hall, Englewood Cliffs, N.J., second edition, 1990. [L89] Lamport, L. A simple approach to specifying concurrent systems. cations of the ACM, 32(l):32-45, January 1989.

Communi-

[L91] Leavens, G. T. Modular specification and verification of object-oriented programs. IEEE Software, 8(4):72-80, July 1991. [L92] Lano, K. C. Z + + . In Stepney et al. [SBC92], pages 106-112. [L94] Leavens, G. T. Inheritance of interface specifications (extended abstract). In Proceedings of the Workshop on Interface Definition Languages, volume 29(8) of ACM SIGPLAN Notices, pages 129-138, August 1994. [L95] Leavens, G. T. Larch/C-f-+ Reference Manual. Version 4.1. Available in ftp://ftp.cs.iastate.edu/pub/larchc-l—h/lcpp.ps.gz or on the world wide web at the URL http://www.cs.iastate.edu/~leavens/larchcH--f.htrnl, December 1995.

An Overview Of Larch/C-f+

[L96] Leavens, G. T. LSL math traits. traits.html, Jan 1996.

141

http://www.cs.iastate.edu/~leavens/Math-

[LG86] Liskov, B. and Guttag, J. Abstraction and Specification in Program Development The MIT Press, Cambridge, Mass., 1986. [LH94a] Lano, K. and Haughton, H., editors. Object-Oriented Specification Case Studies. The Object-Oriented Series. Prentice Hall, New York, N.Y., 1994. [LH94b] Lano, K. and Haughton, H. Specifying a concept-recognition system in Z-J-+. In Lano and Haughton [LH94a], chapter 7, pages 137-157. [LW90] Leavens, G. T. and Weihl, W. E. Reasoning about object-oriented programs that use subtypes (extended abstract). In Meyrowitz, N., editor, OOPSLA ECOOP '90 Proceedings, volume 25(10) of ACM SIGPLAN Notices, pages 212223. ACM, October 1990. [LW94] Liskov, B. and Wing, J. A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811—1841, November 1994. [LW95] Leavens, G. T. and Weihl, W. E. Specification and verification of objectoriented programs using supertype abstraction. Acta Informatica, 32(8):705-778, November 1995. [M94] Mitra, S. Object-oriented specification in V D M + + . In Lano and Haughton [LH94a], chapter 6, pages 130-136. [MC92] Meira, S. L. and Cavalcanti, A. L. C. MooZ case studies. In Stepney et al. [SBC92], pages 37-58. [MCS94] Meira, S. L., Cavalcanti, A. L. C , and Santos, C. S. The Unix filing system: A MooZ specification. In Lano and Haughton [LH94a], chapter 4, pages 80-109. [RD94] Rose, G. and Duke, R. An Object-Z specification of a mobile phone system. In Lano and Haughton [LH94a], chapter 5, pages 110-129. [R92] Rose, G. Object-Z. In Stepney et al. [SBC92], pages 59-77. [S89] Spivey, J. An introduction to Z and formal specifications. Software Journal, January 1989. [S91] Stroustrup, B. The C++ Programming Language: Second Edition. Wesley Publishing Co., Reading, Mass., 1991.

Engineering Addison-

[S92] Spivey, J. M. The Z Notation: A Reference Manual. International Series in Computer Science. Prentice-Hall, New York, N.Y., second edition, 1992. [SBC92] Stepney, S., Barden, R., and Cooper, D., editors. Object Orientation in Z. Workshops in Computing. Springer-Verlag, Cambridge CB2 1LQ, UK, 1992. [T94a] Tan, Y. M. Formal specification techniques for promoting software modularity, enhancing documentation, and testing specifications. Technical Report 619, Massachusetts Institute of Technology, Laboratory for Computer Science, 545 Technology Square, Cambridge, Mass., June 1994. [T94b] Tan, Y. M. Interface language for supporting programming styles. ACM SIGPLAN Notices, 29(8):74-83, August 1994. Proceedings of the Workshop on Interface Definition Languages.

142

Chapter 8

[T95] Tan, Y. M. Formal Specification Techniques for Engineering Modular C Programs, volume 1 of Kluwer International Series in Software Engineering. Kluwer Academic Publishers, Boston, 1995. [W83] Wing, J. M. A two-tiered approach to specifying programs. Technical Report TR-299, Massachusetts Institute of Technology, Laboratory for Computer Science, 1983. [W87] Wing, J. M. Writing Larch interface language specifications. A CM Transactions on Programming Languages and Systems, 9(l):l-24, January 1987. [W91] Wills, A. Capsules and types in Fresco: Program validation in Smalltalk. In America, P., editor, ECOOP '91: European Conference on Object Oriented Programming, volume 512 of Lecture Notes in Computer Science, pages 59-76. Springer-Verlag, New York, N.Y., 1991. [W92a] Wills, A. Refinement in Fresco. In Lano and Houghton [LH94a], chapter 9, pages 184-201. [W92b] Wills, A. Specification in Fresco. In Stepney et al. [SBC92], chapter 11, pages 127-135.

9 STRUCTURAL ACTIVE-OBJECT SYSTEMS FUNDAMENTALS Toshimi Minoura Department of Computer Science Oregon State University Corvallis, Oregon 97331-4602 minoura@cs. orst. edu

ABSTRACT The Structural Active-Object Systems (SAOS) approach provides an architecture suitable for various concurrent realtime applications. A SAOS program is constructed from its component structural active objects by structural and hierarchical composition. The behaviors of structural active objects, in turn, are determined by the transition statements provided in their class definitions. Prototype SAOS programs have been developed in such diverse application areas as process and manufacturing control, discrete, analog, and mixed-mode simulation, hardware logic simulation, graphical user interfaces, graphical editors, LAN/WAN protocol simulation, and algorithm animation, with significant reduction in source code sizes and program development time. In this paper we examine the fundamental ideas underlying the SAOS approach and emphasize the importance of structural and hierarchical object composition (SHOC) in software construction.

1

INTRODUCTION

Object-oriented programming (OOP) [GR83, M88, S86] is making fundamental changes in software development. Such features as encapsulated classes, inheritance, and polymorphism provided by OOP allow us to implement highly modular reusable software components. Furthermore, since objects which embody state and behavior can model real-world objects better than traditional software modules, object-orientation provides a suitable framework for software development [B91, RBPEL91].

144

Chapter 9

Reusability and understandability of software modules are enhanced if they are hierarchically composed from their components [D68]. Structured p r o g r a m m i n g used procedural composition [D72] for executable code and data composition for d a t a structures [H72]. Functional composition is used by Lisp, and relational composition by Prolog. CCS [M89] and CCS-based languages such as L O T O S [BB89] use process composition. The conventional O O P promotes activity composition by message passing, where an activity is an invocation of a m e t h o d . On the other hand, the method universally practiced in constructing m o d e r n engineering products is structural and hierarchical object composition ( S H O C ) , which enables us to design higher level components from their lower level components with m i n i m a l effort. Such electronic components and systems as VLSI chips, circuit boards, and computer systems and such mechanical c o m p o n e n t s and systems as carburetors, engines, and automobiles are all designed and m a n ufactured following this approach. In order to have a composite object t h a t functions actively, it is essential t h a t its component objects are active, since passive objects alone cannot initiate any actions. Note t h a t VLSI chips and automobile components are structurally and hierarchically composable active objects t h a t encapsulate their portion of control. A Structural Active-Object System (SAOS) program is an active object system consisting of structural active objects structural active objects use transition (production) rules, equational assignment statements, and event routines provided in their class definitions to describe their behaviors [MPR93]. P r o d u c t i o n rules have been known to be suitable for various concurrent systems t h a t require flexible synchronization [DK76, K M F 7 8 , Z78]. Production rules are also referred to as guarded commands [D75]. An equational assignment s t a t e m e n t is a unidirectional constraint in a equational form. We refer to transition rules, equational assignment statements, and event routines collectively as transition statements. T h e SAOS approach thus provides an architecture for software systems t h a t integrates object-orientation and transition s t a t e m e n t s . T h e SAOS approach promotes software construction by structural and hierarchical object composition (SHOC) of structural active objects. Although t h e SAOS approach was initially developed for manufacturing control applications [MCR93], it is suitable for various systems t h a t can be modeled as collections of interconnected components t h a t interact with each other asynchronously. T h e interconnections among components m a y be d y n a m i c as well as static. In fact, the SAOS approach turned out to be suitable for such diverse applications as discrete simulation [CM91], digital, analog, and mixed-mode simu-

Structural Active-Object Systems

145

lation [PM93], hardware logic description, process and manufacturing control, graphical user interfaces, graphical user-interface management systems [MC93], graphical editors, and algorithm animation. Another unique feature of the S AOS approach is that it provides a single framework that can be used throughout a software lifecycle encompassing the stages of analysis, design, implementation, test, operation, and maintenance. A SAOS diagram, which graphically represent the structure of a SAOS as a collection of interconnected structural active objects, can be made similar to the application model. A SAOS diagram can thus be used as the basis of a system design document, actual executable code, and user interface during operation. Section 2 provides an overview of the SAOS approach. Section 3 addresses the importance of structural and hierarchical object composition. In Section 4, related approaches are discussed, and the underlying principles of the SAOS approach are summarized. Section 5 concludes this paper.

2

STRUCTURAL ACTIVE-OBJECT SYSTEMS

In this section, we provide an overview of the structural active-object systems (SAOS) approach. We first describe the mechanisms for active behavior specifications for structural active objects, and then we show a simple example of a SAOS program.

2.1

Active Behavior Description

Objects in Smalltalk or C + + are passive in the sense that they only respond to the messages sent to them. Passive objects do not provide proper encapsulation or modularization of control when they are used to model active objects in the real world. A simple example is a (dumb) traffic signal that changes its state according to its own internal timer. When a traffic signal is implemented as a passive object, another object must send the traffic signal a message for it to change its state. When a traffic signal is implemented as an active object, on the other hand, it can, like a real traffic signal, completely hide its capability to change states from an outside observer. Thus active objects, as Ellis states [EG89], provide a higher level of modularity than passive objects.

146

Chapter 9

In order to describe active behaviors, besides event routines that respond to messages, a SAOS program uses transition rules, which are condition-action pairs, and always statements, which are equational assignment statements. We refer to transition rules, always statements and event routines as transition statements. Each transition rule is a condition-action pair whose action part is executed when its condition part is satisfied. An execution of a transition rule is atomic. Examples of transition rules can be found in Subsection 2.2. A transition rule is activated whenever the value of any condition variable used in its condition part changes. A variable used in this way is sometimes called an active value [KKW84]. A simple mechanism for describing a behavior of an object is an equational assignment statement that maintains an invariant relationship (constraint) among the states of objects, always statements are used for this purpose. For example, the class AND_Gate can be defined as shown in Fig. 1. Interface variables input 1 and input2, which act like terminals, are bound to instances of Gate, each of which has an instance variable output. class Gate { public: bool output;

} c l a s s AND_Gate: p u b l i c Gate { interface: Gate * i n p u t l , * i n p u t 2 ; private: always output = i n p u t l - > o u t p u t ft& i n p u t 2 - > o u t p u t ; }

Figure 1

SAOS description of class ANDJSate.

An always statement can be implemented like a transition rule. The execution of an always statement is triggered whenever any of the variables used in the expression of the always statement changes. Triggered always statements are executed immediately at the points where they are activated, their executions being embedded within those of the transition statements. The activations of transition rules and always statements are, at least conceptually, state-driven, and structural active objects communicate with each other by directly accessing the public data of other objects through their interface

Structural Active-Object Systems

147

variables rather than by sending messages to them. Although this mechanism largely eliminates the necessity of activating functions (or methods) by explicit events (or messages), some actions can be more efficiently handled by event routines, which are synchronous function calls, future calls, or future assignments. Activated future calls and future assignments are executed one at a time like triggered transition rules. Synchronous function calls are conventional function calls of C + + , and called functions are executed immediately when they are called. A future call is an asynchronous function call of the form: a f t e r delay. If a non-zero delay time delay is specified, the execution of the future call is delayed by that amount. A future assignment is similar to a future function call: x = expression a f t e r delay. The assignment is performed after the specified time passes. Although a future assignment can be implemented by a future function call, we added this mechanism because it can sometimes eliminate event functions, simplifying the behavior specifications of structural active objects. A future assignment is used in the example shown in Subsection 2.2. A similar mechanism is provided by VHDL [187].

2.2

Simple Queuing System

We now illustrate the key features of the SAOS approach by using a simple queuing system. This example shows how active behaviors are specified by transition statements and how structural composition is used to compose a SAOS program. The queuing system shown in Fig. 2 consists of a generator g that generates a stream of jobs, two processors p i and p2 that process jobs, and three queues ql, q2, and q3 that hold jobs. Fig. 3 gives a SAOS description of the system. It can be easily seen that the code corresponds exactly to the diagram in Fig. 2. That is, the output of g is connected to ql, the input of p i is connected to

148

Chapter 9

genera^*?!::?: K| :??§Pf^ue

Figure 2

proces^^^^^e^jue

proces£^^i^>t^ue

Queuing system with 2 processors and 3 queues.

ql and its output to q2, and so on. Although the main program contains only declarations, it is executable since it consists of active components. main QueuingSystem { public: Generator g with {output = &ql;}; Queue ql; Processor pi with {input = &ql; output = &q2;}; Queue q2; Processor p2 with {input = &q2; output = &q3;}; Queue q3; }

Figure 3

The main program of a queuing system.

A SAOS program consists of a main program and classes. A class contains instance variables and transition statements. A transition statement is a transition rule, always statement, or event routine. Instance variables and event routines can be private, protected, or public, as in C + + [S86]. Transition rules and always statements are always private. Public instance variables and event routines are used as an interface. The main program is defined in the same way as a class, but it is an instance. In order to construct the above system as a SAOS program, we must first define the four classes used by the system: class Job, class Queue, class Processor, and class Generator. Second, we create one instance g of Generator, three instances ql, q2 and q3 of Queue, and two instances pi and p2 of Processor and provide the static interconnections among them by using with clauses as specified in Fig. 3. The interconnections between Job instances and the other system components cannot be defined statically, since Job instances are

Structural Active-Object Systems

149

created dynamically by the Generator and are moved to the Processors and the Queues during the execution of the program.

class Processor { public: Queue *input; // ptr to input job queue Queue *output; // ptr to output job queue Int state = PIdle; // processor state Job *job = nil; // job being processed int maxProcessingTime; // job processing time transition start // start job processing when (input->nJobs > 0 && state == PIdle) { job = input->dequeue(); // get job state = PBusy; // processor busy state = PComplete after maxProcessingTime * randomO; > transition stop // complete job processing when (state == PComplete && output->nJobs < output->nSlots) { output->enqueue(job); // send job out state = PIdle; } }

Figure 4

Class Processor.

A Processor, whose class definition is shown in Fig. 4, processes, one at a time, Jobs found in the Queue designated by interface variable input. When the processing of each Job is complete, the Job is placed in the Queue designated by interface variable output. Instance variable s t a t e indicates if the P r o c e s s o r is free (PIdle) or processing a Job (PBusy) or has completed job processing (PComplete). The transition rule s t a r t is activated whenever the value of either input->nJobs or s t a t e changes. Note that input->nJobs and s t a t e are condition variables. The action part of this transition rule is executed if there is at least one Job in the input Queue and if the Processor is idle. The action, if executed, removes one Job from the input Queue and schedules the completion of processing after the delay of maxProcessingTime * random(). When the specified processing time expires, s t a t e is changed to PComplete

150

Chapter 9

by the future assignment. When the value of s t a t e is changed from PBusy to PComplete, the transition rule s t o p is activated. In the action part of this transition, the Job is sent to the Queue designated by output.

3

STRUCTURAL A N D HIERARCHICAL COMPOSITION

The main emphasis of the SAOS approach is software construction by structural and hierarchical object composition (SHOC). Fig. 5 illustrates the concept of structural and hierarchical composition (SHC). The system is constructed from the two interconnected composite objects X and Y, where X consists of four interconnected components A, B, C, and D, and Y consists of two interconnected components E and F. Some of the components A, . . ., F may be of the same types.

Figure 5 Structural and hierarchical composition.

Many proposals and actual applications of SHC can be found in literature. SARA tried to construct a software system from interconnected program modules with ports [EFRV86]. Software design methodologies based on data-flow diagrams (DFDs) are well-known [YC78, D79]. In order to make SHC effective, active objects and their classes must be supported. Program modules are not suitable units of SHC since they are collections of such heterogeneous entities as type definitions, procedures, and data declarations. SARA and DFDs lack classes, and hence their applications are limited to the analysis and design stages of software development.

Structural Active-Object Systems

151

Unix pipes and scripts allow us to perform SHC of processes. Unix processes are active objects created as instances of their classes (executable code or scripts). However, communication among processes is restricted to streams of characters. VHDL is a widely used hardware description language using S H O C as its m a i n mechanism [187]. VHDL supports classes without inheritance. However, its capabilities are mostly restricted to its intended purpose - hardware logic description. V H D L uses sequential processes to implement behaviors of active components. It is also possible to build a system by structural and hierarchical process composition ( S H P C ) . T h e most notable example of S H P C is calculus for concurrent systems (CSS) proposed by Milner [M89]. T h e protocol specification language L O T O S [BB89] is based on CCS and hence uses S H P C as its p r i m a r y m e a n s of combining process definitions. Another protocol specification language Estelle [L86], which is based on extended state machines, also uses S H P C . Since these languages, like ADA, allow instances of process types to be created, they are class-based. Furthermore, L O T O S allows S H P C through gates, and Estelle through interaction points. Gates and interaction points are rendezvous points in sequential processes. When sequences of actions to be taken are relatively constrained, as in high level communication protocols, S H P C is more effective t h a n SHOC. When actions to be taken are more non-deterministic, however, SHOC is more effective. In order to support structural composition of structural active objects, interface variables, which act like terminals of hardware components, are used to interconnect structural active objects. Interface variables are crucial for S H O C . T h e transition s t a t e m e n t s provided for each structural active object can access, besides the state of t h a t object, the states of the other objects known to it through its interface variables, thus realizing inter-object c o m m u n i c a t i o n . We can establish desired interconnections a m o n g structural active objects by binding proper objects to interface variables. This binding is performed when a composite structural active object is constructed from its component s t r u c t u r a l active objects. T h e objects bound to the interface variables m a y be c o m p o n e n t s of other objects. In a sense, binding objects to interface variables is analogous to wiring VLSI chips. Structural active objects can be modularized in the same way as h a r d w a r e objects are modularized. SHC of active objects with standardized interfaces provides our basis for the realization of software ICs as espoused by Cox [C87]. Since structural active objects are software objects, they are more flexible t h a n hardware objects. Such features as inheritance and polymorphism in the standard O O P , for instance, can be used in defining SAOS classes as well.

152

Chapter 9

In building a complex system, the SAOS approach primarily uses structural composition and hence structural interfaces of structural active objects, whereas conventional OOP uses procedural interfaces provided for passive objects. We often see many procedures (methods) provided as an interface for a conventional OOP class. Understanding and remembering the functions performed by these procedures is not an easy task. A structural interface often allows these procedures to be bundled into a few interface variables.

a) Conventional OOP View Modem M

Terminal T 1 1 Transmit Data I Received Data

1 1

RTS CTS DSR DTR Ground

cable

A

\

Transmit Data Received Data RTS ' CTS

A x \— r~nr \ wV x // i V / /

\

x

1

DSR

1

DTR Ground

1

b) SAOS View Terminal T

Modem M terminal

Figure 6

Structural connection of a terminal and a modem.

The difference between the procedural interface and the structural interface can be illustrated by the following example. Assume that an object T representing a terminal must be connected to an object M representing a modem as shown in Fig. 6. In conventional OOP, a procedure must be provided for each signal DTR (data terminal ready), RTS (request to send), or DSR (dataset ready) received by T or M. An object that interconnects M and T must know all these procedures. On the other hand, in structural composition, the only thing

Structural Active-Object Systems

153

needed is to set a reference to T in the interface variable t e r m i n a l in M. Connecting T and M in this way is analogous to connecting their hardware counterparts by a cable. Since all the required logic to control the interaction between a modem and a terminal must be provided in T or M, at least one of them must be an active object. A composite structural active object can again be used as a component of a larger composite structural active object. It is generally believed that the design process of hardware is better understood than that of software. One important reason for this situation is that the hardware design process mostly depends on SHOC. In supporting SHOC, activeness and interface variables of structural active objects are crucial.

4

OTHER APPROACHES

In this section, we first review related work on active object systems. We then address the inheritance problem as an unresolved issue in other concurrent object-oriented systems and argue that one key feature of a SAOS is localized control. Finally, the fundamental principles of the SAOS approach are summarized.

4-1

Active Object Systems

The idea of active objects originated with the first object-oriented language SIMULA [BDMN73], where active objects were simulated by coroutines. Since SIMULA coroutines can simulate (sequential) processes, we regard them as processes. Interactions between processes and objects in SIMULA are complex. Some objects, after being initialized, turn into processes. A process executing procedure P of object X migrates to another object Y when P calls procedure Q of Y. Objects that become processes are active objects, and those that are only visited by other processes are passive objects. Both active and passive objects can be being visited by multiple processes concurrently. In SIMULA, processes interact with each other by visiting common objects, which may be process objects. Many active object systems have been designed since then. Systems that more or less follow the SIMULA computation model, where processes are dominant

154

Chapter 9

components, are well surveyed by Chin and Chanson [CC91]. Also, ConcurrentSmalltalk [YT87], Hybrid [N87], and R T C + + [ITM90] belong to this group. Another group of active object systems such as Actors [A86, L87], A B C L / I [YSTH87], an P O O L - T [A87] model a system as a collection of objects t h a t interact with each other through messages. In these models, processes are confined to individual objects. This view of a system as a collection of interacting objects significantly helps its conceptual design. However, the difference between (remote) procedure calls and message passing is not as significant as it first looks, since migrating processes and processes exchanging messages are largely equivalent [LN79]. Most of the systems in this group s u p p o r t only one process in each active object. To model a complex object like a factory, however, multiple processes are needed. An active object with a single process, furthermore, cannot support recursive requests. A similar problem has long been recognized for monitors [A91]. Some AI systems allow us to create active objects by using active values [KKW84, KC84], which are used by SAOSs at the implementation level. A KNOs object has an internal state, a set of operations, and a set of rules [TFGN87]. Operations on KNOs objects are invoked by messages and statedriven transition rules. These systems do not support structural and hierarchical composition well. Structural and hierarchical composition can be supported even if objects interact with each other by exchanging messages (or invoking functions) [M91, S92]. In fact, SAOS p r o g r a m s use messages (more precisely, function invocations since they are translated into C + + ) at the implementation level. Functions implementing transition rules are activated by trigger messages sent from condition variables. If a SAOS program is coded at this level, the n u m b e r of pointers the p r o g r a m m e r m u s t deal with will roughly double, and the source code p r o g r a m size will increase accordingly. T h e SAOS translator a u t o m a t i c a l l y generates code t h a t adds back-pointers to trigger the executions of transition rules.

4.2

Inheritance Problem

In conventional O O P , activations of the m e t h o d s of each object are outside the scope of its control. T h e m e t h o d s themselves do not specify when they can or should be activated, and the inheritance mechanism need to s u p p o r t m e t h o d s specifying only actions. Consider a chain of classes C\, C?, ... , where C% is a superclass of C,-+i, and assume t h a t C% specifies a set of m e t h o d s M«. T h e n

Structural Active-Object Systems

155

with inherited m e t h o d s , d effectively possesses the set union M\ U M2... U Mi of m e t h o d s , if overriden m e t h o d s are ignored. On the other hand, in concurrent object-oriented systems, individual objects are responsible also for activation timings of their m e t h o d s . Therefore, if m e t h ods t h a t specify only actions are used as units of inheritance, they m a y cause problems. In Actor-based systems, m e t h o d activation depends on the combination of the pending messages and the states of interface control of individual objects [A86], and hence m e t h o d s alone cannot be inherited. Several proposals to solve this problem have been m a d e , including behavior abstractions [KL89], enabled sets [TS89], separation of constraint, primary, and transition m e t h o d s [S89], and synchronizing actions [N91]. All of these approaches propose the separation of actions and their synchronization. T h e SAOS approach advocates the opposite - i.e., tight integration of each action with its activation condition in one transition rule. Since related activities need not be described in two separate places, the resultant code is shorter and easier to understand. Sequential processes are also not suitable as units of inheritance. Inheritance implies the set union of specifications. If a system supports exactly one process per object, then the process specifications along an inheritance chain m u s t be merged into one process specification. Merging process specifications a u t o m a t i cally is in general impossible. If multiple processes are allowed with each object, the process specifications can be combined. T h e synchronization required for the combined processes to interact properly, however, is often complex. T h i s problem is also recognized for a state machine-based formalism [RBPEL91] (p.

ni). Since behavior specifications given as transition rules can be merged without any extra mechanism, the SAOS approach supports inheritance without any problem. W h e n some transition s t a t e m e n t s are overridden, they can be nullified if triggers for t h e m are not setup.

4,3

Localized Control

State-driven transition rules allow us to think small. We only need to think about when individual actions should be executed within each active object. O n the other hand, behavior specifications based on message passing still require us to think a b o u t the patterns of messages exchanged a m o n g active objects.

156

Chapter 9

Control in a conventional object-oriented program is passed by messages or procedure calls. In both of these cases, methods or procedures can be activated only by explicit external stimulations, which eventually must come from a main program. This control flow passed among methods of passive objects is often complex, especially when the system consists of many concurrently operating objects. We argue that control flow in the conventional OOP is not properly encapsulated or modularized. In a SAOS, structural active objects embody control as well as data and behaviors. Without any global and procedural description of control flow, each structural active object implements its own portion of control to initiate its operations. Furthermore, operations can be executed as long as their activation conditions are satisfied. Localization of control has an interesting implication. The main program of a conventional object-oriented program is substantially different from other classes, and it usually cannot be made into a class that represents a subsystem. Although a SAOS main program is an instance, its description has the same structure as those of other classes. We thus can change a SAOS main program to a class definition by replacing its keyword main to c l a s s . Instances of this class then can be used as components in a larger class.

4.4

The SAOS Approach

One major difference of the SAOS approach from other object-oriented concurrent systems is that it uses transition statements instead of sequential processes. The major reason for this decision was that sequential processes pose the following problems. 1. In order to support structural and hierarchical composition, even a small structural active object, such as one representing a logic gate, needs a process, which is too expensive. On the other hand, a large structural active object, such as one representing a factory, needs many processes that interact with each other in a complex way. 2. Sequential processes cannot adequately handle asynchronous events in such applications as process and manufacturing control and graphical userinterface systems. 3. As we explained in the preceding subsection, sequential processes do not support inheritance well.

Structural Active-Object Systems

157

In the SAOS approach, the basic unit of behavior description is a transition rule, which specifies when it is activated as well as the action taken. Lamport proposed to use a set of t r a n s i t i o n axioms, each of which is a conditionaction pair, as a specification of a concurrent system [L89]. One important beneficial feature of his proof system is that specifications consisting of sets of transition axioms are compositional. That is, let TA\ and TA2 be the sets of transition axioms describing the behaviors of the two components C\ and C2 of a concurrent system C. Then the set union TA\ U TA2 with proper renaming describes the behavior of C. His specification system is not object-oriented, however, and does not provide a mechanism for this renaming. We consider that the SAOS approach provides a suitable framework for this renaming. This is one evidence that transition rules can support SHOC well. Inheritance is a form of composition, and transitions rules can support it without any major problems. As we explained in Subsection 4.2, overloaded transition rules can be handled if the trigger-setup mechanism is slightly modified. We require that an execution of a transition statement be atomic. The rationale for this requirement is similar to that for the requirement that process interactions in CSP [H78] and CCS [M89] be atomic. Non-atomic actions can be easily simulated by atomic actions, but not vice versa. The abstraction of atomic operations has been successfully used in database concurrency control [BHG87] and concurrency models [L89, MI89]. Since the major objective of the SAOS approach is not faithful simulation of physical phenomena but expressiveness, we assume atomic executions of transition rules. In fact, transition statements are used only to describe actions used to schedule activities. We distinguish actions from activities as Rumbaugh et al. do [RBPEL91]. Individual activities, if they are computational, can be performed by sequential processes. In realtime control systems, it is common practice to move such computational activities to dedicated microprocessors. In other words, transition statements describe only those operations that are performed normally in the system (or kernel) mode, and they do not include computations performed in the user mode. We, however, do not intend to eliminate sequential processes completely from the SAOS approach. Although a process can be simulated by a set of transition statements, specifying a sequence of services requested in this way is often awkward. We plan to add sequential processes, each of which supports a set of sequential activities as a shorthand notation for a set of transition statements. Interestingly, Lamport also views sequential processes in this way [L89]. This extension is syntactically easy. Transition rules are allowed to enter non-atomic

158

Chapter 9

computational blocks or issue delay s t a t e m e n t s . Executions of transition rules t h a t include such operations turn into processes.

5

CONCLUSIONS

T h e SAOS approach provides a novel architecture for developing real-time concurrent software systems. A SAOS program can be constructed from its component structural active objects by structural and hierarchical object composition (SHOC). structural active objects are self-contained and active, and their behaviors are defined by the transition rules, always statements, and event routines provided in their class definitions. They interact with each other through their interface variables, which act like terminals. Interface variables are crucial for S H O C . Real-world objects can be simulated closely by structural active objects, and we can often produce a SAOS diagram t h a t is similar to the representation used by an application. A SAOS diagram can thus be used t h r o u g h o u t a software development cycle as a design document, as executable code, and as a user interface. We can generate executable code from a SAOS diagram by reusing old class definitions and creating new ones. We have developed various prototype SAOS programs and realized the following benefits of the SAOS approach.

1. If a system can be conceived as a collection of interacting objects, it can probably be implemented as a SAOS program. So far, we have implemented prototype SAOS programs in the following areas: discrete simulation, digital/analog/mixed-mode simulation, process and manufacturing control, hardware logic simulation, graphical user interfaces, graphical editors, L A N / W A N protocol simulation, and algorithm a n i m a t i o n . 2. S H O C is highly effective also in implementing a software system from its building blocks, especially in implementing graphical user interfaces [MC93]. 3. SAOS class definitions can be easily reused in S H O C , and they s u p p o r t inheritance without any problems. 4. Since SAOS programs are often concise and follow the application models closely, they are easy to write, comprehend, and modify.

Structural Active-Object Systems

159

5. When we write a SAOS program, we must think small. W h e n a traffic simulator, for example, is written as a SAOS program, most of the control logic can be contained in individual vehicles as is the case in the real world. In writing this control logic, we should think like the driver of a car and specify how we react to the changes in the environment surrounding the car. This observation indicates a high level of modularization of control in a SAOS. 6. Since SAOs are well modularized, it is possible to create a graphical SAOS editor t h a t allows editing while the SAOS program being created or m o d i fied is operating. Modifying a live system is not surprising for a hardware system consisting of such components as batteries, switches, and gates, but we consider it quite unique for a software system. This is another indication of a high level of modularization of control in a SAOS p r o g r a m . We consider SHOC as a new software development p a r a d i g m and the SAOS approach as one effective way to implement it. We are currently extending the SAOS approach in the following two areas. 1. We have implemented a prototype graphical user-interface m a n a g e m e n t system based on active objects, called AOUIMS, and realized t h a t graphical objects can be implemented much easily as structural active objects rather t h a n conventional objects. 2. When a system is build by S H O C from small building blocks, transition statements are good enough, and processes are usually not needed. However, there are certain applications such as flexible manufacturing systems, whose control logic may be better described by sequential processes. T h u s , we plan to add sequential processes as behavior definition m e t h o d s of structural active objects.

REFERENCES [A86] G. A. Agha. Actors: A Model of Concurrent Computation tems. MIT Press, 1986.

in Distributed

Sys-

[A87] P. America. "POOL-T: A parallel object-oriented language,". In A. Yonezawa and M. Tokoro, editors, In Object-Oriented Concurrent Programming, pages 199220. MIT Press, 1987. [A91] G. R. Andrews. "Paradigms for process interaction in distributed programs," ACM Computing Surveys 23(l):49-90 March 1991.

160

Chapter 9

[BHG87] P.A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. [BDMN73] G. M. Birtwistle, O-J. Dahl, B. Myhrhaug, and K. Nygaard. BEGIN. Auerbach, 1973.

SIMULA

[BB89] T. Bolognesi and E. Brinksma. "Introduction to the ISO specification language LOTOS,". In P.H.J, van Eijk, C.A. Vissers, and M. Diaz, editors, The Formal Description Technique LOTOS, pages 23-73. North-Holland, 1989. [B91] G. Booch. Object Oriented Design. Benjamin/Cummings, 1991. [CC91] R.S. Chin and S.T. Chanson. "Distributed object-based programming systems," ACM Computing Surveys 23(1):91-124 March 1991. [CM91] S. Choi and T. Minoura. "Active object system for discrete system simulation,". In Proc. Western Simulation Multiconference, pages 209-215, 1991. [C87] B.J. Cox. Object Oriented Programming: An Evolutionary Approach. Addison Wesly, 1987. [DK76] R. Davis and J. King. "An overview of production systems," Machine ligence 8:300-332 1976.

Intel-

[D79] T. DeMarco. Structured Analysis and System Specification. Prentice Hall, 1979. [D68] E. W. Dijkstra. "The structure of the 'THE' multiprogramming system," Communications of the ACM ll(5):341-346 May 1968. [D72] E. W. Dijkstra. "Hierarchical ordering of sequential processes,". In Operating Systems Techniques, number 9 in A. P. I. C. Studies in Data Processing, pages 72-93. Academic Press, London, 1972. [D75] E.W. Dijkstra. "Guarded commands, nondeterminism, and formal derivation," CACM 18(8):453-457 August 1975. [EG89] C.A. Ellis and S.J. Gibbs. "Active objects: realities and possibilities,". In W. Kim and F.H. Lochovsky, editors, Object-Oriented Concepts, Databases and Applications, pages 561-572. ACM Press, 1989. [EFRV86] G. Estrin, R. S. Fenchel, R. R. Razouk, and M. K. Vernon. "SARA (System ARchitects' Apprentice): Modeling, analysis, and simulation support for design of concurrent systems," IEEE Tr. on Software Engineering SE-12(2):293-311 February 1986. [GR83] A. Goldberg and D. Robson. Smalltalk-80: The Language and Its tation. Addison-Wesley, 1983.

Implemen-

[H72] C. A. R. Hoare. "Notes on data structuring,". In Dahl, Dijkstra, and Hoare, editors, Structured Programming. Academic Press, 1972. [H78] C. A. R. Hoare. "Communicating sequential processes," Communications the ACM 21(8):666-677 August 1978. [187] IEEE. IEEE Standard VHDL Language Reference Manual. 1987.

of

IEEE Std. 1076,

Structural Active-Object Systems

161

[ITM90] Y. Ishikawa, H. Tokuda, and Mercer C. W. "Object-oriented real-time language design: Constructs for timing constraints,". In Proc. Conf. on ObjectOriented Programming Systems, Languages, and Applications, pages 289-298, 1990. [KL89] D. G. Kafura and K. H. Lee. "Inheritance in Actor based concurrent objectoriented languages,". In European Conf.on Object-Oriented Programming, pages 131-145, 1989. [KC84] T. P. Kehler and G.D. Clemenson. "An application development system for expert-systems," Systems and Software 34:212-224 1984. [KMF78] Y. Kogure, T. Minoura, and T Fujiwara. "Method and system of controlling . plants,". U.S. Patent 4,115,848, 1978. [KKW84] J. C. Kunz, T. P. Kehler, and M. D. Williams. "Applications development using a hybrid AI development system," The AI Magazine 5(3):41-54 1984. [L89] L. Lamport. "A simple approach to specifying concurrent systems," 32(l):32-45 January 1989.

CACM

[LN79] H.C. Lauer and R.M. Needham. "On the duality of operating system structures," ACM Operating Sys. Review 13(2):3-19 April 1979. [L87] H. Lieberman. "Concurrent object-oriented programming in Act I,". In A. Yonezawa and M. Tokoro, editors, In Object-Oriented Concurrent Programming, pages 9-36. MIT Press, 1987. [L86] R. J. Linn. "The features and facilities of Estelle: A formal description technique based upon an extended finite state machine model,". In V. M. Diaz, editor, Protocol, Specification, Testing, and Verification, pages 271-296. North-Holland, 1986. [M91] V. Mak. "Dose: A modular and reusable object-oriented simulation environment,". In Proc. Western Simulation Multiconference, pages 3-11, 1991. [M88] B. Meyer. Object-Oriented Software Construction. [M89] R. Milner. Communication

Prentice-Hall, 1988.

and Concurrency. Prentice-Hall, 1989.

[MI89] T. Minoura and S.S. Iyengar. "Data and time abstraction techniques for analyzing multilevel concurrent systems," IEEE Tr. on Software Engineering SE-15(l):47-59 January 1989. [MCR93] T. Minoura, S. Choi, and R. Robinson. "Structural active-object systems for manufacturing control," Integrated Computer-Aided Engineering 1(2):121136 1993. [MPR93] T. Minoura, S. S. Pargaonkar, and K. Rehfuss. "Structural active-object systems for simulation,". In Proc. Conf. on Object-Oriented Programming Systems, Languages, and Applications, pages 338-335, 1993. [MC93] T. Minoura and Sungoon Choi. "Active-object user interface mangement system,". In Proc. Tools USA 93, pages 303-317. Prentice Hall, 1993.

162

Chapter 9

[N91] C. Neusius. "Synchronizing actions,". In Proc. European Conf. on ObjectOriented Programming, volume 512 of Lecture Notes in CS, pages 118-132. Springer-Verlag, 1991. [N87] O. M. Nierstrasz. "Active objects in Hybrid,". In Proc. Conf. on ObjectOriented Programming Systems, Languages, and Applications, pages 243-253, 1987. [PM93] S. S. Pargaonkar and T. Minoura. "Structural active-object systems for mixed-mode simulation,". Technical Report 93-40-01, Dept. of CS, Oregon State University, 1993. [RBPEL91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991. [S92] B. Selic et al. "Room: An object-oriented methodology for developing real-time systems,". In Proc. 5th Intl. Conf. on CASE, Montreal, 1992. [S89] E. Shibayama. "Reuse of concurrent object descriptions,". In Proc. European Conf. on Object-Oriented Programming, volume 491 of Lecture Notes in CS, pages 110-135. Springer-Verlag, 1989. [S86] B. Stroustrup. The C++ Programming Language. Addison-Wesly, 1986. [TS89] C. Tomlinson and V. Sigh. "Inheritance and synchronization with enabledsets,". In Proc. Conf. on Object-Oriented Programming Systems, Languages, and Applications, pages 103-112, 1989. [TFGN87] D. Tsichritzis, E. Flume, S. Gibbs, and O. Nierstrasz. "Knos: Knowledge acquisition, dissemination, and manipulation objects," ACM Trans, on Office Information Systems 5(1):96—112 1987. [YT87] Y. Yokote and M. Tokoro. "Experience and evolution of ConcurrentSmalltalk,". In Proc. Conf. on Object-Oriented Programming Systems, Languages, and Applications, pages 406-415, 1987. [YSTH87] A. Yonezawa, E. Shibayama, T. Takada, and Y. Honda. "Modelling and programming in an object oriented concurrent language ABCL/I,". In A. Yonezawa and M. Tokoro, editors, Object-Oriented Concurrent Programming, pages 55-90. MIT Press, 1987. [YC78] E. Youdon and L. Constantine. Structured Design. Youdon Press, 1978. [Z78] M. D. Zisman. "Use of production systems for modelling asynchronous concurrent processes,". In D.A. Waterman and F. Hayes-Roth, editors, Pattern-Directed Inference Systems, pages 53-69. Academic Press, 1978.

10 ORGANIZATIONAL CULTURE: AN OBJECT-ORIENTED FRAMEWORK Joseph Morabito Stevens Institute of Technology Hoboken, NJ 07030, USA

Anilkumar Bhate Stevens Institute of Technology Hoboken, NJ 07030, USA

Abstract This paper proposes a rigorous model for organizational culture. Culture has always been described rather vaguely, often with psychological jargon. It is argued that organizational success depends on the fit between culture and other organizational elements, including information technology. Understanding fit and culture requires a precise specification. Culture itself has many dimensions, each of which may be specified and integrated into a composite contract describing the cultural behavior of the organization. The utility of the proposed model is tested against current organizational research on innovative culture.

1. Introduction Organizations have "personalities." These personalities are called organizational cultures. From the information systems point of view, it is important to take into consideration the culture of an organization. This will enable "fit" between information systems and the organization. The need for a fit between the strategy of an organization and information technology (IT) has been presented by several authors, among them [D 94, HV 93, P 85]. Extending the same arguments, we argue that such a fit is also necessary between the

164

Chapter 10

culture of the organization and its information systems. The definition of culture addresses several dimensions of the organization - values, employee relationships, beliefs, learned behavior, etc. We will be looking at these definitions during the course of this paper. The primary purpose of this paper is to present a rigorous model of culture. This model will enable us to understand culture as well as the fit between culture and IT. In order to align IT with an organization's culture, it is necessary to understand precisely the meaning of culture and its associations to IT. Up to now, culture has been generally considered a loose collection of assumptions and behaviors. In order to develop a precise meaning, we use information modeling concepts to define culture and its associations [KR 94]. Naturally, it is possible to formalize a cultural specification, with say, the Z specification language, as it is to formalize an information specification [PST 91]. We test the utility of our proposed culture model by investigating how well it supports current organizational literature concerning the dimensions and properties of culture. In particular, we verify the model against the emerging area of innovative culture.

2. The Importance of Culture Every business - in fact, every organization — has a culture. Often it is fragmented and difficult to read from the outside. Some people are loyal to their company, others are loyal to their union, and still others have their loyalties elsewhere. Whatever the mix of reasons, at one time corporate culture was strong. Everyone knew the goals of the corporation, and would work towards achieving them, or at least pretend to be working towards achieving them. Times have changed - culture has changed. If you ask employees today why they work, they will most likely answer "because we need the money." Whether weak or strong, culture has a powerful influence throughout an organization. It affects practically everything - from who gets promoted and what decisions are made to how employees dress and how they behave. Today, the word loyalty has been eclipsed by self-interest. Can we ever engender loyalty again in an organization? Shall we be able to build a new culture? What is it that determines the kind of culture a company will have in the first place? And how will this culture manifest itself in the day-to-day life of an organization? The answers to these and related questions are not easy. In order to search for answers, we delved deeper into the organizational literature in order to understand better the elements that make up culture. To our amazement we found a myriad of definitions, connotations, and interpretations of the word culture. We realized that what we needed to do first is a modeling exercise that can enable us to have a better, tighter grip on this slippery concept. This paper is a result of this effort.

Organizational Culture

165

For the most part, culture is closely related to behavior. A strong culture usually consists of a system of rules of behavior that are clearly understood, though mostly informal. These rules guide how people are supposed to behave most of the time. By knowing what exactly is expected of them, employees will waste little time in deciding how to act in a given situation. In a weak culture, on the other hand, employees waste a good deal of time just trying to figure out what they should do and how they should do it. Needless to say, culture strongly influences productivity. However, a strong culture does not, in and of itself, confer competitive advantage. Strong cultures may be unpleasant or even pathological. They may not "fit" the competitive environment. For example, companies in the U.S. usually have cultures that reward individualistic behavior. By contrast, Japanese firms have cultures that reward cooperative behavior. One culture is not better than the other, because their contexts are different. What determines their respective utility is the level of competitive advantage they confer on their organization. This is largely a consequence of the "fit" between culture and the context within which the organization operates. Employees today are confused. They feel cheated. They find that cheating arises from many sources: their jobs, their managers, their work environments, the compensation they receive, and so on and so forth. The result is that their life values become uncertain; they become blameful and cynical; they confuse morality with ethics; they allow special interests to influence and overtake them. Uncertainty lies at the core of all these effects. A strong culture can provide structure, standards, and a value system — good or bad — in which to operate. People at all stages of their careers need to understand culture and how it works, because this will most likely have an effect on their work lives. Culture is bound to shape their responses in a strong but subtle way. Culture can make people empowered or not, productive or not, administrators or leaders, team players or individuals. By the time they have worked at a particular place in a particular company for several years, they may be so conditioned by the company's culture that they may not be capable of recognizing it. But when they change jobs, they may be in for a big surprise. People who want to advance in a particular company also need to understand — at least intuitive — how their culture operates. For example, if you are an engineer in a company where all the heroes are marketing whizzes, then you may have a problem. If product quality is the guiding value in your company, then you better be thinking of working in quality control teams. In some other situation, you may think of pursuing an MBA rather than an MS in mathematics. Or you may move to a more compatible culture. The problems discussed above become even more acute when an old culture is in a state of change. In this case, practically everything is shifting gears and hence

166

Chapter 10

everything is out of synch with everything else. This means you have to be prepared to accept, learn and imbibe some new, evolving culture — and you need to do this fast. Advancement, even survival is not guaranteed. Aside from consideration of personal success, people must understand very clearly how their culture operates if they are to do their jobs and communicate effectively with others. Even in the ideal situation of a strong culture with a positive value system, you must know how to manage the culture. This may involve creating new role models, teaching new employees the rules of the game, and even guiding the culture as it changes. Finally, the last important question is whether the culture trickles down throughout the organization - whether it is shared by everyone. This is particularly important for senior managers. A key ingredient in managerial success is their role in shaping the pattern of culture itself. Success will be determined by what managers really believe and put into practice, and not what they talk about. Companies with strong cultures have managers who practice it; companies with weak cultures have managers who publish slogans. This also has a bearing on what is their culture. Their own culture may be rich with lore, or it may be starved for shared values. It may be driven be virtue, or it may be driven be greed. It may be coherent, or it may be poorly understood. It may be rich, fiery, focused, and strong; or cold, diffuse, and weak. Understanding culture is important for senior executives because this is what ultimately creates meaning for their actions, or contributes to blind confusion or disaffection. Understanding the culture can help them pinpoint why their company is succeeding or failing. Understanding how to build and manage culture can help them professionally. This is because it finally comes down to working with people within their organization. And culture is the most important human characteristic of people.

3. Culture and Fit There are valid reasons for the above mentioned extension of the "fit argument" to culture. As is often observed, mere strategy alone may not lead to success. The culture of an organization is also an important ingredient, one of the deciding factors whether the organization will be successful or not. If the answer is "not," the culture must change. However changing the culture is not easy. There are still no clear-cut answers available to questions like: "what is the precise meaning of culture?", "how can we formalize culture?", "can an organization learn a new culture?", "what is the precise meaning of changing culture?", "when an organization is formed, does this crystallize culture by casting it into stone, or is culture an emergent property of the organization?" These and many other related questions need to be answered by experts in the organizational domain -

Organizational Culture

organizational psychology.

theory

167

(OT), management

information

systems

(MIS),

and

From the IT perspective, there is at least one additional point that we need to look at. Changing an organization's culture also entails bringing changes to its information systems. Otherwise, as culture changes (if it can be changed), the IT-fit will be lost. Such a loss of fit may render an information system less effective. Also, a changing culture may demand changes to an organization's information technology, and visa versa. "Culture implies the existence of certain dimensions or characteristics that are closely associated and interdependent. But most researchers make no effort to specify these characteristics. Rather, they talk of culture as some abstract 'milieu.' If culture exists and we argue that it does, it should have distinct dimensions that can be defined and measured" [R 90]. The purpose of this paper is to provide a rigorous framework by which the dimensions of culture are specified.

4. Definitions of Culture There are many definitions of organizational culture. [R 90] describes culture as: • the dominant values espoused by an organization • the way things are done in an organization • the philosophy that guides an organization's policy towards its employees and its customers • the basic assumptions and beliefs that are shared by members of an organization. As a matter of fact, organizational culture includes all of the above, and still much more. As a working hypothesis, let us take Edgar Schein's definition that culture is "the pattern of learned basic assumptions that has worked well enough to be considered valid, and therefore, to be taught to new members as the correct way to perceive, think, and feel in relation to the problems of survival and integration" [S 94]. This definition tells us that culture establishes a contract between individuals in the organization. That is to say, culture is acquired through the performance of contracts. The result, or the post-condition, of these contracts is the pattern of so called "learned basic assumptions" that has worked well enough to be considered valid. In other words, the contract defines the "accepted" behavior of people in the organization. It determines the behavioral norms that individuals must follow when they interact with each other within the organization. Incoming members of the organization must be taught these norms; they need to be "bound" by this contract on

168

Chapter 10

culture. Observe that we are deliberately describing the language of culture using the language of specification.

5. The Content of Culture Culture manifests itself in overt behaviors, norms, and espoused values. As we will subsequently show, learning the culture is a learning process, implementing or putting culture into practice is also a process. The "content" of these processes actually consists of things related to the "mind-set" of people who are implementing the culture. These "things of the mind-set" are nothing but some of the "less conscious operational values" that the members of an organization share. Thus, culture results from the implementation of contracts. In simpler, common language, we call these "less conscious operational values" as "habits". A psychologist might, perhaps, call them "learned instincts". Whatever may be the name given to them, these habits essentially force us to behave in a particular way. These therefore lie at the root of culture. They are the innermost core of culture. Different cultures exhibit them in different ways. Each culture has its set of own operational values, leading to its own contracts, its own specified behavior. It is this specified behavior, the overt manifestation of culture that is our main concern in this paper. We do not want to touch the inner core of operational values mentioned in the preceding paragraph. Let us leave it to the psychologists. As pointed out by [S 94], a complete analysis of culture would certainly involve a deeper investigation of this underlying, often implicit and unconscious pattern of assumptions which are normally taken for granted. However, being entirely informal and hidden, it is also the most difficult to formalize in an analytical way. In the present article, however, our interest is in rigorous analysis which may lead to a precise specification. Therefore, by intent, we choose to understand culture, not by its informal or hidden structural properties, but by its overt and manifest behavioral contracts and associations with other parts of the organization.

6. Culture Molecule In the process of developing a science, the initial concern is primarily that of the collection and description of data. Precise definitions of terms and other subtleties usually follow later. The same has been happening in the area of organizational culture. Concern over the inadequacy of terminology arises when one wants to attempt to formulate general principles of a theory, or to work out the hypotheses and to arrive at a prediction in order to test these hypotheses. This paper adopts standard OT terms to describe phenomena that can lead to the specification of a generalized model of culture. This will facilitate understanding and communication among different groups of people. However, the model does not have

169

Organizational Culture

to be absolutely (i.e., completely) generalized; rather, it will be sufficient if it satisfies the requirements of specification and communication. Since scientific hypotheses must be logically consistent and verifiable, their constituent terms must be so defined as to be compatible with the rest of the terminology used in the field. It is for this reason that we introduce a culture molecule that uses information modeling concepts for precise specification [KR 94]. That is, we frame the concept of culture with organizational constructs, but precisely specify their interaction with the notation of [KR 94]. The culture molecule is as follows:

culture

human

structure

information

tool

memory

world-view

strategy

In this illustration, we have defined culture in terms of the "component" organizational constructs of human, structure, information, tool, memory, worldview, and strategy. That is to say, culture is a set of behaviors with deliberate and emergent properties, specified by the interaction (i.e., composition association) of these organizational elements. Briefly, these elements are: • a specification of cultural behavior —the culture layer • the people engaged by the organization — the human component • the organization of people supporting the organization — the structure component • the information required to support the organization — the information component • the non-human artifacts required by the organization - the tool component • the shared beliefs and behaviors in the organization- the memory component • the interface between the organization's members and the outside world — the world-view component • the vision and mission of the organization - the strategy component

170

Chapter 10

• the managed collection (i.e., fit) of the components that together constitute the notion of culture — the composition association The composition association is precisely specified through its invariants, and as mentioned above, has both deliberate and emergent properties. Since culture is defined here to be the composite specification of behavior resulting from the interaction of its components, culture is subtyped as a composition - assembly [KR 94]. That is to say, the specification of culture derives from all of its components, and does not exist independently. The primary deliberate property is the composition association itself. That is, culture, being an assembly, exists as a unique set of behaviors only because of its dependency on each of its constituents. Therefore, the properties of culture are, for the most part, emergent. The most significant emergent property of culture is adaptability — whether a culture can change in response to the environment. This property of culture is particularly important in a competitive environment. This leads to the concept of innovative cultures, to be discussed below. The linear specification corresponding to the graphical representation is as follows: fit: composition (culture, {human, structure, information, tool, memory, world-view, strategy}) In the culture molecule, culture is described in terms of the interaction — fit between organizational elements. As a composition, culture has both deliberate and emergent properties. Culture is specified by the composite contract representing the interaction of explicit behaviors - contracts - of each corresponding component. We deliberately ignore the structural, "less conscious operational values" associated with each organizational element.

Observe that in our model, culture does not exist as a single entity that one can grasp, but rather is a composite complex consisting of many organizational entities and a collection of specific interactions. Cultural components include human elements, consisting of all members of an organization: employees, consultants, suppliers, and distributors. Their individual view-points and mind-sets are included. The structure element includes the reporting hierarchy, associated authorities, and work groups such as teams. The information element has two dimensions: the first includes the required information models associated with business processes and decision making; the second includes organization-wide information (e.g., access to corporate policies, strategies, job openings, etc.) The tool component refers primarily to computer technology, but may

171

Organizational Culture

include documents and other sources of information. Memory refers to the legacy or past experiences of the organization. The world-view represents the perception by the individual members of the outside world. Strictly speaking, the world-view is a component of the human element. However, organizational literature identifies this set of behaviors as a discrete factor in understanding culture, and is therefore, identified as a separate component in the above. Strategy consists of an organization's vision, mission, goals, and the plans required to achieve those goals.

7. Applying Technology

the

Culture

Molecule

to

Information

Each component in the culture molecule is a view of culture in organizational literature. Through the process of abstraction, the information modeling construct known as composition, and the contract specification schema, we are able to create a complete view of culture. The culture molecule supports both an individual view and a perspective of the whole. When designing an organization, it is critical to examine each element and how it interacts with associated elements in the culture molecule. A change to one perspective — a cultural component — produces a change in the composite complex of culture. For example, an organization with a client/server implementation has a very different cuUure than one based on a mainframe: the client/server firm tends to have reciprocally organized business processes [M 94], information is more readily available and current, decisions are more likely to be decentralized, the organizational structure more flat, and so on. The lesson here is that a change in platform from mainframe to client/server is not merely a change in the tool component, but a cascade of changes in associated components and their interaction — culture itself. This is an example of the emergent characteristic of culture: the cascade effect is itself an emergent property of culture. As another example, consider a shift from a structured to an object paradigm in software development. As in the previous example, the change is not confined to a single element, but spans the entire cultural complex. Application development is a business process, the clients of which are usually, but not always, internal. The product is an application — information and all supporting infrastructure. The structured approach to software development demands sequential business process design, as is found, say, in information engineering. The availability of information is restricted to the sequence in which it is required; hence, the high quality information systems normally found in a learning organization are rarely associated with structured approaches [E 93]. Moreover, rapid development or prototyping are "work-around" attempts to reorganize sequential processes into reciprocal ones. The time parameter — an emergent property of a business process — has changed, but little

172

Chapter 10

else. In practice, rapid development remains a (shortened) sequence of processes, with little effect on the functional hierarchy, the availability of information, the learning opportunities for members of the development staff, and on the quality of the final product. By contrast, the object paradigm represents an opportunity to change the culture of the information technology (IT) department, and the whole organization. The object paradigm demands reciprocally organized application development tasks. Reciprocal processes are mutually dependent and form the basis of business process reengineering [M 94]. Note that software development is a business process. A reciprocal business process enables, and is enabled by, the object-oriented software development approach where analysis, design, and coding are interconnected. Reciprocal (i.e., object) software development will change the distribution of information and its availability, it may lead to a learning environment, and it may change the functional structure in the development organization from one based on hierarchy to lateral relations. Each of these areas is associated with a culture component as illustrated in the culture molecule. Culture, then, determines whether a new paradigm will be successful, not the paradigm. If the object paradigm is to be successful, IT managers must craft each of the cultural components — not one or two - and be prepared for a change in the organization's culture. If the change is confined to technology, the opportunity for a large impact on the organization will be lost, and more importantly will probably fail. The lesson described by the culture molecule is that changing one organizational element in isolation of the others will violate a cultural (i.e., composition) invariant, and generate a misfit and a dysfunctional culture. Successful organizations have managers who craft change by creating an appropriate fit among organizational components, and who expect a concomitant change in culture.

8. Innovative Culture and the Culture Molecule Any model of culture must make sense in terms of current organizational research. The most far reaching area involves a cultural imperative for organizations to adapt to a turbulent environment. This type of adaptive culture is known as an innovative culture. There is much concern today about the capacity of organizations to adapt to rapidly changing environments. Adaptation means developing the capacity to manage perpetual change. Herein lies a fundamental difficulty that makes the effort of modeling culture all the more important. The problem is that by its very meaning, organizational culture refers to setting up of a pattern. This pattern is behavior — the result of implementing culture contracts. It is assumed that this pattern will survive for a sufficiently long time and continue to serve the interests of its designers and implementors.

Organizational Culture

173

As argued by Edgar Schein (1994) in his chapter on "Innovative Cultures and Organizations," adaptation in a turbulent environment requires more than minor adjustments to the present way of doing things. Managing perpetual change requires innovative ideas, consisting of new missions, new goals, new ways of getting things done, and even new values and assumptions. This means learning a new culture. Organizations must learn how to learn and must become self-designing. Coming to grips with this idea presented by Schein establishes more forcefully the need for developing a precise model for culture. A culture of learning a new culture is, after all, a culture itself. Unless we are able to figure out what this self changing culture is, or would be, how can we develop an organization which will implement it? Thus, this problem once again brings us back to the original problem of modeling culture. Schein's answer to the problem lies in the hope that information technology is the panacea for solving all such problems. According to Zuboff (1988), there is enough promise that this is already in place. On the other hand, Schein further claims that "introduction of IT into organizations will not fulfill the potential of IT as a strategic aid, unless the organizations simultaneously develop innovative cultures." Evidently, these two ideas are closely related. In order to realize the full potential of IT we need innovative culture, and in order to develop an innovative culture we need the use of IT. We claim that the model of culture, namely the culture molecule presented in this paper already takes into account the above situation. The justification of such a claim lies in the argument made above that an innovative culture is itself a culture. In information modeling terminology, innovative culture is a subtype of culture. The facility of making the culture a culture-learning culture must logically be present within the culture itself. If this facility of a learning faculty is absent, such a culture is not, and can never be, an innovative culture. The question therefore is, where does such a learning faculty lie in our culture molecule? We now answer this question as well as look into its resulting implications. An important point to note, however, is that "cultures," whatever they may be, are always built around the core technologies that caused the organizations to be created in the first place. Needless to say, an organization that is designed to operate with the help of a computer network environment is bound to develop an entirely different culture compared to an older organization that was designed to operate with a centralized mainframe computational facility. Thus, whatever is needed, or may be needed in the future, for making a culture an innovative culture is already present in the culture molecule, although this can not be shown explicitly as part of the culture molecule. A learning capability is not a component of culture and hence can not be modeled by means of a composition association. It is essentially an attribute or quality that is possessed by every aspect or

174

Chapter 10

component that is present in the composition shown in the culture molecule. Thus, this means a learning attribute must be shown for each of the components of culture. This means that each of the various components - human, structure, memory, information, tools, world-view, and strategy — must be associated in some way or another with a learning capability. We may represent this cultural learning facility as a reference association from an organization's learning capability (sometimes known as "organizational learning") to each culture component. Thus, innovative culture may be seen as a subtype of culture, depending on the existence of a reference association between the culture molecule and organizational learning. Culture manifests itself in overt behaviors, norms, and espoused values. It is also expressed in some of the less conscious and operational values that members of an organization share. It is possible to model whatever is overt. It is not easy to model whatever is less conscious. We want to repeat our statement made at the beginning of this paper: we address only the problem of modeling that which can be observed by looking at overt behavior. We leave the less conscious stuff to the psychologist. Thus, inevitably, whatever we talk about the learning attribute mentioned above, we are limiting ourselves to only the behavioral aspect of it. Learning certainly has a mental aspect, but we deliberately want to ignore it because it is too mentalistic and hence too slippery to model in a precise way.

9. Innovative Properties and the Culture Molecule Let us now look at what ingredients are required to be present in a culture in order for it to be an innovative culture. Schein has mentioned seven cultural dimensions that influence the innovativeness of an organization. These are: 1.

Organization-Environment relationship - this may be either organizationdominant, environment-dominant, or symbiotic.

2.

Nature of Human Activity - this may be either reactive and fatalistic, harmonizing, or proactive.

3.

Nature of Reality and Truth - this may be either moralistic authority, or pragmatism.

4.

Nature of Time - this may be past-oriented, present-oriented, or future-oriented. Also, it may consist of short-time, medium-time, or long-time units.

5.

Nature of Human Nature - here the basic assumption is that humans are either basically evil, or basically good. Also, human nature is either fixed, or mutable.

Organizational Culture

175

6.

Nature of Human Relationships - this may involve groupism or individualism. Also, it may manifest itself either in authoritarian/paternalistic form, or collegial/participative form.

7.

Subculture diversity./connectedness — this may be either low or high.

It is observed that all of the above dimensions stated by Schein are already in our culture molecule. The relationship of the organization and its environment is included and is an important part of its World-view component. The nature of human activity is included in the Human component. The nature of reality and truth deals with the belief system that the members of an organization share — this is part of the Memory component, and is manifest in the behavior in the form of shared beliefs. It is also in the World-view of the organization that determines whether an organization looks more into the near future and is interested in short-term beliefs, or looks more towards the distant future and is interested in long-term benefits. The nature of human nature is obviously included in the Human component. The nature of human relationships; however, is part of the Memory component, rather than being a part of the Human component. Although the relationships evidently depend on the basic humanness of people (i.e., the Human component), whether these relationships manifests themselves in the form of teamwork or individuality entirely depends upon how people are expected to behave in the organization or what beliefs they are supposed to hold while doing their work. Similarly, whether the organization is oriented towards more diversity and allows proliferation of many diverse subcultures within itself also depends upon the belief system that the organization adheres to in general. Hence, this is also part of the Memory component. Thus the culture molecule has tremendous utility as a modeling device and proves to be all-inclusive, addressing all the dimensions that an organizational researcher working on culture might want to look for. There is one final point concerning the utility of the culture molecule. Culture has traditionally been an amorphous concept. Recall from the above that culture has two dimensions — psychological and manifest behavior. By focusing on the latter, it is possible to elicit unwritten rules of the organization and formalize them. There is no reason for any organizational concept such as culture to remain vague. The culture molecule is the mechanism by which this may be effected.

10. References [D 94] Davenport, T.H. 1994. "Saving IT's Soul: Human-Centered Information Management." Harvard Business Review, March-April 1994., pp. 119-131. [E 93] Earl, M.J. 1993. "Experiences in Strategic Information Systems Planning." MIS Quarterly, March 1993. pp. 1-24.

176

Chapter 10

[HV 93] Henderson, J.C., and Venkatraman, N. 1993. "Strategic alignment: Leveraging information technology for transforming organizations." IBM Systems Journal, 1993. Volume 32, No. 1. pp. 4-16. [KR 94] Kilov, H., and Ross, J.M. 1994. Information Modeling. Englewood Cliffs, N.J. Prentice Hall, Inc. Bertrand Meyer Series. [M 94] Morabito, J. 1994. "Business Process Modeling: An Object-Oriented Framework for Business Infrastructure Specification." In Workshop on Specification of Behavioral Semantics in Object-Oriented Information Modeling, Ninth Annual Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 1994). October 1994. [PST 91] Potter, B., Sinclair, J., and Till, D. 1991. An Introduction to Formal Specification and Z. Hertfordshire, UK. Prentice Hall International (UK) Ltd. C.A.R. Hoare Series. [P 85] Porter, M.E. 1985. Competitive Advantage: Creating and Sustaining Superior Performance. New York, N.Y. The Free Press, A Division of Macmillan, Inc. [R 90] Robbins, S.P. 1990. Organization Theory: Structure, Design, and Applications. Third Edition. Englewood Cliffs, N.J. Prentice Hall, Inc. [S 94] Schein, E.H. 1994. 'innovative Cultures and Organizations." In The Information Technology Revolution, Allen, T.J., and Morton, M.S.S. (eds.) 1994. Oxford University Press.

11 S P E C I F Y I N G AND R E A S O N I N G A B O U T BUSINESS RULES IN A S E M A N T I C N E T W O R K Leora Morgenstern IBM T.J. Watson Research Center Yorktown Heights, NY 10598 [email protected] A b s t r a c t : Semantic networks have long been recognized as useful in commonsense reasoning and business applications. This paper explores an attempt to capture a set of business rules as a semantic network. While some of these rules can be expressed as nodes and their connecting links, other rules are best thought of as logical formulae that are attached to particular nodes. We define Augmented Semantic Networks, a formal structure that can capture this concept. We discuss several of the problems that arise in Augmented Semantic Networks and suggest solutions to these problems. 1. I n t r o d u c t i o n : The desire to formally specify knowledge about a business or commonsense domain has led to the development of a variety of knowledge representation systems: frames [M75], the Entity-Relation model [ER92], semantic networks [SL83], and logicist models [GM92]. Of these systems, semantic networks are often the modelling tool of choice for the formalist with a practical bent. On the one hand, inference methods for taxonomic inheritance networks are well understood, reasoning with exceptions is handled in an intuitive manner, and there exist, at least to some extent, translational semantics [GP90]. At the same time, efficient algorithms exist for inference [HTT90]. Despite the popularity of semantic networks, the business community has embraced this tool somewhat gingerly. Semantic networks used in the commercial world, such as KL-ONE [SL83] and K-REP [MDW91], generally do not handle exceptions; they typically do only simple taxonomic reasoning. x This is a serious limitation; it is clear that inheritance with exceptions facilitates the representation of the knowledge used in many business applications. For example, a medical insurance company may generally reimburse drug purchases; an exception may be made for OTC (over-the-counter) drugs, and an exception to this exception can be made for insulin, an OTC drug which is usually covered. Standard semantic networks are limiting in other ways as well. These systems do not allow for the natural representation of many types of business rules. Rules expressing taxonomic information are clearly easily represented in such a network, as are simple statements expressing the relationship between a class and property. More complex rules, however, are not expressible within such networks. 1

In the academic world, in contrast, virtually all the activity lies in inheritance with exceptions.

178

Chapter 11

This paper describes various types of business rules that cannot be expressed within a standard taxonomic network structure. We suggest an augmented semantic network in which such rules can be expressed and explore the various ways in which inheritance in such a network differs from standard inheritance with exceptions. The work described in this paper was motivated by the development of an expert system for benefits inquiry for medical insurance. Examples from this domain will be used throughout the paper. We begin by describing the domain and the benefits inquiry system. We show that standard semantic networks are not sufficiently powerful for our needs and define augmented semantic networks. We then discuss several of the problems that arise in an augmented semantic network — specifically, rules inheritance, inheriting from subevents, and nonunary inheritance — and suggest solutions for these problems. 2 . T h e D o m a i n — B e n e f i t I n q u i r y S y s t e m s : Augmented semantic networks were developed as a result of the development of a benefit inquiry system for a large medical insurance corporation. The company offers its members a choice of products. A product is a collection of benefits, services, and rules, which are related in the following manner: A service may be covered by a particular benefit. Services and benefits may be subject to some set of rules. Rules are divided into cost-share, administrative, and medical rules, as well as access rules, which restrict the set of medical professionals or facilities that are available. Each product has on the order of 500-1000 rules. Customer service representatives are employees of the medical insurance company who answer various questions about the customers' benefits. Customers may wish to know if a particular service is covered, how that coverage may be limited, or what actions they should take in order to ensure maximum coverage. Examples of typical questions are: Can I use a midwife f o r t h e d e l i v e r y of my baby? If I use both a midwife and a p h y s i c i a n f o r p r e n a t a l c a r e , w i l l both be covered?, and My d o c t o r says I need t o s t a y in t h e h o s p i t a l 48 hours a f t e r c h i l d b i r t h . Will I be covered? The trend in the medical insurance industry is toward a greater number of products and rapid deployment on the market; as a result, customer service representatives find it increasingly difficult to keep up with the multitudes of rules that pertain to the various products. Thus, an automated benefit inquiry system is desirable.

3. The Benefits Network: 3.1 Choosing a R e p r e s e n t a t i o n : The initial question faced in the design of the benefits inquiry system is the choice of representation. An inheritance network seems a natural choice to represent the underlying knowledge for this domain, since so much of the information is taxonomic in nature. For example, TMJ therapy and spinal manipulation are both types of physical therapy; physical therapy, speech therapy, and occupational therapy are all types of therapy, which is a sort of professional service. Indeed, a significant portion of the rules associated with each product directly relate to the structure of the network. For example, the rule "Human Organ Transplant benefits are given for heart, lung, kidney, and liver transplants"

Specifying and Reasoning about Business Rules in a Semantic Network

179

tells us (in part) that heart, lung, kidney, and liver tranplants are subclasses of the class of all human organ transplants. The rule "Cosmetic surgery is covered only to repair the functioning of an organ or body part damaged through sickness or injury" tells us that the class of Cosmetic Surgery services is divided into (at least) two classes: Reconstructive Cosmetic and Aesthetic Cosmetic; moreover, the former is covered while the latter is not. But few rules have so simple a form. More typical is a rule such as "the initial newborn exam must be performed during the mother's hospital stay (for delivery)." Clearly, this rule is much more complex and does not translate into subclass relations between medical services. It is certainly possible to represent such a rule in a network or graphic form: see, e.g., [S84] who discusses the translation between general first-order rules and conceptual graphs. But such graphs do not integrate well with a standard taxonomic structure. The semantics of networks for arbitrary structures is quite different from the semantics of standard taxonomic networks (see [W75]), and the inheritance of attributes in these structures is not well understood. Instead, we suggest that we view such rules as logical formulas that are attached to individual nodes in the standard taxonomic network. 2 We call a semantic network augmented by logical rules attached to nodes an augmented semantic network We give a formal definition below. 3.2 Formal Definition of Network Methodology: We use throughout this paper a direct, as opposed to a translational theory of inheritance [H94]. Translational theories, such as that of [E88] specify the meaning of a network formalism in terms of a non-monotonic logic such as [R80]; direct theories, such as that of [HTT90], analyze and characterize interesting features and properties of semantic networks, such as consistency, and the sets of conclusions that can be derived from the premises, in terms of the network formalism itself. The focus is on paths in the network. A u g m e n t e d Semantic Networks: An augmented semantic network consists of a set of nodes, a set of links, and a background context. N o d e s A node consists of two parts: a label and a (possibly empty) set of rules or well-formed formulas in a first-order logical language. If a node N — (£,i2), where L is the label of the node and R is the set of rules, we sometimes refer to R as the set of rules at N or rules(N). If r is a member of R, we say at(r,N). The label of a node denotes some set of medical services. An example of a label is Surgical, which denotes the set of surgical services. Medical services may be identified as professional procedure services, condition services, or setting services. Professional procedure services, intuitively, are those services that are characterized by the medical professional who delivers it (e.g., surgery and physical therapy). Condition services are those services that are characterized by a particular condition (e.g., maternity and mental health). Setting services are those services that are directly linked to the setting in which they are offered (e.g., inpatient ancillary services or hospice services). When we reason about a set of medical services, we can usually classify that 2 This is a top-level view. We may separate represent the rules in any fashion we wish, such as conceptual graphs or the representation developed by [KR94].

180

C h a p t e r 11

set as consisting of either professional, condition, or setting services. However, the classes are not disjoint; indeed, we often need to reason a b o u t services t h a t are best characterized by two or more of these service types. For e x a m p l e (Section 5), we reason a b o u t physical therapy in an inpatient setting: this set of medical services belongs to b o t h professional procedure services a n d s e t t i n g services. Services m a y also be classified by their coverage; examples are Services Covered by Surgical Benefit and Services Covered by M a t e r n i t y Benefit (see Figure 1) 3 . T h e set of rules R consists of well-formed formulas chosen from t h e firstorder predicate calculus. An examples of a rule is: V x (copay(x) < $75) ( t h e flat co-pay for services is no more t h a n $75). As seen above, t h e s t r u c t u r e of rules m a y be considerably more complex. T h e set of rules at a node is constrained to be consistent. B a c k g r o u n d C o n t e x t T h e context of a network, denoted C. is a (possibly e m p t y ) set of wffs of first-order logic. Intuitively, C represents the b a c k g r o u n d information t h a t is true; for example, C m a y include a wff which s t a t e s t h a t all medical services m u s t be provided by licensed medical professionals in order to qualify for reimbursement. 4 T h e set of rules at each node in a network is constrained to be consistent with the context of the network. Note t h a t C should not be confused with the notion of a context as denned by [ H T T 9 0 ] . L i n k s T h e most i m p o r t a n t types of links between nodes are the positive a n d negative is-a links. Positive and negative is-a links m a y be strict or defeasible. If x and y are nodes, we write x => y a n d x ^ y to represent, respectively, the strict positive and strict negative is-a links; we write x —• y a n d x -/-* y t o represent, respectively, the defeasible positive a n d defeasible negative is-a links. Intuitively, x => y m e a n s t h a t all x's are y's; x j> y m e a n s t h a t all x's are n o t y's (no x's are y's); x —• y means t h a t typically, x's are y's; x / > y m e a n s t h a t typically, x's are not y's. If x => y, x ^> y, x —> y, or x -/-* y, we say t h a t x is a child of y or t h a t y is a parent of x. Our account of p a t h s is based on [H94]. A p a t h is a restricted sequence of positive a n d / o r negative links. We define p a t h s recursively in t h e following manner: • There is a p a t h from x to y iff there is a positive p a t h from x to y or t h e r e is a negative p a t h from x to y. • I f x — • y or x => y (resp., x /> y or x ^ y), then there is a positive (resp. negative) p a t h from x to y. • If there is a positive p a t h from x to y, a n d y —• z or y => z (resp. y -/+ z or y ^> z ), then there is a positive (resp. negative) p a t h from x to z. • If there is a negative p a t h from y to z a n d x —• y or x =>y, t h e n t h e r e is a negative p a t h from x to z. Note t h a t positive p a t h s can have only positive is-a links; negative p a t h s can have j u s t one negative link at the very end of t h e p a t h . P a t h s t h a t c o n t a i n only strict links are called strict paths; p a t h s t h a t contain only defeasible links 3

All figures can be found at the end of the paper. If we wish, we may think of the wffs in a context as being included in the set of rules at each node. 4

Specifying a n d Reasoning a b o u t Business Rules in a Semantic Network

181

are defeasible paths; p a t h s t h a t contain b o t h strict and defeasible links are called compound paths. This paper will be concerned almost exclusively with defeasible p a t h s ; extensions to strict and c o m p o u n d p a t h s are straightforward 5 . Often, there are b o t h positive and negative p a t h s between two nodes. Following [T86] a n d [H94], we speak of the undefeated p a t h s as those which are constructible and neither pre-empted HOT conflicted. Intuitively, the undefeated p a t h s are those which "win out" over their rivals. If there is an undefeated positive (resp. negative) p a t h between x and y, we say x ~~* y (resp. x -/• y ) . Examples of p a t h s can be seen in Figure 1. There is a positive p a t h from Orthopedic Surgery to Services Covered by Surgical Benefit. There are b o t h positive and negative p a t h s from Routine Endoscopic to Services Covered by Surgical Benefit; however, according to Horty et. al.'s [HTH90] specificity criterion (or Touretzky's [T86] inferential distance criterion), the positive p a t h is pre-empted by the negative p a t h . T h u s , the negative p a t h is undefeated. In cases where there is an undefeated p a t h from x to y and an undefeated p a t h from x to z (where y ^ z), we allow the prioritization of a particular p a t h . In Figure 1, there is a (positive) p a t h between Maternity Surgical a n d Services Covered by Maternity Benefit and a (positive) p a t h between Maternity Surgical a n d Services Covered by Surgical Benefit. T h e number 1 denotes t h a t the p a t h between Maternity Surgical and Covered by Maternity Benefit has priority over the other p a t h ( s ) . We m a y also allow such prioritization in cases of conflicting p a t h s . Doing so would entail altering the definition of a conflicted p a t h . S u b e v e n t s A fifth type of link is known as the subevent link. It is n a t u r a l to view a medical service or set of medical services as an event 6 , t h a t is, t h e event in which t h a t medical service is provided to some individual. For example, the set of surgical services can be viewed as the event of some individual undergoing a surgical procedure. By extension, since the label of a node denotes a set of medical services, it is n a t u r a l to consider each node as representing some event. If we view each node as an event, we m a y wish to talk a b o u t the decomposition of t h a t node into subevents. We m a y be interested in a complete 7 decomposition — e.g., the node H u m a n Organ Transplant decomposes into the subevents of (organ) acquisition, (organ) t r a n s p o r t , (recipient) p r e p a r a t i o n , a n d so on — or merely in a partial decomposition which gives us some subevents. If x is a subevent of y, we write subevent(x,y). If we introduce the predicate occurs(n, I), which is true if the event represented by node n occurs during interval I, a n d the predicate sub(Il,I2), which is true if II is a subinterval of 12, then we have the following axiom on subevent: A x i o m : subevent(x,y) D (occurs(y,I) D 3 J (sub(J,I) A occurs(x,J)J) For any node y, we are particularly interested in a distinguished set of subevents: those subevents x for which b o t h subevent(x,y) and x —• y. Anesthe5

Note also t h a t in all examples, nodes represent sets of objects, rather t h a n individual objects. This is done to simplify the exposition; the extension to individuals is straightforward. 6 We follow McDermott's ontology [M82] and understand an event, intuitively, to be the set of intervals in which that event takes place. Since events are just sets of intervals, they can be arbitrarily complex. In particular, sets of events are events. 7 Informally, a decomposition ei . . . e n of an event e is complete if doing all of e\ . . . en in some specified order entails doing e.

182

Chapter 11

sia is an example. It is both the case that Anesthesia is a subevent of Surgical services and that Anesthesia services are a subtype of Surgical services. Thus, there is an undefeated positive path between Anesthesia and Surgical services and between Anesthesia and Services Covered by Surgical Benefit. Therefore Anesthesia inherits the property of being covered by the Surgical Benefit (and is also a candidate for inheriting the rules at Surgical, such as the cost-share rule declaring that the co-pay for Surgical services is 20%; see Section 4 for further details). If x —> y and subevent(x.,y), we write x c—• y. It is important to note that we are maintaining the conceptual distinction between the is-a link and the subevent link. However, in contrast to most other networks in the literature, we do not insist that the relations corresponding to these links be disjoint. Generally, these links are disjoint in networks that contain both is-a and decomposition links. For example, Kautz's [K91] cooking hierarchy distinguishes between those events that are subtypes of the event Make-Pasta-Dish (Make-Fettucini-Alfredo, Make-Spaghetti-Pesto, and MakeSpaghetti-Marinara are examples) and the steps of Make-Past a-Dish (MakeNoodles, Make-Sauce, Boil). (In our notation, Make-Fettucini-Alfredo —• MakePasta-Dish, but subevent(Make-'N oodles ^ Make-Pasta-Dish)). Make-Noodles is not a subtype of Make-Pasta-Dish. In contrast, in this network, there is a significant overlap between these links. It is not the case, however, that whenever x is a subevent of y then x —• y; we mention a common exception below. Moreover, we are not arguing that the is-a and subevent relations must overlap in other networks. Perhaps it is more common for these links to be disjoint. The fact that these relations overlap here is due to a feature specific to this network: many subevents, such as Anesthesia or (organ) Acquisition, are considered bona fide medical services. We note an important connection between a subevent of a medical service and other descendants of that medical service. If x is a subevent of y, it is also a subevent of most descendants of y. For example, since Anesthesia is a subevent of Surgical, it is also a subevent of Endoscopic and of Orthopedic surgical services; likewise, (organ) Acquisition, a subevent of Human Organ Transplant, is a subevent of Heart (transplant) and Liver (transplant), which are subtypes of Human Organ Transplant. An important exception to this rule, of course, is other subevents: if xl t-^ y and x2 ^-> y, it is typically not the case that xl is a subevent of x2. We thus have the following axiom: subevent(x,y) A z ~> y A-> subevent(z,y) D subevent(x,z) Note that it is not the case that x c—• z. Anesthesia is a subevent of Endoscopic surgical, but we would not want to say that Anesthesia —> Endoscopic surgical. In fact, it does not inherit any attributes (or rules) from Endoscopic surgical. Interestingly, Endoscopic surgical may inherit rules from Anesthesia. We discuss this further in Section 6.

4 Inheriting Rules in an Augmented Semantic Network 4.1 The Problem The most important feature that distinguishes augmented semantic networks is that rules are associated with nodes. Thus, we can ask the following

Specifying a n d Reasoning about Business Rules in a Semantic Network

183

question: W h a t rules are inherited by a node in the network? Direct theories of inheritance traditionally focus on answering the question: is there an undefeated positive p a t h between A and B? Since most nodes in a network represent sets, and since the top node in an inheritance hierarchy often represents some a t t r i b u t e , t h e most intuitive interpretation of this question is: does some attribute hold of set A? For example, in the Clyde-Royal Elephant network [T86], the question of interest is: does the grey a t t r i b u t e hold of royal elephants? Such questions are of interest in this inheritance network as well: we wish to know whether a particular medical service is covered by some benefit. In addition, however, we are interested in determining which rules apply or pertain to t h a t service (equivalently, to the node representing t h a t service). Formally, we pose the question as follows. We introduce the following notation: N|V> if rule \j> pertains to node N. Overloading the | symbol, we say N | # if ip e tf iff N # . We define ¥ ( N ) = {ifr | N | rfr }. T h a t is, * ( N ) is the set of rules t h a t apply to node N. Then the question — and the new problem for inheritance theories — is: given a node N in the network described in Section 2, what is the set tf such t h a t N | * ? A naive approach suggests t h a t \£(N) = [JN^ N rules(i\T^)U rules(N). T h a t is, the set of rules t h a t apply to a node N can be obtained by looking at the nodes to which there is an undefeated positive p a t h from N, taking all the rule sets at these nodes and the rules at N, and forming the union of these sets. But such an approach is obviously wrong. Consider, for example, Figure 2. There is an undefeated positive p a t h from N3 to N2. T h u s , according to the naive approach, ¥ ( N 3 ) = rules(N3) U rules(N2) = { Vx P(x), Vx -i Q(x) } U { Vx R(x), Vx(P(x) D Q(x)) }. But this rule set is obviously inconsistent; we clearly do not want to blindly take unions of rule sets. 4.2 E f f e c t i n g R u l e s I n h e r i t a n c e : Since inconsistency can arise, determining \£(N) entails doing two things: 1. Deciding if the set of rules at t h a t node is consistent with b o t h the set of rules at the nodes to which there is an undefeated positive p a t h and the background context. 2. If these sets are not consistent, choosing as m a n y rules as possible which apply to the node. T h a t is, determining a maximally consistent subset (Gardenfors, 1988) of the inconsistent set formed by the union of rule sets. 8 We make two brief remarks about the first step: First, deciding whether a set of rules is consistent is only semi-decidable in general; however, we can restrict our attention to certain subsets of sentences such as those without existential quantifiers or self-embedding function symbols. Such sets are decidable. Second, in decidable cases, deciding whether of not a set of sentences is consistent is intractable; we discuss ways of handling this problem in Section 4.3. 8 Formally (for the case of two mutually inconsistent sets at nodes N l and node N2), we choose a subset S that satisfies the following conditions: 1 . 5 C (rules(Nl) U rules(N2)). 2. S UC is consistent. 3. 5 is the largest subset satisfying conditions 1. and 2. We say that 5 is a maximally consistent subset of rules(Nl) U rules(N2) with respect to (wrt) C. If the meaning is clear, we may omit the reference to C.

184

C h a p t e r 11

Most of the conceptual difficulties arise in the second task: choosing a m a x imally consistent subset. In general, there is more t h a n one m a x i m a l l y consistent subset of rules. T h e question is: which maximally consistent set should we choose? Since each maximally consistent subset is formed by deleting some of the rules in SI U S2, an alternate phrasing of this question is: which rules should we delete? T h a t is, how do we decide t h a t some rules are more i m p o r t a n t t h a n others? T h e general strategy is to articulate some -preference principles for rule sets and to choose maximally consistent subsets in accordance with these principles. For specific guidance on these preference principles, we t u r n to several examples, below. Each example suggests a criterion for preferring some rules to others. We consider first the following example (Figure 2). H G H ( H u m a n G r o w t h Hormone) —* (Prescription) Drugs. Suppose we have the following rules a t these nodes: Drugs: { V x (copay-pct(x) = 10)

V x,p (Non-network(p) and filled-at(x,p) D penalty(x) = $15) } (There is a 10% copay for all drugs and There is a $15 penalty for drugs filled a t non-network pharmacies.) HGH: { V x (copay-pct(x) = 50) }

(The copay for HGH drugs is 50%). If we assume t h a t the background context C entails some basic arithmetic facts such as Vx,vl,v2 (vl / v2) D (-• (copay-pct(x) = vl A copay-pct(x) = v2)), then the union of these two sets is inconsistent with respect to C. Obviously, there are two maximally consistent subsets: 1. T h e set of rules at the Drugs node, namely: { Vx (copay-pct(x) = 10) Vx,p (Non-network(p) and filled-at(x,p) D penalty(x) = $15) } and 2. { Vx (copay-pct(x) = 50)

Vx,p (Non-network(p) and filled-at(x,p) D penalty(x) = $15) } T h e choice of which maximally consistent subset to prefer is clear. T h e HGH node is more specific t h a n the Drugs node; thus we prefer the subset t h a t has the rule from the HGH node to the subset t h a t has the rule from the Drugs node. T h a t is, we prefer subset 2 to subset 1. In general, assume t h a t S I , S2 are sets such t h a t SI U S2 is inconsistent wrt C. Let X I and X2 be maximally consistent subsets wrt C of SI U S2. Let R l = X I - X2; R2 = X2 - X I . i.e., R l and R2 are all t h a t distinguish X I from X2. If this is the case, we say t h a t X I = X2 with respect to R 1 , R 2 . We can s t a t e the following principle: P r i n c i p l e o f P o s i t i o n a l P r e f e r e n c e ( s p e c i f i c i t y c r i t e r i o n ) : Let N l -~» N2. Assume t h a t SI is the set of rules at N l ; S2 is the set of rules at N2; a n d SI U S2 is inconsistent wrt C. Let X I , X2 be maximally consistent subsets wrt C such t h a t X I = X2 wrt R1,R2, where R l C S I , R2 C S2. T h e n we prefer X I toX2. T h a t is, we prefer the set t h a t has the rule associated with the m o r e specific

Specifying a n d Reasoning a b o u t Business Rules in a Semantic Network

185

class. This principle thus merely formalizes the general intuition t h a t lies behind all work on inheritance with exceptions: specific nodes have preference over general nodes. For an example where the principle of specificity does not provide guidance toward choosing between maximally consistent subsets, consider again Figure 2. Insulin Syringes —* Drugs; Insulin Syringes —• Supplies. Insulin Syringes inherits 2 cost share rules: V x (copay-pct(x) = 10) (There is a 10% copay for all prescription drugs) a n d V x (copay-pct(x) = 20) (There is a 20% copay for all supplies.) T h e union of these rules is inconsistent wrt the background context. It is not the case t h a t Drugs ~> Supplies or t h a t Supplies ^ Drugs, so specificity does not help here. However, the p a t h from Insulin Syringes to Drugs has priority over the p a t h from Insulin Syringes to Supplies. Thus, it is reasonable to expect t h a t we will prefer a rule whose source is the Drugs node over a rule whose source is the Supplies node. In practice, we must fine-tune the concept of a prioritized p a t h , since a p a t h m a y have priority for one type of rule, b u t not for another. For example, t h e p a t h from Maternity Surgical to Maternity m a y have preference over the p a t h from Maternity Surgical to Surgical for cost-share rules, b u t not for medical rules. To formalize this principle, we must extend our n o t a t i o n as follows: Let Rules (i,N) denote the set of rules of type i at node N. We can now speak of the priority of a p a t h at a node with respect to a particular rule t y p e . We t h e n state the principle of prioritized p a t h preference as follows: P r i n c i p l e o f P r i o r i t i z e d P a t h P r e f e r e n c e : Assume N l ^ N2, N l ^ N 3 , and t h a t it is not the case t h a t N2 ~» N3 or t h a t N3 ~» N2. Let N l - ^ N2 be the p a t h with highest priority at N l with respect to rule type k. Assume t h a t S2 is of type k and is the rule set at N2, S3 is of type k and is the rule set at N3, and S2 U S3 is inconsistent wrt C. If X2 a n d X3 are maximally consistent subsets wrt C of S2 U S3 such t h a t X2 ^ X3 wrt R 2 , R 3 , where R2 C S2 a n d R3 C S3, t h e n we prefer X2 to X 3 . T h e two preference principles thus proposed are compatible, b u t issues of ordering m u s t be addressed. If b o t h principles apply, which do we apply first? For example, assume t h a t N l ^~> N2, N l ^ N3, t h a t SI is the rule set a t N l , 52 is the rule set at N2, and S3 is the rule set at N3. Assume further t h a t SI U S2 is inconsistent wrt C; t h a t SI U S3 is inconsistent wrt C, a n d t h a t S2 U 53 is inconsistent wrt C. Do we conflict-resolve N2 and N3, a n d then conflictresolve N l and the result? Or do we conflict-resolve N l and N2, conflict-resolve N l and N3, a n d then conflict-resolve the results? Clearly, different approaches will yield different maximally consistent subsets. It appears reasonable to first conflict-resolve N2 and N3, and then conflict-resolve N l and the result. T h a t is, apply the principle of p r i m a r y p a t h before the principle of positional preference. The Positional Preference and Prioritized P a t h Preference principles b o t h utilize information present in the structure of the network. In this sense, they are principles t h a t are specific to the problems of rules conflict in the framework of inheritance. Other s t a n d a r d preference principles m a y also be needed here. One may wish to assign some rules a higher priority t h a n others (as in [M86]),

186

C h a p t e r 11

regardless of the rule's position in the network. For example, a rule s t a t i n g t h a t any form of ambulance transport (air, land, or water) is covered if t h a t form of t r a n s p o r t is medically necessary could have priority over any other rule regarding ambulances no m a t t e r where these rules are positioned. Likewise, it is also reasonable to prefer a particular subset of rules based on the results t h a t this subset entails. This is equivalent to preferring one extension, or model, over the other (as in [S88]). For example, we m a y prefer extensions in which a claim gets paid to one in which the claim does not get paid. 4 . 3 C o m p u t a t i o n a l I s s u e s : Inheriting rules immediately transforms the problem of inheritance from a tractable problem (at least in the case of u p w a r d s inheritance: see [SL93]) to one t h a t is badly intractable. In practice, we have discovered t h a t we can deal with the complexity issue by using a divide-andconquer strategy. T h e trick is to divide the set of rules into k types, subject to the following constraint: If Rules(i,n 1) U Rules(j,n2) is inconsistent wrt C, then i — j . T h a t is, rules are constrained so t h a t sets can contradict one a n o t h e r only within their own type. This cuts down on much consistency checking (since often when N l - ^ N2, the rule sets at N l are of a different type then the rule sets at N2) and greatly reduces the time needed for consistency checking a n d m a x i m a l subset construction and choice. Obviously, the greater k is, the m o r e this strategy helps. Finding a division of the rules into sets t h a t satisfy this constraint is not a trivial task. A good knowledge representation is indispensable. Finding such a representation is no longer only of academic interest; it can greatly affect the tractability of the system. We plan to investigate this issue in detail in the near future. T h e work of [KS96] is particularly relevant for our purposes. They have developed a m e t h o d of representing a n d categorizing rules according to their underlying functional structure ([K96] does this in greater detail). It is possible t h a t rules in certain categories can be shown to be consistent with respect to rules from other categories. If such properties can be proven, we will have discovered a division t h a t satisfies the above constraint. 4 . 4 B a c k t o A t t r i b u t e I n h e r i t a n c e We first noted the need to do conflict resolution a n d recognition when we were faced with the issue of rules inheritance. Further reflection, however, suggests t h a t similar problems can arise even when performing s t a n d a r d a t t r i b u t e inheritance. Consider Figure 1. M a t e r n i t y Surgical ~> Covered by Surgical Benefit; Maternity Surgical ^ Covered by Maternity Benefit. In fact, however, Maternity Surgical cannot be covered by b o t h benefits: there is a constraint t h a t services are covered by at most one benefit. This constraint is not explicit in the structure of the network; it is entailed by background d o m a i n knowledge; i.e., the context C. In general, when some of the knowledge of the inheritance network is present as background knowledge, inheriting a t t r i b u t e s from multiple parents has the potential for leading to inconsistency, even if this is not explicit. This problem has not been discussed in the inheritance literature in AI (to my knowledge) because inconsistencies in the examples used have always been

Specifying and Reasoning about Business Rules in a Semantic Network

187

explicit. The Nixon diamond example [RC81] is a classic example. Suppose, however, we modify Touretzky's [T86] modification of this example. Nixon => Republican; Nixon => Quaker; Republican —• Hawk; Quaker —• Pacifist. There is no explicit contradiction between Hawk and Pacifist. If, however, we add the background knowledge that these concepts are contradictory: Vz (Pacifist(x) = -> Hawk(x)), then there is an inconsistency that must be resolved. Depending on the amount and form of the background knowledge, detecting and resolving this inconsistency can be arbitrarily difficult (that is, as hard as the problem of rules inheritance). In object-oriented languages, limited type-checking is sometimes performed, and the user is warned when an object inherits conflicting types. However, this is done only for a small set of easily predictable conflicts; the general problem is not addressed. Moreover, contradictions are merely flagged, rather than resolved. 5 Non-network Non - u n a r y I n h e r i t a n c e ! Standard inheritance networks are characterized by the fact that each link connects exactly two nodes. This concept has been formalized by [E88]. Using a translational approach to inheritance in which an inheritance network is represented using the formalism of a non-monotonic logic, Etherington views such networks as a special case of default theories [R80). Specifically, network theories are defined as those default theories (D, W) in which • W contains only literals or disjuncts of the form (a V (3) where a and (3 are literals • D contains only normal and semi-normal defaults of the form ^j@- or tt:PA7iA—A7^ where a, /3, and all 7» are literals. A special case of network theories are unary theories [KS89]: Wdoes not contain disjuncts; D contains only normal or seminormal defaults of the form ^f- or ^i T , where (3 is a literal, a and (31 are positive literals and 7 is a negative literal. In network theories and unary theories, the antecedent of an implication or inference rule contains only one literal. In the terminology of the direct approach to inheritance networks, Etherington's restrictions entail that all links connect exactly two nodes, each of which expresses a literal. Virtually all examples in the inheritance literature are of network theories; most of the best known, indeed, are of unary theories. The benefits semantic network, however, is highly non-network and thus highly non-unary. 9 Consider, for example, the therapy portion of the network. Physical Therapy(PT), Occupational Therapy (OT), and Speech Therapy (ST) are all subtypes of the Therapy service, and are covered by the Therapy Benefit. However, coverage — as well as the rules that apply — depends also on the setting in which therapy is delivered and the condition of the patient receiving therapy. PT is covered by the Therapy Benefit if delivered in the home or office; however, it is considered a Hospice Ancillary service and is covered by the Hospice Benefit if it is 9

The term non-network is odd because we are after all discussing inheritance in a semantic network. Moreover, as we see below, [HT90] have shown how to extend the graphical notation to general boolean expressions. In what follows, therefore, we will usually refer to these theories as non-unary.

188

C h a p t e r 11

delivered in a hospice setting. It is considered an Inpatient Hospital Ancillary service and is covered by the Inpatient Hospital Benefit if it is delivered in an inpatient hospital setting. Moreover, if P T is delivered in an inpatient hospital setting while the patient is recovering from a cardiac condition or a stroke, it is covered under the Physical Medicine and Rehabilitation Benefit. Like P T , O T and ST are covered under the Inpatient Hospital Benefit if delivered in an inpatient setting; however, they are not covered at all if delivered in a hospice. Assuming t h a t each of these benefits, services, and settings is represented as a single node, it is clear t h a t these facts cannot be represented as links between two nodes. We can, however, represent these facts by the following default theory: (We use the following abbreviations: I P = inpatient hospital, IA = Inpatient Ancillary, H = hospice, HA = Hospice Ancillary, P M & R = Physical Medicine and Rehabilitation) PT:Therapy OT:Therapy Therapy Therapy PT Al P A(car diacV str oke):P M &R PM&R Therapy-.Therapy Bene fit IAtlPBenefit Therapy Bene fit IPBenefit

ST:Therapy PTAlP.IA Therapy IA (STvOT)AlP:IP IA PM&R:PM&RBenefit PM&RBenefit

PTAH.HA HA (STvOT)AH:^Covered ^Covered

This is clearly a non-network, non-unary theory. T h e question is: how can we represent this theory and perform inferences in an inheritance network? Two approaches are possible. First, we can associate nodes with boolean expressions. We can do this by either dropping the a s s u m p t i o n t h a t nodes represent literals or introducing new literals t h a t are defined as equivalent to boolean expressions (e.g., introducing a literal P T I P where P T I P is defined as P T A I P ) . In either case, we call this approach reifying boolean expressions as nodes, or reifying booleans. Applying this approach to the example above, we have, for example, P T A IP as a node which is a child of P T ; P T A I P A (cardiac V stroke) is a node which is a child of P T A IP, and so on. We then draw links from these new nodes to the nodes representing the conclusion. T h e semantic network for the therapy example can be seen in Figure 4. We have chosen this approach for the development of the benefit inquiry tool. But the approach has a serious disadvantage: it can lead to an inordinate number of new nodes. (Note t h a t in general, reified nodes can be children not only of leaf nodes, but also of any internal nodes in the network.) T h i s profligacy is undesirable from the c o m p u t a t i o n a l , intuitive, a n d presentational points of view. T h e computational problems are obvious. T h e intuitive problem stems from the fact t h a t we lose the information t h a t certain nodes should be grouped together. For example, the fact t h a t the hospice setting t r e a t s O T a n d P T differently, or t h a t O T and ST are treated similarly, is clear only after we search the O T , P T , and S T subtrees. T h e presentational problems are inherent in the fact t h a t the large number of nodes t h a t result from reification can m a k e portions of the network difficult to display either on a page or screen. In practice, we deal with these issues as follows: the benefit inquiry tool t h a t we have developed does not draw trees below the P T , O T , a n d S T levels. Instead, we provide functions called association links. An associated setting link is a function m a p p i n g a (non-setting service) in the network together with a setting (such as home or inpatient hospital) to another node in the network. For example, the associated setting link would m a p the pair ( P T , inpatient hospital)

Specifying and Reasoning a b o u t Business Rules in a Semantic Network

189

to Inpatient Ancillary. T h e associated condition-setting link m a p s the d o m a i n associated with the associated setting function together with a condition to a node in the network; for example ((PT,inpatient hospital), cardiac) m a p s to P M & R . T h e associated condition and setting-condition links are defined analogously. Users of the benefit inquiry system m a y call u p these functions by clicking on a node, and subsequently clicking on the relative condition a n d / o r setting in order to get to the parent of the reified node. This is all rather far from the spirit of inheritance, although necessary at this pass of the i m p l e m e n t a t i o n . A more promising approach is one based on preliminary work of [HT90]. Horty and T h o m a s o n have extended the framework of the s t a n d a r d inheritance network to a c c o m m o d a t e general boolean expressions such as those t h a t occur in the example above. Nodes t h a t represent boolean operators are provided. Analogous to Touretzky's [T86] definition of a p a t h t h a t is constructible b u t neither pre-empted nor conflicted, Horty and T h o m a s o n have defined the set of arguments t h a t are neither pre-empted nor conflicted. T h e Horty-Thomason approach does not yield a particularly simple network (see Figure 5 for a rendering, using this approach, of a portion of the therapy graph depicted in Figure 4). It is easy to see t h a t the number of nodes in such a graph, if we count boolean connectives as nodes, can easily surpass even the large number of nodes used in the reifying booleans approach. However, the network does show the connections between boolean expressions and their components, and thus facilitates reasoning about parts of boolean expressions in a way not possible using the reifying booleans approach. This approach is preliminary and needs to be developed further. In particular, it is not clear how one can translate the definition of undefeated arguments, which has a heavily proof-theoretic flavor, into reasonable algorithms 1 0 .

6. Inheritance from Subevents S t a n d a r d (AI) inheritance is parent-oriented with scarcely a t h o u g h t for siblings and other relations. This is not true of the current system. Rules can be inherited not only from parent nodes, but also from a distinguished set of sibling (or cousin) nodes, the subevents of t h a t node. Consider, for example, a simplified version of the H u m a n Organ Transplant ( H O T ) of the network (Figure 5): Acquisition, Transport, Storage, Preparation, and Transplant are all subevents of H O T . Rules applying to Acquisition are relevant whether one is performing a heart transplant or a liver transplant. T h u s , the rules a t t a c h e d to the Acquisition node (and to the other subevent nodes as well) must be accessed while answering questions or adjudicating a claim a b o u t a heart or liver transplant. This changes several features of inheritance as we u n d e r s t a n d it. First, we must modify the inheritance algorithm used in s t a n d a r d inheritance networks. Neither a strictly top-down nor a strictly b o t t o m - u p algorithm will suffice in this case; modification is needed. If we are performing b o t t o m - u p inheritance (the efficient way, as Selman and Levesque [SL93] have d e m o n s t r a t e d ) , we can modify the algorithm as follows: when reasoning a b o u t a node, we must find 10

"Reasonable" is a relative term here; as Horty and Thomason have shown, reasoning in such a network is NP-complete.

190

C h a p t e r 11

any subevents of each ancestor of t h a t node. (We can streamline this search by storing with each node a boolean indicating if there are subevents descending from t h a t node, as well as other information.) In addition, we must also consider the following questions: If a node's rule set is inconsistent with those of a subevent, which rules have priority? C a n we consider the rules of the subevent to be less specific t h a n those of the node? If all nodes need consider the rules applicable to all subevents, why not place those rules at the root service node? (The answer seems t o be t h a t since subevents m a y be subtypes in their own right, they deserve for b o t h logistical and conceptual reasons to be nodes in their own right — a n d t h u s to have rule sets.) Finally, what are the semantics of subevent inheritance? W h a t does inheriting from subevents m e a n ? Answering this last question will probably entail delving into previous work on t e m p o r a l reasoning (e.g., [S88]). n 7 . C o n c l u s i o n : We have defined and developed a u g m e n t e d semantic networks, semantic networks t h a t a t t a c h logical formulas to nodes. We have shown t h a t such networks are useful for specifying complex business rules in t h e medical insurance d o m a i n . We have investigated several of the problems arising in augmented semantic networks, including rules inheritance, n o n - u n a r y inheritance, and inheriting from subevents. Augmented semantic networks were developed in the medical insurance domain but most likely will be useful in any domain in which concepts are structured hierarchically (thus suggesting the need for a semantic network) a n d there is a need to use and reason with regulations (which can be represented as wffs of first-order logic). Examples of such d o m a i n s include other p a r t s of the insurance industry, such as property, car, and life insurance; and enterprise m o d elling, particularly in hierarchically organized bureaucracies which have m a n y regulations. In addition, the legal d o m a i n appears to be a rich area for investigation, since legal concepts are often organized hierarchically, a n d t h e relation between laws and well-formed formulas is obvious. A c k n o w l e d g e m e n t s : This paper is a revised version of "New P r o b l e m s for Inheritance Theories," delivered at the T h i r d S y m p o s i u m on Logical Formalizations for Commonsense Reasoning, Stanford, CA, January, 1993. T h a n k s to Ernie Davis, Benjamin Grosof, and Daniel L e h m a n n for helpful discussions and suggestions and to Bill W y n n e for his assistance in p o p u l a t i n g the benefits semantic network. References: [ER92] Proceedings of the First International Conference on Enterprise Modelling Technology, MIT Press, 1990 [E88] D. Etherington: Reasoning with Incomplete Information, Morgan Kaufmann, Los Altos, 1988 [GP90] M. Gelfond and H. Przymusinska: Formalization of Inheritance Reasoning in Autoepistemic Logic, Fundamenta Informaticae, 1990 11

Note that properties inherited by subevents are not "liquid" in Shoham's sense. When a property is liquid, if it holds over an interval, then it holds over all subintervals; here, we merely claim that some properties are inherited by the subevents explicitly mentioned in the network, which are not, of course, all possible subevents or subintervals.

Specifying and Reasoning about Business Rules in a Semantic Network

191

[G91] B. Grosof: Generalizing Prioritization, in J. Allen, R. Fikes, and E. Sandewall (eds): Proceedings of the Second International Conference on Principles of Knowledge Representation and Reasoning, Morgan Kaufmann, San Mateo, 1991, 289-300 [H94] J. Horty: Some Direct Theories of Nonmonotonic Inheritance in D. Gabbay, C. Hogger, and J. Robinson, eds: Handbook of Logic in Artificial Intelligence and Logic Programming, Vol. 3: Nonmonotonic Reasoning and Uncertain Reasoning, Oxford University Press, Oxford, 1994, 111-187 [HT90] J. Horty and R. Thomason: Boolean Extensions of Inheritance Networks, A A AI1990, Morgan Kaufmann, Los Altos, 1990, 663-669 [HTH90] J. Horty, R. Thomason and D. Touretzky: A Skeptical Theory of Inheritance in Nonmonotonic Semantic Networks, Artificial Intelligence 42, 1990, 311-349 [K91] H. Kautz: A Formal Theory of Plan Recognition and its Implementation in J. Allen, H. Kautz, R. Pelavin, and J. Tenenberg: Reasoning About Plans, Morgan Kaufman, San Mateo, 1991, 69-125 [KS91] H. Kautz and B. Selman: Hard Problems for Simple Default Logics in R. Brachman, H. Levesque, and R. Reiter (eds): Proceedings of the First International Conference on Principles of Knowledge Representation and Reasoning, Morgan Kaufman, San Mateo, 1991, 189-197 [KS96] H. Kilov and I. Simmonds: Business patterns: Reusable Abstract Constructs for Business Specifications, to appear in Proceedings, IFIPWG8.3 Conference, London, July 1996, Chapman and Hall [K96] H. Kilov, Private communication [EMW 91] E. Mays, R. Dionne, and R. Weida: K-REP System Overview, SIGART Bulletin, 2:3, 1991 [M80] J. McCarthy: Circumscription - A Form of Non-Monotonic Reasoning, Artificial Intelligence 13, 1980, 27-39 [M86] J. McCarthy: Applications of Circumscription to Formalizing Common-sense Knowledge, Artificial Intelligence 28,, 1986, 86-116 [M82] D. McDermott: A Temporal Logic for Reasoning About Processes and Plans, Cognitive Science 6, 1982, 101-155 [M75] M. Minsky: "A Framework for Representing Knowledge," in The Psychology of Computer Vision, ed. P.H. Winston, McGraw Hill, New York, 1975, 211-277 [Q68] M. Quillian: Semantic Memory in M. Minsky (ed): Semantic Information Processing, MIT Press, Cambridge, 1968 [R80] R. Reiter: A Logic for Default Reasoning, Artificial Intelligence 13, 1980 [RC81] R. Reiter and G. Criscuolo: On Interacting Defaults, IJCAI1981, 270-276 [SL83] J. Schmolze and T. Lipkis: Classification in the K L - O N E Representation System, IJCAI 1983 [SL93] B. Selman and H. Levesque: T h e Complexity of Path-Based Defeasible Inheritance, Artificial Intelligence 62:2, 1993, 303-340 [S88] Y. Shoham: Reasoning About Change: Time and Causation from the Standpoint of Artificial Intelligence, M I T Press, Cambridge, 1988 [S84] J. Sowa: Conceptual Structures: Information Processing in Mind and Machine, Addison-Wesley, Reading, 1984 [T86] D. Touretzky: The Mathematics of Inheritance Systems, Morgan Kaufmann, Los Altos, 1986 [W75] W. Woods: "What's in a Link," in D. Bobrow and A. Collins, eds: Representation and Understanding, Academic Press, New York, 1975, 35-82

1 9 2

Chapter 11

Figure 1: A portion of the benefits network Plain lines: defeasible is-a; slashed lines: negative defeasible is-a {(x,p)(Non-network(p) & filled-at(x.p) --> penalty (x) = $15)), (x)(Copay-pct(x) = 10)}

Figure 3: A portion of the therapy network, using the Horty-Thomason approach

{(x)(copay-pct(x) = 20)}

{(x)(Copay-pct(x) = 50) }

Figure 2: choosing maximal consistent subsets

inpatient benefit

Figure 5: Inheriting from subevents. y true at all subtypes

therapy benefit

Figure 4: Reifying boolean expressions as nodes in non-unary inheritance

12 DYNAMIC AND MULTIPLE CLASSIFICATION James J. Odell Ann Arbor, Michigan USA 71051.1733@compuserve. com

OBJECT LIFECYCLES Most objects have periods of existence. For these objects, the beginning and ending points can be reasonably defined. Such objects can include a particular product, an instance of a distribution process, a specific flamingo at the zoo, or your '57 Chevy. However, when does that object you think of as your car cease to be an object? Is it still an object after it enters the junkyard and is squashed into a cube? For you, the object may no longer exist. For the salvager, however, it is an object—though not an instance of the concept Car. What happens when the squashed cube is melted in a pot with 27 other cars? Without doubt the car/cube then ceases to be an object for us. However, what occurs if you slice it in two? Is it still the same object or two different ones? Objects appear in our awareness when we first apply a concept to them, and objects disappear when concepts no longer apply. In this way, objects can seem to have their own lifecycles. To describe this change, we can employ sets. SET MEMBERSHIP While objects are individual, independent instances, a set is a particular collection, or class,* of objects. Membership in a set is determined solely by its concept's complete definition or intension. For example in Fig. 1, the intension of the concept Pawn is the complete definition of a Pawn. This definition acts as a filter that screens all Class is considered—technically—to be the correct word when referring to the collection of objects to which a concept applies [W10] and, thus, provides a basis for using words such as classify and classification. Some [Q87] argue that set and class mean the same thing. Since class has a different meaning in OO programming languages, the word set will be used to avoid confusion. It is worth noting, however, that the inspiration for using the term class in OO originally came from the centuriesold mathematical notion.

Dynamic and Multiple Classification

194

objects—permitting only those objects into the set that pass the membership test. Set, then, is another name for the extension of a concept. A set can include many objects and each object can be a member of many sets. In Fig. 2, three concepts are displayed—Man, Woman, and Employee. Each set is a collection of objects that complies with the membership requirement of its underlying concept. Of the eight objects in the figure, the two labeled Jane and Paul are members of two sets simultaneously. The Jane object is a member of both the Woman set and the Employee set—and could easily be a member of other sets, such as Wife, Mother, Author, Chief Justice, Fun Person, and Good Friend. Since each object exists only once, there can be only one instance of Jane. As in life, we can (and usually do) recognize an object in several different ways at the same time. Candidate Pawn Object

Not a Pgwn Object

concept label

extension

Figure 1. Set membership (the extension) is determined by the concept's definition (the intension). CLASSIFICATION When we determine that a concept applies to a specific object, the object is classified as a member of a specific set. In this case, the set membership is increased by one object. When an object is declassified, it is removed from a particular set—thereby decreasing the set size by one.

195

Chapter 12

Figure 2. A set can have many objects; an object can be a member of many sets. Figure 3 portrays the object Jane classified and declassified in terms of the Employee set. At some point in her life, Jane was first classified as an Employee. Later, through some process, Jane was declassified as an Employee and she became unemployed. At another point, Jane may become reemployed, followed again by a period of unemployment. Such Employee-related behavior can continue until a time or decision for retirement is reached, or object termination takes place. Specifying the method of these classification changes is a technique at the very heart of OO process specification.

f Employee f I set (

\ Xi

] PropertyN Owner )

Figure 3. The Jane object moving in and out of the Employee and Property Owner sets over time. IMPLICATIONS OF OBJECT LIFECYCLES Additionally, Fig. 3 indicates that Jane acquired a pet and became a Property Owner. Later, she sold the property and was removed from the Property Owner set. Figure 3, then, depicts an object in terms of only two set memberships. However, the Jane object can be classified and declassified in other sets over time. At the age of 18, she changed from the set Girl to the set Woman. At some point, she may get married and be added to the sets Married Person and Wife. In her lifetime, Jane may be a member of several sets and, on many occasions, change her set membership. In other words, an object can have multiple concepts that apply to it at any one moment. Such a phenomenon is called multiple classification. Additionally, the collection of concepts that applies to an object can change over

Dynamic and Multiple Classification

196

time—a phenomenon called dynamic classification. Both multiple and dynamic classification are alien to traditional I.S. practice. In traditional I.S., the data in a record can be obtained only by its one record type, or file. Most OO programming languages are similarly restrictive. Here, except for the superclasses in the object's inheritance hierarchy, an object can be an instance of only one OOPL class for life. To change its class, a new object must be created to replace the old one. (Odell [M096] suggests several other techniques for implementing multiple and dynamic classification in object-oriented implementations.) However, in OO analysis, we are not modeling how computer languages and databases work, we are analyzing the enterprise world as people understand it. In this way, we can achieve an understanding that applies to—but is not limited by—data processing. REFERENCES [M095] Martin, James, and James Odell, Object-Oriented Methods: A Foundation, Prentice-Hall, Englewood Cliffs, NJ, 1995. [M096] Martin, James, and James Odell, Object-Oriented Methods: Pragmatic Considerations, Prentice-Hall, Englewood Cliffs, NJ, 1996. [Q87] Quine, W. V., Quiddities: An Intermittently Philosophical Dictionary, Belknap Press, Cambridge, MA, 1987. [W10] Whitehead, Alfred North, and Bertrand Russell, Principia Mathematica, Cambridge University Press, Cambridge, 1910.

13 SPECIFYING BUSINESS POLICY USING AGENT-CONTRACT META-CONSTRUCTS John Palmer Integration Services IBM Consulting Group Rt. 9, Town ofMt. Pleasant North Tarrytown, NY 10591 john_palmer@ VNET.IBM. COM

Abstract Business policy is a set of rules, regulations, invariants and definitions that govern the behavior of an enterprise. It is typically formulated by business people and formalized by lawyers. Business policy is often written down. However, much policy exists only in the memories of those who work for or with an enterprise. Still other policy is embedded in the code of enterprise software systems. Solution developers have long realized that software is a means of promulgating and enforcing business policy. Without a correct or complete understanding of that policy, software will not function as required by the business. In addition, software that indiscriminately mixes policy and technology is difficult to maintain and reuse. Finally, as the only place where much business policy is documented, software commonly becomes de facto policy. For all of the importance of business policy to behavior in general and software in particular, it is curious that most businesses have no formal business policy management processes. It is ironic that the haphazard business policy management that is done is almost untouched by automation. A new meta-model dubbed the "agent-contract" meta-model was created recently by the IBM Consulting Group in collaboration with several of IBM's industry solution

198

Chapter 13

units. This model was created as a means to integrate of IBM's existing and future industry models. During the development process, it became clear that this metamodel would also provide direct support for business policy analysis and management. This essay describes the major concepts in the meta-model and connects the work to the growing rules/invariants movement within the object community. A partial problem statement Over the last twenty years, a number of "paradigms," ways of structuring an understanding, have been the basis for business modeling methods. These paradigms include: function decomposition - whole-to-parts decomposition of business functions data/control flow - business function decomposition along with the information and control flows that connect them entity-relationship - things about which the business gathers, tracks and remembers information along with the associations between those things object-orientation - the set of objects that integrate the information requirements of a business with its behavioral requirements While business models have been built with each of these paradigms successfully, none of them has succeeded as a direct specification of business policy. A major reason is that these business analysis paradigms are typically biased by software technology. Top-down decomposition of business function was supposed to lead seamlessly to the top-down decomposition of modules in 3GL software. Structured analysis, as introduced by Douglas Ross, was originally intended to show the connection of a function to the agent executing that function and to resources consumed in the process. Entity-relationship analysis focused on the structure of information that would be retained in a database. Object-oriented models are supposed to lead seamlessly to object-oriented enterprise software. Technology bias in business modeling is largely the result of an unspoken arrangement between business people who sponsor software development and software developers. Business people typically want a minimal involvement with software development. Software developers want the minimum of deliverables between business requirements and code. As a result, developers are commonly allowed to dictate the terms and terminology of business modeling methods. With clear connections to implementation technology, developers know they can more easily derive software designs and ultimately code. Business people either learn to

Specifying Business Policy Using Agent-Contract Meta-Constructs

199

deal with technological bias or validate commentary made about the model rather than the model itself. This arrangement has produced positive results. Model-based development is increasingly replacing the code-and-go approach. Technology bias helps sell design and modeling to developers. For example, relational bias helped data and database administrators see value in entity-relationship modeling. Biased methods facilitate the adoption of a "new" technology. Developer interest in and ability with object technology has accelerated with the increasing robustness of object-oriented analysis and design methods. There are also problems with technology biased methods. While the degree of damage varies with each method, all commonly used analysis and design methods have problems dealing with business rules. These problems include: camouflage - neither input, process and output specifications nor method implementations nor graphical connectors between entities or objects are direct expressions of business rules. Rules are either expressed through the processes that enforce them, narrative data structure definitions or graphical symbols. omission - technology bias makes it more likely that rules will be omitted. In order to validate the completeness of a policy specification, policy analysts have to interpret and interpolate rules from an indirect representation. Top-down functional decomposition, by itself, omits all of the rules that would be specified, albeit indirectly, in an entity-relationship model. fragmentation - all of the paradigms result in a fragmented specification of rules. Fragmentation can occur at the paradigm level as with the function decomposition, data/control flow and entity-relationship paradigms. It can also occur between views within a paradigm. In the object paradigm, rules are divided between the static and dynamic view of the object model. In addition, rules "involve recognition of data patterns that occur across many objects, often several links apart in an object model net."[B95] Technology bias in business models should help connect business modellers with software developers. However, it blocks communication between business people and developers. As a result, many business rules are never found or properly specified. Other business rules are accidentally discovered during later development phases. It is frightening to think that business policy is often invented by programmers and designers. Often the omissions are unnoticed until the software testing phase. In any case, business rules end up encrusted in software and therefore made inaccessible to future development efforts. For most corporations, the policy manual has been transformed into a tangle of COBOL or nowadays C++ or Smalltalk.

200

Chapter 13

Business policy specification problems make business evolution significantly more difficult. Since application software becomes a de facto business policy manual, any change in business policy requires significant expenditure of developer and technician resources. Since policy is often intertwined with software technology, significant policy analysis work must be done whenever software technology changes. To expedite effective business evolution, business policy and technology must be separated to the greatest degree possible. Ideally, there would be no connection between these two critical elements of a business. As an example, word processing technology changes have minimal impact on the content of a document. At the same time, the content of a document can be changed with very little regard for the technology used by the word processor. In order to reach this state of separation, three problems must be solved: technology neutral policy specification - the concepts used to analyze and specify business policy must be as free as possible of the influence of current software technology. Put another way, business policy must be expressed from the business person's perspective[R95]. policy specification rigor - business policy specifications need to be rigorous enough to be able to predict business and software behavior without the need to write application software. ability to communicate to technicians - technicians should be able to view a business policy specification with whatever technology bias they are comfortable with. automatic mapping - translation software should be used to convert business policy into a form compatible with a policy-neutral run-time environment. This environment should be capable of implementing enterprise and network-centric systems. Performance tuning and other system management capabilities should be built into this environment. Proof-of-concept tests of the agent-contract meta-model show it to be capable of achieving these goals. The greatest difficulty lies in adapting the variety of technologies in use today to a true business rules "front-end." In the worst case, the business rules specification could be translated into a the products of existing object methods as a temporary approach to this problem. Major concepts in the agent-contract meta-model From "functions" through "entities" and now with "objects," meta-models have focused on concepts used by business modellers to do their work. The agent-contract

Specifying Business Policy Using Agent-Contract Meta-Constructs

201

meta-model adds "Agents," "contracts" and "declarations" to this list of basic method concepts. It also identifies enterprise subject matter domains that these concepts can be used to understand. This section presents each of these basic concepts. Subject matter domains Agent-contract concepts can be applied to three basic subject matter domains: business - business policy and business processes, both logical and concrete, are included in this domain. application - business policy and process can be allocated to software technology for implementation. Within that context, both logical and technological perspectives can be taken. technology - policy and process associated with how people and software implement business processes independent of the business processes themselves. These subject matter domains are connected in what could be called a "ying/yang" structure. That is, opposing, but connected perspectives. Technology knowledge common to all businesses and business knowledge independent of technology are the connected opposites. Either of these perspectives is the result of "abstracting out" knowledge associated with the other perspective. The common ground for the ying and yang perspectives is the application domain. The word "application" in this context refers to the application of automation to solve a business problem. A software application can be viewed from either a policy or a process perspective. It can also be viewed from a software design perspective or a run-time process perspective. In any case, business and technology knowledge come together in this domain. Domains can contain other domains. Within the business domain, there are two major sub-domains: business policy and business process. The business policy domain is defined by the following principles: technology/resource independence - business policy is expressed in natural language. Objects exclusively associated with the implementation of business policy by people or computer technology are not found in business policy. information orientation - business policy is expressed in terms of informational statements. It is not expressed as imperatives or commands to agents. internal sequence neutrality - business policy is often specified by procedures or sequences of either imperative statements or message-object expressions. An agent-contract specification states actions that can result from a particular event

202

Chapter 13

and a set of pre-conditions. Connections between the post conditions from one event and pre conditions for another are not explicitly stated. automatic instance identification - business policy specifications do not specify the either rules or processes for identifying a particular object instance. The business policy domain consists of three sub-domains: invariant - policy in this domain must always be true across all business events situation - policy in this domain consists of a set of business event specifications. Each business event specification specifies the transition from one situation to another. contractual - policy in this domain package invariant and situation policy into contracts that define the interactions between agents Agents The term agent has a long and useful history in both business and software worlds. It has been used in a variety of object-oriented methods including Booch, Fusion and ROOM[SGW94]. Software agents are becoming common in application software as well. Both through the Internet and through "office suite" software, agents - also known as wizards and assistants - are becoming as common as icons in a GUI. In fact, one of the biggest problems with the term "agent" is its association with the insurance and professional sports businesses. Insurance agents are infamous as persistent and persuasive salespeople. Professional sports agents are infamous for negotiating team-breaking, fan-aggravating compensation plans. In the agent-contract meta-model, the agent concept is more than a generic class of software object. It is any real or imaginary thing empowered to play a role on behalf of a person or group of people. Agents are animated by processors or actors that have the following abilities: learning - an actor has to be capable of acquiring a specification of the actions required in a given situation. People can listen to or read statements of business policy. Computers can "learn" through their programming. information processing - an actor has to be able to interpret, remember and create information. It is important to remember that information in this context is not data as in sets of values. Information in this context is a collection of "infons." An "infon" is a semantic object that is an n-place relation, with objects appropriate for the argument places of the relation and an "polarity value" that indicates whether the infon is true or false[D91].

Specifying Business Policy Using Agent-Contract Meta-Constructs

203

acting - an actor is capable of acting. The action can be viewed as being instantaneous or have some time duration. By this definition, software objects, individuals and groups of people doing a job, hard-wired and programmable devices can be the processor or actor component of an agents. A role is defined by a set of responsibilities. Responsibilities are functions that that the agent will and must perform. There is a spectrum of creativity associated with how an agent satisfies its responsibilities. With some, like increase market awareness or decrease claim processing time, the agent will have to create and execute a plan for responsibility fulfillment. Other responsibilities, like taking customer orders and checking guests out, can be specified precisely enough to be automated. Many methods use the term "role" or actor instead of agent. OOram from Reenskaug et al[RWL96] makes extensive use of "role objects." The Harrison et al [HKOS96] notion of dynamic supertypes might also be confused with the notion of agent. As long as there is agreement on a common definition for these terms, it is not necessary to legislate "agent" as the exclusive or primary name for the concept. However, in common usage, the concepts of actor and role are not interchangeable. An actor plays a role and can play many roles over time. A role can be played by many actors. When playing the role, an actor is "in character." The agent concept subsumes both concepts. An agent is an actor playing a role. "Agent" is one of a number of commonly accepted software object categories. Information hiding modules and data structures led to the first major object category: abstract data types. Data modeling techniques introduced the entity, relationship and attribute object categories. Jacobson's Object-Oriented Software Engineering (OOSE) added two more object categories: control and interface objects. There is growing interest in "role" objects and dynamic supertypes. The Internet is popularizing "agents" as an software object category. Agents are related to other agents in four ways: subtyping - one agent can be the subtype of another agent. For example, a stock broker is a specialization of the more general broker agent. collective identity - a collection of individual agents can be thought of as an agent. For example, a collection of customer service representatives can be considered collectively as "customer service." incarnation - one or more agents can be used to implement an agent. For example, several software objects, each considered to be agents in their own right, can be used to implement an automated agent that processes insurance

204

Chapter 13

claims. Together, a claim data entry clerk and the automated claim processing agent implement the abstract notation of a claims agent. interaction - agents interact with each other. Customers interact with stock brokers. A number of concepts ~ control, event, data and message flow and collaboration ~ have been used to specify agent interaction. The contract concept in the agentcontract model supplements these concepts. Within the domain of business policy analysis, the contract concept has a special part to play. Contracts The contract concept has an even longer history than "agent" in both the business and the software engineering worlds. In fact, the history of the contract in the business world is far too big a subject to be covered in this space. In recent memory, Bertrand Meyer's programming by contract approach uses a contract concept. It also acknowledges the connection between software engineering and human contracts [M94]. In the agent-contract meta-model, there are two basic types of contracts. Both specify policy governing the interaction between two or more agents. Agent-to-agent contracts specify all interactions among a set of agents. Event-response contracts specify all interactions among a set of agents associated with a particular interaction initiating event. Here is an example of an agent-to-agent contract with the Molybdenum Credit Card Co. and a Molybdenum Card Holder: Contract Between: Molybdenum Card Holder and Molybdenum Credit Card Co.(MCC) Relevant definition declarations: Line of Credit is a type of Card Holder Account In Good Standing is a state of Card Holder Account Line of Credit Amount is a characteristic of Line of Credit

Specifying Business Policy Using Agent-Contract Meta-Constructs

205

Event-response specifications from the Card Holder's perspective: Event: MCC sends invitation to apply for Line of Credit Event "Before" Conditions: Card Holder Account is In Good Standing Event "After" Conditions: Line of Credit Amount is specified Conditional Response Event: Card Holder applies for Line of Credit Event: MCC changes Credit Limit of Line of Credit Event "Before" Conditions: Line of Credit exists Event "After" Conditions: Credit Limit of Line of Credit is specified, Effective Date is specified, Credit Limit Change Notification is forwarded Conditional Response Event: None Event: MCC issues Monthly Statement Event "Before" Conditions: Line of Credit exists, Billing Period is expired Event "After" Conditions: Starting Balance is specified, Closing Balance is specified, Payments are specified, Credit Requests are specified, Minimum Payment Due is specified, Interest Owed is specified, Fees are specified, Line of Credit Status is specified Conditional Response Event: Card Holder makes Payment Event specifications from MCC's perspective: Event: Card Holder applies for Line of Credit Event "After" Conditions: none Unconditional Response "After" Conditions: none Conditional Response "After" Conditions: Line of Credit exists Response "Before" Conditions: Card Holder sent Line of Credit Application, Card Holder Account is In Good Standing, Card Holder Credit Limit is specified

206

Chapter 13

Event: Card Holder access Credit Line Event "After" Conditions: Credit Request Exists, Credit Request specifies Credit Request Amount Unconditional Response "After" Conditions: none Conditional Response "After" Conditions: Credit Request is Accepted Response "Before" Conditions: Credit Request Amount is greater than Minimum Credit Request Amount, Line of Credit Account is In Good Standing, Credit Request Amount is less than or equal to Credit Available Event: Card Holder makes Payment Event "After" Conditions: Payment Amount is specified Response "Before" Conditions: none Unconditional Response "After" Conditions: Line of Credit Balance is decreased Conditional Response "After" Conditions: Line of Credit is In Good Standing Response "Before" Conditions: Line of Credit is Delinquent, Delinquent Payment time period is in effect, Payment Amount is greater than or equal to Delinquency Amount Conditional Response "After" Conditions: Line of Credit is Closed Out Response "Before" Conditions: Line of Credit is Canceled, Delinquent Payment time period is in effect, Payment Amount is greater than or equal to Line of Credit Balance Field experience so far indicates that a single contract format is probably too cumbersome and limiting across all engagements. However, all contract-based policy specification work to date has used some combination of invariants, events, pre and post conditions. Contracts are often assumed to be nothing more than an alias for "use case." The many interpretations of the use case concept complicate the discussion of differences between the two ideas. In brief, however, the differences revolve around these issues: degree of encapsulation - contracts specify agent interactions from an exclusively external perspective. Some definitions of use case do as well. Other use case models show the internal message flow necessary to satisfy an agent's contract[S95].

Specifying Business Policy Using Agent-Contract Meta-Constructs

207

declarative vs. procedural - contracts specify agent interactions from a declarative perspective. They specify both situations and the events that cause transitions from one situation to another. Use cases often specify sequences of actions that an agent carries out. That is, they are process specifications. generic contract types - as mentioned earlier, agent-contract uses two basic types of contracts. In use case modeling, is no explicit distinction between agent-toagent and event-response use cases. Use cases are typically viewed to be eventresponse in scope. Even if use cases and contracts are exactly the same concept, there is still need for the term contract. It will be some time before lawyers write use cases for their clients or rock stars fight to have their use case re-negotiated. Software technology lay people already have perfectly good words for the use case concept and one of those words is contract. Declarations The invariants, events and before and after (pre and post) conditions that make up a contract are all instances of the meta construct declaration. Declaration is a type whose attributes of information correspond to the elements of a relatively simple sentence type. Each declaration will have a subject and a predicate (in the grammatical sense of the word). The subject is the "thing" that is being described by the declaration. The predicate is the part of the declaration that says something about the subject. Predicates consist of a verb or verb phrase, an optional verb complement and an optional prepositional phrase. A verb phrase consists of a verb — an assertion about the subject ~ and auxiliaries (like the "a" in "is a"). A verb complement is a word, typically a noun, that completes the meaning of the verb or verb phrase. A prepositional phrase consists of a preposition, a prepositional object and its modifiers. Nouns that name objects play the role of subject, verb phrase object and prepositional object in a declaration. The declaration type is the root node of a generalization-specialization hierarchy. The three subtype of declaration are: definition declarations - declarations that will hold true across all situations covered by a contract. In some methods and meta-models, these declarations are called invariants. Here are three definition declarations: Engine is a Part of Vehicle, Total is the sum of all Order Item Subtotals, Student Population is count of Students. condition declarations - specify special states that result because of business world activity. Here are three condition declarations: Person purchased many

208

Chapter 13

Stock Shares, Book copy is overdue and Available Quantity is less than Reorder Quantity. event declarations - identify state transitions from an existing situation to a new situation. Event declarations can represent situation transitions that are either within or beyond the enterprise's control. An action performed by one agent is viewed as an event by other agents. Here are three event declarations: Person purchases many Stock Shares, Project Team Member becomes Project Manager and Loan Repayment begins. There is a very close resemblance between the declaration constructs and NIAM (Nijssen's Information Analysis Methodology). To paraphrase NIAM's basic philosophy, a contract specifying agent interaction policy consists of a selected set of sentences from natural and commercial language. As with NIAM, the agent-contract meta-model is designed to involve business people directly in the business policy analysis process.[BK83] Unlike NIAM, sentences do not have to be mapped into sentence graphs or diagrams. Instead, the sentences themselves can be viewed directly. Agent-contract also departs from NIAM by providing both a simplified grammar and a fixed set of declaration types. Many of these declaration types have been derived from a variety of object and data modeling meta-models. Others were derived from procedural and function programming language constructs. By supporting the specification of both data and functional relationships, the declarative perspective takes a page out of Prolog. Unlike object languages, prolog has no special syntax for specifying data and function. Both are expressed by Prolog predicates. Of course, since natural language came first, it may be more appropriate to say that Horn clauses took a page out of the declarative style of human communications. Declaration instances can be organized into extended semantic networks [K79] Declaration objects can be mapped to nodes while the verb phrase in the declaration can be mapped to arcs that connect nodes. However, a semantic network of declaration instances is not the same as the declaration portion of an agent-contract policy model. In the declarative portion of the agent-contract meta-model, each declaration is an instance of a specific binary or n-ary relationship type. The declaration portion of an agent-contract meta-model is only meaningful when the logic at the meta level is instanced with the specific policy of an enterprise. A semantic network of declaration instances is substantially a replication of the logic that exists within and between these types with the specific terminology of a business policy domain. As such, it is a "front" or a "puppet government" for the real logic in the policy.

Specifying Business Policy Using Agent-Contract Meta-Constructs

209

A semantic network could be created that combines both declaration types and instances. However, only the instance portion of that network would be unique to the policy being represented. The type portion of this combined type-instance semantic network would be a set of arcs and nodes that could be reused to build any policy network. This reusable semantic network is the difference. Declaration types represent large semantic network chunks that can be reused across different business policy analysis engagements. Without the declaration types and their logic, a semantic network modeller is doomed to reinvent them every time. The Kilov and Ross [KR94] concept of generic relationship types and the invariants associated with these types are a significant part of what I've called the meta level logic that connects declaration types. The agent-contract model adds meta level logic for object value and state maintenance. It is probably safe to say that more meta level logic will be found. However, no serious reuse effort can afford to ignore the high reuse leverage present in meta-level logic in general and generic relationship types in particular. Objects Every declaration contains objects in the grammatical sense of the word object. There are verb objects and prepositional objects in many declaration types. The nouns that occupy these grammatical positions come either from the language of the business ~ customer, interest rate swap, trouble ticket --, from a built-in set of nouns that are part of the agent-contract meta-model -- sub type, equation, role - or from nouns introduced by policy analysts to deal with commonality between client supplied nouns. (For example, the noun "vehicle" might be added by an analyst to deal with commonality between train, plane and automobile.) Declarations contain nouns that express the concept of an object. They do not contain the object itself. The objects represented by the nouns in agent-contract declarations are assumed to have identity, but are not required to encapsulate technology or be capable of acting. This is the common usage definition of object. In this context, an object is a real or imaginary thing. Unfortunately, this perspective on objects is sometimes often viewed to be at odds with the definition of object used by most object-oriented methods. The agent concept provides two ways to reconcile this issue: everything is an object and all objects are agents - if all objects are agents then they are all associated with a real or imaginary actor that gives them the ability to act. In the real world, an object's ability to act may not be natural. For example a plain cardboard box is incapable of taking action. However, attaching a transponder to the cardboard box would create a "smart" box that can identify and transmit its location. Ultimately, technology in the form of transponders or

210

Chapter 13

object-oriented programming languages is required to make this position on agents and objects rational everything is an object, some objects are agents - with this position a dumb box is an object, but it isn't naturally an agent because it can't act. A "smart" box can be viewed as an agent. Since agents are a type of object, a "smart" box is also an object in the non-technological sense of the word. In both cases, software objects are viewed as being capable of taking action. From an agent-contract perspective, all software objects are agents animated by a computer or computer network. Neither one of these views is clearly better than the other. The first view can be artificial to non-technicians. However, it appears to have great value to objectoriented solution developers. As a result, there are potential time-to-market and software cost reduction benefits that justify the artificiality. The second approach is less connected to a software solution technology. However, as mentioned earlier, solution technology bias can decrease the effectiveness of business policy analysis. At present, the best approach seems to be using both perspectives in the appropriate context. Issues raised by the agent-contract meta-model Many acknowledged authorities in meta-models, development tools, systems development methods, object technology and business transformation have commented on agent-contract concepts. Certain issues are raised repeatedly. The positions developed on these issues help clarify agent-contract concepts. They also help define the terms of the debate with respect to rules, invariants and declarations as the basis for business policy analysis. A complement to Flores and Winogradperspective Agent-contract concepts are often viewed to be an extension of work of Flores and Winograd[FW87]. Given the impact of Flores and Winograd on both the AI and software engineering community, there is no doubt that a strong connection exists. However, there is a substantial difference between the agent-contract and the Flores and Winograd perspective. The difference stems from, again, a sort of technology bias. Flores and Winograd, ROOM and Alan Scherr [S93] all deal with the nature of agent interaction. However, to a greater or lesser degree, these works view interactions as information and control exchanged within a communications channel. This perspective is clearly valuable and necessary, especially for software engineering. ROOM in particular provides a very rigorous method based on this point of view that includes a Flores and Winograd interpretation of the contract concept.

Specifying Business Policy Using Agent-Contract Meta-Constructs

211

ROOM agents communicate "messages" to each other through either imaginary or real channels. A "protocol" is a set of messages along with information about the direction of the message, valid message sequences and expected quality of service. "In essence, a messaging protocol is like a contract that constrains the behavior of both parties in a communication." In fact, the ROOM concept of a contract is "a binding and the two interface components that it connects." A variety of business process modeling approaches also use the Flores and Winograd perspective. SADT, structured analysis, LOV-EM/Cabe and essential systems analysis either directly or indirectly subscribe to this point of view. In each of these meta-models, a communications channel is assumed. That communications channel is used to communicate some combination of data and control flows. Alan Scherr's approach to business process analysis also takes the Flores Winograd "communication channel" perspective. To Scherr, transactions communicate intent lead to commitments made by the communicating agents. example, a customer applies for a loan; a bank may commit loan money to customer; the customer commits to pay the money back.

and that For that

These transactions and their communication are clearly important. Even more important are the definitions of those transactions. However, it is trivial to show that the same declarations that define the structure of a database also define the structure of transactions. Both transaction and database designs must implement the declaration Purchase Order has many Purchase Order Items. It is possible and in many situations useful to think of declarations independent of how they will be captured in either a transaction or database structure. Therefore, beneficial as it may be, the Flores and Winograd model is not an absolute analysis perspective. In addition, the Flores and Winograd/Scherr perspective is that of agents in the process of doing business. The customer is applying for a loan; the bank is approving the application. The agent-contract approach adds the idea that transaction definitions can be stated from an a priori perspective. A contract would say or imply "when" a customer applies for a loan and "when" all of the necessary conditions for granting a loan have been met. Within the context of business specification, contracts view transactions before they happen; the Flores and Winograd school views transactions as they are happening. The a priori or "before-the-fact" perspective is especially important when "new" policy is being formulated. Wall Street is always creating new investment vehicles. Beyond the policy specification associated with this work, significant effort will go into defining the transactions associated with a business system that will support those vehicles.

212

Chapter 13

The "before-the-fact" perspective is also important to a group of typically business people who understand their business processes from a "situation" perspective. These people are concerned with the "before" and "after." They assume there will eventually be a transactional system that will detect situations and track them over time. Contracts in the business world have long been used to specify a "before-the-fact," "situation" perspective to business transactions. This perspective is also taken by both Syntropy and Meyer's programming by contract. The agent-contract approach also provides support for this perspective. Situations can be expressed as a set of conditions. Invariants detail conditions that must be true in any situation. Event specifications detail the transition from one situation to another. Agents are responsible for dealing with situations and in the process, create new situations. The situation-oriented contracts in the agent-contract approach link situations with the agents that bring them about or communicate them. These contracts also deal with the situation linkage between agents. That is, a situation created by one agent causes another to create a situation in reaction. The agent-contract meta-model acknowledges both the Flores and Winograd and the "situation" perspectives on interacting agents. In addition, a significant amount of work has been done to formally establish the linkage between these two perspectives. The existence of multiple, complementary perspectives or paradigms is a central principle of the agent-contract approach. Reversing representation priorities Over the last twenty years, many methods have claimed to be business policy analysis and specification methods. These include entity-relationship analysis, structured analysis, and object modeling. As different as these methods are, they all have something in common. Each method advocates the creation of a graphical model of all or part of the business that the business policy is associated with. These models take the perspective of business processes (structured analysis), informational entities (entity-relationship) or interrelated objects (object models). Business policy is specified partially by graphs and by free-form narrative text that describes elements of the graph. This "picture is worth a thousand words" philosophy has been both a wild success and an abject failure. Graphically oriented modeling has changed the way business processes evolve. Once business process reengineering was equivalent to programming. Graphical modeling has introduced and supported several higher levels of abstraction to business process reengineering (BPR.) Model-based BPR and software development is the great success of graphical approaches.

Specifying Business Policy Using Agent-Contract Meta-Constructs

213

Unfortunately, most graphical systems are not designed to capture all aspects of business policy. Those that try quickly prove that graphs reach a point of diminishing returns[P95]. On the other hand, few popular modeling approaches provide even a semi-formal language for specification policy that can't be specified in a graph. As a result, this policy is usually omitted from the model. Eventually, the omitted policy must be specified. This occurs in earnest during detailed design and programming. Policy ultimately does end up specified in a formal language. However, those languages are more commonly known as programming languages. It is safe to say that code is an inadequate way to document business policy. From a business person's perspective, code is literally written in a foreign language. The agent-contract philosophy is biased towards text. The goal is to provide as much completeness, consistency and rigor to business policy specification. Graphs can be used to provide an abstract representation of or an index to business policy. Automation will be used to help an analyst move between graphic and textual representation. By reversing the prevailing perspective, analysts are not locked into a graphical approach. Instead, either form of representation can be ,used as is appropriate. Expanding meta-model focus Most meta-models focus on documenting the results of business policy analysis. This is the result of two factors: construct-process gap - most model-based processes are expressed at a very high level of detail. As a result, it is often unclear how to systematically manipulate meta-model constructs to get the "right" model. On the other hand, the notion of documenting results whether good or bad is very clear. So most CASE tools and therefore meta-models were designed around the role of documenting results. CASE tool technology bias - meta-models were first created as specifications for repositories accessed by CASE tools. These repositories where typically implemented with flat files or relational databases. With logic programming or object-oriented capabilities, meta-modellers might have gone beyond models that could only remember policy analysis work. Without that technology, metamodels never got beyond the data model perspective. The agent-contract meta-model goes beyond specifying constructs that capture business policy. It includes concepts that support policy evaluation, issue identification, issue resolution, reuse and translation. Here's how each of these areas is supported:

214

Chapter 13

policy evaluation - guidelines exist to help evaluate business policy for both consistency and completeness. For example, if policy analysts claim that an object like Insurance Policy both has attributes and can be assigned values, there may be a problem in understanding what an Insurance Policy really is. policy extrapolation - policy analysts are typically able to extrapolate additional business policy from what they have specified at any point. Some of this expertise has been captured in the agent-contract model. For example, upon finding the declaration "Checking Account becomes Overdue," the declaration "Overdue is a state of Account" can be extrapolated. policy issue management - the agent-contract meta-model defines constructs so that inconsistencies, potential omissions and potential extrapolations of policy can be captured and tracked. The meta-model also deals with the resolution of these policy analysis issues. policy reuse - the meta-model defines constructs so that instance reuse can be tracked. For example, when the declaration "Customer purchases goods" is reused, all of the domains it is appropriate for can be identified. policy/technology translation - while older business policy analysis approaches are technology biased, they describe valid perspectives that many analysts will take. The agent-contract meta-model contains mappings so that business policy can be converted with minimum "signal loss" from one perspective to another. By supporting all of these capabilities, the agent-contract meta-model becomes a "smart" meta-model. Given the volume of business policy for an enterprise and the variety of perspectives that must be accommodated, there is no alternative. Only additional automation of both product and process will support the large-scale efforts that enterprises are already forced to undertake. Commonality management Commonality is commonplace. In business policy, the same words, sentence fragments and sentences are repeated over and over in different combinations. Even after allowing for unnecessary repetition resulting from mistakes or lack of team coordination, commonality across business policy is a fact of life. This commonality must be managed and ideally minimized. Commonality control will prevent integrity problems associated with inconsistent updates to duplicate requirements

Specifying Business Policy Using Agent-Contract Meta-Constructs

215

minimize the information transfer necessary to validate requirements. This, in turn, will make missing or incorrect requirements easier to identify. maximize policy reuse instead of policy re-creation Commonality issues exist with each of the major constructs in the agent-contract meta-model. Therefore, there are features with these major constructs that deal with commonality: contract commonality management - subtyping contracts, maintaining declarations independent of the contracts they are used in and remembering which declarations are unique and which are reused all help minimize the problems of redundant declarations across contracts declaration commonality management - maintaining declaration vocabulary independent of the declarations themselves, retaining reusable declaration fragments and virtual declarations are the aspects of agent-contract that deal with commonality across declarations. (Virtual declarations are declarations that can be deduced from other declarations.) object commonality management - generic objects, duplicate entry blocking and aliasing help prevent and control object duplication during business policy analysis. In addition to commonality management at the construct level, the agent-contract meta-model supports commonality management across policy domains. Domain commonality management is accomplished by keeping a list of the domains a contract, declaration or object is common to. For example, it should be possible to find the declaration "Line Item is a part of Purchase Order" in both the shipping and purchasing functions within an enterprise. That commonality might extend to a number of enterprises. The list of domain involvement for that declaration would include all enterprises and the domains within each enterprise. Business process analysis The relationship between business policy and business process is a crucial issue in business evolution. Business policy is implemented, enforced and promulgated by business processes. Business processes, especially essential processes - business processes independent of the technology used to implement them[MP84] - are critical to evaluating a business policy specification. In addition, much business policy has to be abstracted from an analysis of both essential and incarnation business processes. Each of these aspects of the relationship between policy and process deserves significant discussion. Here are some thoughts that have surfaced so far.

216

Chapter 13

Business policy is implemented in business processes in two basic ways: dynamic procedure - both human and software agents are able to create a process for enforcing policy "on the fly." This approach is desirable because it eliminates the need for process specification. When the potential process associated with enforcing policy is simple, this is especially valuable. On the "down side," many people can only evaluate business policy as it appears in process descriptions. In addition, when policy is complex, it is easy to create a process that fails to fully enforce that policy. Dynamic process creation greater increases this kind of enforcement risk. static procedure - it is more common, especially for software agents, that the process of enforcing policy is a set, static sequence of instructions or message passes. Static procedures can be easier to evaluate. The reviewer can imagine themselves "following the cook book" and assess whether the right behavior is called for. In addition, static processes can be implemented more efficiently. The time taken to decide the next step in a sequence is eliminated. Unfortunately, rigorous procedural specifications are time consuming to write, voluminous in content and difficult to maintain. The agent-contract approach was designed to begin to resolve these two perspectives. The declaration types and their relationships are such that "first cut" logical process descriptions can be generated automatically. These process descriptions can be used to validate business policy without the time and maintenance associated with static process descriptions. Many significant policy/process issues remain to be dealt with. These issues include: policy reverse engineering - both procedure manuals and procedural code are a rich source of business policy. Policy analysis quality and efficiency can be greatly improved by expanding the capabilities and use of business rules recapture technology. policy allocation - in designing a real business process, policy must be allocated to a network of enterprise agents. While there is no question that this work is done somehow, it is also clear that it can't yet be described clearly. Even bigger than those issues is the need to introduce the business policy domain as a valid analytical perspective. To many people, business analysis and business process analysis are one and the same. A significant amount of consciousness raising will be necessary to make these people aware of an additional business analysis domain.

Specifying Business Policy Using Agent-Contract Meta-Constructs

217

Implementation in software Business policy specified using the agent-contract approach can be implemented either directly or indirectly. Expert system shells and Prolog provide evidence that declarations can be directly implemented. On the other hand, business policy is commonly translated into assembler, COBOL and C++ and into DL/1 and SQL. Logic languages like Prolog show both the advantages and disadvantages of direct implementation of business policy. The big advantages are improved time-to-market and reduced development and maintenance costs. The disadvantages have to do with the novelty of the languages. Without a pool of interchangeable designers, programmers and maintainers, it is hard to justify using logic languages. As a consequence, middle-ware and infrastructure developers will not develop software that would allow logic languages to deal with large-scale enterprise-wide applications. A significant amount of work takes place to translate business policy into 3GL, 4GL and object languages. Declarations are turned into procedures. They are also packaged into fixed groupings or structures like class definitions. All traceability between policy and code is typically lost in the translation. A compromise option is extending commonly used languages with declaration processing capabilities. Throughout the years, individual development teams have stumbled on this option for implementing policy. Table-based processing of business rules has been used almost as long as there has been COBOL. Southern California Edison extended CICS with their Generalized Architecture. Ooxpert shows that Smalltalk can be extended to support policy-driven dynamic processes. The extension of commonly used languages would seem to eliminate the esoteric language risk. In each case, the extension option succeeded in providing at least a limited direct policy implementation capability. However, extending a commonly used language to process rules ultimately produces an esoteric language. At that point, the organization is subject to the same novelty problems that plague Prolog, LISP and CLOS. It is likely that the extension approach will not gather critical mass until a common business policy language is agreed to. That sort of standard is an important and doable step that the business policy/invariants/declarative specification community must take. Once that language exists, developers can decide which side of the business/technology line they belong on and choose accordingly. Concluding remarks Business policy analysis is clearly a "growth area" in the world of methodology. Agents, contracts, declarations, rules and invariants are part object-orientation and

218

Chapter 13

part a step beyond. In addition to the substantial technical work, there is a great deal of consciousness raising and paradigm shifting that must be done. As these new ideas evolve it is important to take the expert system, 4GL and enduser computing hype backlash into account. When introducing business policy analysis, it is inevitably likened to those technologies. "Been there, done that" is often the snap judgment. Ironically, some of the worst resistance to these ideas may come from the object community. Many in the object world were scarred by the "fifth generation's" fail from grace. While objects may not be "5GL" all the way, at least these folk can make a living working with some pretty wonderful technology. There will be many religious and technical battles in the process of introducing business policy analysis. Yet all of these battles will be beneficial. By the time business policy analysis becomes popular enough for enterprises to introduce it as a business function, the meta-models, methods and tools should be up to the job. Business policy analysis methods may be the first "new wave" of approaches that are deployed when they are well-defined and ready to provide immediate help with business evolution.

Specifying Business Policy Using Agent-Contract Meta-Constructs

219

References [B95] Todd Blanchard, Modeling Business Semantics Using Objects and Production Rules, Proceedings Fourth Workshop on Specification of Behavioral Semantics, OOPSLA '95. [BK83] J. Blank and M.J. Krijger, Editors, Software Engineering: Methods and Techniques. Wiley-Interscience, New York, NY, 1983. [D91] Keith Devlin, Logic and Information. Cambridge, UK, 1988.

Cambridge University Press,

[FW87] F. Flores and T. Winograd, Understanding Computers and Cognition. Addison-Wesley, New York, NY, 1987. [HKOS96] William Harrison, Haim Kilov, Harold Ossher and Ian Simmonds, From Dynamic Supertypes to Subjects: A Natural Way to Specify and Develop Systems, IBM Systems Journal, Volume 35, Number 2, to appear. [KR94] Haim Kilov, James Ross, Information Modeling: an Object-oriented Approach. Prentice-Hall, Englewood Cliffs, NJ, 1994. [K79] Robert Kowalski, Logic for Problem Solving. Elsevier North-Holland, Oxford, UK, 1979. [M94] Bertrand Meyer, Object-oriented Software Construction. Prentice-Hall International, Cambridge, UK, 1988. [MP84] Stephen McMenamin and John Palmer, Essential Systems Analysis. Prentice-Hall, New York, NY, 1984. [P95] Marian Petre, Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming, Communications of the ACM, Volume 38, Number 6, June 1995. [R95] Guus Ramackers, Object Business Modeling, Requirements and Approach, Proceedings Fourth Workshop on Specification of Behavioral Semantics, OOPSLA '95. [RWL96] Trygve Reenskaug, Per Wold and Odd Arild Lehne, Working With Objects. Prentice-Hall, New York, NY, 1996. [S93] A. L. Scherr, A New Approach to Business Processes, IBM Systems Journal, Volume 32, Number 1, 1993.

220

Chapter 13

[SGW94] Brian Selic, Garth Gullekson, Paul T. Ward, Real-Time Object-Oriented. John Wiley & Sons, New York, NY, 1994. [S95] Jean Stanford, Enterprise Modeling with Use Cases, Proceedings Fourth Workshop on Specification of Behavioral Semantics, OOPSLA 495.

14 ARCHITECTURAL SPECIFICATIONS: MODELING AND STRUCTURING BEHAVIOR THROUGH RULESf Carlos Paredes, Jose Luiz Fiadeiro, Jose Felix Costa Faculty of Sciences, University of Lisbon Dept. Informatics, Campo Grande, 1700 Lisboa, Portugal email: {cmp,llffgc}@difc.ul.pt

Abstract We propose an approach covering both the linguistic and engineering dimensions of the behavioral specification of reactive systems. On the language side, systems, their components and connectors, are described through CV-Nets. CV-Nets are a formal graph-oriented language which includes attributes, actions and behavioral rules based on deontic and temporal logic. It is shown how the model promotes concurrency, modularity, reusability, abstraction, and refinement of specifications. The engineering side is based on category theory as a support for (i) specialization and refinement of abstract specifications and frameworks (following a top-down tailoring approach), as well as for (ii) the modeling and composition of components and connectors (following a bottom-up construction approach).

1.

INTRODUCTION

Dealing with the increasing complexity of software systems is a tremendous challenge for systems modeling and design. This problem becomes even more critical in the presence of highly distributed systems, reacting to concurrent events in the world, and dependent on multiple and heterogeneous sources of data. Modularization and incremental development have long been recognized as fundamental requirements to tackle such complexity.

t

This work was partially supported by the ESPRIT-III BRA project 8319 (MODELAGE: A Common Formal Model of Cooperating Intelligent Agents) and the PRAXIS XXI contract 2/2.1/MAT/46/94 (ESCOLA). Carlos Paredes is a grantee of JNICT (BD/2774/93-RM).

222

Chapter 14

The motivation and support for such issues is schematically presented in figure 1. final goals

proposed support

requires explicit relationships & collaborations

incremental behavior semantics

Categories with diagrams describing constructions and dependencies. Theories with modaltemporal rules for describing behav. properties

Figure 1 - Roadmap and motivation for our approach.

Modularity and Explicit Relationships By improving modularization and explicitly describing relationships between components, we are able to improve the understanding of the system, of its overall structure, and of dependencies among its components. Modularization has deserved considerable attention, but the need to also formalize interconnections and relationships has only been recognized more recently (e.g. [HHG90], [KR94], [AG94] and [GP95]). This problem becomes particularly critical in what concerns the behavioral aspects of systems. The importance of this problem is reflected on the research efforts on software architectures [GP95], object-oriented application frameworks [Joh93], and design patterns [GHJV94], which, to a large extent, try to provide the means for understanding and specifying connectors, relationships and collaborations among the components that make up the system and that induce some of its key properties. Adaptability and Incremental Development Object-oriented application frameworks (OOFW) are an example of a good approach to systems development and reuse in-the-large, that would benefit from models that describe explicitly and rigorously the collaborations among components, as well as the rationale of those collaborations. Such models must not only cover the high-level (incomplete or abstract) specification and architecture of the system, but also its refined and detailed (executable) specification. Framework-based development in particular [Joh93], and software adaptation and evolution in general, would benefit from a formal support for the smooth adaptation and extension of systems behavior, which often can be adequately described through behavioral rules, instead of having to rely on the reconfiguration or redefinition of complete methods (actions) at the, rather complex, implementation level of OOFWs.

Architectural Specifications: Modeling and Structuring Behavior through Rules 223

Selecting a Behavior Model for Incrementality and Interconnection Taking into consideration the need for supporting highly distributed and concurrent systems, we follow an object-oriented, reactive systems paradigm, where objects play the role of modularization units. Among the different models for describing the behavior of objects, we can distinguish three main categories: • Process models — (e.g.: [CSS92], [EGS91]) the behavior is described in terms of sets of traces, state-transition diagrams, sheaves, etc; • Algebraic models — (e.g.: [Gog91]) functional approach where the notion of state is usually modeled by sorts (order sorted, hidden sorted formalisms) and the notion of method as functions between sorts; • Modal logics — (e.g.: [MP91], [FM92]) the behavior is described in terms of rules using temporal, dynamic, or deontic logics; Considering what we have said about incrementality and the intention of being as close as possible to the requirements level, we follow this third approach. Selecting a Structuring Infrastructure Category Theory, as argued in [GG78], constitutes a natural mathematical infrastructure for addressing the modularization and structuring of systems. Moreover, it has been applied successfully in the context of modal and temporal logic-based specifications (e.g., [FSMS92, FM92, FM96]), to some elementary software engineering techniques such as monotonic specialization and composition of theories, and interaction through symmetric event synchronization. Briefly, a category consists of a collection of objects together with a collection of morphisms between objects. The morphisms have an associative composition law as well as an identity morphism for each object. For our purposes, objects represent components, whereas morphisms represent elementary relations between components. More elaborate relationships may be represented by diagrams interconnecting different components. One interesting aspect of using categories is that "given a category of widgets, the operation of putting a system of widgets together to form a super-widget corresponds to taking the colimit of the diagram that shows how to interconnect them" [GG78]. For a more detailed introduction to Category Theory and its applications to object-oriented specification and system design, the reader may consult [FM94, FM96]. Overview In this paper, we propose a declarative approach for behavior modeling — based on temporal theories — and show how it scales up for the refinement and interconnection of components — based on categorial constructions. Section 2 describes the behavior model and a graph-based language for single objects, i.e., for a unit of modularization. Then, sections 3 and 4 present, in a categorial setting, some of the techniques to extend, adapt, compose, interconnect, and wrap components.

224

Chapter 14

2. OBJECT THEORIES Object Theories In our approach, and following [FM92], objects are described through theories. Each theory consists of a signature (I) plus a collection of axioms or rules (T). A signature consists of: • attributes, each one with a domain over some sort, • event types (usually just called events), Each attribute and event has an associated collection of parameters. The axioms are defined over a suitable modal-temporal logic, and represent the behavioral rules that prescribe the behavioral properties of the object or system. Such rules include: • for each event, safety conditions specifying when it may (or is permitted to) occur; • for each event, liveness conditions specifying when it must (or is obliged to) occur; • for each event x attribute pair, a valuation expression describing the effects of the occurrence of the event over the attribute. Example: Banking Account As an example of an object theory consider a simple banking account. Its specification over a Constraint-Valuation Net (CV-Net) is depicted on figure 2. Constraint-Valuation Nets (shortly called CV-Nets) are a graphical notation based on Graph Structures [Par94]. They allow to manipulate and reason about theories at a diagrammatic and syntactic level, highlighting the behavioral dependencies among the elements (attributes and events) of the theory.

Figure 2 - Specification of a banking Account In a CV-Net, plain boxes denote state attributes and dashed boxes refer to parameters. Dashed arrows denote parameterization relations. Events are denoted by circles. Each event has two associated boolean expressions denoting safety conditions (marked with a '?', whose default is true) and liveness conditions (marked

Architectural Specifications: Modeling and Structuring Behavior through Rules 225

with a '!', whose default is false). Arrows between attributes and events denote dependencies between them: a — • e : the event e , i.e., its conditions and valuations, depend on the value of a a <—• e : the value of attribute a depends on the occurrence of the event e. This arrow is labeled by an expression, of the same type as a, that defines the new value of a after the occurrence of e. Events are also subject to inheritance (eo < ei) of their associated parameters, safety and liveness conditions, and valuations. In the example of figure 2, events deposit and withdrawal inherit parameter amount from event operation. This relationship between events constitutes also the basic support for interaction, as detailed in section 4. Sorts, Attributes, and Parameters Attributes and parameters are defined over domain sorts, denoting the possible values that an attribute can take. Such sorts, as well as the corresponding operations, are defined through abstract data types, or data theories. For simplicity, we omit the specification of those data theories, but it could be easily incorporated following one of the many algebraic-equational formal specification languages for abstract data types (e.g., OBJ3 [GWMFJ92], ACT ONE [CEW93], Larch [GH93, Lea96]). This explicit distinction between data-theories and object-theories is motivated by the fact that sorts define values, like, e.g., the number '3', or the color 'blue', which are not subject to change or evolution, and are usually manipulated in a functional way. On the contrary, object-theories define dynamic systems or components, subject to change and evolution, and usually better manipulated through a reactive approach. So it becomes natural to integrate the two approaches, each one dealing with the abstraction level that it handles best. Behavioral Rules The language of behavioral rules can be summarized as follows: ::= <StateCond> | | <StateCond> ::= <Expr (Context=Att, type=Bool)> ::= ( | <EventOcc> ) => (<SafetyCond> | | <EventOcc> )+ <SafetyCond> ::= ?<Expr (context=Att©XAttePar, type=Bool)> ::= X = <Expr (context=Att0XAtt©Par, type=T)> ::= ( <StateCond> | <EventOcc>) => F<EventOcc> where <Expr (context=C, type=T)> denotes a usual functional expression of type T, defined over the data types and over the elements of context C, such as attributes, parameters, and pos-values of attributes (denoting the value of an attribute after the event, when applicable).

226

Chapter 14

Two temporal operators may be included in behavioral rules. The temporal operator X (neXt) denotes the next state. Prefixing an attribute with X denotes the value of the attribute after the occurrence of the event to which the rule is associated. Liveness conditions require an extra temporal operator designated F (Future). For instance, cond => Fevt means that if cond holds (now), then sometime in the future evt should occur. Usually this operator F (future) is replaced by an operator U (until), which is more general and allows the specification of liveness conditions with bounded commitment, i.e., for instance, with timeouts or deadlines. However, for simplicity, we will not consider the operator U. Another remark should be made wrt the difference between the notion of safety condition and the traditional notion of pre-condition. Safety conditions, sometimes also called guards in the literature, take the logical form evt => safety-cond A effects

Whereas pre-conditions, as defined in most object-oriented approaches, take the form evt A pre-cond => effects

Figure 3 exemplifies the use of this textual language to the specification of the previously considered banking account. 1 object-theory Account sorts Money = Real attributes balance: Money events operation (amount: Money) <= (deposit, withdrawal) rules init => Xbalance = 0, deposit => Xbalance = balance + amount withdrawal => Xbal ance = balance - amount withdrawal => ?(Xbalance >= 0) end Account Figure 3 — Textual specification of banking Account (from figure 2).

Concurrency Modeling behavior through rules enhances concurrency, since no sequencialization rules are artificially introduced. The occurrence of an event a in parallel with an event b simply means that there is no relationship (sequencialization or synchronization) between a and b. That is, parallelism is the absence of rules. So, if we have a model based on rules and constraints, the default is the absence of rules. Thus, the default is to have as much concurrent behavior as possible.

Architectural Specifications: Modeling and Structuring Behavior through Rules 227

3. EXTENDING THEORIES — TOP-DOWN REFINEMENT Reuse by Specializing Components One of the strategies to deal with the increasing complexity of systems is to reuse or adapt existing components, according to an incremental refinement approach. This is usually achieved through inheritance and, to some extent, parameterization. However, reuse and, in particular, inheritance, usually suffer from two problems: (i) it is applied too late, just in software design, rather than in specification and conceptual modeling which is where the main effort should be placed; (ii) it is applied just to object signatures (i.e., attributes and events), not covering their behavioral properties. By using theories to describe our objects, we are able to extend existing objects, not only with more attribute and event symbols, but also with more behavioral rules that extend functionality and add behavioral properties to the object, thus providing smooth incrementality to the behavior semantics of objects. Specialization Incremental construction, in the sense discussed above, is supported by the concept of specialization of theories, often also called inheritance or subclassing, and which presents several levels of monotonicity of the source theory [CSS93]. In a monotonic form, specialization can be formalized as a morphism between theories as follows: A monotonic specialization morphism of theories S+: < I i , Ti> —> <S2, T2> is a total morphism of signatures S+: Ei —» I2 such that: — S + : Si —> £2 i s a monomorphism (injection) of signatures, i.e., there is no merge of elements of the signature (attributes, events, or parameters); - 1~2 2 S + (rO , i.e., the source rules (after being translated) are include in the set of rules of the base theory, i.e., there is no redesign of the axiomatic base; The morphisms of signatures follow a standard definition (e.g. [FM92]). Hence we will not go into further mathematical details (provided in [Par94]). Monotonic specialization can be characterized in the following way: • • • • •

new attributes and new events may be added; new and old parameters may be associated to new attributes and events; safety conditions may be strengthened (A); liveness conditions may be weakened (v); valuation expressions, if not defined, may be added.

Figure 4, presents a theory of savings account, specified as a specialization of our previous account, and seen respectively in a diagrammatic and textual forms.

228

Chapter 14

Figure 4a — Specification of a Savings Account, as a specialization of Account (figure 2) Iobject- theory SavingsAccount => Account attributes Rate: Real Term: Nat interests: Moneydays: Nat events new_day capitalize rules init => (Xinterests = 0, Xdays = 0 ) new_day => (Xdays = days+1, Xinterests = interests + pos(balance)*(Rate/365)) (days >= Term) => Fcapitalize capitalize => (Xinterests = 0, Xdays = 0 , Xbalance = balance + interests) lend SavingsAccount Figure 4b -Textual specification of a SavingsAccount (from figure 4a).

|

Monotonicity Levels of Specialization As mentioned before, specialization of theories holds a variety of monotonicity levels [CSS93], characterizing the impact of additions and redefinitions induced by the specialization over the properties of the base theory. Monotonic specialization presents three sub-levels of strictness: • conservative subtyping (views) — the old behavior is not, directly or indirectly, affected; • strict or "pure" subtyping — the new events may not assign to inherited attributes (no side-effects); • with side-effects. Non-monotonic specialization presents two sub-levels of strictness: • with non-monotonic overriding — some inherited behavioral rules are redefined or replaced by new ones.

Architectural Specifications: Modeling and Structuring Behavior through Rules 229

• with non-monotonic structural overriding — also the inherited signature (attributes and events) can be removed (together with their associated rules). Monotonic (To -» T|) and non-monotonic (To -> T2) specializations of a theory To, are represented textually by T1 => To and T2 /=> To , and diagrammatically through specialization arrows as shown on figure 6. Notice that the arrows at the language level have the opposite direction of category morphisms. As an example of a non-monotonic extension of a theory, consider that we want to define a credit account, which is similar to a savings account, but: (i) allows to withdraw money even if the balance is not enough; and (ii) instead of computing interests over the savings (positive part of balance), computes interests over the debts, also paid by the end of the term. The theory of such credit account can be derived from the theory of savings account, through a non-monotonic specialization, as shown in figure 5. Within a non-monotonic specialization, the operator become allows to rewrite (part of) a rule of the source theory. For instance, if the source theory states p(a), and if, within the specialization specification, p (a become b) is stated, then p(b) shall hold in the constructed theory. Iobject- theory CreditAccount /=> Account extends SavingsAccount => Account redefine rules new_day => (Xinterests = interests + (pos(balance) become -pos( -balance)) *(Rate/365)) withdrawal => ?(Xbalance >= (0 become CreditLimit)) add attributes CreditLimit: Money rules CreditLimit >= 0 end CreditAccount

Figure 5 -Textual specification of a CreditAccount, as a specialization of Account, and reusing the SavingsAccount theory as also a specialization of Account. With function pos (x) = (if (x>0) x else 0). Decomposing Non-monotonic Specialization Non-monotonic specialization can be explained by an abstraction (the inverse operation of monotonic specialization) followed by a monotonic specialization, where: • the intermediate object captures the features of the base object that are preserved, i.e., the features that are common to both objects; • the abstraction morphism captures the features that were preserved or deleted; • the monotonic specialization morphism extends the intermediate object.

230

Chapter 14

Composition of Specializations Reuse may also be achieved through composition of specializations of a given base theory [PF95]. It is important to emphasize the difference between this technique and multiple inheritance. In multiple inheritance, inherited objects are "merged", resulting into possible undesired duplications or incompatibilities of the features of the inherited theories. In the composition of specializations, the two or more original specializations are combined using categorial colimits over theories [FM92], [PFC92] resulting in a "stronger" specialization. Hence, the colimit construction can explicitly manage the features that must be shared — the ones derived from the base theory — and the features that must be added disjointedly — the ones added by each specialization. Considering our previous examples of accounts, we have two specializations of Account — SavingsAccount and CreditAccount, as depicted in figure 6. ICCOUN-

savina^^

£AVINGS\ iCCOUNTi

;SS_credit

fCRED\T\ ACCOUNT)

Figure 6 — Diagram specifying: (i) SavingsAccount as specialization with side-effects of Account, because payment of interests (new event) changes balance (old attribute); and (ii) CreditAccount as a non-monotonic specialization of Account, where the safety of withdrawal, forbidding balance to become negative, has been redefined.

Now, suppose that we want to create a new specialization of Account — call it Super Account — which combines the features of saving and credit. This SuperAccount can be defined, as specified in figure 7, by the composition of the two theories SavingsAccount and CreditAccount as specializations of Account. This composition of specializations defines a diagram of theories and specialization morphisms in the category of theories, and an isomorphic diagram in the category of structured graphs. The theory defined by the composition corresponds to the colimit of the diagram of theories. This resulting theory can be viewed and analyzed, at the syntactic level, by computing the colimit of the diagram of structured graphs. In our example, the SuperAccount denotes an object theory as presented in figure 8.

Architectural Specifications: Modeling and Structuring Behavior through Rules

231

Figure 7a — SuperAccount is a specialization of Account, which is achieved through composition of the previous specializations (saving and credit) in such a way that it can either be seen as a savings-specialization followed by a credit-specialization, or the vice-verso. The diagram on the left describes the construction at the language level, where as the diagram on the right denotes the construction over the category of theories or structured graphs. object- theory SuperAccount /=> Account extends SavingsAccount => Account as sav CreditAccount /=> Account as cred end SuperAccount Figure 7b -Textual specification of a SuperAccount, as a specialization of Account, reusing the theories SavingsAccount and CreditAccount as specializations of Account.

Figure 8 - CV-Net presentation of SuperAccount.

232

Chapter 14

4. INTERCONNECTING OBJECTS AND SUBSYSTEMS — BOTTOM-UP COMPOSITION Modeling the "Glue" Until now, we have shown how to describe components, and how to extend them in order to build or adapt more complex components. However, building or adapting a system, in particular when its complexity increases, usually requires more than this. It requires the architectural structuring of the system by interconnecting existing, adapted, or created components or subsystems. At this point it is crucial to be able to explicitly describe such interconnections and dependencies as first class entities, as pointed out by [AG94], who propose a theory of interconnection styles, formalized over CSP. Some of the desirable requirements for the specification of interconnection are as follows: (i) The specifications of connectors or relationships should follow, as much as possible, the language and concepts of component specification; (ii) It should be possible to compute the system resulting from the composition of components together with their connections, and still present the overall system specification, in the same language, as a single bigger component; (iii) It should be possible to perform analysis of system properties, architectural style conformance [Sha95], etc., over the system structure; As we have previously seen, Category Theory, in conjunction with behavioral rules, constitutes a good approach for achieving the required level of compositionality. We should now illustrate how it applies to different cases of interconnection. Synchronous Event Calling One of the basic forms of interconnecting objects is through synchronous event calling (following, e.g. [SEC90]). A calling interaction from an event ei of an object obi to an event e2 of another object ob2 (figure 9) means that: • if ei occurs then necessarily e2 also occurs, and synchronously with e ^ • however, e2 might occur without the happening of e 1; • and ei "inherits" the constraints (safety conditions) of e2, as well as their effects (valuations), in the sense that it may happen just if both safety conditions of ei and ez are satisfied, and if ei occurs then both valuations of ei and e2 are required.

Architectural Specifications: Modeling and Structuring Behavior through Rules 233

Figure 9 - Interaction by event calling

A binding rule over the contexts of both events may also be added in order to express the matching between parameters of both events, and may also constraint, even more, the synchronous occurrence. In a rather liberal form, this interconnection can be achieved through the construction of the diagram in figures 10, where the two components obi and ob2 are put together (through a colimit), making a single object whose behavior is further constrained with an interaction rule (through a specialization). Of course, these two steps can and should be aggregated into a single construction step, because we do not want the existence of the intermediate theory of the construction.

Figure 10a - Diagram denoting interaction, through composition of the source and target objects. The diagram on the left describes the construction at the language level, where as the diagram on the right denotes the construction over the category of theories or structured graphs. object- theory CompositeObject extends Obi, Ob2 rule Obi.el => (Ob2.e2, ?binding) end Compos_iteObject Figure 10b - Event calling interaction, specified through composition of source and target objects plus an interaction rule.

The result of this construction is a theory CompositeObject, whose interpretation over CV-Nets is shown in figure 11.

234

Chapter 14

Figure 11 - Composite object specification, as a result of aggregation of objects obi and 0b2, behind the calling interaction (from figure 9).

Interactions Through Attribute Dependency and Manipulation In spite of being against the traditional laws of encapsulation and protected forms of interaction, it may be useful or required to establish object interconnections or dependencies through direct manipulation of attributes. The real problem of such interconnections is not so much with their form or style, but rather with their commonly undocumented and untraceable existence. When using theories to formally and explicitly document interactions, this problem is partially solved. Figure 12 shows an example of such an interaction for the definition of term and rate of a SavingsAccount. Iobject- theory BankMng attributes ActiveSavTerms: P Nat / / f i n i t e s u b s e t of Nat SavRates (term:ActiveSavTerms): Real end BankMng [obj ect- theory RateContract extends BankMng as Bank // local renaming SavingsAccount as SA rules SA.init => (?(XSA.Term: Bank .ActiveSavTerms), XSA.Rate = Bank.SavRates (term==SA.Term)) SA.capitalize => (XSA.Rate = Bank.SavRates (term==SA.Term)) end RateContract Figure 12 — Specification of an interaction between SavingsAccount and the bank management, for the definition of Term and Rate.

Encapsulation and Ports The previous approaches to interconnection are very general and powerful. Virtually any kind of interconnection, or interdependency, can be added by putting together components and adding interacting behavior rules, because we have access to all the features of the components. However, such flexibility may raise serious problems of

Architectural Specifications: Modeling and Structuring Behavior through Rules 235

protection and encapsulation, as well as flooding the context of interaction with unnecessary details. To overcome this encapsulation issue, we can introduce ports of component objects, which abstract the features required for defining the interconnection. Such ports are object theories defined as an abstraction (the inverse operation of specialization) of their "ported" object theory. For the case presented in figures 10, we would have, the construction presented in figure 13.

Figure 13 — Diagram (plain arrows) in a category denoting interaction, as a constrained extension of ports from source and target objects. The composite object, which denotes the result of composing objects under this interaction theory, is computed as the colimit of the diagram.

One further advantage of using ports for encapsulation is that it is possible to define multiple ports or interfaces for different connection purposes. For instance, considering our previous example of a SavingsAccount, it is natural to define different ports (figure 14) for each related group of external dependencies: (i) one port for interaction with client operations (deposit and withdrawal of some amount) from ATMs or branches, (ii) one port for interacting with the bank management for the definition of applicable Terms and Rates, (iii) and another port for interacting with a timer or clock, on the triggering of a new_day.

Figure 14a - Diagram presenting the different ports for interconnection with an Account and a SavingsAccount.

236

Chapter 14

obj ect- theory SavingsAccountJBankMngPort abstracts SavingsAccount attributes [Write] Rate: Real [Write] Term: Nat events [Observ] init [Observ] capitalize end SavingsAccount_BankMngPort Figure 14b - Specification of the SavingsAccount port for interconnection with the BankMng.

Packaging and Wrapping Objects Considering the previous example (in figure 12) of the interaction RateContract between BankMng and SavingsAccount, we may later want to redesign the interaction in such a way that it not only makes explicit the interaction theory ports, but also conforms to a more robust, modular interaction style, or a pre-required architectural style, or a common style for the overall system architecture. These quite common types of problem can be tackled in several ways [Sha95]. Here, we consider a wrapping over the component — the SavingsAccount — that exhibit some side-effects or internal state interferences. This is essentially a consequence of partial or incomplete specification, with which we have to deal. In fact, when early designing SavingsAccount we were not able, or did not want, to detail how attributes Term and Rate would change; we only knew that they existed and were needed. By wrapping the SavingsAccount theory, we create a new SavingsAccount _BankMngPort2 (figure 15) through which the interaction between BankMng and SavingsAccount can be performed following a "data consultancy" style. More specifically, this is achieved through the use of an extra event defConditions added by the SA_Wrapper. Observation and constraint of the occurrences of defConditions event is now the only way of defining the terms and rates applicable to a SavingsAccount. The SavingsAccount, or its wrapper, has the responsibility of triggering defConditions. SA BankMng) vPoitr

BankMng] Port

SA (Wrapper)

(BankMng)

SA BankMng) Port

/Savings) V Account/

Rate ontracti

Figure 15a - Diagram presenting a redesigned RateContract2 interconnection, taking a wrapped SavingsAccount port.

Architectural Specifications: Modeling and Structuring Behavior through Rules 237

1 obj ect- theory BankMng_Port abstracts BankMng attributes [Read] ActiveSavTerms : P Nat

// finite subset // of Nat [Read] SavRates (term:ActiveSavTerms): Real

events [Observ] add__rate (term: Nat, rate: Real) [Observ] change_rate (term: ActiveSavTerms , rate : Real) [Observ] cancel_rate (term: ActiveSavTerms) end BankMng_Port

|

obj ect- theory SavingsAccount_BankMngPort2 abstracts SavingsAccount_Wrapper events [Observ] defConditions (newTerm:Nat, newRate:Real) end SavingsAccount_BankMngPort2 [object- theory RateContract2 extends BankMng_Port as Bank, | SavingsAccount_BankMngPort2 as SA rules SA.defConditions => (?(newTerm: ActiveSavTerms), newRate = Bank.SavRates (term == newTerm)) end RateContract Figure 15b - Redesigning an interconnection for architectural style conformance.

5. RELATED WORK There are a wide variety of approaches with similar proposes of specifying and managing the refinement, composition, and explicit interconnection of systems. O.O. Algebraic-Based Specification Languages Several major algebraic-based specification languages, such as FOOPS, which includes a rich notion of module [GS95], and Larch [GH93], are trying to incorporate concurrency and dynamic proprieties, such as liveness and safety conditions, into their models. But, this seems to be a difficult task. As we said earlier, it seems more appropriate to use algebraic-models where they are better suited, namely the specification of data sorts and their operations. How this integration between reactive and functional approaches can be improved is a challenging issue. O.O. Model-Based Specification Languages Another source of progress wrt to the structural issues that we described, are the object-oriented extensions of traditional formal model-based specification methods, such as Object-Z [DKRS91], and VDM++ [DK92]. These approaches also organize the specification in terms of theories, hence much of what we presented can be transposed to those models.

238

Chapter 14

Architecture Description Languages More recently, there has been a strong emphasis, not only on making relationships explicit, but also on making them formally conformant to a given style, by providing languages for describing more precisely the possible interconnection types, as well as the properties that the whole structure of components and connectors should exhibit. Among these architecture description languages, we stress: Rapide [LKAVBM95] — which adopts a behavior model based on partially ordered event sets, including a rich set of temporal primitives; Wright [AG94] — which follows a process-based approach (CSP) for the specification of interconnection protocols; and Darwin [MDEK95] — which uses the 7i-calculus as a formal support for dynamic configuration of systems. These approaches, in general, have a drawback in what concerns the data-modeling capabilities. 6. CONCLUSIONS We have outlined an architectural object-oriented, logic-based model for systems specification, namely reactive and concurrent information systems. Among the advantages of using such a formal and declarative framework, we claim that it: • captures and supports incomplete information which is highly important in conceptual modeling, framework definition, and prototypal deployment; • is able to handle rigorous architectural models where both components and connectors are first order entities, and subject to extension, adaptation and reuse; • is useful to refine specifications both of simple components and system frameworks, by adding successive details, namely through incremental association of dynamic properties to existing events; • supports reasoning about specifications. Several issues still remain to be explored, namely: • Multiple views and languages — this core behavioral model should be able to support, specialized high-level languages, models, and views (e.g., Data and Control Flow, State Machines, etc.), which may be more adequate for capturing certain types of system properties or requirements. Integration of these different views could also be established in a categorial setting, following functorial techniques as presented in [FM95]. • Dynamic configurations — that allow to dynamically change the interconnections among components. REFERENCES [AG94] R.Allen and D.Garlan, Formal Connectors, Technical Report CMU-CS-94-115, Carnegie Mellon University, March 1994. ftp://reports.adm.cs.cmu.edu/usr/anon/1994/CMU-CS-94115.ps. [CEW93] I.ClaBen, H.Ehrig, and D.Wolz, Algebraic Specification Techniques and Tools for Software Development, AMAST Series in Computing, Vol. 1, World Scientific, 1993.

Architectural Specifications: Modeling and Structuring Behavior through Rules 239

[CSS92] J.-F.Costa, A.Sernadas, C.Sernadas, and H.-D.Ehrich, "Object Interaction", in Proc. of Mathematical Foundations of Computer Science, LNCS, Vol. 629, Springer-Verlag, 1992, pp 200-208. [CSS93] J.-F.Costa, A.Sernadas, and C.Sernadas, "Object Inheritance Beyond Subtyping", in Acta Informatica, Vol. 31, Springer-Verlag, 1993, pp. 5-26. [DK92] E.Durr and J.van Katwijk, "VDM++: A Formal Specification Language for O-O Designs", in Proceedings of TOOLS 7, G.Heeg, B.Magnusson, B.Meyer (eds), Prentice-Hall, 1992, pp. 63-78. [DKRS91] R.Duke, P.King, G.Rose, and G.Smith, The Object-Z Specification language, Version I, Technical Report 91-1, University of Queensland, Dept. of Computer Science, May 1991. [EGS91] H.-D.Ehrich, J. Goguen, and A.Sernadas, "A Categorial Theory of Objects as Observed Processes", in Proc. of the REX90 Workshop on Foundations of Object-Oriented Languages, LNCS 489, Springer-Verlag, 1991, pp. 203-228. [FM92] J.Fiadeiro and T.Maibaum, "Temporal Theories as Modularization Units for Concurrent System Specification", in Formal Aspects of Computing, 4(3), 1992, pp. 239-272. [FM94] J.L.Fiadeiro and T.Maibaum, Category Theory for the Object Technologist, OOPSLA'94 Tutorial Notes #8, Portland (OR), October 1994. ftp://ftp.fc.ul.pt/pub/papers/modeling/94-FM-OOPSLA-TutCateg.ps.gz [FM95] J.Fiadeiro and T.Maibaum, "Interconnecting Formalisms: Supporting Modularity, Reuse and Incrementality", in Proc. 3rd Symposium on the Foundations of Software Engineering (FSE3), ACM SIGSOFT, October 1995, pp. 71 -80. [FM96] J.Fiadeiro and T.Maibaum, "A Mathematical Toolbox for the Software Architect", in Proc. Int'l Workshop on Software Specification and Design (IWSSD-8), IEEE Press, March 1996, pp. 46-55. [FSMS92] J.Fiadeiro, C.Sernadas, T.Maibaum, and A.Sernadas, "Describing and Structuring Objects for Conceptual Schema Development", in Conceptual Modelling, Databases and CASE, P.Loucopoulos and R.Zicari (eds), John Wiley, 1992, pp. 117-138. [GG78] J.Goguen and S.Ginali, "A Categorical Approach to General Systems Theory", in Applied General Systems Research, G. Klir (ed), Plenum 1978, pp. 257-270. [GH93] J.Guttag and J.Homing, Larch: Languages and Tools for Formal Specification, Springer, 1993. [GHJV94] E.Gamma, R.Helm, R.Johnson, and J.Vlissides, Design Patterns: Elements of ObjectOriented Software Design, Addison-Wesley, 1994. [Gog91] J.Goguen, "Types as Theories", in Proc. Conf. on Topology and Category Theory in Computer Science, Oxford University Press, 1991, pp.357-390. [GP95] D. Garlan and D.Perry (guest eds), IEEE Transactions on Software Engineering (Special Issue on Software Architecture), 21(4), April 1995. [GS95] J.Goguen and A.Socorro, Module Composition and System Design for the Object Paradigm, Technical Monograph PRG-117, Oxford University, January 1995. Abstract available at http://www.comlab.ox.ac.uk/oucl/publications/monos/PRG-l 17.html. [GWMFJ92] J.Goguen, T.Winkler, J.Meseguer, K.Futatsugi, and J.-P.Jouannaud, Introducing OBJ3, Technical Report SRI-CSL-92-03, SRI International, 1992. [HHG90] R.Helm, I.Holland, and D.Gangopadhyay, "Contracts: Specifying Behavioral Compositions in Object-Oriented Systems", in Proc. of ECOOP/OOPSLA '90 joint Conference, ACM SIGPLAN Notices, 25(10), October 1990, pp. 169-180.

240

Chapter 14

[Joh93] R.Johnson, How to Design Frameworks, Tutorial Notes, OOPSLA'93, Washington (DC), 1993. ftp://st.cs.uiuc.edu/pub/papers/frameworks/OOPSLA93-frmwk-tut.ps. [KR94] H.Kilov and J.Ross. Information Modeling: an Object-Oriented Approach. Prentice-Hall Object-Oriented Series, 1994. [Lea96] G.Leavens, "An Overview of Larch/C++: Behavioral Specifications for C++ Modules", in this book, Chapter 8, pp. 121-142. [LKAVBM95] D.Luckham, J.Kenney, L.Augustin, J.Vera, D.Bryan, and W.Mann, "Specification and Analysis of System Architecture Using Rapide", in IEEE Transactions on Software Engineering (Special Issue on Software Architecture), 21(4), April 1995, pp. 336-355. [MDEK95] J.Magee, N.Dulay, S.Eisenbach, and J.Kramer, "Specifying Distributed Software Architectures", in Proc. 5th European Software Engineering Conference (ESEC'95), Barcelona, September 1995. [MP91] Z.Manna and A.Pnueli, The Temporal Logic of Reactive and Concurrent Systems: Specification, Springer-Verlag, 1991. [Par94] CParedes, Reuse of Object Specifications, Technical Report, University of Lisbon, September 1994 (in Portuguese). ftp://ftp.fc.ul.pt/pub/papers/modeling/94-Par-Reuse.ps.gz. [PF95] CParedes and J.Fiadeiro, "Reuse of Requirements and Specifications: A Formal Framework", in Proc. ACM SIGSOFT Symposium on Software Reusability (SSR'95), Seattle (WA), April 1995, pp. 263-266. [PFC92] CParedes, J.Fiadeiro, and J.Costa, "Object Reuse and Composition, within a Formal Framework", in Proc. ERCIM Workshop on Methods and Tools for Software Reuse, Heraklion, Crete, Greece, October 1992, pp. 162-182. ftp://ftp.fc.ul.pt/pub/papers/modeling/92-PFCErcimReuse.ps.gz. [SEC90] A.Sernadas, H.-D.Ehrich, and J.-F.Costa, "From Processes to Objects", in The INESC Journal of Research and Development, Vol. 1, No. 1, 1990, pp. 7-27. [Sha95] M.Shaw, "Architectural Issues in Software Reuse: It's Not Just the Functionality, It's the Packaging", Summary of invited talk in Proc. ACM SIGSOFT Symposium on Software Reusability (SSRV5), Seattle (WA), April 1995, pp. 3-6.

15 THE SEARCH FOR THE LINKING INVARIANT: BEHAVIORAL MODELING VERSUS MODELING BEHAVIOR David Redberg NETWORK programs inc. 255 Old New Brunswick Rd. N320, Piscataway, New Jersey 08854 USA DavidRedberg@attmail com

INTRODUCTION One of the key tenets in software engineering is the accurate, precise transformation of information from the viewpoint of the system analyst (end-user) to the viewpoint of the system designer (developer) [W95]. The mapping of information between parts of the problem space and corresponding parts of the solution space is called isomorphism [H78] and its mechanism is known as the linking invariant [H94]. Despite the fact that the object paradigm can be used today in software application development to produce abstractions that map directly to both the problem space and solution space, software reuse and productivity is far from the level seen in the hardware world. Why? In this chapter, we are first going to look at what's technically feasible in terms of realizing reusable software components and frameworks for construction of complex software systems within a business' application domain. Domain, in this context, refers to the set of problems over which the business has, or needs to have, control of the solution. Things outside a particular domain are beyond the scope of the business' control. In particular, we will explore how to define components that can be reused to efficiently construct many similar, yet customized, complex software solutions within a given domain. This requires the right choice for the "size" of the components used in a domain. In the solid-state electronics domain, Integrated Circuits (IC) are components that can be used to make larger systems (like circuit boards) which can be components of yet larger systems (like backplanes). The ICs themselves are made up

242

Chapter 15

of smaller components, e.g., gates and flip-flops which are, in turn, made up of smaller components (like transistors, diodes, resistors, etc.). The availability of the optimal size component in software development, as in hardware, is a critical and nontrivial issue. We are also going to examine some of the problems in achieving these objectives. Objects, for which technology has been around for two decades, can be used to model complex problem and solution structures, thereby enabling simple and straightforward linking. Given that objects have the potential to greatly increase software productivity, just as ICs did for hardware, why don't we see this increased software productivity, especially in the more complex problem domains where the greatest benefits can be attained? These domains, the ones in which we see the greatest presence of legacy systems, are being held back from reaping the benefits of object technology by inertial behavior, our human legacy. LINKING INVARIANT Figure 1 below illustrates the concept of the linking invariant for a given problem domain, this case being switching systems, with a very simple problem statement and two possible solutions. Note that this is a graphical depiction of the concept of the linking invariant and doesn't use any actual object model. The general problem defined in the domain, switching systems, is to connect the current incoming circuit to a requested outgoing circuit. The left-hand side of the solution space shows a possible solution using manual means. The solution is defined for switching only voice telephony circuits, where the caller requests a human operator to connect her circuit to the outgoing circuit The right-hand side shows a solution that uses a computer programmed to read an incoming signal and extract data about the incoming and outgoing circuit identifiers for the purpose of making a connection (in software). Notice that by defining the problem in a generic way for cross-connecting circuits, as opposed to specifically cross-connecting voice circuits, the system shown in the computerized solution can apply to any type of circuit (as long as the incoming signal provides the right data and protocol). The assertion is that it is possible to identify generic abstractions or patterns in a problem domain and patterns or abstractions in the solution space that can be easily linked. A system defined in terms of its data and behavior can be implemented through either manual policies, rules and procedures, or through software (e.g., database systems plus application code). In this case, we see that the manual solution is more specific than the computer solution, and therefore applicable to a more narrow range of problems (i.e., a smaller domain). However, if the computerized solution is coded in a way that makes it dependent on voice circuit switching, the computerized solution will also not be reusable in the broader switching system domain. Later in this chapter we will highlight some of the principles of object-oriented domain modeling for the implementation of generic software components that can be used to construct software solutions in a given domain. BUSINESS SPECIFICATIONS

The Search For The Linking Invariant

243

A business specification for software implementation purposes is best served by an object-oriented information model that links the problem space to the solution space in the most simple and straightforward way. The ideal way is to define a single model that is easy to understand and use, and conforms to both the problem and solution semantics.

"Connect incoming circuit to requested outgoing circuit" problem space linking invariant

Object Model solution space

i

fe3

encoded signaling message incoming circuit ID = 1 outgoing circuit ID = 2

Figure 1: Linking the Problem Space to the Solution Space We can look for patterns and abstractions in the problem domain that can be understood in terms of patterns and abstractions in the solution domain, realizing that the patterns and abstractions seen in the solution domain are general enough to solve other problems. To see this concept, let's look at a problem representation and its corresponding solution representation for a part of a domain. The primary pattern shown in this example is one that occurs in many problem domains, namely, hierarchical compositions of ordered components. These are compositions where the components are ordered in a prescribed way as a result of having defined the meaning of "first", "last" and "next". Further, the components can be composites themselves, or they can be non-decomposable components (sometimes referred to as "leaf). The composite and leaf objects share the same component properties (i.e., the same supertype). The sample problem described here, determining available flights for an airline, illustrates the use of this abstraction. Later, we will see other examples in unrelated problem

244

Chapter 15

domains that make use of this same abstraction. Then we will look at how crossdomain solutions like the one for solving hierarchical composition problems can be packaged to provide larger, more specialized, components that are reusable within a single domain. Let's define the sample problem more precisely as follows: Problem Statement: Define a system to determine all flight paths in an airline and the flight status for each of the flight paths. Terms are defined as follows (in italics): Refer to Figure 2 for a graphical representation of the system. A flight path is the association between an originating city and a destination city. Hereafter, we will use the term city pair to refer to the two cities that are the originating city and terminating city for a given flight path. A flight route is an ordered assembly (type of composition) of flight paths, where flight path can be either a flight segment or a flight route. A flight segment is the non-docomposable flight path between the cities of a city pair. So, a direct, non-stop flight path is one flight segment, that segment being between the origination city and the destination city. A flight path between NY and LA with a stop in Chicago (CHGO) is a flight route composed of an ordered set of two segments, i.e., NY to Chicago is the first, and Chicago to LA is the next (second and last) segment. Each city is attributed a status to indicate good or bad weather, and coordinates from which to determine mileage with respect to another city. For simplification purposes, we will ignore time and capacity constraints that determine whether a flight path is available to passengers. In other words, we assume planes are always available on demand for all segments. The only thing that makes a flight segment's availability status "false" is bad weather at the originating and/or terminating city. This will be reflected by the status of the city. The system is required to keep a list of flight paths (presumably for passengers to book). A client of the system (either an application function or user interface function) can request the status of any flight path in the system (presumably to see if its available) by referencing the city pair. Further, the originating city and the terminating city of the requested flight path must be different, and no segment can be repeated in any flight path since this would lead to a looping problem. If more than one available flight path exists between the two cities in the city pair, the system is to return the flight path between the two cities with the least number of segments. If more than one flight path exists between the two cities of the city pair consisting of the same number of segments, the system is to return the flight path with the minimum distance between the originating and terminating city, as determined from the sum of the distances between city pairs of all its segments.

The Search For The Linking Invariant

245

flight route (NY to LA) - composed of two segments

segment (CHGO to LA)

Legend flight path type (originating city to terminating city)

Figure 2: Illustration of Example Airline System

The airline system object model in Figure 3 below shows the associations between the objects in the model for this problem. The relationships (in boldface) between objects are defined using the generic relationship library found in [KR94]. Originating city and terminating city are dynamic overlapping subtypes of city. This means that the same city can be both an originating and terminating city. Each flight path instance is the (unique) symmetric association of one instance of originating city and one instance of terminating city. Flight route and flight segment are dynamic overlapping subtypes of flight path, where the flight route is a composition (more precisely, an ordered assembly composition) of more than one flight path, and the flight segment is non-decomposable. So a flight path instance can be both a component and a composite A flight route will be created/deleted based on the following two rules: Rule 1. If a flight path's terminating city is the same as another flight path's originating city, then this flight path is the first component and the other flight path is the next component. A flight route will then exist that associates the originating city of the first path and the terminating city of the second path.

246

Chapter 15

Rule 2. No flight path can have the originating city be the same as the terminating city.

originating city flight path

city

terminating city

flight route

Legend

flight segment

symmetric association

:SA1 ordered assembly composite —<X)A— component

subtyping supertype — < ^ S

subtype

reference maintainedl-
Figure 3: Object Model for Airline System Each flight segment has a reference to the city pair with which it is symmetrically associated. Note, the determination of valid city pairs that can be associated by a flight segment is outside the scope of this problem. Because each flight route is a composite (specifically, an ordered assembly) of flight paths, the state of the flight route can be determined based on the states of its component flight paths. In other words, there is an implied reference association between the composite flight route and the ordered assembly of component flight paths. The referenced instances are read-only and used for changing the state of the maintained instance. Each flight path determines its availability status based on the following reference rule: Rule 3. If one or more object instances referenced by a flight path is not available (i.e., availability status is equal to false), then the flight path is not available. Otherwise (if all referenced object instances are available), the flight path status is available.

The Search For The Linking Invariant

247

We will assume that all flight segments, their mileage and their associated city pairs are known to the system (in other words, we are side-stepping the problem of populating and changing the system data). Also, each flight segment has an associated value corresponding to the mileage between its originating and terminating cities that can be determined based on the coordinates of the cities in the given city pair. With the system defined above, its easy to see how the problem of determining flight paths can be solved. A variety of approaches and algorithms are available for constructing the flight routes and organizing the flight paths based on the number of component flight segments and their respective mileage. For example the set of flight segments can be used to construct a graph (segments corresponding to arcs and cities to nodes) for which many applicable graph theory algorithms exist. SOLUTION SPECIFICATIONS In our simple example airline system, we can observe several patterns of reasoning that are based on generic relationships in the problem domain. The flight path composition is a specific application of a universal pattern of part-whole hierarchies, where the (composite and non-decomposable) parts and the whole share the same properties from the perspective of a system's client. The flight path associating two cities is a specific application of a universal pattern of two like entities being related by a third entity. In the solutions domain, one of the most promising areas getting much recent attention is design patterns [GHJ94]. Design patterns are catalogued abstractions of modular software designs that solve some generic set of problems. They can be used independently, or in combination to form a higher level pattern with resulting increased programming productivity within a domain. Several of the patterns that are catalogued are immediately applicable to our sample problem. Let's start by looking at the composite pattern. Figure 4 below shows the design pattern called "composite". The composite pattern is designed to be used when you want to represent part-whole hierarchies of objects, and when you want system clients to be able to ignore the differences between compositions of objects and individual objects. Clients will treat objects in the composite structure uniformly, as depicted by the arrow from the client to the supertype component in Figure 4. Clients interact with the objects in the composition through an interface with the component class. If the client request is to a leaf, then its handled directly. If the client request is to a composite, then it can be passed to the composite's components, optionally executing other operations before and/or after forwarding. The motivation for this design pattern is to avoid defining different classes for non-decomposable leaf objects and composite objects resulting in more complex programming required to distinguish among these objects [GHJ94]. Since recursive composition occurs in so many problems, identifying and making use of this pattern can lead to an implementation of a reusable (e.g., through parameterization or template) software component.

248

Chapter 15

The part of the information model for the airline system shown within the dotted line back in Figure 2, and the model for the composite pattern shown above in Figure 4 are isomorphic to each other. The general pattern of recursive composition is evident in both models. The precise behavioral semantics arising from the more specific associations defined in the analysis model in Figure 2 (ordered assembly is a special case of composition and dynamic overlapping subtyping is a special case of subtyping) can be transformed by specifying object operations (methods) for the design objects in Figure 4.

Client Component Operation() Add(Component) Remove(Component) Get(Component)

Leaf

Composite

I

for all g in componel g.Operation():

OperationO © Add(Component) Remove(Component) Get(Component)

Legend

subtyping

composition composite ^ < ^ C —component

supertype

subtype

Figure 4: Graphical Representation of the Composite Pattern In addition to the composite pattern, another pattern, "observer" has relevance to our airline system. The observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically [GHJ94]. This pattern maps directly to our problem of updating the status of flight paths which we defined earlier through a reference association. Now if we look at a higher order pattern common to many management and control problems, namely propagating state changes based on a reference to a composite, we see how an implementation incorporating patterns, like observer into composite leads to a more powerful component. Since higher order (larger, more general) patterns and their respective implementations are formed by combining and/or extending lower-order (smaller, more-specific) patterns, they are applicable to a narrower set of problems. The

The Search For The Linking Invariant

249

composite pattern itself is extremely broad in its applicability; one of the problem domains used in [GHJ94] to illustrate the use of the composite pattern was graphics systems; a completely different problem domain than our airline system . The combined pattern using the observer and the composite for our flight path problem is still very general. It can be used in a variety of applications, such as network planning or inventory management. But is also less generic than each of the parts from which it is derived. The preceding discussion and examples highlight the primary concepts for developing reusable software components within a domain. It also shows the feasibility of doing so, by abstractly defining the resources and their relationships that are subject to control and management by the software system. We must look at the intrinsic behavior of these objects from the perspective of the operations required by clients of the system. And, we need to identify behavioral patterns based on generic relationships among these abstractions that have corresponding known or implementable solutions. By doing this, we can follow the same path as complex hardware development, and look to software engineers to construct systems from component-ware (the ICs and circuit boards of the software world [C86]) to solve families of problems within a defined problem domain. It is important to recognize the necessity of defining the domain-specific framework within which the software components must function, just as we need to define the "system bus" which ICs and boards plug into. Although software buses are domain specific (e.g., network management, air traffic control, space travel, publishing, etc.), these domains can overlap with respect to observed abstractions and patterns. As in the hardware world, there are other important practical considerations in using frameworks and components for complex software construction. Domain frameworks need things like Application Programming Interfaces (API), Application Oriented Languages (AOL), and tools (e.g., editors and compilers). These things are beyond the scope here, but they are all based on the fundamental concepts described in this chapter. COMPONENT WHERE? Looking around the software industry, there is a growing body of work that has resulted in reusable software components (called component-ware) that improve productivity in narrow, but frequently-encountered, domains. In particular, the use of Graphical User Interfaces or GUIs, and tools/widgets for building GUI applications (e.g., Visual Basic Controls -VBXs, etc.) has been extremely beneficial. However, the benefits are limited for the most part to systems characterized by GUI client applications served by database management systems. As our requirements for intelligent client and server application software evolve in many complex problem domains, system complexity increases so rapidly that these types of improvements have only second order effects on improving productivity.

250

Chapter 15

Today's computing literature is increasingly citing new and emerging systems for constructing object- oriented software systems using domain specific components The OpenDoc platform is a good example of where component-based software construction can be applied to a more complex problem domain (relative to GUI-only client applications), namely compound document management problems. OpenDoc provides a standardized (with respect to the computer operating system below it) document management framework and semantic interface that enables functional components (e.g., spreadsheets) to exchange data and messages and offers several layers of "glue" for composing a custom application from various parts. [B96] While OpenDoc provides a good example of a cross-platform component-based architecture for a document management framework, many problem domains in the software industry are still struggling with software complexity problems, especially in the areas that are most complex and therefore need the most help; areas like outer space exploration, air traffic control, and telecommunications network management and operations systems. In these areas, the software crisis continues to deepen and has not seen significant improvement in productivity over the past two decades. Bill Joy of Sun, referring to the pervasiveness of Microsoft programs in the industry said at the PC Forum in 1990 [F95]: "As we add more and more of these features to older systems, the complexity gets multiplicative. I have 10 different packages that interact in 10-to-the-10th different ways. I get all sorts of surprises, and yet because these things don't play together well the power is only additive. I get this feature and that feature but the combinations don't work. What I'd really like to see is a system where the complexity goes up in a linear way but the power goes up exponentially."

Current software construction techniques have evolved incrementally over the past quarter century. For very large, complex systems, this leads to prohibitive costs and inefficiencies because of the need to integrate functions embedded in these huge monolithic systems that were originally designed as stand-alone. One observation is that things as large as end-user applications are too big to be useful as components in an integrated system. The current situation is that the power of applications currently rises linearly as complexity of development rises exponentially when we attempt to enhance existing large systems/applications that interact with many other systems/applications. This is seen in complex domains where attempts to interwork multiple applications become very costly as the number of applications increases. Systems that exist in this environment are known as legacy systems. A characteristic of a legacy systems is that software for a particular function is almost always intertwined (i.e., is interdependent) with software for other system functions. It is extremely difficult to reuse and integrate this software since embedded functions do not have corresponding code modules that can be isolated and used directly in other applications; in many cases it would be easier to just re-write software for a function in a new application rather than account for all the software dependencies in making a change. (As an analogy, imagine having to rebuild your engine every time you had to change the spark plugs).

The Search For The Linking Invariant

251

With the consequent high cost of upgrading and replacing legacy systems, much work is currently being focused on standards for interoperability. Interoperability, sometimes referred to as interworking, is achieved when one system can be replaced by another system in a distributed systems environment by meeting a standardized interface specification. Customers want interoperability so they can replace one of their systems without replacing or upgrading all other systems with which there is some interaction. Certainly, interoperability is a worthy goal, but upon closer observation, current standardization practices in some areas may be just be treating the symptoms rather than attacking the root-cause. As management customers increasingly expect interoperability between systems (from the same or different vendors) to solve business problems that cannot be solved by independent systems, the vendors are pressured to provide "integrated" systems, where functions embedded in one system are expected to interwork with functions embedded in another system. Therefore, one condition for interoperability is a common definition of the overall problem to be solved by the systems working together. This is also a requirement for achieving reuse and integration within a family of systems, illuminating the point that software reuse and integration, and system interoperability are highly related; their respective realization depends on some of the same fundamental principles including problem definition and analysis. In the next subsection, we will examine the current practices in complex software areas applied to problem analysis and definition. ARE COMMUNICATIONS PROTOCOLS ENOUGH FOR INTEROPERABILTY? Current standards (set within standards bodies, industry consortia and private enterprise) for interoperability in complex problem domains focus primarily on communications infrastructures, but not on behavioral aspects of the overall system. As an example, current recommendations in network management primarily address communications protocols and data models. The intent of these standards is to define interoperable interfaces between management systems, and between management systems and Network Elements (equipment used for switching and transmission in communications networks), so that expensive management systems can deal with the rapidly changing and complex world of Network Element (NE) technology and different vendors' implementations without having to constantly reinvest. Without standards for interoperability, a unilateral change in the interface of one system, e.g., a new type of NE, would require changes in all systems with which it interacts. But let's examine more closely the subject of standardization, communications protocols and static data models (e.g., hierarchical containment for naming, and inheritance for taxonomy), to see if this really solves the interoperability problem. The International Telecommunications Union's (ITU) Telecommunications Management Network (TMN) recommendations for the Common Management Information Service/Common Management Information Protocol [CMIS], [CMIP], and the Generic Network Information Model [M.3100] form the basis for specifications of interoperable interfaces used in the industry across a wide variety of network element technologies and network types. TMN employs a manager-agent paradigm [M.3010] as shown in Figure 5 below. The system in the manager role sends

252

Chapter 15

requests to the system in the agent role to perform management operations, and receives autonomously generated notifications of management events from the system in the agent role. The TMN system playing the agent role has objects, called managed objects (representing the real-world resources of the network), that are defined in terms of their operations and notifications, but the TMN system playing the manager role has no objects in defined for it. Although there is a standard format and message defined between "interoperable" manager and agent systems, there are no relationships specified between agent objects and manager objects (because there are no manger objects defined).

Managing Open System

Communications Interface

Managed Open System managed objects

Manager

Management Operations Notifications

Agent

^

1

Figure 5: TMN Manager-Agent Paradigm The current TMN generic network model [M.3100], on which many NE technologyspecific models are based, describes relationships among the managed objects in a Management Information Base (MIB), but only through Entity-Relationship (E-R) diagrams. Further, the "behavior" included in the TMN managed object definitions is currently limited to unstructured English prose descriptions of the objects themselves1. Because the present TMN information models define managed objects and MIBs independent of their manager counterparts, the information available for implementing interoperable CMIS/CMIP interfaces is limited primarily to data type definitions and static data structures2. Lacking specifications based on the manager/agent There is a recommendation for simple state management [X.731] that defines allowable state changes, however, it can lead to inconsistent behavior as shown in a later example 2 Static data structure, in the context of this chapter, refers to the type of information that can be conveyed through a conventional E-R diagram. This includes named links (relationships) between entities with indications of mandatory/optional participation and cardinality. Therefore some semantics can be derived based on the invariant of the structural relationships, but there is no formality or precision in the specification of the behavior.

The Search For The Linking Invariant

253

relationships, there is not enough behavioral information from which to derive a consistent and meaningful semantic interface between the manager and the agent. This is a legacy of mainframe-style computing, where all functionality resides in a specific computer (the network management system playing the TMN agent role in this case) and is accessed through a dumb terminal-like system (the system playing the Manager role). Protocol specification and E-R modeling were adequate for interoperability in the mainframe world because of the limited, simple behavior of the dumb-terminal, but is not enough in a client/server world where we need to distribute functionality among many computer systems. TMN recommendations acknowledge that systems can be distributed in many ways, stating that any system can simultaneously play both manager and agent roles, and there can be a hierarchy of systems using the manager/agent interface. For example, suppose there was a network of high speed and low speed circuits, where the lower speed circuits were clients of the higher speed circuits. A resource model for this would include entities to represent both kinds of circuit and their association. In one situation, the high speed circuits and low speed circuits are managed as one network by a single system. This system would be the agent for some other system. Then, in another situation the low speed circuits are managed by one system and the high speed circuits by another system. The former system would still be an agent for some other system as in the preceding situation, but it would be the manager with respect to the latter system which would be its agent. Therefore, by showing that MIBs are distributable, we have also shown that TMN managed objects can be "manager" objects as well. This means that the behavior based on the manager/agent association must be specified within the network model. In other words, the TMN generic network model should define associated manager and agent objects, and their collective behavior independent of how the objects are physically distributed. Using the current TMN standards, the MIB for this high-speed/low-speed network would only specify object definitions - primarily data- for the high speed and low speed circuits, and some direct or indirect static relationship between them3 using E-R diagrams (e.g., high speed circuits has low-speed circuits). Now we will show that MIBs specifying limited semantics based on static data structures, and protocols specifying message syntax for the inputs and outputs of the system do not provide enough information to adequately understand the problem domain. To better understand the aspects of telecommunication network management systems which we are currently attempting to standardize in our TMN example, we could draw a parallel between software systems for network management and general software systems. Software systems have the same basic characteristics no matter what the application domain. There is an environment in which the software system must be placed for purposes of management and control of that environment. There is a way to interact with the elements in the environment; commands and controls can be sent as

Based on the generic network model [M.3100], the association would be indirect through some other object classes (endpoints). But the point is the same, there is not enough behavior to specify inter-system operations.

254

Chapter 15

input, reports and notices can be received as output. So, every software system will include receptors and effectors through which it interacts with resources in its environment for the purposes of management and control. A protocol is required to define the syntax of the message interface between the software system and its environment. But, to control and manage the resources in a meaningful way, the software must embody some abstract representation of this environment. This abstract representation, called the resource model, must include semantics arising from both structure and function of the inter-related resources. In the hardware world, where a lot of comparisons to software have been made regarding reuse and integration [C87][C86], we observe that protocol is an issue of infrastructure, implementation and engineering. An ICs protocol with its environment deals with power requirements, impedance matching and voltages, among other things. It has nothing at all to do with behavioral aspects of the chips, such as Boolean functions or other semantic aspects of the system [C87]. MISSING SEMANTICS Even though a message can be read because the types of all its data elements and their range of values are known, it doesn't mean there is any semantic information for deciding what should be done as a result of receiving the message. For example, TMN standards define an operational state for network objects, with possible values enabled or disabled. But if this is the extent of the scope of the definition, what does it mean for an object that is both a container and a component to be in the disabled state? Does it mean the object itself is disabled, its container is disabled, its components are in some special state, or a combination of these? We need to define the collective behavior between objects in the respective sending and receiving roles, part of the problem space, or we are not going to improve interoperability (let alone reusability). Going back to the hardware analogy, Coplien [C87] noted: Almost all digital hardware designs use a small number of TTL pins as their interface to the outside world, yet they can provide complex functionality (like a CPU chip). Most software systems have no such common mechanisms for connecting modules together: there is no concept of "pin" through which information could be passed, and if these pins had powerful enough associated semantics, then there would be a good basis for reusability.

There is no argument that a single protocol and corresponding data definition (the level of information model currently available in standards) will improve the situation for a given system where the interface to the environment (including other systems) is known and fixed. A protocol implies that a message is being sent from something (like the NEs in the network environment) and received by something else (like the software system for managing networks of multiple NEs), and vice versa; this is a system interface. In the distributed object world, having a protocol and message set means that the distribution of objects across machines is already known; this is the engineering viewpoint - part of the solution space. However, by defining part of the solution as a standard without first seeking to understand the generic problems of the

The Search For The Linking Invariant

255

domain, we may only be adding constraints that may eventually increase the complexity of pin development. The fact that standards define inheritance hierarchies also does not help solve the problem of specifying behavior. Again this is legacy influence from the predominant relational data paradigm. Inheritance is an implementation issue, part of the technology viewpoint (some programming languages do not support inheritance, for example). A communications endpoint in the TMN model for a network, is classified as a termination point. This is subclassed into connection termination point, trail termination point, and each of these is further subclassed into source, sink or bidirectional types. A physical resource corresponding to a termination point can take on characteristics of any of these subtypes over its lifecycle in the real world (just like a person can be in the role of a homeowner, an employee or a basketball player at various contexts). The problem addressed by inheritance in the telecommunications network management standards is really one of dynamic subtyping, [HKOS95] where inheritance is one of several possible solutions that can be applied depending on the particular constraints of the solution space (e.g., programming language, performance, etc.). Hence, specifying hierarchies of inheritance presents a solution without adequately defining the problem. SEMANTIC INTEGRATION Despite standardization efforts for communications infrastructures, the lack of semantic integration as the basis for interoperability (of software systems) still exists. We have already shown that communications protocols and static data structures are necessary, but not sufficient, conditions for achieving interoperability between systems. Additionally for two systems (that were not designed to work together initially) to interoperate, a pairwise mapping between the respective systems' views of the real-world must be defined and agreed to by implementors of the systems on both sides of the communications interface. This pairwise mapping is necessary for semantic integration. For functions in n systems to be "integrated", the result is n * (nl)/2 pairwise mappings that must be performed. Each mapping is complex in itself because the resource models embodied in each system have different semantics, and their coded representations are intertwined with the other application software. For large n, the problem gets very big, very fast. Further, changing or adding any single function within a system may result in having to perform the entire pairwise semantic integration over again because of the tightly coupled system interactions. The point is that protocol definition alone doesn't provide sufficient meaning for interworking among distributed systems because it doesn't address the overall problem to be solved by the distributed application. What's needed to define the problem is a model of the domain representing the real-world resources common to all the interacting systems. This includes behavior (in the form of rules, contracts, constraints, etc.) based on the resource objects' relationships to each other and to the clients which they serve. Note that in a distributed system, the client of a given resource can be another resource entity, where the latter entity is the server of yet another client.

256

Chapter 15

The above is not to say that protocol standards are not useful or necessary. Computer communications problems are fairly complex. Inter-computer (i.e., distributed) application development productivity is greatly increased by standardizing protocols as part of a communications infrastructure, but only when done in the right measure. The right measure can only be determined once the problem domain is understood through its interdependent data and behavioral aspects. By analogy, if we wanted to connect multiple national toll highway systems on a continent to form an international highway system, its much better if each country requires drivers to drive on the same side of the road. A protocol could be agreed to that says all drivers must drive on the right-hand side of the road. But it's not productive to define international speed limits in a least common denominator approach. Safety issues aside, some countries may have better roads that can support higher speeds than others and therefore, attract more drivers. And, although a standard protocol as part of the communications infrastructure is necessary for inter-system interoperability, it is not sufficient. Also needed is an understanding of the overall problem that is being solved by (distributed) systems working together and communicating over the infrastructure. Although, most of the current standards in network management are lacking semantic information about functional behavior, there are some notable exceptions. One is the ISO Generic Relationship Model [GRM], which focuses on semantics based on roles and relationships. However, the GRM work is not consistently applied to other standards in network management. For example, the generic relationships in [GRM] are not applied to the generic network model in [M.3100], where relationships are only depicted in E-R diagrams. Another example of how standards work is evolving to better address the behavioral aspects of a system is the work that is underway in ITU Study Group 15 (SG-15), responsible for recommending a new standard transport network model to be used for interoperability among different vendors' network element, network control and management applications. SG-15 employs the Reference Model for Open Distributed Processing (ODP-RM) [ISO-10746] viewpoints for specifying interoperable interfaces. The ODP information viewpoint is defined in terms of schema that include the specification of objects, relationships and allowable state changes. The computational viewpoint contains the behavioral information in terms of pre- and post-conditions for the allowable state changes. The goal of the SG15 work is setting standards for interoperability among distributed network management systems by specifying a computational network interface, not by specifying implementations within a system. Additionally, the SG-15 model is required to be compatible with existing standards, such as the TMN generic network model [M.3100]. LEGACY BEHAVIOR A significant factor in the exponential increase in development complexity while application richness is growing only linearly is "legacy behavior". Typically, for mission critical, complex systems like the ones in the legacy areas mentioned previously, much money has been spent in creating special purpose programs to run in huge monolithic systems. The benefits derived from these early systems far

The Search For The Linking Invariant

257

outweighed the costs. However, as time goes on, and these systems need to be enhanced and modified, the cost and time needed for each change is increasing as more and more changes are required. The specifiers of these systems, with their wealth of experience, become trapped by legacy thinking. There is inertia caused by the reluctance to let go of what is known and move on to the next generation of tools, methods and technology. And, perhaps more significantly, there is the perception that it will cost a lot more to build a new system than to change the existing one4. Usually, these domains don't move up a generation until the leading edge of the general software industry has moved two generations ahead. As an example, the general computing industry has embraced object technology and therefore, uses platform components like object data base systems and application architectures for distributed computing like client-server. The legacy environments have only recently moved to, and are still very much entrenched in the relational world (typical reasons for not changing include "new technology is not proven") and mainframe-style computing with respect to application intelligence (as opposed to physical architectures where a GUI with little or no application intelligence runs as a client to a DBMS). Legacy systems bring about legacy behavior. Also a factor, the domain analysis techniques and specification technology for implementation lags software programming technology, and does not enable the new software technology to be used optimally. For example, although object-oriented programming techniques have been widely practiced for the last dozen years or so, we are just beginning to recognize the importance of domain analysis. Another result legacy behavior that becomes a productivity barrier is the equating of data model with information model. As previously discussed, data models lack adequate behavioral information, whereas object-oriented information models are valuable in that they encapsulate data and behavior in a single model. Still, most popular analysis methodologies separate data models from behavioral models early in the process. This is a carry-over from the relational world and encourages early focus on a "data model" without much regard for the behavior that is inseparably tied to the data in the real world. The result is the specification of two models one for data and one for behavior (or process), that must later be merged together in the implementation when its more difficult and error-prone [KR94] (because it misses the mark of a simple, straightforward linking invariant). A prominent area in software development that exemplifies this kind of legacy behavior is the CASE tool business. In searching for helpful and productive object-oriented tools for analysis and specifying requirements, it becomes obvious that there is a huge deficit between what is available for expressing the analysis in the problem domain and what is available for expressing the implementation in the solution domain in terms of the richness and robustness of the languages and notations. Most of the commercially available tools force the premature 4

This is true in many cases for any single change to a system. However, a longer term business case virtually always shows that for repeated changes, the overall costs can be lowered significantly by designing reusable componentsfromwhich to build the new system in the first place. This is an important message in this chapter, and the legacy behavior here is on the part of the short-sighted thinking of software business management governed by short-term motivation.

258

Chapter 15

separation of static data structure from the behavioral aspects of the problem with the result being the specification of two separate models; a situation that does not lead to the specification of a simple, easy-to-use, linking invariant. In a recent software development project in which the author was involved, the application of the ODP-RM to the project was the subject of heated debates. Everyone agreed, in principle, that use of object technology and software designed for reuse were key characteristics for success of the project, and that the ODP-RM was applicable in realizing these goals. But the disagreements came regarding methodologies in the application of ODP. One side of the debate held that a separate E-R model, representing the information viewpoint, should precede and serve as input to a behavioral model (e.g., extended state machines for the objects), representing the computational viewpoint5. The other side contended that there should be only one object model incorporating both data and behavior. ODP doesn't say anything explicitly about the validity of either approach. The information viewpoint in ODPRM includes behavior by way of invariants, which allows for the use of E-R models in the information viewpoint. And, there is no ODP-specified demarcation between data and behavior, so a separate model for behavior is not ruled out of the computational viewpoint. Nor is a single model that captures both data and behavior through objects and relationships ruled out. The team finally agreed on a neutral party making the decision with weighted input from the "customer" of the requirements; the customer in this case being the software architects and developers. The view of the customer, i.e., the experienced software developers and architects on the project, was that it is better to use a single, uniform object-oriented model for capturing both the informational and computational viewpoints for software construction purposes. There should be a close mapping between the objects determined by the analysis and the ones that form the basis of software architecture and development. They may not always be identical, but they should be similar and there should be a thread through the requirements and design objects. The reasoning behind this, aside from the empirical, has to do with the fundamental definition of objects and approaches to object oriented system development. A specification of a single object model improves clarity, leads to robust and compact code, and offers less opportunity to introduce errors. An object is an entity with a collection of attributes and a collection of methods. A first order approximation is that the attributes represent the data state of the object and the methods represent the operations or activities the object can perform. It is this duality of objects, i.e., static/dynamic, data/behavior, state/operation, that allows a single object-oriented model to provide the linking invariant between the problem and the solution. The tendency towards separation of data model from behavioral or process model is part of our legacy behavior. This practice can be observed presently

5

It was revealed during these discussions that the project team members favoring separate E-R and computational models also had biases, based on past experience, towards CASE tools that forced separate models for data and behavior very early in the analysis of the problem.

The Search For The Linking Invariant

259

in traditional legacy environments, even in the interpretation of recommendations like the ODP framework, for state-of-the-art specification of distributed object-oriented systems. DOMAIN MODELS A single, generic, object-oriented information model of the domain resources can be defined that includes behavior based on the intrinsic relationships among the domain elements, as well as the system data. Having this allows each individual application development to build to the same interface provided by an implementation of that model. This enables applications to share the software that represents the structure and function of the domain resources to be managed. This is significantly different than having separate models for static data and behavior which have to be merged together eventually to implement an object based system. The difference is especially profound when the data model is introduced separately, and behavior is determined by different teams within a project. In complex developments involving multiple teams, each responsible for implementing a different process as part of the application, there is virtually always the production of multiple versions of what should be the exact same software when the teams are supplied only with a common resource data model (with limited or no behavioral specifications based on the intrinsic relationships between the resource objects). Further, when each team builds their specific part of the application software in a way that makes it dependent on their own implementation of the resource behavior, the integration of these processes becomes much more difficult. This is because the different semantics in the resource model necessitates the pairwise mapping between the parts that are required to share information about these resources6. If, instead, one single model of the resources was specified that incorporated data and behavior, it could be implemented and its interface made available for each process developer to program into, thereby significantly reducing the integration effort (as well as each process development). Applications are insulated from changes in the environment by the domain model since the applications only interact with the environment through the resource model interface, which can flexibly map to different environments in the domain. Let's go back to our airline system to illustrate this difference: The model of the resources in our airline system uses hierarchical composition; a composite object instance has associations with component object instances in one or more lower layers. Further, the component and composite objects share the same supertype. See Figure 6 below for an object instance diagram. The component objects in this example are flight paths. These associations are derived from a generic relationship library [KR94]; for example an assembly (part of the ordered assembly type of composition used in the model) specifies that the composite flight path instance cannot exist 6

The problems become even worse if the resource data models are determined by individual teams in the project.

260

Chapter 15

independent of its component flight path instances. Note that this is not the same as saying, for instance, that the component objects are "contained" in the composite since in a containment association the component objects cannot exist independently of the composite. Therefore the behavior for the various operations (Create/Read/Update/Delete) is known more precisely from the invariants and constraints of the assembly association than from the more general composition association presented by a static data model, and more importantly, the collective behavior of the entities participating in this relationship is already specified and available from the generic relationship library[KR94]. Having this behavior specified clearly during the analysis of the problem makes the solution more robust, compact and easier to maintain since the rules, contracts and constraints are coded once and available to whatever objects may need them. routes of three segments

CHGO-LA

NY-CHGO I ICHGO-DNVRl

I CHGO-LA I

I DNVR-LA I

routes of two segments

segments

cities

Legend

ordered assembly composite
symmetric association

component

Figure 6: Instance Diagram for Airline System In a static E-R model of the resources of the airline system, each flight route instance would associate with multiple flight segment instances in a one-to-many relationship. Dynamic behavioral properties, such as the state of the flight segment propagating to its composite flight routes, could not be specified in a data model. Because of the limitations in expressing subtyping in a meaningful way in E-R modeling7, there would also be no way to show that the composite flight route and the leaf flight 7

E-R modeling methodologies allow the subtyping relationships to be specified, but they are only used to carry-over attribute-level definitions. No behavior is inherited by the subtypes.

The Search For The Linking Invariant

261

segment are subtypes of the component flight path. The kind of generic recursive composition structures represented in the information model shown back in Figure 2 would not be evident from a static data model alone. Therefore we would miss the opportunity to directly link the problem space abstraction for recursive, hierarchical assemblies to an efficient object-oriented implementation designed to solve this problem. Figure 7 shows one possible E-R diagram for our airline system that follows the spirit of the generic network model8 in [M.3100]. In the diagram, we show that routes contain segments, routes are originated and terminated by route terminating cities, segments are originated and terminated by segment terminating cities and segment terminating cities have pointer associations with route terminating cities9 (to allow us to show when segment terminating cities are the same as route terminating cities). There is not enough meaning in the E-R model to come up with the instance diagram in Figure 6. It is not clear from Figure 7 that there is any ordering of segments within a route. And even if the "route contains segments" association is changed to reflect (in words) that there is an ordering of segments, there is no way to tell from the diagram that any given city can be either an origination or a destination or both, nor is there any way to tell when a city can terminate a route or a segment or both.

Figure 7: E-R Alternative for Airline System The only way to address this insufficiency in a data model is to use additional relationships that do not correspond to concepts needed in the problem definition (for

8

In the generic network model [M.3100], trails are equivalent to flight routes, connections to flight segments, trail termination points to route terminating cities and connection termination points to segment terminating cities 9 This form of model is similar in nature to the one found in the generic network model [M.3100] and is meant to provide a realistic example of an E-R type of model.

262

Chapter 15

example, the pointer and contains associations between the route terminating city and the segment terminating city entities do not add understanding to the problem definition). A distinction is made between cities that terminate routes and cities that terminate segments. Further distinctions, not shown in the figure, are made between cities that are origination cities, cities that are destination cities and cities that are both. The pointer association is introduced as a way to identify that an origination city is the same as a destination city. This can be used to identify the segments that make up a route (assuming one understands how to order the segments). Pointer management becomes a major problem when we consider all the types of cities that will have to maintain pointer associations with other types of cities. Another problem is that in order to construct a recursive tree like that in Figure 6, we have to navigate to higher level routes indirectly through their associations with cities instead of directly between composite and component flight paths as in the information model shown back in Figure 2. Further, it is not clear that flight routes can be composed of lower order routes before reaching the lowest level flight segments in the system, i.e., the recursive composition pattern cannot be easily observed. There are ways to specify the recursive construct in E-R modeling but these add clutter that detract from understanding. In this case, to show that a route is a component of another (higher-order) route, the model uses an indirect association, "route terminating city contains segment terminating city" when both are actually the same city. CONCLUSION The point of all the discussion above is that it is not optimal to produce data models separate from (and sometimes not including at all) behavioral models as specifications for implementation. Even in our simple airline system the lack of behavioral information coupled with the system data leads to inconsistent and imprecise specifications, and incomplete understanding of the general problem to be solved. In large projects, where the development of complex software systems is divided into teams, the lack of clarity and precision available from a separate data model forces each team to incorporate behavior differently. This results in redundant and incompatible software implementations. This practice of focusing on a common data model as the basis reusable, integrated software, as seen in many parts of the software industry today, is a result of our legacy behavior and shifts the focus of analysis from first figuring out what is the real-world problem that needs to be solved. Although E-R models are required when implementing a solution in a relational database, it is often counter-productive to define this part of the solution without first explicitly defining the problem to be solved. And, although specification of a protocol supports abstraction, it achieves interchangeability without guaranteeing interoperability. A protocol allows parts with different implementations to meet an interface standard, but unless the behavior of the part is understood, the result of its use cannot be predicted.

The Search For The Linking Invariant

263

Finally, we will suggest a more effective application of the ODP viewpoints for producing specifications reusable, distributable integrated software. We asserted previously that software systems for management and control of some set of physical and/or logical resources can be described relative to real world. There is a way for the software to interact with the environment, commands and controls can be sent as input, reports and notices can be received as output. A required step in analysis is to define the structure of the resources in the problem domain so that the objects representing the system's managed resources behave consistently regardless of the specific set of inputs and outputs ,or their communications protocol (i.e., the interface to the real world) whose definition is beyond the control of the business. This step corresponds roughly to the information viewpoint of ODP. It defines the framework, the basis for the implementation of the software bus. The analysis also must define the functions required to manipulate the resources as represented in the resource model. We can start by looking for all the required interactions with the system at the highest level, the level of interaction between the system and a client (either human user or another computer application). This corresponds roughly to the ODP enterprise viewpoint. Then we successively break down the high level interactions to find common primitive actions, those that are the lowest level of interest in the particular domain. This corresponds to the ODP computational viewpoint. It should be noted that this decomposition will further refine the structure of the resource model. The end-result is a single object-oriented information model (not to be confused with the ODP information viewpoint) that abstractly represents the resources of the problem domain by encapsulating the collective behavior and data of the system in terms of resource objects and their primitive operations. This model serves as the linking invariant by defining a simple mapping of the resource model to a set of general-purpose solution components (analogous to ICs and the pins). In everyday computing terms, software that uses the reusable software components is the domain "application" and the software representing the functional components and framework is the domain "operating system. The specification of the interface to the resource objects in the domain operating system becomes the basis for implementing larger reusable components (circuit boards in the analogy) within the domain. Once the core of the domain operating system is discovered and put into use, it can evolve and expand with additional resources and functions migrating from the applications as the domain knowledge is increased, or as the domain encompasses more into its family of problems. Let's look at a successful real world application that exemplifies this approach, the UNIX™ operating system, concentrating on the part known as the file system. The resources in this problem domain are things like hardware devices (printers, tape drives, etc. ) and disks. The analysis of this domain resulted in, among other things, the conclusion that these are resources that operate on streams of characters. The user of the computer (operator and/or programmer) doesn't care about the lower level things in the system, like sectors and cylinders on a disk. The power of the UNIX file system draws from treating the system resources generically, at the appropriate level of abstraction, as files (directories in UNIX are just special files). Therefore all

264

Chapter 15

primitive functions that are available for operating on files and directories, such as finding, creating, traversing and linking files, are accessible to applications through the same simple interface as offered by the device driver framework. So, we see that our garden-variety UNIX operating system can be viewed as a successful framework with reusable software components that greatly increased programming productivity (e.g., by hiding the implementation of devices and disks from the application programmer). Now we must find analogous frameworks and components in today's critical problem domains. We have the technological means to achieve these goals, we just have to change some of the ways we think about the problem. To paraphrase Einstein, "You can't solve the problems of today with the same level of thinking that you used to create them. You must go to the next level of thinking". That is the software challenge as we head toward the new millennium. REFERENCES [B96]

RGA Cote "OpenDoc: Small is Beautiful" BYTE February 1986, p. 167.

[CMIP]

ISO 9596 "Common Management Information Protocol".

[CMIS]

ISO 9595 "Common Management Information Service".

[C87]

JO Coplien "On Hardware, Software, and Productivity: A Position Paper" AT&T Bell Labs Internal Document, May 1987.

[C86]

BJ Cox "Object Oriented Programming: An Evolutionary Approach", Addison-Wesley, 1986.

[F95] [GHJ94]

G Gilder "The Coming Software Shift" Forbes ASAP, August 28 1995. E Gamma, R Helm, R Johnson "Design Patterns: Elements Of Reusable Object-Oriented Software" Addison- Wesley 1994. ISO/IEC CD 10165-7.2 "Information Technology-Open Systems Interconnection-Management Information Services-Structure of Management Information-Part 7: General Relationship Model" August 1993.

[GRM]

[HKOS95] W Harrison, H Kilov, H Ossher, I. Simmonds "From Dynamic Supertypes To Subtypes: A Natural Way To Specify And Develop Systems" Proceedings of OOPSLA'95 Workshop 21Fourth Workshop on Specification of Behavioral Semantics 1995, p. 17. [H78]

DR Hofstadter "Godel, Escher, Bach: an Eternal Golden Braid" Basic Books, 1978.

[KR94]

H Kilov, J Ross. "Information Modeling: An Object-Oriented Approach", Prentice-Hall, 1994.

[M.3010]

ITU-TS Study Group 4 "Principles for a Telecommunication Management Network" Recommendation M.3010 1993.

[M.3100]

ITU-TS Study Group 4 "Generic Network Information Model" Recommendation 1992.

M.3100,

[ODP-RM] ISO/IEC CD 10746/-2: "Open Distributed Processing - Reference Model, Part 2: Foundations" IS 10746-2/1TURecommendation X.902 March 1995. [W95]

Proceedings of OOPSLA'95 Workshop 21-Fourth Workshop on Specification of Behavioral Semantics, 1995.

16 AUTOMATA DESCRIBING OBJECT BEHAVIOR Bernhard Rumpe and Cornel Klein Institut fur Informatik, Technische Universitat Munchen 80333 Munchen, Germany http://www4- informatik. tu-muenchen. de/

ABSTRACT Relating formal refinement techniques with commercial objectoriented software development methods is important to achieve enhancement of the power and flexibility of these software development methods- and tools. We will present an automata model together with a denotational and an operational semantics to describe the behavior of objects. Based on the given semantics, we define a set of powerful refinement rules, and discuss their applicability in software engineering practice, especially with the use of inheritance.

1

INTRODUCTION

1.1

Software Development Methods: Theory and Practice

In the industrial practice of software engineering in the last fiveteen years a multitude of so-called software development methods have been developed. Such methods, such as SSADM [AG90], OMT [RBPEL91] or Fusion [CABDGHJ94], normally use different description techniques for describing different views of a software product to be developed. On the one hand, these description techniques provide notations which are well-suited for the communication with the ^ h i s paper originated in the SYSLAB project, supported by the DFG Forschungs Gemeinschaft) and by Siemens-Nixdorf

(Deutsche

266

Chapter 16

application expert, and which can be efficiently used for typical modeling problems such as data modeling (e.g. entity-/relationship-diagrams, [C76]). On the other hand, however, these description techniques lack a precisely defined semantics. Even their syntax is sometimes only defined informally, e.g. by giving examples. As a result, a lot of problems during the application of such methods arise, which are caused by the ambiguous interpretation of the semantics of the used modeling concepts: • problems concerning the communication between different persons involved in the project occur due to ambiguities arising from informal semantic definitions, • it is impossible to define formal relationships between different system views and to define rules to transfer information between different description levels, • and moreover even in one description level there is a lack of clarity concerning issues of "consistency" and "completeness". As a consequence, tool systems assisting methods (so called "CASE-Tools") often do not cause the expected gain in productivity: The information which can be acquired by the use of methods is, because of the deficient semantic foundation of the methods, not very evident. As a result of this the functionality of tools is mostly restricted to document editing- and managing functions. The vast literature concerning the commercial software development methods at least suggests that these methods are widely applied in industry. Another important research direction in academia, however, are formal methods. These techniques are based on mathematical models of information processing systems, such as process algebras ([M89], [H85]), structures of temporal logic [L91], or stream processing functions [BDDFGW93]. They are equipped with powerful refinement techniques, allowing to formally relate models on very different abstraction levels. As description techniques, various logical languages are used. While formal methods are theoretically appealing, their acceptance in industry is still in its infancy. We think that the main reasons for this are: • the produced documents can not be used as the basis for communication with the application expert, because they consist of logical formulae which are difficult to understand even for many software engineers. • no description techniques are provided for typical modeling problems such as e.g. data modeling. • the refinement calculus provides only a set of "low-level", fine-grained refinement rules with an emphasize on completeness. What is needed are powerful, large-grained refinement rules which are tailored for typical refinement problems and typical description techniques.

AUTOMATA DESCRIBING OBJECT

BEHAVIOR

267

It is the aim of this paper to present a step towards closing the abovesketched g a p between theory and practice. We believe t h a t b o t h worlds, theory and practice, can benefit from such an approach. For formal m e t h o d s , c o m m e r cially successful description techniques m a y aid in scaling u p these m e t h o d s for their application in the development of larger systems. Commercial m e t h o d s may benefit conceptually by more precisely defined concepts, and by C A S E tools with enhanced functionalities such as improved consistency checks and more powerful generation- and analysation facilities.

1.2

Overview of t h e p a p e r

Typical for all object-oriented software development m e t h o d s are description techniques of the following two kinds: • A description technique for data modeling. These description techniques are normally based on the e n t i t y - / r e l a t i o n ship-model [C76], which is extended in various ways. D a t a models describe the structure of the persistent d a t a of a system, and some integrity constraints. Entity-/relationship-modeling is the most widely used modeling technique. • A description technique for modeling behavior. State-Transition diagrams, or a u t o m a t a , are used to model the behavior of the whole system, of subsystems or of single objects. For reducing t h e complexity of the notation, hierarchical state-transition d i a g r a m s such as statecharts [H87] have been proposed, which are used e.g. in O M T . In this paper, we will present an a u t o m a t o n model which is well-suited for the description of the behavior of objects. We will consider objects as being active entities encapsulating a local d a t a space and a local process, and which communicate with asynchronous message passing. This kind of objects can not be tackled adequately with well known modeling approaches, b u t they are gaining importance in industry in the context of distributed client-/server applications. T h e paper is organized as follows: In the following section, we define the abstract syntax and a concrete graphical notation for our a u t o m a t a . T h e m a i n purpose of the graphical notation is to illustrate the examples. In section 3, the denotational semantics of an a u t o m a t o n is given by a predicate characterizing a set of stream processing functions (see [BDDFGW93], [RKB95]), and the operational semantics is defined as the set of their executions. Based on the given denotational semantics, we will continue by define a calculus for refinement which is well-suited for the use by application experts and software engineers. We show the usefulness of the refinement rules by a short example.

268

2

Chapter 16

MESSAGE PROCESSING AUTOMATA

In this section, we define the abstract syntax for message processing automata (in short automata) as well as one notation for them. We will use automata to model the input-/output behavior of components. For this purpose, we will not use a black-box-view, which only relates the input and the output of a component. Instead, we will use an abstraction of the internal structure of a component. This approach is also called the "state-boxview", e.g. in the cleanroom software engineering method ([MDL87], [HM93]). We will also abstract from the concrete messages which objects may receive and send. Instead, we model equivalence classes of these messages, called characters. One such equivalence class is for example the set of all messages of the same type, abbreviated by the name of this type. An automaton describes the reaction of a component with respect to a given input stimulus and a given state. The automaton consumes the input message, produces a sequence of output messages, and enters a new state for processing the next input message. Thus, transitions are labeled with sequences of messages, as this is the case in mealy automata [HU90]. Our approach for modeling the input-/output behavior of components is closely related with I/O-automata ([J87], [J85], [LS89]). One transition of an I/O-automaton can input a character, output a character, or it can be an internal transition. The processing of an input character triggers a sequence of further transitions, where each transition may output a further character. To guarantee that the environment of an I/O-automaton may send messages at any point in time, an additional constraint called "input enabledness" is imposed on the transition relation. Because an I/O-automaton can only accept or emit one character per transition, it needs a fine grained set of control states. Our notion of an automaton is more abstract, it labels transitions with the input character as well as with output characters, thus modeling the input characters causal for the output. Therefore, no intermediate control states are necessary. One transition models the handling of a complete message, describing input and output as well as the internal state change. We only use abstract data states, characterizing equivalence classes of the data states of the modeled components.

2.1

Abstract Syntax for Automata

The abstract syntax contains only the essence of the concrete textual or graphical notation of the automaton, while it ignores the keywords used or the concrete shape of the graphical symbols. We define the abstract syntax of an automaton as follows:

AUTOMATA DESCRIBING OBJECT BEHAVIOR

269

Definition 1 (Message P r o c e s s i n g A u t o m a t o n ) A message processing automaton is a 4-tuple (S,M,<5,I), consisting of • a set of states S; • a set of input and output characters M, • a state transition relation S C SxMxSxM*, where the first two components are the source state and the input message and the second two components are the destination state and a sequence of output messages, and • a set I C SxM* of pairs each consisting of a start state and an initial output. (End Definition) I will be called the set of initial elements. Instead of ( s , m , t , o u t ) G ^ we will often write <5(s,m,t,out). For given source s and input m, we write <$(s,m) as a shorthand if there exists a destination t and output out such that <$(s,m,t,out). An automaton models the input-/output behavior and the state changes of an object, which processes messages from the set M. A sequence of characters is processed in the following way: Nondeterministically, according to the first character of the input stream and the current state of the automaton a matching transition from S is selected. The transition is labeled with output characters, which are sent out during the processing of the input character. The automaton enters a new state according to the transition, in which he continues the processing of the input stream where the first character has been removed. A transition models the fact that the output of the transition causally depends on the input of the transition. During the processing of a transition, the output is emitted. This does not mean that the output immediately follows the input, but only that the output is caused by the input, and is sent sometimes later. This corresponds to possible message delay between distributed, asynchronously communicating objects. In contrast to finite automata ([T90], we also allow infinite state sets, and extend transitions with output. We do not use final states, because we do not model terminating components, but components with an infinite lifetime. Definition 2 (Total Automaton) An automaton (S,M,<S,I) is called total, if for each input in each state at least one transition exists: Vs£S,m£M. 6 ( s , m ) ^ 0 . An automaton which is not total is called partial. (End Definition)

270

2.2

C h a p t e r 16

Notation for Automata

To illustrate our a u t o m a t a model, in the sequel we will use a graphical representation for a u t o m a t a . Nodes will represent (equivalence classes of) states of an a u t o m a t o n , while directed arcs will be used to represent the transitions of an a u t o m a t o n . Another possibility for the concrete syntax of a u t o m a t a might be the use of tables, as this is the case in [J93a], [P92] and [S94]. We will not discuss the various advantages of graphical and textual notations for software engineering here. An excellent survey concerning this topic can be found in

[P95]. Example 1 (Parity automaton) The automaton in figure 1 describes the behavior of an object computing the parity of its input messages. The automaton has two states, representing an even or odd sum of the bits received so far. The current parity can be requested by issuing a ?. (End Example)

Parity:

?/o(

•"7

M = {0,L, ?}

^r

_JV__

>c

)?/L

^"LT"

Figure 1: Graphical representation of the parity a u t o m a t o n In general, the nodes represent the states S. T h e state transition relation S is given by arcs, which are labeled with one input character m and with an o u t p u t sequence out in the form m/out. T h e e m p t y o u t p u t sequence e is o m i t t e d for simplicity. T h e initial states are characterized by arcs without source node, which are labeled with the initial o u t p u t in the form / o u t . Only the set M of input- and o u t p u t characters has to be given explicitly. In software engineering methods like [SM92], [B94], [CABDGHJ94] or [J93] state transition graphs or hierarchical extension of these are used to represent the behavior of components. Due to the fact t h a t the state space of c o m p o nents is infinite in general, in these m e t h o d s one node of a graph represents an equivalence class of states. To allow for the formulation of propositions a b o u t

AUTOMATA DESCRIBING OBJECT BEHAVIOR

271

states, pre- and postconditions are used. We will illustrate this by specifying an object which realizes an unbounded FIFO-buffer (see figure 2). Transitions are additionally labeled by pre- and postconditions in a suitable formal language. For the pre- and postconditions we use the well-known Hoare notation. The variable s denotes the source state and the variable s ' denotes the target state of a transition. The functions # , ft and rt are defined in the appendix. Because one node of the graph represents a non-empty set of states, there has to be a mapping from nodes in the graph to sets of states. This mapping is defined by conditions which are attached to the nodes and which constitute a partition of the state space.

Buffer:

?/?(

\

M = D U {?},

d/ {s'=}

f^\ I

d/ {s'=s"d} ) {#s>2} ?/ft(s) {s'=rt(s)}

>GD

[ s=e \ ^

/l

S = D*, I = {(£,£)}

{s=} ?/d

1 Figure 2: Graphical representation of a buffer automaton

3

SEMANTICS FOR AUTOMATA

We now give a denotational semantics for our automata. The denotational semantics associates a set of stream processing functions with each automaton. Stream processing functions provide an abstract, compositional semantics for asynchronous communication objects [BDDFGW93]. We will also give an operational semantics, associating a set of transition sequences with each automaton. These transition sequences reflect the intuitive understanding of the operational behavior of an automaton.

3.1

Denotational Semantics

The semantic model of stream processing functions is introduced in the appendix. The semantics of an automaton is a set of stream processing functions.

272

Chapter 16

A set of stream processing functions can either be viewed to model an underspecified agent, i.e. as an agent in the specification of which some details have been left open, or as a model of a non-deterministic agent, i.e. as an agent which non-deterministically chooses between alternatives during its lifetime. The difference between nondeterminism and underspecification can not be observed. Non-determinism in our automata occurs because of the non-deterministic choice of the transition relation 6. Here, any transition with matching source state and input character may be chosen: Definition 3 (Semantics for Total Automata) The semantics of a total automaton (S,M,<5,I) is defined as follows: [[(S,M,M)]] C dU { gG Mw 4 Mw I 3 he H(S,M,<5,I)]]C', (s t -,out,-)GI. Vin. g ( i n ) = o u t r h ( s , - , i n ) } where \[.]\c is the greatest set of state parameterized functions satisfying the following equation (the greatest fixpoint via set inclusion): [[(S,M,<5,I)]]C dU { he SxM" A H" | (Vs. h ( s , e ) = e) A Vm,s.3t,out.<5(s,m,t,out) A 3h'eft(S,K,6,I)]ic. Vin. h ( s , n T i n ) = out^n' ( t , i n ) } (End Definition) The recursively defined set [[(S,M,($,I)]](:7 consists of state parameterized stream processing functions. According to a given input message m and the current state s non-deterministically a transition ( s , m , t , o u t ) is chosen, the output out is emitted and the new state t is entered. To allow for maximum non-determinism, a new function h ' is chosen to model the behavior in the new state. For empty input streams, an empty output stream is emitted. In [R96] it has been shown that the • semantics of total automata is well-defined, • that automata cannot be inconsistent in the sense that they denote an empty set of stream processing functions, if set I is nonempty. A partial automaton can be viewed as shorthand for an automaton which in certain cases leaves the target state and the output completely unspecified. Such an automaton allows for any behavior in cases where the state transition relation is partial for certain inputs. We call this situation chaos. Partial automata can easily be totalized by adding auxiliary transitions. This way, the semantic definition for partial automata can be reduced to the semantic definition for total automata.

AUTOMATA DESCRIBING OBJECT

3.2

BEHAVIOR

273

Operational Semantics

We now define the operational semantics for our a u t o m a t a , as a set of executions. An execution describes the transitions of an a u t o m a t o n which are used during the processing of a certain input sequence. An execution also describes which o u t p u t is produced and how the o u t p u t causally depends on the i n p u t . An execution is composed of the following components, which describe socalled execution elements: s

— m / o u — * - t is a (normal) transition with o u t p u t , when < 5 ( s , i n , t , o u t ) . —ou

Q

> so describes an initial element, when ( s o , o u t o ) E l .

Formally the execution elements are members of the sets (SxMxSxM*) and (SxM*). Definition 4 (Executions) An execution is a finite or infinite sequence of execution elements. The first element of an execution has to be an execution element without source state, while all other elements have to be execution elements corresponding to transitions. The source- and target states of subsequent execution elements have to be identical. It is depicted as: outn ^

£u

im/outi^ ^

in2/out2>

^ (End Definition)

Each execution describes the set of the traversed states as well as the processed input and the produced o u t p u t during execution of the transitions. T h e operational semantics of an a u t o m a t o n is the set of all possible executions. In [R96] it has been shown t h a t the denotational and operational semantics of our a u t o m a t a correspond to each other. T h e theorem proven shows t h a t the intuitive understanding of the computations, which is formally modeled using the operational semantics, corresponds to the denotational semantics, which is better suited for the correctness proof of the refinement rules in the following section.

4

REFINEMENT TECHNIQUES

Refinement techniques are a necessary prerequisite for efficient software production, for reusing given components, and for a transformational software development starting with very abstract, underspecified c o m p o n e n t s and resulting in concrete and efficient executable code. Another area of application is the inheritance of behavior from a super-class to a sub-class. This has been studied extensively in another context in [PR94].

274

4.1

C h a p t e r 16

T h e Refinement Calculus

For the tractability of a refinement calculus it is i m p o r t a n t t h a t the transformation rules are described on the syntactic level. Nevertheless, the transformation rules have to have a well defined underlying m a t h e m a t i c a l semantics for ensuring their correctness. The refinement relation we use at the semantic level is the inclusion relation between sets of stream processing functions. This way, refinement corresponds to the reduction of underspecification (or n o n - d e t e r m i n i s m ) . We define refinement as follows: Definition 5 An automaton

(Refinement) (S} ,K,S> ,I}) is called refinement of the automaton

(S,M,6,I),

iff l(S',H,6f,l')]i This refinement

C [[(S,M,<5,I)]].

relation is denoted by

(S,M,M) -

(S',M,<$',l') (End Definition)

Note t h a t the refinement relation is a transitive relation due to the fact t h a t the inclusion between sets (of stream processing functions) is transitive. Transformation rules often need additional constraints (so called application conditions) which have to be fulfilled to ensure t h a t a transformation rule can be successfully applied. While from the theoretical point of view a complete and powerful set of refinement rules might be desirable, from the practical point of view it is more i m p o r t a n t t h a t these conditions can be effectively checked. T h e transformation rules given in figure 3 are very elementary. Their full power only reveals by their adequate composition to more powerful transform a t i o n rules. These rules can be understood as follows: ( A r b ) allows to start a development process by creating a new a u t o m a t o n with arbitrary state set, message set, transition relation and initial states. ( R e m I ) allows to refine an existing a u t o m a t o n by removing initial states thus reducing the initial choice and thus nondeterminism. ( R e m T ) allows for the removal of transitions if alternative transitions exist, also reducing nondeterminism. ( A d d T ) allows the addition of transitions if so far no corresponding transitions exist. Therefore the a u t o m a t o n gets more robust, because chaotic behavior is replaced by an explicit description of behavior.

AUTOMATA DESCRIBING OBJECT BEHAVIOR

275

(Arb) (S.M.M) (S,H,6,I)

(Reml)

IT

—J

I' C I

<S.M,*,I') ^ (S,M,<5,I) (RemT)

6- C S VsGS.meM. <5(s,m) => <$'(s,m)

-i (S,M,<$M)

(AddT)

* C <5' VseS,m€M. (<5'\<5)(s,m)

—J(S,H,6,I)

->6(s ,m)

(S,M,*',I) (S,M,<5,I) I (RemS)

-i

reach(S,M,6,I) C S' C S 6' = 6 H S'xMxS'xM*

(S\M,<$M)' (AddS)

(S,M,<5,I)

[

S C S'

~i (RefS)

( S ' , M , * , I ) "• (S,M,<5,I) f[ a: S> -> S total, surjective —^ 1 6 , = { ( s{,(ms ',,to, ou ut )t ) I | (<$(a out)} a ( s , )s,m,a , o u t ) Gt I, >

(s',M,^,r)l

Figure 3: Refinement rules (RemS) allows for the removal of non-reach able states, where r e a c h denotes the set of reachable sets of an automaton. (AddS) allows for the addition of new states. (RefS) allows for the refinement of states. This way a single state can be

276

C h a p t e r 16

refined into a more fine grained set of states. As already mentioned, for the practical applicability of a refinement calculus it is i m p o r t a n t t h a t the applicability conditions of the refinement rules can be checked automatically. If the state set and the transition set are both final, as this is the case in description techniques for software engineering m e t h o d s , all the applicability conditions of all refinement rules can in fact be checked automatically. However, the situation gets more complex if one uses a finite representation of an a u t o m a t o n which has infinite state- and transition sets, as this was the case in section 2.2. We will not study this further, however one soon gets problems with the decidability of the applicability conditions. See also [PR94] and [PR94b]. T h e refinement rules given in figure 3 leave the syntactic interface of a refined component unchanged. In [R96] an extension to refine the interface of an object is also given. It allows for extending the input and o u t p u t set of characters as well as refining one abstract character (such as a message name) by a set of characters (such as the set of possible messages). It also m a y be used to add further components to messages arriving at or emitted from an object. Especially object-identifiers for identifying the receiver of a message may be added. T h u s object-identifiers may be left out if the abstract behavior of an object should be modeled and only later be introduced if the object are modeled more concrete for implementation purposes.

4.2

Refinement Example

In order to d e m o n s t r a t e the usefulness of our calculus, we now show a small example for a development process where the behavior of objects is refined step by step by the presented refinement calculus. In figure 4 the development process of the behavior of objects of a class F i g u r e is shown. In figure 5 the continued development for subclass 2D—Figure is depicted. T h e development is somewhat erratic (as it often is in practice), because it uses intermediate development steps t h a t do not contribute to the result, but are undone by other development steps. This is due to our intension of showing all kinds of refinement steps, their flexibility and their combined application within one example. For simplicity, we do not model o u t p u t within this example. However, it would be no problem to add o u t p u t restrictions at any stage of the development process. Objects of class F i g u r e represent objects shown on the screen. These objects may be selected and deselected by sending appropriate messages to t h e m . T h e development process shown in figure 4 of F i g u r e - o b j e c t s consists of the following steps, corresponding to applications of the rules of our calculus:

AUTOMATA DESCRIBING OBJECT BEHAVIOR

Step 1: (Arbitrary) •

—

sel=False

- • * -

277

select

___

, sel=True <

•

Step 2: (AddS) L

sel=Error select

A

>•

sel=False

sel=True

Step 3: (AddT)

r\d deselect^^~~~"~"~~^

•

H

sel= Error

<

#

eselect, select J

sel=False

deselect^-'

deselect

Step 4: (RemT)

(~\ deselect, select sel=Error select

sel=False deselect O"

sel=True deselect

Step 5: (RemS) select sel=False deselect v_y

sel=True

h

•

sel=True

k

•

deselect

Step 6: (RemI) select sel=False deselectLJ

1

deselect

Figure 4: Development of behavior of class Figure

278

C h a p t e r 16

S t e p 1 : At the beginning of our development, we start with a very simple aut o m a t o n : It has two states reflecting a selected and an unselected figure. It has one transition modeling what happens if the figure object is sent a s e l e c t if it is not yet been selected. Both states are initially allowed. S t e p 2 : We want to add transitions for a deselection, but what h a p p e n s if the figure is already deselected? We decide to introduce an additional state, reflecting this error. S t e p 3 : We now add d e s e l e c t - t r a n s i t i o n s , leaving open whether d e s e l e c t results in an error or is just being ignored in the deselected s t a t e . S t e p 4 : T h e customer wants a robust implementation of d e s e l e c t . Therefore, we remove the possibility to result in an error. Another alternative would be to require the o u t p u t of a warning message in the the left deselect-\oop. S t e p 5 : T h e previously introduced error state is now superfluous and can be removed. S t e p 6 : In a last development step we decide t h a t a newly introduced figure is automatically selected and therefore remove one initial element. The development for class F i g u r e is now finished. It describes the behavior of any object of this class, in terms of the state change according to a given sequence of input messages. The substitutability principle ([WZ88], [W90]) for objects now enforces the inheritance of this a u t o m a t o n to all subclasses of F i g u r e . This not only m e a n s t h a t the signature is preserved or extended, but t h a t behavior is inherited in some way. An a u t o m a t o n thus can be seen as an interface description which may be viewed as a contract on which clients may rely on. We now continue the development process by developing a class 2D—Figure, which is a subclass of F i g u r e . 2D—Figure in addition allows to fill and e m p t y its area. We start with the inherited a u t o m a t o n from class F i g u r e : S t e p 7 : We add transitions for filling end emptying selected 2D-figures. T h e figures remain selected. S t e p 8 : Filling changes the state of a 2D-figure. This is not modeled. Therefore, we refine the in which a figure is selected into two states. T h i s has the effect, t h a t every transition with source or destination in the unrefined state is duplicated. This way, underspecification has been introduced. S t e p 9 : We now remove some transitions to describe the behavior of f i l l and empty in more detail. In addition we model t h a t a newly created 2D-figure is not filled.

AUTOMATA DESCRIBING OBJECT

Step 7: (AddT)

BEHAVIOR

select

sel=False deselect

XT

279

sel=True

crfill,

deselect

empty

Step 8: (RefS)

^

sel=True 1 no contents J

sel=False fill, empty

deselect v-^ select

fiU?

u

empty

fill, empty

sel=True j filled cont. J^

T 7 fill,

/

empty

s

Step 9: (RemT) and (RemI)

sel=True no contents

sel= False

~XJ empty

deselect sel=Tn filled cont.

mpty

TJm Figure 5: Development of behavior of class 2D—Figure

T h e presented development steps should be sufficient to show t h a t the refinement calculus can be applied to real application development problems, and t h a t the rules of our calculus exactly reflect the development steps used for the development of behavior descriptions. However, this small example also shows t h a t a rigid tool support is inevitable for larger example.

5

RELATED WORK

Recently, various approaches for formalizing m e t h o d s of systems and software development were given. Well known are the so-called " m e t a - m o d e l s " , originating in the context of tool integration, (see [T89] and [HL93]). However, by this "models" almost only the abstract syntax of the description techniques is captured. An overview of several projects concerning the integration of struc-

280

Chapter 16

tured methods with techniques of formal specification can be found in [SFD92]. In [H94], the British standard method SSADM [AG90] is formalized using the algebraic specification language SPECTRUM [BFGHHNRSS93]. This work is continued in the project SYSLAB [B94a]. It is the aim of this project to provide a scientifically founded approach for software- and system development. SYSLAB emphasizes the early phases (analysis, requirements definition, logical design), prototyping, reuse, and code-generation. In the context of the SYsLAB-project, a multitude of description techniques have been formalized up to now. Examples are entity-/relationship-diagrams ([H93], [H95]), data flow techniques [N93a] or time sequence diagrams [F95]. The formalization in most of these cases is based on a so-called mathematical system model or on Focus, which have been presented in [RKB95] and [BDDFGW93]. This mathematical system model, which is based on streams and stream processing functions, is also the basis for this paper, and it is presented in the appendix. The specialization of automata has been a research topic of some groups, especially in the context of object oriented systems. In software engineering methods ([RBPEL91], [CABDGHJ94] oder [SM92]) automata are used for the behavior modeling of systems and its components. Due to the informal semantics of the description techniques used in these methods in general no guidance is given for determining the relationship of automata of classes being in an inheritance-relationship. Closely related to our approach is the work presented in [PR94]. However, in [PR94] output actions are not considered and only one (powerful) refinement rule is given. The semantic model of stream processing functions is not used. First order formulae are used for expressing the pre- and postconditions of transitions. The work in [LW93], [AC93], [C93] is based on the basic principle of substitutability, which has been presented in [WZ88] and [W90]. Here, substitutability means that elements (objects) of a supertype can safely be substituted by objects of a subtype. These approaches also study the specialization of behavior in the context of subtyping, which is interesting if the behavior of methods of objects is specialized by inheritance. The concepts developed in these approaches are partially integrated in some object-oriented languages, e.g. in Modula-3 [CDGJKN92], [A93]. Nierstrasz uses finite automata in [N93] for typing objects. The automata are used to model which messages are accepted by an object in which states. This way, the type of an object not only contains information about the static method interface, but also information about the sequences of possible method invocations of a client. Moreover, Nierstrasz defines a subtype relation which corresponds to a behavior specialisation. The subtype-relation is suitable for sequential as well as for distributed, parallel communication. However, the construction of the subtype-relations gets very complex, possibly due to the underlying synchronous communication paradigm which is based on Milner's CCS [M89].

AUTOMATA DESCRIBING OBJECT BEHAVIOR

281

A simpler refinement calculus which is based on asynchronous communication and an I/O-automaton approach is given in [BHS96]. There, input- and output characters are not distinguished and only one character is allowed for each transition. The semantics and the refinement rules are based on a trace semantics. In [PR94b] we studied how automata can be integrated in the algebraic specification language SPECTRUM [BFGHHNRSS93]. There, an automaton is viewed as a special notation for a logical axiom. This way, a visual description technique is integrated in an axiomatic specification language, while the power and flexibility of SPECTRUM is available in cases where automata can not be used adequately. Examples where SPECTRUM can be applied are pre- and postconditions, as they have also been used in this paper. The translation process of automata, which have been developed in the design phase, in an implementation using current object-oriented programming languages like C++ [S91] is error-prone. Therefore, in [R94] we used finite automata the transitions of which are labeled with executable program fragments and executable pre- and postconditions. This way, automata get part of the programming language. The resulting language called C++STD contains concepts of design and implementation and can therefore be viewed as a veryhigh level programming language. For C++STD a prototypical implementation exists.

6

CONCLUSIONS

We have presented an automata model for the design phase of object-oriented software engineering methods. A denotational and an operational semantics have been given, which correspond with each other. Because the denotational semantics was based on stream processing functions, the refinement techniques of stream processing functions could be used to define refinement rules for our automata. The example of a development process has shown that the presented set of refinement rules is simple, flexible and powerful. Therefore, the refinement rules seem to be well-suited for integration in commercial software engineering methods- and tools.

Thank We thank Klaus Bergner and Manfred Broy for discussing ideas with us and Bernhard Schatz for a thorough reading of this paper.

282

A

Chapter 16

STREAMS AND STREAM PROCESSING FUNCTIONS AS A MODEL OF INTERACTIVE SYSTEMS

Stream processing function provide an abstract model for information processing systems and their components. Objects are modeled as components communicating asynchronously with their environment by the exchange of messages. Objects have an input port for receiving messages from their environment, and an output port for sending messages to their environment.

A.l

Streams

In our model, the behavior of an object is modeled by its runs, which describe the relationship between the messages arriving at the input port of the object and the messages sent on the output port of the object. We assume that for each run the events on a port are totally ordered, which means that for two different events always one temporarily precedes the other. This allows to model the communication history on a port by a stream of messages. A stream is a finite or infinite sequence of messages. If M denotes the set of messages, M* the set of all finite sequences of messages and M°° the set of all infinite sequences of messages, for the set of all streams over M, denoted by Mw, the equation

holds. We will use the following operations and relations: • " : M" x M w —> M" denotes the concatenation of two streams, i.e. the stream which is obtained by putting the second argument after the first. The operator ~ is usually written in infix notation. We assume that s

e M°°^s"t

= «,

holds, i.e. the concatenation of an infinite stream s with a stream t yields the stream s. ~ will also be used to concatenate a single message with a stream. • # : M" —>• (NatU {oo}) delivers the length of the stream as a natural number or oo, if the stream is infinite. • Filter : V(M) x M" -» M" denotes the filter-function. deletes all elements in s which are not contained in set N.

Filter (N,s)

• ft : M" —> M delivers the first element of a stream if the stream has at least one element, and is undefined if its argument is the empty stream.

REFERENCES

283

• rt: M" —>• Mw removes the first element of a stream if the stream has at least one element, and is undefined if its argument is the empty stream. • C : M^ x M^ —>- Bool is the prefix order between streams. m\Zn holds if there exists an u such that mu — n. Using streams, the communication history of an object can be represented by a pair of streams of messages, where the first component represents the input history of the object and the second component represents the output history of the object.

A.2

S t r e a m processing functions

The behavior of an object is modeled by a stream processing function mapping a stream of input messages to a stream of output messages: Behavior : M w -» M" However, not every function with this functionality represents an adequate model of an object: In reality, it is impossible that at any point of time the output depends on future input. To model this fact, we impose an additional mathematical requirement. We require stream processing functions to be monotone with respect to to the prefix ordering on streams: xQy=> Behavior

(x)\ZBehavior(y)

An additional requirement, continuity, has also to be imposed on stream processing functions as models of objects. We will not define continuity here, but refer to [BDDFGW93]. All monotone and continues stream processing functions are denoted by the function arrow A . While one stream processing function can be used to model a deterministic agent, we also have to take into account nondeterminism. Nondeterminism occurs during the development process due to underspecification, or during the lifetime of an agent due to non-deterministic choice during the execution. In our model, non-deterministic agents are modeled by sets of stream processing functions. Please note that all the above definitions can easily be extended to objects with more than one input- or output port, see [RKB95] or [BDDFGW93]. While the model of stream processing functions could only be sketched here, in these papers also more details are given.

References [A93]

M. Abadi. Baby Modula-3 and a Theory of Objects. SRC Research Report 95, Digital Equipment Corporation, February 1993.

284

REFERENCES

[AC93]

R. M. Amadio and L. Cardelli. Subtyping Recursive Types. SRC Research Report 62, Digital Equipment Corporation, January 1993.

[AG90]

C. Asworth and M. Goodland. SSADM - A practical approach. McGrawHill, 1990.

[B94]

G. Booch. Object Oriented Analysis and Design with Applications. jamin/Cummings Publishing Company, Inc., 1994.

[B94a]

M. Broy. SysLab - Projektbeschreibung. Internal project report, October 1994.

Ben-

[BDDFGW93] M. Broy, F. Dederichs, C. Dendorfer, M. Fuchs, T. F. Gritzner, and R. Weber. The Design of Distributed Systems — An Introduction to FOCUS - revised version -. SFB-Bericht 342/2-2/92 A, Technische Universitat Miinchen, January 1993. [BFGHHNRSS93] M. Broy, C. Facchi, R. Grosu, R. Hettler, H. Huftmann, D. Nazareth, F. Regensburger, O. Slotosch, and K. St0len. The Requirement and Design Specification Language SPECTRUM, An Informal Introduction, Version 1.0, Part 1. Technical Report TUM-I9312, Technische Universitat Miinchen, 1993. [BHS96] M. Broy, H. Huflmann, and B. Schatz. Graphical Development of Consistent System Specifications. In FME'96, Formal Methods Europe, Symposium y96, LNCS. Springer-Verlag, Berlin, 3 1996, to appear. [C76]

P.P. Chen. The Entity-Relationship Model - Towards a Unified View of Data. ACM Transactions on Database Systems, l(l):9-36, 1976.

[C93]

L. Cardelli. Extensible Records in a Pure Calculus of Subtyping. SRC Research Report 81, Digital Equipement Corporation, January 1993.

[CABDGHJ94] D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994. [CDGJKN92] L. Cardelli, J. Donahue, L. Glassman, M. Jordan, B. Kalsow, and G. Nelson. Modula-3 Language Definition. ACM SIGPLAN NOTICES, 27(8):15-42, August 1992. [F95]

C. Facchi. Methodik zur formalen Spezifikation des ISO/OSI ells. Herbert Utz Verlag Wissenschaft, 1995. PhD Thesis.

Schichtenmod-

[H85]

C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985.

[H87]

D. Harel. Statecharts: A Visual Formalism for Complex Systems. of Computer Programming, 8:231-274, 1987.

[H93]

R. Hettler. Zur Ubersetzung von E/R-Schemata nach SPECTRUM. Technical Report TUM-I9333, Technische Universitat Miinchen, 1993.

[H94]

H. Huftmann. Formal Foundations for SSADM. Miinchen, Habilitation Thesis, 1994.

[H95]

R. Hettler. Entity/Relationship-Datenmodellierung in axiomatischen ifikationssprachen. Tectum Verlag, Miinchen, 1995. PhD Thesis.

[HL93]

H.J. Habermann and F. Leymann. Repository - eine Einfuhrung. der Informatik. Oldenbourg, 1993.

Science

Technische Universitat Spez-

Handbuch

REFERENCES

[HM93] [HU90] [J85]

[J87]

285

A. Hevner and H. Mills. Box-Structured Methods for Systems Development with Objects. IBM Systems Journal, 2:232-251, 1993. J. Hopcroft and J. Ullman. Einfuhrung in die Automatentheorie, Formale Sprachen und Komplexitatstheorie. Addison-Wesley, 1990. B. Jonsson. A Model and Proof System for Asynchronous Networks. In Proc. 4^h ACM Symposium on Principles of Distributed Computing. ACM, 1985. B. Jonsson. Compositional Verification of Distributed Systems. PhD thesis, Uppsala University, Uppsala Sweden, 1987.

[J93]

I. Jacobson. Object-Oriented Software Engineering Approach. Addison Wesley, 1993.

- a Use Case

Driven

[J93a]

R. Janicki. Towards a Formal Semantics of Tables. Technical Report 264, CRL, September 1993.

[L91]

L. Lamport. The temporal logic of actions. Technical Report 79, Digital Equipment Corporation, Systems Research Center, Palo Alto, California, December 1991.

[LS89]

N. Lynch and E. Stark. A Proof of the Kahn Principle for Input/Output Automata. Information and Computation, 82:81-92, 1989.

[LW93]

B. Liskov and J. M. Wing. A New Definition of the Subtype Relation. In ECOOP 93, pages 118-141, 1993. [M89] R. Milner. Communication and Concurrency. Prentice-Hall, 1989. [MDL87] H. Mills, M. Dyer, and R. Linger. Cleanroom Software Engineering. IEEE Software, 4:19-24, 1987. [N93] O. Nierstrasz. Regular Types for Active Objects. In Andreas Paepke, editor, OOPSLA '93. ACM Press, October 1993. [N93a] F. Nickl. Ablaufspezifikation durch Datenfluftmodellierung und stromverarbeitende Funktionen. Technical Report TUM-I9334, Technische Universitat Miinchen, 1993. [P92] C. Parnas. Tabular Representation of Relations. Technical Report 260, CRL, October 1992. [P95] M. Petre. Why Looking Isn't Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 38(6):33-44, June 1995. [PR94] B. Paech and B. Rumpe. A new Concept of Refinement used for Behaviour Modelling with Automata. In FME'94, Formal Methods Europe, Symposium '94, LNCS 873. Springer-Verlag, Berlin, October 1994. [PR94b] B. Paech and B. Rumpe. Spezifikationsautomaten: Eine Erweiterung der Spezifikationssprache SPECTRUM um eine graphische Notation. In Formale Grundlagen fur den Entwurf von Informationssystemen, GI-Workshop, Tutzing 24.-26. Mai 1994 (GI FG 2.5.2 EMISA). Institut fur Informatik, Universitat Hannover, May 1994. [R94]

B. Rumpe. Verwendung endlicher Automaten zur Implementierung des dynamischen Verhaltens von C + + Objekten. In G. Snelting U. Meyer, editor, Semantikgestuetzte Analyse, Entwicklung und Generierung von Programmen, 9402. Justus-Liebig-Universitat Giessen, March 1994.

286

[R96]

REFERENCES

B. Rumpe. Formale Methodik fiir den Entwurf verteilter objehtorientierter Systeme. Phd-thesis, to appear, Technische Universitat Miinchen, 1996.

[RBPEL91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991. [RKB95] B. Rumpe, C. Klein, and M. Broy. Ein strombasiertes mathematisches Modell verteilter informationsverarbeitender Systeme - Syslab Systemmodell -. Technical Report TUM-I9510, Technische Universitat Miinchen, Institut fiir Informatik, March 1995. [S91]

B. Stroustrup. The C++ Programming Language. Addison-Wesley, 1991.

[S94]

K. Spies. Funktionale Spezifikation eines Kommunikationsprotokolls. SFBBericht 342/08/94 A, Technische Universitat Miinchen, Mai 1994.

[SFD92] L.T. Semmens, R.B. France, and T.W.G. Docker. Integrated Structued Analysis and Formal Specification Techniques. The Computer Journal, 35(6):600-610, 1992. [SM92]

S. Shlaer and S. Mellor. Object Lifecycles, Modeling the World in Yourdon Press, 1992.

States.

[T89]

I. Thomas. P C T E interfaces: Supporting tools in software-engineering environments. IEEE Software, pages 15-23, November 1989.

[T90]

W. Thomas. Automata on Infinite Objects. In J. van Leeuwen, editor, Handbook of Theoretical Computer Science, volume Band B, chapter 4, pages 135-192. Elsevier Publisher Amsterdam, 1990.

[W90]

Peter Wegner. Concepts and Paradigms of Object-Oriented Programming. OOPS Messenger, l(l):7-87, 1990.

[WZ88]

P.Wegner and S. Zdonik. Inheritance as an Incremental Modification Mechanism or What Like Is and Isn't Like. In S. Gjessing and K. Nygaard, editors, Proceedings ECOOP '88, LNCS 322, pages 55-77. Springer Verlag, Oslo, August 1988.

17 ENTERPRISE MODELING WITH USE CASES Extending Jacobson 's Approach Jean Stanford Hestia Systems 15349 Falconbridge Terrace Gaithersburg, MD 20878 (301)869-7355 [email protected]

Abstract Use cases are being adopted throughout the object-oriented (OO) systems development community, not only to define requirements but also as enterprise analysis vehicles. When analyzing an entire enterprise, we found it necessary to extend the methodology in order to cover all important "transactions of value" at each level of decomposition.

Introduction Use cases have been invented and popularized by Ivar Jacobson in numerous publications (see [J94, J94a], etc.). A use case is: "a sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the system" [J94, p. 105]. As such, the use case focuses the developers' attention on functions which directly support the end users (actors). This is an admirable goal; many times the work of the potential users have not been systematically examined. The system's requirements were often stated in high level fashion (e.g., "the system shall print monthly bills") without consideration of the folks who will have to enter the billing information (or peel the forms off the printers). Jacobson's recent book [J94] indicates that use cases can be used to analyze an entire enterprise for business process re-engineering purposes (independent of automation). He recommends a layered decomposition of the enterprise, with simple use cases describing the top level functions and more details as the lower levels are analyzed.

288

Chapter 17

This nicely dovetails with the advice from Michael Hammer, the guru of business process re-engineering [H94]. Since many re-engineering methodologists use yellow stickies on a wall as their modeling process, a more organized use case-based approach is bound to be a tremendous help in working with large enterprises. Once the enterprise model is developed, analysts then "drill down" to develop detailed models to serve as requirements for the portions that will be automated, still using use cases as the primary requirements analysis vehicle. As we attempted to apply Jacobson's approach to analysis of larger systems, we encountered several difficulties (which could well be our fault, but we were unclear about the best approach even after reading the new Jacobson book). We teach the use-case driven approach to students who tend to work on very large projects ($50 million or more). Thus, it is very important for us to develop a coherent approach to modeling so that all our analysts can produce consistent results across a project. We ran into several different types of problems with the standard methodology: •

Identifying a complete set of actors and transactions at each organizational level

•

Deciding how much of the supporting internal functions to include in the use case (functions which are of value to the internal system but are of no value to the actor).

•

Specifying data requirements in situations where data must be provided by one use case in order for other use cases to complete their transactions

•

Differentiating the purpose or key elements of a use case which must be preserved from those which are merely descriptive, "nice to have" or incidental in such a way that subsequent analysts know which is which.

•

Describing how use cases inter-relate, especially in terms of time or in terms of pre- and post- conditions for complex situations.

Defining Actors & Functions For Each Layer Jacobson recommends [J94, p. 326] that superordinate and subordinate use case models can be developed for complex organizations. He says: 'There is thus a type of equivalence between the superordinate use-case model and the subordinate use-case model. Each actor in the superordinate use case model corresponds exactly to an actor in the subordinate use case model. Each use case in the superordinate use case models corresponds to a set of sub-use cases in a subset of the business system areas in the subordinate use case model. Sub-use cases are linked together via communication associations. A subuse case does not need to be linked to every other subuse case."

Enterprise modeling with use cases

289

We have not found the above definition to hold true. For example, consider the following enterprise-level use case for Amalgamated Medical Machines, a company that makes blood chemistry equipment for sale to hospitals and clinics: Blood Chemistry Equipment Sales Primary Actor: Hospital Lab Director 1. I

Sales Rep calls on Hospital Lab Director to determine if he is interested in Blood Chemistry equipment

2.

Hospital Lab Director requests proposal (cost, warrantee, features).

3.

Sales Rep prepares proposal.

4.

Hospital Lab Director accepts proposal.

5.

Contract is signed.

Blood Chemistry is delivered and installed in the Hospital Lab.

This is fine as a high level use case. However, if we are going to go to the next level, we cannot derive all the necessary actors from "Hospital Lab Director". Consider the following subordinate use cases:

Customer Lead Response I Primary Actor: Lab Technician 1.

Lab Technician sees Amalgamated Medical advertisement in technical magazine.

2.

Lab Technician detaches and mails "bingo card" indicating interest in obtaining more information.

3.

Customer Service receives bingo card and generates a customer contact record in data base.

4.

Customer Service mails promotional material to Lab Technician.

5.

Marketing receives a report from Customer Service, indicating which accounts had sent in bingo cards.

Marketing manager adds Lab Technician's Hospital to Marketing Rep's Customer Call Plan.

290

Chapter 17

Now, this is an interesting use case. As far as the Lab Technician Actor is concerned, the only "transaction of value" is his completion of a bingo card and receipt of promotional literature. Because we know something about the goals and procedures of Amalgamated Medical Machines, we know that we should add some additional internal processes to this use case (steps 3, 5 and 6 have nothing to do with the transaction of value to the Lab Technician Actor). Should these steps be included in the use case? If we are purists about the "transaction of value" definition, we should really leave them out. But if we want to capture the actual process flow within Amalgamated, we should leave them in and make sure that they are viewed as requirements for our completed system. Indeed, the system would be much less valuable to Amalgamated if it did not support generation of call plans. Yet call plans are never visible to the external customer ~ so where do they fit in our use cases? If we do not include the internal processing steps, we will have a "Potemkin village" requirements specification ~ the interfaces will be elegant, but there will be no substance to the buildings. In Chapter 8 of [J94], Jacobson describes the use cases developed for re-organizing the Objectory organization. Included in this description is a "support layer" of activities, such as budgeting and planning, which are necessary to run the enterprise but do not provide direct value to the external actors. We agree that such support activities are necessary for a complete model; but they will not be obvious when constructing the initial models. (They probably were not obvious to Jacobson's modelers either, when their modeling project began) . Only by including the support steps within the individual use cases can we develop a complete picture. Further analysis can reveal the functions which can be abstracted into a support layer. We suggest that this be performed as an explicit step. Further, we could easily have missed the Lab Technician actor. Only by following up on a lucky question ("How did you know you should call on the Lab Director?") did we realize that the sales lead had been generated by an external actor that was interacting with the system. If we had not asked this particular question, we could have missed an important requirement. We must have some organized way to determine if we really have garnered the complete set of external actors. Relying on the Marketing Rep's memory alone would not do it; he is blissfully unaware of how the data base is generated. There are certain activities of an organization that are taken for granted by most participants and will not be revealed by general questions. Note that Lab Technician is not the same as Lab Director (our primary actor in our Superordinate use case). One could make the argument that the Lab Technician works for the Lab Director, so we could say that he corresponds exactly to an actor in the superordinate use case model if we are quite flexible in our use of the term "corresponds exactly". Also note that the "bingo card" transaction can only be said to be derived from the higher level use case in a very tenuous sense. There is nothing intrinsic to the high level use case to indicate how the sales call was triggered. This use case leads to another question - should we examine explicit input and output data as part of the use case? The data definitions have been left to the object modeling phase, yet for many systems the data is of prime importance in producing a

Enterprise modeling with use cases

291

valid specification. The same types of issues come up in examining the data needed for this use case as did in defining its transactions. If we are simply to examine this use case from the perspective of the Lab Technician, all that would be needed on the bingo card would be his return address and the type of analysis machine he was interested in learning more about. However, from Amalgamated's perspective, the bingo card should include a space to designate which hospital he works for (so the hospital name can be added to the sales call list). If we don't make this data requirement explicit, we are going to have to rely on the designers to include this data in the object model. But the designers won't be familiar with the data needs of the system and may not realize that this data should be added. If the users are validating the use cases alone, they will not have an opportunity to examine the data in the object model and will not be able to correct errors. This does not necessarily mean that we have to define data structures, field lengths or implementation details in the use cases. It may mean that we should include postconditions that specify that certain data must be made available from this use case to another use case. For example, we could say: Post-condition: Sales call list updated with name of Lab Technician's institution We intend to further expand these ideas, using the concepts from [KR94] as the basis for our extensions. Kilov and Ross discuss the use of contracts to define information system requirements. These contracts make it clear what data and functions are necessary. They say: "As a corollary, 'data modeling' will not be artificially separated from 'process modeling'..." ([KR94], p. 67). This makes sense in terms of object orientation ~ the whole premise of object modeling is that we manage the data and the methods that manipulate them within the same object. Why shouldn't we specifically consider data in the use case? Hold those thoughts as we look at another subordinate use case:

Contract Definition Primary Actor: Hospital Counsel 1.

Marketing rep presents Counsel with a draft contract.

2.

Counsel negotiates terms and conditions with Marketing rep.

3.

Marketing rep consults with Amalgamated Marketing Director and Counsel, gaining approval of the revised terms and conditions.

Hospital Counsel approves contract.

292

Chapter 17

Now, the Counsel is not at all the same as the Lab Director. He doesn't report to the Lab Director. He might not even be a Memorial Hospital Employee. So we will have a very hard time saying that he corresponds exactly to an actor in the superordinate use case model. Further, not every customer will have a Counsel actor empowered to sign such contracts or negotiate terms and conditions. Sometimes it will be internal to the customer organization. But there is a complex process within Amalgamated to circulate proposed revisions to terms and conditions through Marketing, Engineering, and Legal management teams to ensure that Amalgamated can live with the changes. Unless we examine the interaction between the Counsel actors and the marketing rep in detail through this use case, we will miss important transactions of value for this enterprise. Here is another situation where the use of pre and post-conditions will help support our analysis of the customer environment. We can specify the following precondition: Precondition: a draft contract is available Postcondition: Counsel has approved the contract (with possible amendments). Final contract text made available to internal Counsel, to Marketing and to site support.

Nested Use Cases Some analysts say that we should take a nested approach to use case analysis in the enterprise. If we follow that approach, we would say that the marketing rep would become the Actor at the next level, and we would then have a place to define all the activities that the marketing rep performs in interacting with the rest of the Amalgamated organization. That helps somewhat, but does not address the problem of identifying other external actors at each level. Instead, we must take a fresh look around at each level of the use case, define all the actors (both internal and external) who actually are involved at that level, specify the data that they need and the functions that they need to perform with the data. We must indicate the pre and post-conditions explicitly. In a multi-layered enterprise, there are often pre-requisite tasks that must be done before other tasks can complete. If we don't specify these in our use cases, we run the risk of invalid assumptions being made as the object model is constructed. That won't help our users or our modelers — or our customer satisfaction metrics. Figure 1 shows the layers of the revised Amalgamated use cases. Obviously the drawings get to be very complex; we don't want to go much further without suppressing some detail. At the same time, we need to be sure that our methodology will actually ensure that we capture all essential detail to produce a valid model.

Enterprise modeling with use cases

•e 1: Layered Use Cases

Identifying Key Elements When we work on a very large system, there are necessarily several analysts who are developing use cases independently. Usually our developers have divided up the prospective systems into major functional chunks (e.g., Marketing, Installation Planning) and assigned one or two analysts to each. These analysts document their use cases, work with their customers, etc., with a fairly minimal amount of interaction across functional groups. Whether that is totally desirable or not is a topic for another paper ~ but it does allow the teams to carve up the work and get on with development. On a complex project, that is a crucial capability. No one can be involved in everything. One fact of corporate life is that people move in and out of projects, in and out of the company ~ in other words, there is no guarantee that the analyst who wrote the use case will be around to answer questions when the coder is ready to develop the dynamic model or the tester is ready to write the acceptance test.

294

Chapter 17

We have found that interpreting any sort of requirements documentation (not just use cases) in the absence of the original author is prone to error, particularly errors of context or assumptions. The author took certain things for granted, and simply didn't think to write them down. Gause and Weinberg [G89] wrote a wonderful book on making requirements unambiguous. Absent the amount of time necessary to implement all their recommendations, we did develop one simple construct that helped identify the important elements in a use case ~ that is the "Because" statement. The "Because" statement in each use case gives the rationale for the transaction - why the user needs to do it. We sometimes included a Because within the transaction steps in a use case, as shown below, because it clarified an important but unobvious requirement. Recall the following transaction step from our earlier use case: 3. Customer Service receives bingo card and generates a customer contact record in data base Because: The customer contact record is used to generate call sheets for Marketing and to assess the effectiveness of our advertising campaign (by counting the number of cards returned from a particular ad in a particular publication.

The simple Because statement clarifies to subsequent analysts why this step is important. It identifies the owners of the contact data record (Marketing) and explains how and why that data is used. This is clearly an important requirement - not a candidate for cost-cutting removal. Developing Because statements with users is a real exercise in clarification - it's amazing how different the users' perceptions of the rationale for transaction can be. By validating this assumption, a great deal of irrelevant or dubious function can be eliminated. Managers relate to the Because statement really well - they can see why they have to pay for implementation of that particular use case - or why they can safely chop it. Testers find it helpful, too.

Tracking Use Case Relationships Cognitive control of the overall system gets more and more difficult as the use cases proliferate. Once there are more than fifty or so, a structured organization scheme needs to be set up so that the right use cases can be found at the right time. There is no consensus on how use cases should be organized. Some analysts organize them by actors (e.g., all use cases where the principal actor is a lab technician are grouped together). Some organize the use cases functionally (thus, all use cases pertaining to installing the analyser would be grouped together). Other projects don't have much of any organization to their use cases at all. They often have trouble relating their scenarios (instantiations of a use case with specific data) to the correct use

Enterprise modeling with use cases

295

case because they do not develop a numbering or indexing scheme for the documentation. Clearly this makes traceability and review difficult for complex projects. We developed the concept of a Use Case Roadmap, a table of dependencies for the use cases which shows sequencing (if necessary), concurrency (if possible) across the use cases. I know that Jacobson says that sequencing is not a matter for use cases and should be left to other phases of analysis (e.g., dynamic modeling). However, when we were working with users and trying to validate the use cases, it was frankly difficult not to have such a table for reference. We had no credibility if we did not indicate that we had to sell the blood gas analyzer before we presented the client with a bill or began the installation process. Simple tables work pretty well for this purpose. Decision trees were also useful in showing the relationship of transactions to each other.

Extending the Methodology We have extended the use case methodology to say: 1.

When enumerating the use case, include processing steps which are not strictly necessary to satisfy the external interface, but which are necessary to complete internal functions that are important at this level of abstraction (e.g., don't worry about low level details in the high level use cases, but do indicate the functions at this level which are required to support the enterprise).

2.

When extending a use case, do not confine your analysis to the functional "stovepipes" (e.g., looking only at Marketing). Look across the entire organization, in all departments, to find new actors and new functions that interact with other parts of the user community to complete the entire "transaction of value". If we had concentrated only on the Lab Director, we would have missed the interaction with the Counsel and with the Lab Technician. In addition, there are other important actors who should have use cases of their own (e.g., the Hospital Engineering department, who will prepare the site for the chemistry machine, contract for plumbing and wiring, etc.).

3.

When examining an internal actor for Subordinate use cases, examine the actor's roles and determine which internal and external actors must be involved with each role. This provides a completeness check which helps alleviate the "missing actors" problem.

4.

Specify pre and post-conditions as part of the use case, where relevant. In particular, specify data that must be available in order for the use case to be implemented and data which must be provided to other use cases when this use case is complete. Keep the data definitions limited to simple descrip-

296

Chapter 17

tions of the data necessary; do not include data types, field sizes, structures, etc. 5.

Add "Because" statements to each use case (and to individual transaction steps, where appropriate). If you can't come up with a simple Because statement for the use case, it is either too complex (and should be subdivided) or it is not really a "transaction of value" and should be eliminated.

6.

Use tables, decision trees or other techniques to organize the use cases. Numbering schemes and naming conventions are also important. All the analysts on the project should use the naming schema in a consistent way (this is a task for management - it is a critical success factor).

To implement point 3, examine the interfacing Actor that spans the Superordinate and the Subordinate use cases (e.g., the Marketing Rep interacts with the external actors in the Superordinate use case and becomes the external actor for the Contracting Subordinate use case). Look at all the roles that the Marketing Rep plays in dealing with external actors (e.g., he contacts the customer, provides a bid, supports the installation process, supports the training process, manages the customer ordering process, etc.). For each role, examine all the transactions internal to the organization and with the customer to ensure that all necessary use cases are identified.

Conclusion Use cases provide a very useful method for organizing information about an enterprise. Care must be taken to look at the complete enterprise and not to stay within the narrow view of each functional organization, such as Marketing or Engineering. The entire process flow can only be known by systematically searching for actors at every level of the organization ~ internally and externally. Likewise we must be careful not to ignore data requirements within the use cases. Data and functions should be considered together in terms of requirements as well as during modeling.

References [G89] Gause, Donald C , Weinberg, Gerald M., "Exploring Requirements: Quality Before Design", Dorset House, NY, 1989. [H94] Hammer, Michael, Stanton, Steven, "The Reengineering Revolution: A Handbook", Harper Business, New York, 1994. [J94] Jacobson, Ivar, Ericsson, Maria, Jacobson, Agneta, "The Object Advantage: Business Process Reengineering with Object Technology", Addison-Wesley, New York, 1994. [J95] Jacobson, Ivar, "Use Cases in Large Scale Systems", Research on Object Oriented Analysis and Design (ROAD), Vol. 1, No. 6, March-April 1995, p. 11. [J94a] Jacobson, Ivar, Christerson, Magnus, Jonsson, Patrik, Overgaard, Gunnar, "Object-Oriented Software Engineering: A Use Case Driven Approach", Addison-Wesley, New York, 1994. [KR94] Kilov, Haim, Ross, James, "Information Modeling: An Object-Oriented Approach", Prentice Hall, 1994.

18 FORMAL OBJECT-ORIENTED METHOD-FOOM Paul Swatman Centre for Information Systems Research Swinburne University of Technology, P.O. Box 218, Hawthorn, Victoria 3122 Australia Email: [email protected]

ABSTRACT FOOM (Formal Object-Oriented Methodology) is a method which assists in understanding and modelling organisations and thus information systems. The method promotes: • highly appropriate and precise requirements specifications for information systems • models of organisational and inter-organisational processes, which may form the basis for organisational and network reengineering. In this paper, I summarise FOOM, which has been under development since 1989 and which was initially described by Swatman & Swatman [SS92a], and argue that the FOOM approach offers clear potential benefits within the Information Systems domain. The paper is non-technical in nature and is designed to offer a summary of existing work and future directions. References to the detailed and technical publications of the FOOM project are provided for the interested reader.

298 INTRODUCTION Boehm's studies of systems development at IBM and TRW [B76], which are still widely accepted, showed that approximately 60% of system faults can be traced to specification errors, ambiguities and omissions. The FOOM project has developed and continues to enhance an information systems requirements engineering method which focuses on the problem of precisely specifying appropriate systems. This paper describes, in outline, FOOM and provides references to the published literature on the detail of the method for the interested reader. Much of this literature is accessible via the Web1. This paper is structured as follows: Background The motivation for FOOM and the issues which the method addresses The FOOM Project A brief history and a description of the FOOM approach in outline The FOOM specification The format of the output of our requirements engineering method and how this document is validated and used Current and future work Documentation of design rationale and the development of support tools; further evaluation and evolution of the method. In this paper, I use the first person singular ("I") to indicate my views as the author of the paper and the first person plural ("we") to indicate the views of the FOOM project team in general.

BACKGROUND We were motivated by the dissatisfaction with the performance of the Information systems profession which was pervasive within commerce and industry. The focus of that dissatisfaction is often referred to in the literature as the "Software Crisis" [B87, S87, S92a]. In developing FOOM we have focused on the commercial and industrial rather than the technical and scientific domain. This domain is characterised by clients whose education and focus is primarily non-technical; and by information systems where the complexity of the social and organisational aspects overshadow the technical difficulties. Computer scientists and software engineers appear to have shown little interest in

The URL for the FOOM home page is: http://mae.ba.swin.edu.au/~paul/foom.html

Formal Object-Oriented Method—FOOM

299

studying the peculiarities of systems development within this domain - most research to date has been undertaken by the Information systems community - and the foci of interest and thus the approaches taken by these communities of researchers are quite distinct [SS92a]. We have synthesised a method for understanding and modelling problem situations and for specifying and validating the requirements of intervention in those situations, based on ideas developed within both communities. Our method, FOOM, is designed to assist in the process of developing systems which are: • conformant to requirements • buildable • maintainable

Conformance Conformance to requirements is a central goal of any programme of high-quality information systems development. We consider this concept in two parts: • conformance of the specification to the requirements of the clients; and • conformance of the resulting system to the specification It is important that the specification appropriately and accurately represent the problem context, as well as the requirements of and constraints on any proposed intervention. The positivist, objectivist philosophy, which (largely unacknowledged) underlies much of the software engineering community's research into systems development methods, has been widely criticised within the information systems literature. The critics argue that in socio-organisational contexts there exists no single, objective statement of requirements just waiting to be uncovered, but rather that such contexts may only be viewed subjectively through the cognitive filter of the various associated actors (see, for example, [C81,C95]). A number of approaches to understanding problem situations which take into account these ideas have been embodied in systems development methodologies, including: Soft Systems Methodology [C81, C89, C95, CS90], ETHICS [MW79] and Multiview [AWH86, WHAA85]. In developing FOOM, we have been strongly influenced by these ideas which enhance the process of eliciting information and understanding of problem contexts and thus contribute to improving the conformance of the specification. Problems do, however, remain. No existing requirements engineering methods which adopt these ideas deliver specifications which are formal (in the sense that they are mathematically precise). The questions, then, are: • How can we validate a requirements specification which has no precise meaning? • How can we reliably design and implement a system which fulfills a specification which has no precise meaning? These questions are, of course, unanswerable. An imprecise specification cannot form

300

Chapter 18

an adequate basis for communication or agreement between the modellers and the actors in the problem domain, nor may it provide a basis for communication with those who will design and implement a specific intervention ("solution"). In principle, the problem of precise representation has long been solved - all engineers understand the necessity and benefit of building mathematical models both for analysis and communication and, within the software engineering research community, formal specification has been the focus of considerable interest for some time. In recent years, we have seen increasing use of formal methods in the development of safety-critical software systems particularly. If we are to build high-quality information systems, it is clear that the specification must be sufficiently precise to provide a baseline for the evaluation of conformance. Consequently, requirements in FOOM are represented in a mathematically formal specification language. Formal languages allow us to be precise in our communication, but do not necessarily allow us to be effective. For example, the monolithic COBOL and FORTRAN programs of the 1960s were precise specifications, but they quickly became difficult to maintain because, although they were effective mechanisms for communicating with compilers, they were ineffective for communicating with people. We must be able to communicate the specification to the actors in the problem context and the designers/implementors of the consequent intervention. We seek: • to reduce cognitive dissonance between the model which underlies our specification and the models in the minds of the domain actors and the design/implementation team • to assist the design implementation team to build their own mental model of the required system. We have addressed these goals by: • adopting object-orientation as the underlying abstract architecture for FOOM specifications. The 0 0 community believes both that we naturally understand the world in terms of systems of interacting objects and that OO systems development is seamless in the sense that requirements, design and implementation models for a given system are, typically, architecturally similar (see, for example, [HSE94]). • incorporating a object-oriented diagrammatic notation (drawn from MOSES [HSE94] then extended and modified by Fowler et al [FSW95] and Wafula & Swatman [WS95a, WS95b]) as descriptive documentation. The adoption of an object-oriented abstract architecture also allows us to emphasise reuse. Reuse of well-defined high-quality components reduces some of the opportunities for error in the design/implementation process, provided that appropriate components may be identified. Naturally, reuse of a domain artefact (together with its design and implementation) offers more leverage than reuse of a design artefact which, itself, offers more leverage than simple reuse of an implementation artefact. One significant problem remains. The conventional wisdom has been that mathematically formal techniques would be unacceptable and, in any event, ineffective

Formal Object-Oriented Method—FOOM

301

within the commercial IS context. In our work we have challenged this belief, successfully using formal specifications supplemented by explanatory diagrams, text and discussion in collaborative requirements engineering projects within conventional commercial contexts.

Buildable Systems We see three important trends in software development occurring at an organisational level: • the move to third-party systems development [B86,D87, HM84, RH88, SM86, SS90, SSE90] • system assembly from variously sourced components [A90, G90, M89, R91, S90, VK90]. In these, the development (the design and/or the implementation) of individual system components is sub-contracted (sometimes under the control of a specialist systems integrator, sometimes under direct in-house control) to a variety of third-party organisations. In the general case, some components may be developed in-house. When integrated, these components form the final system • the increasing importance of inter-organisational information systems [F87, RE88,SS92c]. These trends clearly suggest that, increasingly, information systems will be developed in a complex, multi-organisational context where there may be multiple client organisations and where the "solution" designer(s) and implementor(s) may be organisationally independent of any client. We must, therefore, adopt a requirements specification architecture within which the design and implementation of precisely described components may be subcontracted in a manner analogous to that adopted in more conventional engineering domains. We suggest that formally precise specifications based on an Object-Oriented architecture address this problem.

Maintainable Systems Systems do, of course, change during their lifetime - estimates of the ratio of maintenance/enhancement cost to development cost of systems range up to 2:1 and beyond. OO is argued by its proponents to be an intrinsically more maintainable architecture than the common alternatives (see, for example, [HSE94]) and we accept these arguments - which appear to be theoretically sound, though I am not aware of any conclusive empirical evidence in support. We have more recently begun to grapple with a further aspect of maintainability - that of understanding existing systems. Our work is incomplete but I will, nonetheless, outline the concepts here. In our earliest work, we considered the problem of communicating our specifications to the domain actors on the one hand and to the designers and implementors on the other. We are only now considering communication

302

Chapter 18

with maintainers and enhancers of the system. We see the difficulties here as being similar in many ways to those which face: • the developers of reuse libraries • the developers of corporate data models. [C96] and [S96] have shown that one of the difficulties with ongoing use of corporate data models is that potential reusers are unable easily to understand the models. A potential solution to the problem in this case is the annotation of the data model with design rationale - that is, to include documentation which illustrates the reasons which underlie the specific architecture of the data model.

HISTORY OF THE FOOM PROJECT [SS92a] describe, in outline, a framework for an information systems development methodology, widely applicable within the conventional information systems domain, which draws upon a number of established areas of research: Socio-organisational contextual analysis following the work of Checkland [C81, C89, C95] and Checkland & Scholes [CS90] which, in the general case, denies the existence of a single, objective requirements specification waiting to be discovered by the systems analyst The object oriented approach in which situations are modelled as systems of interacting, encapsulated objects, each object belonging to some class Mathematically formal specification languages in particular, the object oriented specification language Object-Z [DKRS91] by means of which the abstract characteristics of classes may be described precisely and unambiguously. Figure 1 depicts a process model, developed by Fowler [F96], based upon the initial FOOM framework. All three areas of research make a contribution to the systems analysis and requirements modelling process. The socio-organisational approach is relevance-centred. It is concerned with increasing the likelihood that the impact of intervention within the organisational context would be understood — and, thus, that any intervention would be appropriate. Although the major contributions promoted by adherents to the object oriented approach are concerned with engineering aspects of the systems development process (such as modularity, information hiding, robustness, reuse, traceability), the approach also offers a contribution to communication between specifier and client, to the extent that object orientation is a natural modelling paradigm (see, for example, [HSE94]).

Formal Object-Oriented Method—FOOM

303

I requirements specification

Figure 1: The FOOM Process Model Formal Specifications were, initially, considered to be a conformance-centred approach to software development. They were presented as a basis for a formal "concretisation" process2 leading to provably correct code. More recently, formal specifications have come to be acknowledged for their contribution to problem understanding [H90, S92a, SS92a, W90], their precision offering potential for enhanced communication and evaluation of understanding. Our preliminary research [FSS93, S93, SFG92, SS92a] suggested that a socio-organisational approach could be used beneficially in concert with object oriented formal specification techniques within the information systems domain. The FOOM framework was developed by synthesis and logical argument, drawing on research in a number of largely independent areas across the breadth of the information systems and software engineering domains [SS92a, SS92b]. Preliminary evaluation of feasibility and potential benefit were undertaken by means of simulated [SSD91] case studies and small commercial [SFG92] system specifications; and by means of educational case studies and pseudo-laboratory experiments [S93].

Understanding and Modelling Problem Domains

This process is normally referred to as refinement within the specialist literature (see, for example, [M94]. In this paper we use refinement in its more common sense of clarification or increasing relevance

304

Chapter 18

In common information systems development practice, a problem context is first informally and then systemically specified. The informal specification is ambiguous, imprecise and contradictory. Various systematic specification techniques3 have been designed to reduce this ambiguity, imprecision and contradiction. Unfortunately, while systematic techniques assist in this process, only specifications written in formal languages which have a well-defined syntax and semantics are capable of precise analysis. Once the solution design and implementation have occurred, the formalised information system which results has a well-defined behaviour, free of ambiguity. Programming languages are, in a sense, mathematical specification languages and a program listing (in, for example, C or COBOL) is, therefore, a precise and complete specification of the behaviour of the corresponding executable - all programs do something, the question is whether or not this something happens to match the intention of the specifier. In essence then, the systems development process takes an ill-structured and possibly contradictory context as input and delivers, inter alia a precise, well-defined (but, too often, neither the desired or expected) computer system as output. The critical issue, therefore, is to determine at what point we should resolve the imprecisions, ambiguities and contradictions of the problem context. The FOOM approach, which is illustrated in Figure 2, is to resolve these issues during the information analysis process. The

ARCHITECTURAL MODEL

Analysis

• Refinement

• Validation

<

< Figure 2: Information Systems Development

argument, set out in detail in [SS92a], is based upon the following assertions: • we must formalise our approach sometime (a program is mathematically precise — if somewhat difficult for human beings to analyse) • it is significantly more likely that the participants in the information analysis process (which would include actors within the context) would bring problem-context-related worldviews to the identification and resolution of ambiguities and contradictions than would software designers and computer programmers whose worldview is likely to be essentially technical

J

For example, Dataflow Diagrams [D79]

Formal Object-Oriented Method—FOOM •

305

a formal specification of requirements may be communicated to the designers and programmers precisely and unambiguously.

Following an extensive action research undertaken in collaboration with the Western Australian Department of State Services (DoSS), some aspects of which have been reported by Swatman et al [SFG92] and Fowler et al [FSS93], both the FOOM process and the model (requirements specification) which forms the deliverable from that process have been refined. Fowler & Swatman [FS96] describe the process in detail. This action research project has provided strong indictive support for an approach in which OO Analysis diagrams drawn, in modified form, from MOSES [HSE94] are used with text to document the definitive Object-Z specification. We have therefore developed a semantic correspondence between Object-Z and modified MOSES OO analysis notation. The complete mapping may be divided into three main parts: A structural model which involves mapping the classes and the various structural relationships between them (in particular, inheritance, association and aggregation) described within an Object-Z specification on to MOSES diagrams [WS95b] An object communication model which associates, with the Object-Z specification, a pictorial representation of message passing between the objects and, therefore, control [WS95a]. The pictorial representation corresponds to the notions of interaction graphs [CABDGHJ94], event models [HSE94], interaction diagrams and object diagrams [B94] A dynamic model in which Event Chain notation [FSW95] is used to illustrate and lead the reviewer to a full understanding of the Object-Z fragments extracted from the formal specification which combine to define unambiguously the dynamics of the system.

4 THE FOOM SPECIFICATION The DoSS action research project has also provided strong indicative support [FSW94, FS94] for an approach to specification presentation in which, firstly, requirements specifications are divided into several sections, each having a different focus, to cater for the needs of different audiences and, secondly, OO analysis diagrams drawn, in modified form, from the systematic OO methodologies are used with text in an explanatory role. The FOOM approach suggests that requirements specifications be presented in the following form: An executive summary forms the first part of the specification. Designed for

306

Chapter 18 presentation to management, this section contains a textual explanation of the system at a very high level, supplemented by informal diagrams

A behavioural perspective is presented in the middle section, in which Event Chain notation [FSW95] is used to illustrate and lead the reviewer to a full understanding of the fragments extracted from the formal specification which combine to define unambiguously the dynamics of the system. In essence, the reviewer is assisted to consider the specification of the system from a behavioural perspective, firstly at an intuitive level by means of the Event Chain diagrams, then formally, precisely and unambiguously by means of appropriately combined fragments of the complete Object-Z specification which is contained in the final section. The behaviourally oriented section is designed for those user(s) responsible for accepting the specification The formal specification in its entirety is presented last and is intended for those responsible for taking the requirements specification and developing the resulting system. The specification is presented in the traditional fashion, with text and OO Analysis diagrams used to explain the mathematics. The development of a well defined mapping from Object-Z into MOSES [HSE94] notation extended by Wafula & Swatman [WS95a, WS95b], has been the subject of recent work by Wafula [W95].

SUMMARY AND FUTURE WORK The FOOM approach, outlined by Swatman [S92c] has been refined by Fowler [F96] through application in a multi-organisational development of a major interorganisational information system. Version 1 of FOOM is now documented in [FS96]. Our research has demonstrated that the FOOM approach can be used, apparently beneficially, in typical IS environments - but further evaluative work is clearly required. To date, FOOM has been applied only in small or artificial systems developments as the subject of case studies on the one hand; and in a realistic project, but within an action research framework, on the other hand, in which the method evolved as a result of the identification of difficulties and opportunities. The next phase of the evolutionary process must, we believe, be a series of realistic field trials - we reject the usefulness, certainly at this stage of the development of FOOM, of controlled experiments since our primary concern is to confirm the existence of potential practical benefits from the use of the methodology. There are, however, technical difficulties to be overcome before such realistic case studies may be undertaken: •

Object-Z, the formal notation which underlies FOOM, contains many mathematical symbols and conventional word processing software offers only limited support for the creation of Object-Z specifications. In our research to date, we have used a set of macros which were developed at the University of

Formal Object-Oriented Method—FOOM

307

Queensland to extend the LaTeX typesetting system. This technique, while valuable so far, would, we believe, be totally unacceptable in the professional information systems domain. Some research has already been undertaken into the design of an appropriate user interface to Object-Z [S92b, W94] •

The presentation of the requirements specification resulting from the application of FOOM, discussed above, requires that the formal specification not only be presented in full (in section three of the requirements specification) but also that fragments be extracted from it and also presented in section two ... perhaps more than once. It is of course essential that the specification remain consistent! Further, the 0 0 diagrams which support the reviewers' understanding of the formal specification must also remain consistent with the formal specification. Initial work in this area [T94, W95] suggests that it is possible to mechanise the maintenance of consistency to a significant degree and, in any event, to mechanise consistency checking.

Tan [T94] has created the outline design of a FOOM workbench, both to support the creation of Object-Z specifications and associated explanatory diagrams and to support consistency maintenance. Work has recently commenced on the development of a prototype based on this outline design and we hope to begin field trials in late 1996. Further work on the documentation of design rationale within FOOM specifications (and the benefits thereof); and on quality within the FOOM analysis process itself is currently being undertaken within the Centre for Information Systems Research at Swinburne University by Nguyen and Carroll respectively.

REFERENCES [A90]

Ambrosio, J. (1990). Soul searching: Four case studies. Computerworld, pages 69-73.

[AWH86]

Avison & Wood-Harper, A.T.( 1986). Multiview—an exploration in information systems development. Australian Computer Journal, 18 (4), 174—9.

[B76]

Boehm B.W. (1976). Software engineering. IEEE Transactions on Computers, C-25(12), 1226-1241.

[B86]

Brooks Jr., F.P. (1986) No silver bullet: Essence and accidents of software engineering. In H.-J. Kluger, editor, Information Processing '86, Amsterdam. Elsevier Science Publishers B.V.

[B87]

Booch, G. (1987). Software Engineering in Ada. Benjamin Cummings, Menlo Park, 2nd edition.

[B94]

Booch, G. (1994). Object-Oriented Analysis and Design with Applications. Benjamin Cummings, Redwood City, California, 2nd edition

[C81]

Checkland, P.B. (1981). Systems Thinking, Systems Practice. Wiley, Chichester.

Chapter 18 [C89]

Checkland, P.B. (1989). Soft systems methodology. Human Systems Management, 8(4), 237-289.

[C95]

Checkland, P.B. (1995). Soft systems methodology and its relevance to the development of information systems. McGraw-Hill Book Company Europe, Berkshire, England.

[C96]

Chaiyasut P. (1996). Title. PhD thesis, Department of Information Systems, Monash University, P. O. Box 197, Caulfield East, 3161, Australia, (under examination).

[CABDGHJ94]

Coleman, D. Arnold P., Bodoff S., Dollin C , Gilchrist H., Hayes F. and Jeremaes P. (1994). Object-Oriented Development: The Fusion Method. Prentice Hall, Englewood Cliffs..

[CS90]

Checkland, P. & Scholes, J. (1990). Soft Systems Methodology in Practice. Wiley, Chichester.

[D79]

DeMarco, T. (1979). Structured Analysis and System Specification. Yourdon Press, New York.

[D87]

Dearden, J. (1987). The withering away of the IS organisation. Sloan Management Review, pages 87-91.

[DKRS91]

Duke, R., King, P., Rose, G., & Smith, G. (1991). The Object-Z specification language: Version 1. Technical Report 91-1, Software Verification Research Centre, Dept. of Computer Science, Univ. of Queensland, Australia.

[F87]

Foundation, B.C. (1987). Competitive edge applications—myths and realities. Research Report 61, Butler Cox and Partners Limited, London.

[F96]

Fowler, D.C. (1996). Formal Methods in a Commercial Information Systems Setting: The FOOM Methodology. PhD thesis, Centre for Information Systems Research, Swinburne University of Technology, P. O. Box 218, Hawthorn 3122, Australia, (under examination).

[FS94]

Fowler, D.C. & Swatman, P.A. (1994). Validating object oriented formal requirements specifications: A description of an action research study. Working Paper 1994-13, Centre for Information Systems Research, Swinburne University of Technology, P. O. Box 218, Hawthorn 3122, Australia.

[FS96]

Fowler, D.C. & Swatman, P.A. (1996). FOOM—a methodological description. Working paper, Centre for Information Systems Research, Swinburne University of Technology, P. O. Box 218, Hawthorn 3122, Australia, (forthcoming).

[FSS93]

Fowler, D.C, Swatman, P.A., & Swatman, P. M.C. (1993). Implementing EDI in the public sector: Including formality for enhanced control. ]n J.Gricar & J.Novak, editors, Strategic Systems in the Global Economy of the 90s, The 6th International Conference on Electronic Data Interchange and Interorganizational Systems, pages 244—256, Kranj, Slovenia. Moderna Organizacija.

[FSW95]

Fowler, D.C, Swatman, P.A., & Wafula, E.N. (1995). Formal methods in the IS domain: Introducing a notation for presenting Object-Z specifications. Object Oriented Systems, 2(2).

[G90]

Goodwin, S. (1990). Software integration, systems integrators and the automation process. Manufacturing Systems, pages 64—66. Hall, A. (1990). Seven myths of formal methods. IEEE Software, 7(5), 11-19.

Formal Object-Oriented Method—FOOM

309

[HM84]

Horowitz, E. & Munson, J.B. (1984). An expansive view of reusable software. IEEE Transactions on Software Engineering, SE-10(5), 477-487.

[HSE94]

Henderson-Sellers, B. & Edwards, J.M. (1994). BOOKTWO of Object-Oriented Knowledge: The Working Object. Prentice Hall, Sydney.

[M89]

Moad, J. (1989). Contracting with integrators. Datamation, pages 18-22.

[M94]

Morgan, C.C. (1994). Programming from Specifications. Prentice Hall International Series in Computer Science, 2nd edition. Mumford, E. & Weir, M. (1979). Computer Systems in Work Design: the ETHICS Method. Associated Business Press.

[MW79]

[R91]

Radding, A. (1991). Using subcontractors: Outside help is in. Computerworld, pages 57-60.

[RE88]

Runge, D. & Earl, M. (1988). Gaining competitive advantage from telecommunications. In M.Earl, editor, Information Management: The Strategic Dimension, pages 125—146. Clarendon Press, Oxford.

[RH88]

Rouse, R.A. & Hartog, C. (1988). The new MIS professional—part 1. Journal of Systems Management.

[S87]

Schneider, R.J. (1987). Prototyping toolsets and methodologies: User / developer sociology. In Proceedings of IEEE International Conference on Systems, Man, and Cybernetics.

[S90]

Stevens, L. (1990). Who does what is a tricky multiple choice. Computerworld, pages 63-67.

[S92a]

Sommerville, I. (1992). Software Engineering. Addison Wesley, Wokingham, England, 4th edition.

[S92b]

Stanton, W.A. (1992). Object-Z translator: A tool for the visualisation of object-oriented formal specifications using Object-Z. Honours thesis, Department of Computer Science, Curtin University of Technology, G. P. O. Box U1987, Perth 6001, Australia.

[S92c]

Swatman, P.A. (1992). Increasing Formality in the Specification of High-Quality Information Systems in a Commercial Context. PhD thesis, Curtin University of Technology, School of Computing, Perth, Western Australia.

[S93]

Swatman, P.A. (1993). Using formal specifications in the acquisition of information systems: Educating information systems professionals. In J.P. Bowen & J.E. Nicholls, editors, Z User Workshop: London 1992, Workshops in Computing, pages 205—239. Springer Verlag, London.

[S96]

Shanks G. (1996). Using and Understanding Corporate Data Models: A Case Study of an Australian Bank. Working paper, Department of Information Systems, Monash University, P. O. Box 197, Caulfield East, 3161, Australia. (Submitted for publication).

[SFG92]

Swatman, P.A., Fowler, D.C., & Gan, C.Y.M. (1992). Extending the useful application domain for formal methods. Jn J.E. Nicholls, editor, Z User Workshop: York 1991, Workshops in Computing. Springer Verlag, London.

[SM86]

Sprague, R.H. & McNurlin, B.C. (1986). Information Systems Management in Practice. Prentice-Hall International Editions, New Jersey.

310

Chapter 18

[SS90]

Swatman, P.A. & Swatman, P.M.C. (1990). The software reusability issue: Perspectives from software engineering and information systems. In Proceedings of the 1st Australian Conference on Information Systems.

[SS92a]

Swatman, P.A. & Swatman, P.M.C. (1992). Formal specification: An analytic tool for (management) information systems. Journal of Information Systems, 2(2), 121-160.

[SS92b]

Swatman, P.A. & Swatman, P.M.C. (1992). Managing the formal specification of information systems. In Proceeding of the International Conference on Organization and Information Systems, Bled, Slovania.

[SS92c]

Swatman, P.M.C. & Swatman, P.A. (1992). EDI systems integration: A definition and literature survey. Information Society Journal, 8(3).

[SSD91]

Swatman, P.A., Swatman, P.M.C, & Duke, R. (1991). Electronic Data Interchange: A high-level formal specification in Object-Z. In P.A. Bailes, editor, 6th Australian Software Engineering Conference (ASWEC91): Engineering Safe Software, Sydney, NSW.

[SSE90]

Swatman, P.A., Swatman, P.M.C, & Everett, J.E. (1990). Stages of growth of an innovative software house: An additional criterion for software package selection. Australian Computer Journal, 22(3), 81—91.

[T94]

Tan, C.H. (1994). The design of the FOOM workbench. Honours thesis, School of Computing, Curtin University of Technology, G. P. O. Box U1987, Perth 6001, Australia.

[VK90]

Vinton, R. & Knight, F. (1990). Systems integration: Sharing risks and responsibilities.

[W90]

Wing, J.M. (1990). A specifier's introduction to formal methods. IEEE Computer, 23(9), 8-24. Business Communications Review, 20(10), 18-23.

[W94]

Wan, L. (1994). A prototype syntax directed editor for Object-Z. Honours thesis, School of Computing, Curtin University of Technology, G. P. O. Box U1987, Perth 6001, Australia.

[W95]

Wafula, E.N. (1995). Graphical representation of Object-Z specifications using MOSES. MBus thesis, Centre for Information Systems Research, Swinburne University of Technology, P. O. Box 218, Hawthorn 3122, Australia.

[WHAA85]

Wood-Harper, A.T., Anthill, L., & Avison, D.E. (1985). Information Systems Definition: The Multiview Approach. Blackwell Scientific Publications, Oxford.

[WS95a]

Wafula, E.N. & Swatman, P.A. (1995). FOOM: A diagrammatic illustration of inter-object communication in Object-Z specifications. In Proceedings of 3rd Asia-Pacific Software Engineering Conference APSEC'95, Brisbane, Queensland.

[WS95b]

Wafula, E.N. & Swatman, P.A. (1995). Merging FOOM and MOSES: A semantic mapping from Object-Z to structural object-oriented diagrams. In Proceedings of the 6th Australasian Conference on Information Systems (ACIS'95).

A abstract class, 128, 131 abstract data type (ADT), 121 abstract model, 122, 137 abstract value, 121 abstraction and precision vii ff., 65 ff, 78 ff., 300 abstraction function, 121 acceptance by analysts and designers, 95 action 105, 108 active object 145, 153 active object system 154 actor 288 ff. Ada, 122 advantages of formal methods xi, 41, 72, 299-300 agent, 197, 201, 203, 204, 208, 210 ambiguities in the Core Object Model 20 architecture 2 assigned variable, 128 asynchronous, 271 attributes, 87 augmented semantic networks, 179, 183 automaton, 265

B background domain knowledge, 1867 behavioral interface specification, 122, 137 behavioral rules, 224-226 behavioral subtype, 131 boundary between analysis and design, 81 business changes, 85 business policy, 197, 200, 212, 215-8

business rule, 86, 88, 89, 90 business specification, 78, 92, 98, 243 business transformation, 91, 92 buy-in, 94

c C, 122 C++, 121, 122 Carroll, xi category theory, 223, 227, 230, 233 Chalin, 130 change of business systems, 92, 172 checkable redundancy, 124, 130 claims, 130 class, abstract, 128, 131 classification 194-5 closed system 104 coercion, see simulation, 133 collections of related things, 79 collective behavior xii, 77-100, 255 ff. combination of formalisms, 47ff commonality, 209, 214, 215 common knowledge, 83 compact specification of business rules, 88 completeness, 83 component, 4, 169 composite pattern, 247-8 composition xi, 68, 85-6, 169-70, 230-233,245,261 composition and its specializations, 86, 245 ff. composition, hierarchical, 150 composition of specializations, 230231 composition of theories, 232-233 configuration, 5 conformance, 299, 300, 303 connectors, 234-237

312

Index

consistency checking, 128 constructor, 133 context of a semantic network, 180 contract, 79, 197-217, 291 ff. (see also use case) copying whiteboard, 83 CORBA, 2 Core concepts, 21 Core Object Model, 18 creeping system scope, 83 CSP, 52ff. customer, xi, 77-100, 287-296 CV-Nets, 221, 224-225

D deallocation, 130 declaration, 207-9, 211, 214-7 declarative approaches, 84, 85, 223 ff. declassification, 194-5 defaults in requirements, 83, 293-4 deliberate omissions, 90 denotational semantics of automata, 271 design pattern, 247 design vs. analysis, 79, 82 details, 78 diagramming techniques, 94 different understanding of meaningful names, 91 Dijkstra, vii, 81 disadvantages of formal methods, 42 domain, 201, 202, 204, 209, 215, 216 dynamic classification, 195 dynamic typing, 88

E enterprise-wide business specification, 91 event, 202, 204, 207, 208 examples, in specifications, 128, 130 exception, specification of, 134 executions of automata, 273 expressiveness, 137

extension, 193-4

F fairness, 107, 108 feedback, 96, 99 field lengths, 90 FOOM, 297-300, 302-307 formal specification, 41 ff., 63 ff., 221 ff, 300, 301, 303-307 formality, tunable, 131 formality, tuning, 126, 133 frame axiom, 128 framework 250, 263, 264 Fresco, 126

G General Relationship Model, xi ff, 84, 256 generic relationships, 84, 86, 209, 245 ff. given set, 126, 131 goal of a business analyst, 78 Guttag, 122

H Hoare, viii, 121 Horning, 122 hyper-text, 12

I implicit semantics, 79 incremental behavior specification, 222-223, 227 incremental modeling, 111-114, 118 informality, 126, 131, 133, 137 information model, 242, 247, 257, 259 inheritance, 110-111, 113 inheritance from subevents, 189-90 inheritance, of specifications, 131 inheritance of automata, 265

Index

313

Insurance Application Architecture, 80,91,92 insurance, 85, 89 integration, 251 intension, 193-4 interface specification, behavioral, 137 interface, 121 international standards, 79 (see also General Relationship Model; Open Distributed Processing) interoperable interface, 251, 256 interworking, 250, 255 invariant, 68-9, 77, 79, 85, 88, 131, 209 inventing missing business knowledge, 82 is-a links, 180 is-a links, defeasible, 180 is-a links, strict, 180

L Larch Shared Language, 122 Larch, 122 Larch/Ada, 122 Larch/C++, 121, 122 Larch/Smalltalk, 122, 131 large projects, 91 LCL, 122, 128, 130 LCLint, 128 legacy OO approaches, 68 legacy systems, 45 ff, 84, 250-1 legal contract analogy, 95 levels of abstraction, 89 liberal specification, 129 life insurance company in 1835, 98 linking invariant, ix, 242 liveness conditions, 224, 226 liveness property, 106, 113, 116 LM3, 122, 131 localized control, 155 LSL, 122, 123

M manila folder, 94 mapping requirements and specification, 57ff meaningful names, 80, 91 member function specification, 129 message, 269 message-processing automaton, 269 messages, 90 meta level logic, 209 methodologies, 81 mini-spec, 95 model-based specification, 121 model-based, 122 modify, 130 Modula-3, 122 MooZ, 122, 131 multi-object action, 104 multiple classification, 195 multiple inheritance, 110, 113

N names of things, 91 need to market business specifications, 82 non-declarative approach, 82 non-trivial concepts, 94 nondeterminism, 108, 110 normal forms, 90

o object collaborations, 90 object lifecycle, 193,195 Object Management Group, 2, 17, 63 Object-Z, 122, 131,305-307 objects and relationships, 84 OOPSLA, viii-ix OOZE, 122, 131 Open Distributed Processing, viii, xi, xii, 256-8, 263-4 operation specifications, 84, 89 operational semantics of automata, 273

314

Index

operations, 79, 85 outsourcing, 81 overspecification, x, 81 ff.

P paradigm, 199, 218 paraphrase, 11 Parnas, vii, 95 partial correctness, 129 phases of specification acquisition, 43 ff. ports / interfaces, multiple, 234-236 post-state, 128 postcondition, 3 ff, 79, 85, 89, 121, 167,291 ff pragmatic approach, 44 pre-state, 128 preconceptions, 94 precondition, 3 ff, 79, 85, 89, 121, 226,291 ff preference principles for rule sets, 184 ff primary and foreign keys, 90 process composition, 144 productivity 242, 246, 257, 264 project failures, 78 proof system, 10 properties of good business analysis, 78 protocol, 3

Q queueing system, 147

R reactive systems, 224 realtime, 117 redundancy, checkable, 124, 130 reference relationship, 85, 174, 246 refinement, 97, 112 refinement of automata, 265

relationships, 77-100, 222 ff, 241264 (see also generic relationships; General Relationship Model) representing and categorizing rules, 186 requirements analysis, 290 ff requirements engineering process, 303 requirements in terms of solutions, 82 requirements elicitation, 82 ff reusable specification patterns, ix reuse by composition, 232 reuse by extension, 227 reuse, 84, 92, 99, 197, 209, 214, 215, 227, 232 rework, 81 rigorous definition, 91 role, 202, 203,207, 209,213 rules inheritance 183

s safety conditions, 224, 226 safety property, 106, 113 safety-critical systems, 5 Iff SAOS approach, 143, 156 scope of an automation project, 91 scribing, 83 security evaluation, 48 ff self, 129 semantic free "relationships", 98 semantic networks, 177 ff, 208-9 semantics vii ff, 94, 254 separation of concerns, ix ff set membership, 193-4 SHOC (structural and hierarchical object composition), 144, 150 signature, 79, 85 simplicity, 82, 83 SIMULA, 153 simulation function, 133 small teams, 83, 91 Smalltalk, 122 socio-organisational analysis, 299, 302, 303

Index

315

software architecture, 46 ff., 222, 232, 234-238 software reuse, 241, 251 solution specification, 78, 247 specialization, 227-229 specialization, monotonic, 227 specialization, non-monotonic, 228229 specification case, inLarch/C++, 134 specification inheritance, 131 specification validation, 305 specification, 1-311 specifying exceptions, 134 standards, definition of, 19 state transition diagram, 269 stream processing function, 272 streams, 271 structural active-object system, 143, 145 structural composition, 150 structuring and categorizing business rules, 90 subclass, 131 subevents, 181 subject matter domains, 201 subject matter experts, 91 subject-orientation, 84 substitution principle for objects, 278 subtype, behavioral, 8, 131 subtype, structural, 6 subtyping, 87, 245 ff. subtyping, multiple, 88, 193 ff. superposition, 111-114, 118 supertype, behavioral, 131

T Tan, 130, 137 Telecommunications Management Network (TMN), 252 ff. temporal logic 226 temporal logic of actions 105-108 tools, 93 tradeoffs, 84 training designers to read the specification, 83

training, 94 trait, 123 trash, 130 triggering condition, 79, 85 tunable formality, 131 tuning formality, 126 type of a collection of objects, 85 type of the object, 85

u unassigned variable, 128 understandability by business users, 81 understandability, 83 understanding, vii, 78 Unix file system, 56 ff. unnecessary details, 82 unstated assumptions, 83 use case, 206-7, 287 ff. (see also contracts for operations) use of diagrams, 86

V validation of specifications 59 valuations 224 VDM++, 122, 131 VDM-SL, 122 virtual, member function specification, 131

w walkthroughs, 91 Wing, 122 workflow, 85, 92 workflow-like concepts and constructs, 97 wrappers, 236

Y year 2000, 3 Iff.

316

Index

£ Z, xi, 21, 63 ff., 97, 122

Z and concurrent systems, 28 Z++, 122, 131 ZEST, 122, 126, 131