PREFACE The notation In software perhaps even more than elsewhere,thought and language are closely connected.As we progress through these pages,we will carefully develop a notation for expressing object-oriented concepts at all levels:modeling,analysis,design, implementation,maintenance. Here and everywhere else in this book,the pronoun "we"does not mean "the author":as in ordinary language,"we"means you and I-the reader and the author.In other words I would like you to expect that,as we develop the notation,you will be involved in the process. This assumption is not really true,of course,since the notation existed before you started reading these pages.But it is not completely preposterous either,because I hope that as we explore the object-oriented method and carefully examine its implications the supporting notation will dawn on you with a kind of inevitability,so that you will indeed feel that you helped design it. This explains why although the notation has been around for more than ten years and is in fact supported by several commercial implementations,including one from my company (ISE),I have downplayed it as a language.(Its name does appear in one place in the text,and several times in the bibliography.This book is about the object-oriented method for reusing,analyzing,designing,implementing and maintaining software;the language is an important and I hope natural consequence of that method,not an aim in itself. In addition,the language is straightforward and includes very little else than direct support for the method.First-year students using it have commented that it was"no language at all"-meaning that the notation is in one-to-one correspondence with the method:to learn one is to learn the other,and there is scant extra linguistic decoration on top of the concepts.The notation indeed shows few of the peculiarities (often stemming from historical circumstances,machine constraints or the requirement to be compatible with older formalisms)that characterize most of today's programming languages.Of course you may disagree with the choice of keywords (why do rather than begin or perhaps faire?),or would like to add semicolon terminators after each instruction.(The syntax has been designed so as to make semicolons optional.)But these are side issues. What counts is the simplicity of the notation and how directly it maps to the concepts.If you understand object technology,you almost know it already. Most software books take the language for granted,whether it is a programming language or a notation for analysis or design.Here the approach is different;involving the reader in the design means that one must not only explain the language but also justify it and discuss the alternatives.Most ofthe chapters of part C include a"discussion"section explaining the issues encountered during the design of the notation,and how they were resolved.I often wished,when reading descriptions of well-known languages,that the designers had told me not only what solutions they chose,but why they chose them,and what alternatives they rejected.The candid discussions included in this book should,I hope,provide you with insights not only about language design but also about software construction,as the two tasks are so strikingly similar.PREFACE ix The notation In software perhaps even more than elsewhere, thought and language are closely connected. As we progress through these pages, we will carefully develop a notation for expressing object-oriented concepts at all levels: modeling, analysis, design, implementation, maintenance. Here and everywhere else in this book, the pronoun “we” does not mean “the author”: as in ordinary language, “we” means you and I — the reader and the author. In other words I would like you to expect that, as we develop the notation, you will be involved in the process. This assumption is not really true, of course, since the notation existed before you started reading these pages. But it is not completely preposterous either, because I hope that as we explore the object-oriented method and carefully examine its implications the supporting notation will dawn on you with a kind of inevitability, so that you will indeed feel that you helped design it. This explains why although the notation has been around for more than ten years and is in fact supported by several commercial implementations, including one from my company (ISE), I have downplayed it as a language. (Its name does appear in one place in the text, and several times in the bibliography.) This book is about the object-oriented method for reusing, analyzing, designing, implementing and maintaining software; the language is an important and I hope natural consequence of that method, not an aim in itself. In addition, the language is straightforward and includes very little else than direct support for the method. First-year students using it have commented that it was “no language at all” — meaning that the notation is in one-to-one correspondence with the method: to learn one is to learn the other, and there is scant extra linguistic decoration on top of the concepts. The notation indeed shows few of the peculiarities (often stemming from historical circumstances, machine constraints or the requirement to be compatible with older formalisms) that characterize most of today’s programming languages. Of course you may disagree with the choice of keywords (why do rather than begin or perhaps faire?), or would like to add semicolon terminators after each instruction. (The syntax has been designed so as to make semicolons optional.) But these are side issues. What counts is the simplicity of the notation and how directly it maps to the concepts. If you understand object technology, you almost know it already. Most software books take the language for granted, whether it is a programming language or a notation for analysis or design. Here the approach is different; involving the reader in the design means that one must not only explain the language but also justify it and discuss the alternatives. Most of the chapters of part C include a “discussion” section explaining the issues encountered during the design of the notation, and how they were resolved. I often wished, when reading descriptions of well-known languages, that the designers had told me not only what solutions they chose, but why they chose them, and what alternatives they rejected. The candid discussions included in this book should, I hope, provide you with insights not only about language design but also about software construction, as the two tasks are so strikingly similar