Table Of ContentPractical Foundations of Business System Specifications
Practical Foundations
of Business System
Specifications
edited by
Haim Kilov
Independent consultant, Millington NJ
and Affiliate Professor,
Stevens Institute of Technology, Hoboken, NJ, U.S.A.
and
Kenneth Baclawski
Associate Professor,
College of Computer Science,
Northeastern University, Boston, MA, U.S.A.
SPRINGER-SCIENCE+BUSINESS MEDIA B.V.
Library of Congress Cataloging-in-Publication Data
ISBN 978-90-481-6367-0 ISBN 978-94-017-2740-2 (eBook)
DOI 10.1007/978-94-017-2740-2
Printed on acid-free paper
All Rights Reserved
© 2003 Springer Science+ Business Media Dordrecht
Originally published by K.luwer Academic Publishers in 2003
Softcover reprint of the hardcover l st edition 2003
No part of this work may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, electronic, mechanical, photocopying, microfilming, recording
or otherwise, without written permission from the Publisher, with the exception
of any material supplied specifically for the purpose of being entered
and executed on a computer system, for exclusive use by the purchaser of the work.
CONTENTS
Preface Haim Kilov and Kenneth Baclawski ............. vii
1 Service-oriented Business and System Specification:
Beyond Object-orientation
Luis Filipe Andrade and Jose Luiz Fiadeiro ............... 1
2 Formalization of Situation Awareness
Kenneth Baclawski, Mieczyslaw K. Kokar,
Chistopher J. Matheus, Jerzy Letkowski
and Marek Malczewski ................................... 25
3 From RM-ODP to the formal behavior representation
Pavel Balabko and Alain Wegmann .. .................... 41
4 Towards the specification of software development processes:
An information modeling approach
Richard J. Balicki ....................................... 67
5 .NET Contracts: Attaching Specifications to Components
Mike Barnett, Wolfram Schulte
and Nikolai Tillmann .................................... 83
6 From Box-and-Line Drawings to Precise Specifications:
Using RM-ODP and GRM to Specify Semantics
Othmar Bernet and Haim Kilov ......................... 99
7 Domain Models of "The Market"
- in Preparation for £-Transaction Systems
Dines Bj¢rner .......................................... 111
8 Mathematics of UML:
Making the Odysseys of UML less dramatic
Zinovy Diskin .......................................... 145
9 Using Roles to Characterize Model Families
Robert B. France, Dae-Kyoo Kim,
Eunjee Song and Sudipto Ghosh ........................ 179
10 Business Modeling:
Modeling the Business Modeling and IT Businesses
Michael Guttman and Haim Kilov .. .. ... .. .......... ... 197
11 Flow-Service-Quality (FSQ) Engineering
for Specification of Complex Systems
Alan Hevner, Richard Linger,
Mark Pleszkoch and Gwendolyn Walton ..... ... ......... 215
12 Describing Architectures Using RM-ODP
Thomas Kudrass ........... ... ...... ... ... ... ... .... ... 231
13 Extending UML for Agent-Based Systems
James Odell, H. Van Dyke Parunak
and Bernhard Bauer .... ............. .... .. ............. 245
14 A Program for Building a State of the Art
Enterprise Ontology: Report on Progress
Chris Partridge and Milena Stejanova ... ..... ....... ... 271
15 Refactoring of Programs and Specifications
Jan Philipps and Bernhard Rumpe .. ... ........ ......... 281
16 Using Information Modeling to Initiate Business Strategies
- A Case Study for the E-Publishing Industry
Ira Sack and Angelo Thalassinidis ......... .......... ... 299
17 Games, Complexity and Interaction:
The Role of Games in Computer Science
Peter van Emde Boas ......... ............ ....... ...... 313
Author Index ........ ... ........ ..... ..... ......... .. ... 329
Index ...... ...... ... .. ........ ......................... 331
PREFACE
"In the mathematics I can report no deficience, except that it be that men do
not sufficiently understand the excellent use of the pure mathematics, in that
they do remedy and cure many defects in the wit and faculties intellectual. For
if the wit be too dull, they sharpen it; if too wandering, they fix it; if too inherent
in the sense, they abstract it."
Roger Bacon (1214?-1294?)
"Mathematics-the art and science of effective reasoning."
E.W. Dijkstra, 1976
"A person who had studied at a good mathematical school can do anything."
Ye. Bunimovich, 2000
This is the third book published by Kluwer based on the very successful OOPSLA
workshops on behavioral semantics (the first two books were published in 1996
[KH 1996] and 1999 [KRS 1999]). These workshops fostered precise and explicit
specifications of business and system semantics, independently of any (possible)
realization. Some progress has been made in these areas, both in academia and in
industry. At the same time, in too many cases only lip service to elegant specifica
tions of semantics has been provided, and as a result the systems we build or buy are
all too often not what they are supposed to be.
We used to live with that, and quite often users relied on human intermediaries
to "sort the things out." This approach worked perfectly well for a long time. How
ever, with the rapid development of e-commerce and agent-based systems, there is
no human intermediary, or such intermediation is too expensive. As a result, if the
system is not what it is supposed to be then its customer will quickly go to a com
petitor.
The series of OOPSLA workshops has successfully brought together practitio
ners and theoreticians who have been working to make precise and clear specifica
tions of semantics a reality. It has been especially important to go "Back to Basics"
by revisiting the classics and the foundations of our field.
One of the unfortunate characteristics of computing science and software engi
neering is a noteworthy lack of interest in work done "long ago". It is taken for
granted by many that a two-year old book could not possibly still be relevant. Yet the
computing classics published in the 1960s show that many concepts considered now
to be a recent invention have existed for a long time, perhaps under different names.
This includes, among many others, such concepts as pair programming, component
viii Preface
factories, the gross inadequacies of box-and-line diagrams, and the confusion gener
ated by a set of tacit assumptions. Then, as now, software engineering - especially
including business and system specifications - ought to be based on the types of
theoretical foundations and practical disciplines that are traditional in the established
branches of engineering. Systematic usage of the basic ideas from the classics would
prevent the enormous waste of effort resulting from reinventing - and sometimes
rejecting-these ideas.
The purpose of creating, purchasing and using a technological artefact - com
puter-based or not- is to satisfy some business need(s). However, decision makers
in the business technology field stressed that the trust and the patience of our cus
tomers have been exhausted due to poor quality of our products and services and
mismatched expectations [E2002]. The business needs and business environments in
which the IT artefacts ought to be used have often been considered less important
than the properties, real or perceived, of those IT artefacts.
The overemphasis on technological artefacts did not start yesterday. For exam
ple, one of the best books about the business of financial services includes the fol
lowing observation: "The casual visitor to the Stock Exchange is apt to come away
much impressed with the mechanical appliances on the floor ... but rather oblivious
to its much more important human mechanism. For the securities market is able to
function only through the highly specialized work of the several different types of
brokers and dealers who go to compose it. Indeed, the day was when the only me
chanical appliance in the New York stock market was the old buttonwood tree ... "
[M1930].
Here is a more recent example of a less than optimal approach to serving busi
nesses: "Earlier this year, Ford Motor Co. was forced to write off $1 billion of the
value of its inventory of palladium and other precious metals used to manufacture
auto-emissions parts. The problem? While new engineering designs called for less
palladium, Ford's purchasing department continued to stock up on the pricey metal.
Then the price of palladium dropped, leaving the carmaker with a huge inventory."
[W2002]. However, the solution proposed in the article - a "financial-planning ap
plication [that] will bring businesses closer to the Holy Grail of real-time financial
planning" - is also less than optimal. Businesses are much better served by under
standing their problems and proposing business solutions rather than by applying
new and therefore better technologies. In this case, better financial planning, real
ized, for example, by commodity derivative trading, would have been a business
solution approach avoiding possible huge losses.
Business and IT organization stakeholders often express themselves in very dif
ferent ways. In order to create information management systems that serve the needs
of complex and rapidly changing businesses, or to understand what systems to buy,
effective communication is imperative. In order to communicate effectively, a small
collection of shared (by business and IT) concepts and constructs with clearly de
fined semantics is essential. These concepts and constructs - basic patterns of rea
soning - facilitate understanding and therefore bridge the gap between business and
IT. They ought to be used as a basis of all kinds of specifications, such as of tradi
tional businesses and of middleware artefacts.
Preface IX
Fortunately, we know a lot about these basic business patterns. Most have been
used for centuries in other areas of human endeavor, like engineering, business and
law (for example, essential patterns of market economy were eloquently and pre
cisely described by Adam Smith [S 1776] and Francis Hutcheson [H 1755) in the sec
ond half of the XVIII century). Important modeling and specification basics were
standardized in the ISO Reference Model of Open Distributed Processing [RM
ODP2]. The fundamental concepts and constructs usually come from mathematics or
philosophy, and their definitions can be translated from mathematical terms into
terms more familiar to various stakeholders. Of course, it may be of interest what
areas of mathematics-the art and science of effective reasoning (E.W. Dijkstra)
ought to be taught and how. Similarly, when we deal with very complex systems in
software engineering (including business modeling!), we recall that programming is
"the art of organising complexity, of mastering multitude and avoiding its bastard
chaos as effectively as possible" (01972].
Different users of specifications, especially business experts, may have serious
difficulties in reading and understanding them due to the complexity and size of the
specifications. However, if the basic concepts are explained (and the irrelevant de
tails ignored via abstraction) then these difficulties become resolved. Furthermore,
the explicit semantics of concepts and constructs we use helps a lot in distinguishing
between useful (in accordance with some explicit criteria) and less useful techno
logical artefacts massively introduced in industry (and to some extent in academia).
The approach of concept reuse, as well as of clear separation between essential
and accidental, is not unique to information technology. For example, ordinary busi
nesses in the US use the Uniform Commercial Code not only as a set of reusable
patterns of reasoning and acting, but also as a law. Moreover, stable and elegant
systems of concepts - rather than technological details - permit us to tame com
plexity of any system: we ponder to reduce reasoning to a doable (by humans or
computer-based systems) amount [D 1976].
The basic patterns of reasoning are much more stable than technological arte
facts - languages, methodologies and tools - used to represent them. Therefore
such technological artefacts as various versions of UML™ and XML ought to be
assessed from the viewpoint of their support (or otherwise) of the semantics of the
concepts and constructs which have to be represented using these artefacts.
The essentials of comprehensible specifications of business and of system arte
facts ought to be used by, and therefore understandable to, all customers of these
specifications - business subject matter experts, decision makers, analysts, IT ar
chitects and developers. These documents have to be abstract, precise and explicit
(see, e.g., [Kl999, K2002]). They have to be understood in the same manner by all
stakeholders. Specifically, as C.A.R. Hoare observed, only abstraction "enables a
chief programmer or manager to exert real technical control over his teams, without
delving into the morass of technical detail with which his programmers are often
tempted to overwhelm him" (Hl983). Since the tacit assumptions of different
stakeholders are often different, specifications should not rely on such assumptions
including "meaningful names".
X Preface
The book brings together theoreticians and practitioners to report their experi
ence with making semantics precise, clear, concise and explicit in business specifi
cations, business designs, and system specifications. It includes both theoretical and
very pragmatic papers based on solid and clearly specified foundations. A substantial
number of papers demonstrate that good business (and IT) specifications ought to
start with the stable basics of the relevant business domains, thus providing a foun
dation for describing and evaluating the details of apparently "always changing"
requirements.
While it is always tempting to provide a classification for a collection of papers,
once again we admit defeat. The papers are arranged in the order of the first author's
last name. In the tradition of our previous Kluwer books, we have asked the authors
to demonstrate the relevance of their theoretical work in the simplest possible terms.
On the one hand, the basics of many businesses were perfectly specified centuries
ago, and these specifications can be and have been successfully reused now. On the
other hand, only recently it became possible to articulate the common mathematical
ideas underlying different branches of mathematics and probably engineering. These
fundamental insights, both in category theory and in very pragmatic specification
and programming areas, lead to better understanding and thus to delivering products
and services that are what we want them to be (rather than what was hacked to be
delivered to and often hated by the customer).
By mixing the "theoretical" and "practical" papers together in one volume we
hope to show that these seemingly different papers address different aspects of a
single problem - they are all about understanding of business enterprises and of
information systems (computer-based or not) that these enterprises rely upon.
As editors and organizers of the OOPSLA workshops on behavioral semantics,
we would like to thank the organizers of the OOPS LA conferences for their wonder
ful assistance in running the workshops, as well as the authors of the book's articles
for their help in putting the work together. Many thanks also go to F. Robbert van
Berckelaer and Susan Vorstenbosch from Kluwer Academic Publishers for their
help.
We would like to thank our loved ones for their support, encouragement and tol
erance during our virtual and physical (workshop) absence.
REFERENCES
[01972] E.W.Dijkstra. "Notes on structured programming." In: 0.-J.Dahl, E.W.Dijkstra,
C.A.R.Hoare. Structured programming. Academic Press, 1972, pp. 1-82.
[D 1976] E.W. Dijkstra. "The teaching of programming, i.e. the teaching of thinking." In Lan
guage hierarchies and interfaces. (Eds. F.L. Bauer and K. Samelson), Lecture Notes in Com
puter Science, Vol. 46 (1976), pp. 1-10, Springer Verlag.
[E2002] Bob Evans (Editor-In-Chief), Information Week, February II, 2002.
[H 1755] Francis Hutcheson. A system of moral philosophy. Foulis, Glasgow & Millar, Lon
don, 1755.
