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 ( 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 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) 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, (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 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 | | <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) 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-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,

^ (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,