Table of Contents
Foreword by Jon Bentley.
Preface.
Acknowledgements.
Introduction.
A.
Ambiguity.
The Application Domain.
Arboricide.
Aspects of Software Development.
B.
The Bridges of Königsberg.
Brilliance.
C.
The Calendar.
Classification.
Composition.
Connection Domains.
Connection Frames.
Context Diagrams.
Critical Reading.
D.
Dataflow Diagrams--1.
Dataflow Diagrams--2.
Definitions.
Dekker.
Descriptions.
Designations.
Deskilling.
Domain Characteristics.
Domain Interactions.
Domains.
E.
EntityRelation Span.
Events and Intervals.
Existence.
F.
Frame Diagrams.
The Fudge Factor.
G.
Graphic Notations.
H.
Hierarchical Structure.
I.
Identity.
Implementation Bias.
Individuals.
Informal Domains.
Is.
J.
JSP Frame.
L.
Logical Positivism.
M.
Machines.
Mathematics.
Method.
Misfits.
Models.
Mood.
A Multi-Frame Problem--1.
A Multi-Frame Problem--2.
N.
The Narrow Bridge.
O.
Object-Oriented Analysis.
P.
The Package Router Problem.
Partial Descriptions.
Phenomena.
Poetry.
Polya.
Predicate Logic.
Problem Complexity.
The Problem Context.
Problem Frames.
Problem Sensitivity.
Procrustes.
R.
Raw Materials.
Refutable Descriptions.
Reification.
Requirements.
Restaurants.
Rough Sketches.
S.
Scope of Description.
Shared Phenomena.
Simple Control Frame.
Simple IS Frame.
Software.
Software Engineering.
Span of Description.
Specifications.
T.
Top-Down.
Tree Diagrams.
Trip-lets.
W.
What and How.
Bibliography.
Index.
Forewords & Introductions
The practice of the book's title is the practice of software development, especially of the requirement and specification activities that often precede programming. The principles are those that I believe should govern software development and the methods by which we try to make it easier and more effective. And the prejudices are the settled personal opinions that I have formed over some years of thinking about these things.
The central theme of the book is the relationship of method to problem structure on one side and to description on the other. To deal with a significant problem you have to analyse and structure it. That means analysing and structuring the problem itself, not the system that will solve it. Too often we push the problem into the background because we are in a hurry to proceed to a solution. If you read most software development texts thoughtfully, you will see that almost everything in them is about the solution; almost nothing is about the problem.
On the other side, description is important because it is the clay in which software developers fashion their works. Methods are, above all, about what to describe; about tools and materials and techniques for descriptions; and about imposing a coherent structure on a large description task.
This book does not explain or advocate one particular development method. Nor is it a survey of methods, or an encyclopaedia of techniques and notations. It explains what I hope and believe are useful ideas and insights—both my own and other people's. It is arranged as an alphabetically ordered set of short pieces forming a lexicon, or a kind of specialized dictionary. Because many of theideas are neglected or simply unfamiliar, the selection of topics, the content and some of the terminology are unconventional. This is not in any way meant to be a standard reference work.
I chose the dictionary form for two reasons. First, because a more structured arrangement would have seemed to promise a unity and a completeness that I cannot attain. This is a collection of ideas and insights, not a new method. Second, putting the same point more positively, because I believe that many of the ideas in the book can be applied piecemeal in many different development contexts. They can be used to make local improvements in established methods, and to shed light on some of the local difficulties and problems that are met in any development.
Software development should be a thoughtful activity. You should think not only about the problem and its solution, but also about the way you're tackling it. Some software developers and method users behave as if they were bicycle riders. When you are riding a bike you shouldn't think about what you're doing. If you do think about it you'll probably fall off. But software development isn't like bike riding. You'll be a much better developer if you think consciously about what you're doing, and why. This book is intended to help you.
When you encounter a difficulty in software development, what you need above all is a set of appropriate conceptual tools. Perhaps you're trying to describe something that stubbornly refuses to fit cleanly into your description; or to disentangle the simple problems that you feel sure must lie beneath the intractable complex problem that is holding you up. The right conceptual tools help you to think consciously about what you're doing, often just by providing names for concepts that you already had but never articulated. So when you're struggling to get a description right it's helpful to be able to ask yourself: Have we got the right description span here? Are we sure we understand the designations well enough? Have we made a spurious classification? And when you're dealing with a problem complexity it's helpful to be able to ask yourself: Is this a multi-frame problem? Is there a problem frame misfit here? Are we trying to look at shared phenomena from the point of view of only one domain?
I hope that the lexicon form of the book will work to underline its nature. It is offered as a resource from which you can take what you want, not as another orthodoxy that demands acceptance or rejection as a whole. The arrangement of the book, I hope, will encourage you to browse and skip from piece to piece, and I don't expect it to be read straight through. Inevitably, this has led to some repetition, but not enough, I hope, to seem tedious. I have tried to make each piece self-contained but, of course, that is not always possible, especially for some of the pieces about less familiar ideas—such as problem frames. So there is a full index, and cross-references, capitalized in the text, from each piece to other relevant pieces. If you're feeling puzzled by a piece it may be a good idea to follow some of the cross-references in its earlier paragraphs before reading on.
If you prefer to read more systematically, you could start with the Introduction, which comes, out of alphabetical order, at the beginning. The Introduction lays out some of the main ideas, and puts them in context. Then you can follow the cross-references from the Introduction to anything that catches your interest, and so onwards from one piece to another. There is a bibliography that expands the short and informal references—both to books and to their authors—appearing in the text and adds a few bibliographical notes.
Another way of using the book is by taking a tour around one theme or topic at a time. I've prepared some itineraries of tours you might take. Most of them are quite short and don't try to include everything about their themes. You can take them in any order. As with most tours, the time needed will depend on how long you spend on the places of interest. Some places of interest appear in more than one tour. If you visited a place on a previous tour, you could stay on the bus. On the other hand, you might see something you hadn't noticed on your first visit.
Whatever your approach to this book I hope it will be useful to you: that you will find something in it to help you in your work, to illuminate a difficulty you have struggled with, to offer amusement or insight, to provoke you to thought, or in any other way to repay you for having opened it.
Michael Jackson
May 1995
Acknowledgements
Much of my working life so far has been occupied with devising, teaching, and using software development methods. In the 1970s and early 1980s I was deeply involved in the JSP method of program design and the JSD method of system development. Some of the themes and ideas of this book emerge indirectly from the successes of that work; some from its failures. I learned a lot from the many people I worked with during those years—especially from John Cameron.
I also learned a lot, although I did not always realize it at the time, from some people whose ideas about method were diametrically opposed to my own. As Mark Twain said: "When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to twenty-one I was astonished at how much the old man had learned in seven years".
Many of the ideas in this book have been formed and sharpened during several years of cooperation with Pamela Zave. Particularly, they have been influenced by her approach to multiparadigm specification, and have benefited from the insightful work that she has done in cooperation with Peter Mataga on specifying telephone switching systems.
Daniel Jackson has helped me in more ways than I can count. He read the whole book in at least two of its versions and commented in detail on every part of it. He explained many things I had not known or had misunderstood. He discussed many of the topics with me at length. And he has always been ready to offer advice, encouragement, and constructive criticism at just the right moments. As a small recompense I have stolen a quotation by Niels Bohr from his PhD thesis.
Some of the ideas in the book have been aired at meetings of the Software Development Research Group of the University of the West of England, Bristol. I am grateful to the other members of the group—Barry Cawthorne, Ian Beeson, Richard McClatchey, Steve Probert, Tony Solomonides, and Chris Wallace—for their interest and help. Chris Wallace introduced me to the work on patterns in object-oriented design.
Tom DeMarco helped me generously with many acute and sensitive comments. His suggestions have removed many stumbling blocks from the reader's path.
Much of the treatment of Dekker's algorithm follows the presentation in Dick Whiddett's book Concurrent Programming for Software Engineers.
Andy Ware of Addison-Wesley has been unfailingly tolerant and courteous to an unreasonable and curmudgeonly author. And Susan Keany has been an agreeable and efficient production editor. It has been a pleasure to work with them both.
To all these people, and to everyone else who has helped me, I am very grateful.
Read an Excerpt
PREFACE:
The practice of the book's title is the practice of software development, especially of the requirement and specification activities that often precede programming. The principles are those that I believe should govern software development and the methods by which we try to make it easier and more effective. And the prejudices are the settled personal opinions that I have formed over some years of thinking about these things.
The central theme of the book is the relationship of method to problem structure on one side and to description on the other. To deal with a significant problem you have to analyse and structure it. That means analysing and structuring the problem itself, not the system that will solve it. Too often we push the problem into the background because we are in a hurry to proceed to a solution. If you read most software development texts thoughtfully, you will see that almost everything in them is about the solution; almost nothing is about the problem.
On the other side, description is important because it is the clay in which software developers fashion their works. Methods are, above all, about what to describe; about tools and materials and techniques for descriptions; and about imposing a coherent structure on a large description task.
This book does not explain or advocate one particular development method. Nor is it a survey of methods, or an encyclopaedia of techniques and notations. It explains what I hope and believe are useful ideas and insights--both my own and other people's. It is arranged as an alphabetically ordered set of short pieces forming a lexicon, or a kind of specialized dictionary. Because many ofthe ideas are neglected or simply unfamiliar, the selection of topics, the content and some of the terminology are unconventional. This is not in any way meant to be a standard reference work.
I chose the dictionary form for two reasons. First, because a more structured arrangement would have seemed to promise a unity and a completeness that I cannot attain. This is a collection of ideas and insights, not a new method. Second, putting the same point more positively, because I believe that many of the ideas in the book can be applied piecemeal in many different development contexts. They can be used to make local improvements in established methods, and to shed light on some of the local difficulties and problems that are met in any development.
Software development should be a thoughtful activity. You should think not only about the problem and its solution, but also about the way you're tackling it. Some software developers and method users behave as if they were bicycle riders. When you are riding a bike you shouldn't think about what you're doing. If you do think about it you'll probably fall off. But software development isn't like bike riding. You'll be a much better developer if you think consciously about what you're doing, and why. This book is intended to help you.
When you encounter a difficulty in software development, what you need above all is a set of appropriate conceptual tools. Perhaps you're trying to describe something that stubbornly refuses to fit cleanly into your description; or to disentangle the simple problems that you feel sure must lie beneath the intractable complex problem that is holding you up. The right conceptual tools help you to think consciously about what you're doing, often just by providing names for concepts that you already had but never articulated. So when you're struggling to get a description right it's helpful to be able to ask yourself: Have we got the right description span here? Are we sure we understand the designations well enough? Have we made a spurious classification? And when you're dealing with a problem complexity it's helpful to be able to ask yourself: Is this a multi-frame problem? Is there a problem frame misfit here? Are we trying to look at shared phenomena from the point of view of only one domain?
I hope that the lexicon form of the book will work to underline its nature. It is offered as a resource from which you can take what you want, not as another orthodoxy that demands acceptance or rejection as a whole. The arrangement of the book, I hope, will encourage you to browse and skip from piece to piece, and I don't expect it to be read straight through. Inevitably, this has led to some repetition, but not enough, I hope, to seem tedious. I have tried to make each piece self-contained but, of course, that is not always possible, especially for some of the pieces about less familiar ideas--such as problem frames. So there is a full index, and cross-references, capitalized in the text, from each piece to other relevant pieces. If you're feeling puzzled by a piece it may be a good idea to follow some of the cross-references in its earlier paragraphs before reading on.
If you prefer to read more systematically, you could start with the Introduction, which comes, out of alphabetical order, at the beginning. The Introduction lays out some of the main ideas, and puts them in context. Then you can follow the cross-references from the Introduction to anything that catches your interest, and so onwards from one piece to another. There is a bibliography that expands the short and informal references--both to books and to their authors--appearing in the text and adds a few bibliographical notes.
Another way of using the book is by taking a tour around one theme or topic at a time. I've prepared some itineraries of tours you might take. Most of them are quite short and don't try to include everything about their themes. You can take them in any order. As with most tours, the time needed will depend on how long you spend on the places of interest. Some places of interest appear in more than one tour. If you visited a place on a previous tour, you could stay on the bus. On the other hand, you might see something you hadn't noticed on your first visit.
Whatever your approach to this book I hope it will be useful to you: that you will find something in it to help you in your work, to illuminate a difficulty you have struggled with, to offer amusement or insight, to provoke you to thought, or in any other way to repay you for having opened it.
Michael Jackson
May 1995
Acknowledgements
Much of my working life so far has been occupied with devising, teaching, and using software development methods. In the 1970s and early 1980s I was deeply involved in the JSP method of program design and the JSD method of system development. Some of the themes and ideas of this book emerge indirectly from the successes of that work; some from its failures. I learned a lot from the many people I worked with during those years--especially from John Cameron.
I also learned a lot, although I did not always realize it at the time, from some people whose ideas about method were diametrically opposed to my own. As Mark Twain said: "When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to twenty-one I was astonished at how much the old man had learned in seven years".
Many of the ideas in this book have been formed and sharpened during several years of cooperation with Pamela Zave. Particularly, they have been influenced by her approach to multiparadigm specification, and have benefited from the insightful work that she has done in cooperation with Peter Mataga on specifying telephone switching systems.
Daniel Jackson has helped me in more ways than I can count. He read the whole book in at least two of its versions and commented in detail on every part of it. He explained many things I had not known or had misunderstood. He discussed many of the topics with me at length. And he has always been ready to offer advice, encouragement, and constructive criticism at just the right moments. As a small recompense I have stolen a quotation by Niels Bohr from his PhD thesis.
Some of the ideas in the book have been aired at meetings of the Software Development Research Group of the University of the West of England, Bristol. I am grateful to the other members of the group--Barry Cawthorne, Ian Beeson, Richard McClatchey, Steve Probert, Tony Solomonides, and Chris Wallace--for their interest and help. Chris Wallace introduced me to the work on patterns in object-oriented design.
Tom DeMarco helped me generously with many acute and sensitive comments. His suggestions have removed many stumbling blocks from the reader's path.
Much of the treatment of Dekker's algorithm follows the presentation in Dick Whiddett's book Concurrent Programming for Software Engineers.
Andy Ware of Addison-Wesley has been unfailingly tolerant and courteous to an unreasonable and curmudgeonly author. And Susan Keany has been an agreeable and efficient production editor. It has been a pleasure to work with them both.
To all these people, and to everyone else who has helped me, I am very grateful.
0201877120P04062001
loading...