its limitations and will allow Essence to evolve and improve. This book is an important contribution to transferring knowledge about Essence from specialists to a more general audience. Although notionally aimed at students, it provides an accessible introduction to Essence for all software engineers.
Organized into four parts, the first three parts focus squarely on using Essence as a means of thinking about, planning, and describing software development. Using real but manageable examples, Parts I and II of the book cover the fundamentals of Essence and the innovative use of serious games to support software engineering. Part III explains how current practices such as user stories, use cases, Scrum, and microservices can be described using Essence and shows how their activities can be represented using the Essence notions of cards and checklists. Part IV is perhaps more speculative but offers readers a vision of how Essence can scale to support large, complex systems engineering.
Software engineering has been both facilitated and hampered by the rate of technological innovation. The need to build software for new technologies has led to huge investment in the discipline but, at the same time, has made it difficult to reflect on what software engineering really means. Now, 50 years on, Essence is an important breakthrough in understanding the meaning of software engineering. It is a key contribution to the development of our discipline, and I’m confident that this book will demonstrate the value of Essence to a wider audience. It, too, is an idea whose time has come.
Ian Sommerville
Emeritus Professor of Software Engineering at St. Andrews University, Scotland. For more than 20 years, his research was concerned with large-scale complex IT systems. He is the author of a widely used textbook on software engineering, titled Software Engineering, first published in 1982, with the 10th edition published in 2015.
Foreword by Grady Booch
The first computers were human; indeed, the very noun “computer” meant “one who computes or calculates” (and most often those ones were women).
My, how the world has changed.
Computing has woven itself into the interstitial spaces of society. Softwareintensive systems power our cars and airplanes; they serve as our financial conduits; they track our every action; they fight our wars; they are as intimate as devices we hold close to us or even within us and as grand as the wanderers we have flung into space and that now inhabit other planets and venture to other stars. There is no other invention in the history of humanity that has such a potential to amplify us, diminish us, and perhaps even replace us.
I have often observed that the entire history of software engineering can be characterized as the rising levels of abstraction. We witness this in our programming languages, in our tools, in our frameworks, in the very ways with which we interact with software-intensive systems … and even in the ways in which we craft these systems. This is the world of software engineering methods.
I am proud and humbled to call myself a friend of Ivar Jacobson. The two of us, along with Jim Rumbaugh, were at the center of a sea change in the way the world develops and deploys software-intensive systems. We got some things right; we got some things wrong. But, most important, we helped to codify the best practices of software engineering in their time. Indeed, that was an incredibly vibrant time in the history of software engineering, wherein many hundreds if not thousands of others were struggling with how to codify the methods by which systems of importance could best be built.
The nature of software development has changed—as it should and as it will again—and even now we stand at an interesting crossroads in the field. Agile methods have proven themselves, certainly, but we are at the confluence of technical and economic forces that bring us again to a very vibrant point in time. As the Internet of Things brings computing to billions of devices, as computational resources grow in unceasing abundance, and as deep learning and other forms of artificial intelligence enter the mainstream, now is the time to establish a sound foundation on which we can build the next generation of software-intensive systems that matter.
In a manner of speaking, one might say that the essence of Essence is its powerful mastery of the fundamental abstractions of software engineering. I saw in Ivar the seeds of Essence in the early days of working with him and Jim on the UML, and so now it is wonderful to see this work in its full flowering. What you hold in your hands (or on your computer or tablet, if you are so inclined) represents the deep thinking and broad experience of Ivar; information that you’ll find approachable, understandable, and—most importantly—actionable.
Enjoy the journey; it will make a difference for the good.
Grady Booch
IBM Fellow, ACM Fellow, IEEE Fellow, recipient of the BCS Ada Lovelace Award, and IEEE Computer Pioneer.
Preface
We have developed software for many years, clearly more than 50 years. Thousands of books and manymore papers have been written about how to develop software. Almost all teach one particular approach to doing it, one which the author thinks is the best way of producing great software; we say each author has canned his/her method. Most of these authors have some interesting ideas, but none can help you in all the circumstances you will be faced with when you develop software. Even the most modern books take this approach of presenting and selling “the one true way” of doing it. Unless you are a world leader ready to impose your own true way of doing it, all other top experts in the world seem to be in agreement that this proprietary approach is not the way to teach software development to students.
You now have in front of you a book that will teach you modern software engineering differently from how the subject has been taught since its infancy. On one hand, it stands on the shoulders of the experience we have gained in the last 50 years or more. On the other hand, it teaches the subject in a universal and generic way. It doesn’t teach you one particular way of developing software, but it teaches you how to create one way of working that matches your particular situation and your needs. The resulting way of working that you create is easy to learn (intuitive), easy to adopt (by a team), easy to change (as you learn more), and fun to work with thanks to its user experience being based on games and playing cards.
It is worth repeating: This book does not primarily teach you one particular way of developing great software; rather, it teaches you how to create such a way of working that should result in great software.
How This Book Is Different from Other Software Engineering Textbooks
On the surface this book looks like most other books in software engineering (and there are many of them; some are excellent books). It describes many important aspects of software engineering and how a typical software engineering initiative resulting in a new or improved software product takes place. However, underneath the surface, this book is fundamentally different. The things being described are selected because they are prevalent in every software engineering initiative. They are the essential things to work with, the essential things to do, and the essential competencies needed when you develop software. They are not just examples of things or typical things. They are selected because they are the things that underpin all recognized ways of developing software. The selection has been made by a group of experts from around the world representing academia, research, and industry, under the auspices of an international group called Object Management Group that gave rise to the Essence standard.1
Essence addresses, first and foremost, a number of serious challenges we have in the software industry today, one of which is that for 50 years we have had a war between the canned methods (but there are many more challenges, which we will discuss in the book). In addressing these issues, Essence has made it possible to systematically improve the way we work, which should result in better software—faster and cheaper. However,