This book provides selective, in-depth coverage of the fundamentals of software engineering by stressing principles and methods through rigorous formal and informal approaches. In contrast to other books which are based on the lifecycle model of software development, the authors emphasize identifying and applying fundamental principles that are applicable throughout the software lifecycle. This emphasis enables readers to respond to the rapid changes in technology that are common today. Principles and techniques are emphasized rather than specific tools—users learn why particular techniques should or should not be used. Understanding the principles and techniques on which tools are based makes mastering a variety of specific tools easier. The authors discuss principles such as design, specification, verification, production, management and tools. Now coverage includes: more detailed analysis and explanation of object-oriented techniques; the use of Unified Modeling Language (UML); requirements analysis and software architecture; Model checking—a technique that provides automatic support to the human activity of software verification; GQM—used to evaluate software quality and help improve the software process; Z specification language. For software engineers.
|Product dimensions:||7.05(w) x 9.25(h) x 1.55(d)|
About the Author
Carlo Ghezzi is a professor of computer science at the Politecnico di Milano, where he holds the chair of software engineering. He was named a Fellow of the Association for Computing Machinery in 2000 for his contributions to software engineering research.
Mehdi Jazayeri is a professor of computer science at the Technische Universität Wien, where he holds the chair of distributed systems. He spent many years in software development at several Silicon Valley companies, including 10 years at Hewlett-Packard Laboratories, Palo Alto, CA.
Dino Mandrioli is a professor of computer science at the Politecnico di Milano, where he holds the chair of theoretical computer science. His research interests are centered on the application of formal methods in the practice of software engineering.
Table of Contents
1. Software Engineering: A Preview.
The Role of Software Engineering in System Design. A Shortened History of Software Engineering. The Role of the Software Engineer. The Software Life Cycle. The Relationship of Software Engineering to Other Areas of Computer Science. The Relationship of Software Engineering to Other Disciplines.
2. Software: Its Nature and Qualities.
Classification of Software Qualities. Representative Qualities. Quality Requirements in Different Application Areas. Measurement of Quality.
3. Software Engineering Principles.
Rigor and Formality. Separation of Concerns. Modularity. Abstraction. Anticipation of Change. Generality. Incrementality. Two Case Studies Illustrating Software Engineering Principles.
4. Software Design.
The Software Design Activity and its Objectives. Modularization Techniques. Handling Anomalies. A Case Study in Design. Concurrent Software. Object-Oriented Design. Architecture and Components.
5. Software Specification.
The Uses of Specifications. Specification Qualities. Classification of Specification Styles. Verification of Specifications. Operational Specifications. Descriptive Specifications. Building and Using Specifications in Practice.
6. Software Verification.
Goals and Requirements of Verification. Approaches to Verification. Testing. Analysis. Symbolic Execution. Model Checking. Putting it All Together. Debugging. Verifying Other Software Properties.
7. The Software Production Process.
What is a Software Process Model? Why Are Software Process Models Important? The Main Activities of Software Production. An Overview of Software Process Modes. Dealing with Legacy Software. Case Studies. Organizing the Process. Organizing Artifacts: Configuration Management. Software Standards.
8. Management of Software Engineering.
Management Functions. Project Planning. Project Control. Organization. Risk Management. Capability Maturity Model.
9. Software Engineering Tools and Environments.
Historical Evolution of Tools and Environments. Dimensions for Comparing Software Tools. Representative Tools. Tool Integration. Forces Influencing the Evolution of Tools.
The Future. Ethics and Social Responsibility. Software Engineering Code of Ethics.
Preface to the Second Edition
The first edition of this book was published in 1991. Since then, there has been a lot of progress in computing technology and also in software engineering. Certainly the proliferation of the Internet has had a profound influence on education, research, development, business, and commerce. We decided to produce this second edition in order to bring the book up to date with respect to the advances in software engineering in the last 10 years.
We were pleased to find that the basic premise of the bookthe durability and importance of principleshas been borne out by the passage of time: Even though the technology has improved, principles of software engineering have remained the same. We have therefore been able to update every chapter without changing the original structure of the book. The following is still the structure:
- Introduction: Chapters 1-3;
- The product: Chapters 4 -6;
- Process and management: Chapters 7 -8;
- Tools and environments: Chapter 9.
The product-related chapters follow the sequence consisting of design (4), specification (5), and verification (6). This is different from the approach taken by other books, which cover specification before design. The reason for our choice follows from the principles-based approach of the book. All of these activitiesdesign, specification, and verificationare basic activities that must be learned and applied throughout the software life cycle. For example, design is something we do not only with software architecture, but also with software specifications. The modular design approach helps us structure software and also the specification documents. Other books present specification first and then design, allegedly becauseaccording to the traditional software processesfirst we specify a software and then we design it. By contrast, we believe that learning about the design activity and approaches first, creates the needed motivation for the study of specification and provides the skills and techniques for structuring those specifications.
While all areas of software engineering have evolved since the first edition of the book was written, the area of tools and environments has changed substantially. Chapter 9, therefore, is revised considerably. Our approach in this chapter also is to present primarily principles rather than specific tools. We have seen over the years that tools change as technology evolves, and the choice of what particular tools to study depends on the student's environment and focus. We therefore cover a framework for studying and evaluating software tools without a detailed look at any particular tools.
Besides many minor improvements and changes, we have made the following major additions:
In Chapter 3, we have added two new case studies, one of a simple compiler and the other of the elevator system that we use throughout much of the book. The two case studies are complementary in that they deal with different application areas and pose different design challenges. They are presented in this chapter in a simple and intuitive way to get the student oriented towards thinking of system issues. They are intended to illustrate the use of general principles with concrete examples.
In Chapter 4, we have extended the treatment of object orientation, software architecture, components, and distributed systems.
In Chapter 5, we have added a treatment of Z and UML. A new section gives a more systematic treatment of requirements engineering.
In Chapter 6, we have added model checking and GQM as evaluation and verification techniques.
In Chapter 7, we have included a treatment of the unified process, the open-source process, and the synchronize-and-stabilize process. We have also added a new case study on requirements engineering.
In Chapter 8, we have added the capability maturity model and a description of the Nokia software factories.
In Chapter 9, we have added a treatment of the concurrent versioning system (CVS).
In Chapter 10, we have provided coverage of the Software Engineering Code of Ethics.
In the appendix, we have added a new case study on the use of formal methods in industry.THE ROLE OF OBJECT ORIENTATION
The book covers the principles of object orientation in a balanced way, rather than as the only way to do software engineering. Object-oriented analysis, design, and programming have certainly evolved and become a dominant approach to software engineering. We believe, however, that the principles underlying software engineering are deeper than objects. What the student should learn are principles and methods that can be used in different approaches. The student should learn how to choose between approaches and should be able to apply object orientation when it is the right choice. For example, the student should learn about information hiding before learning about objects and inheritance.THE PURPOSE OF CASE STUDIES
The case studies presented throughout the book and also in the appendix have two purposes. One is to present the issues discussed in a larger context, in order to give the student a broader view of why the principles or techniques are important. The second reason is to give those students who have not seen real projects a picture of realistic projects. The case studies are necessarily simplified to focus on important issues, but we have found that they are useful especially to less experienced students. The study of software engineering poses a challenge in a university setting because the typical student has not been exposed to the problems that software engineers face daily. These case studies attempt to overcome this challenge.INSTRUCTOR RESOURCES
A companion CD, including solutions and sample course sylllabi is available to instructors. A companion Web site is available through the publisher to both students and instructors. You may contact the authors through the Web site. We welcome your feedback, comments, and suggestions.
Palo Alto, California
This is a textbook on software engineering. The theme underlying the book is the importance of rigor in the practice of software engineering. Traditional textbooks on the subject are based on the lifecycle model of software developmentthat is, requirements, specification, design, coding, maintenanceexamining each phase in turn. In contrast, our presentation is based on important principles that can be applied independently of the lifecycle model and often in several phases of the lifecycle. Our emphasis is on identifying and applying fundamental principles that are applicable throughout the software lifecycle.
The general characteristics of the book are the following:
- It deals with software engineering as opposed to programming. Thus, we do not discuss any programming issues. For example, we omit any discussion of programming language constructs such as goto, loops, etc. We believe that the student of software engineering should have prior familiarity with these issues, which are more properly covered in textbooks on programming languages. On the other hand, we do discuss the issue of mapping software design constructs into specific programming languages. We concentrate on intermodule issues and assume as prerequisite the ability to program individual modules.
- It emphasizes principles and techniques as opposed to specific tools (which may be used in examples). Many companies are actively developing software engineering tools and environments today and we expect that better and more sophisticated tools will be invented as our knowledge of software engineering increases. Once the student understands the principles and techniques that the tool is based on, mastery of the tool will be easy. The principles and techniques are applicable across tools while mastering the use of any particular tool does not better prepare the student for the use of other tools. Further, use of tools without understanding their underlying principles is dangerous.
- It presents engineering principles; it is not an engineering handbook. Principles are general and are likely to remain applicable for many years while particular techniques will change due to technology, increased knowledge, etc. An engineering handbook may be consulted to learn how to apply a particular technique: it contains a set of prescriptions. This book, on the other hand, aims to enable the reader to understand why a particular technique should be used and, just as important, why it should not be. Even though we do show how a particular technique can be used to implement a given principle, our primary emphasis is on the understanding of the why question.
This book embodies our beliefs in the use of fundamental principles and the importance of theory in the practice of engineering. We have used the material in this book in both university and professional courses on various aspects of software engineering.AUDIENCE
This book is designed to be used as a textbook by students of software engineering either in a classroom or for self-study. Professional engineers and managers will find material here to convince them of the usefulness of modern practices of software engineering and the need to adopt them. It may be used by professionals who are willing to invest the time for serious study; it is not really appropriate for a cursory reading. In particular, wherever necessary, we have sacrificed breadth for depth. For the professional, the notes on further references will be especially helpful. An Instructor's Manual is available with ideas for course organizations and solutions to some of the exercises.PREREQUISITES
The book is designed for junior, senior, or beginning-graduate level students in computer science. The reader must have had a course in data structures and should be fluent in one or more programming languages. We assume that the reader is already proficient in programming. Analytical reasoning, although not strictly necessary, will greatly enhance the ability of the reader to appreciate the deeper concepts of the book. This skill is developed by mathematics courses such as calculus, discrete mathematics, or-even better-theoretical computer science. 'Mathematical maturity' is necessary for the student of any engineering discipline.ORGANIZATION AND CONTENT
Software engineering is a large, multi-dimensional discipline. Organizing a textbook on the subject poses a challenge because a textbook should present material sequentially, but the many facets of software engineering are so interrelated that there is no optimal sequence of topics. We have organized this textbook based on the view that in software engineering:
- We are building a product: the software;
- We use a process to build that product; and
- We use tools in support of that process.
The book thus has three technical sections dealing in turn with the software product (Chapters 4 through 6), the software engineering process and management (Chapters 7 and 8), and the software engineering environment (Chapter 9). Chapters 1 through 3 form a general introduction to the field and the subsequent more technical sections of the book.
In Chapter 2, we discuss the many facets of software and common desirable characteristics for software. These characteristics impose constraints on the software builder and the process to be used. In Chapter 3, we present principles for building high-quality software. By studying principles rather than specific tools, the student gains knowledge that is independent of a particular technology and application environment. Because technology changes and environments evolve, the student should be armed with principles and techniques that can be utilized in different application areas. Chapters 4 through 8 present and discuss techniques for applying the principles of Chapter 3 to, respectively, design, specification, verification, engineering process, and engineering management. In Chapter 9, we discuss the use of computers themselves to help in the building of software. We postpone the discussion of any specific tools to this chapter.
While the material in the first two sections should withstand the passage of time, it is likely that the material in the third section will become outdated (we hope) because newer and better tools are being developed. Since programming languages are a fundamental tool of the software engineer, we use Chapter 9 as a bridge between the design issues of Chapter 4 and specific programming language constructs.EXERCISES
The book contains many exercises of three types:
- short, paper exercises, aimed at extending the knowledge gained from the book or applying the knowledge more deeply; these exercises are interspersed throughout the chapters.
- longer paper exercises at the end of each chapter, requiring integration of the material in the chapter.
- term-projects requiring the development of some substantial software system by a small team.
Solutions to some of the exercises are provided at the end of each chapter. More exercise solutions are given in the Instructor's Manual.CASE STUDIES
Several case studies are used in the text to demonstrate the integration of different concepts and to contrast different approaches in realistic situations. In addition, three case studies of real-life software engineering projects and their analyses are presented at the end of the book. These case studies may be read and studied at different times and for different purposes. From these case studies, the new student with little industrial experience can gain a quick view of the diversity of problems faced in industrial practice. The student with some experience perhaps will identify with certain aspects of these case studies and learn from others. The case studies may be read concurrently with the main text. Several exercises in the book refer to these case studies.LABORATORY COURSE
Many software engineering courses combine lectures and a laboratory project. To do this in a single semester is rather difficult. The teacher will find himself discussing organizational issues while the students are concentrating on their daily forays into debugging. We believe that software engineering must be taught as all other engineering disciplines by first providing the student with a solid foundation in the 'theory.' Only after this has been achieved will laboratory experience enhance the student's knowledge. This implies that the student project must start closer to the middle of the semester rather than at the beginning. In our view, a better approach is to spend one semester on the theory and a second semester on the laboratory. The Instructor's Manual offers several ideas for organizing a laboratory course based on this text.READING GRAPH
The book may be read in different sequences and at different levels. Each of Chapters 4 through 7 contains material that may be skipped on the first reading or for a less detailed study. Chapters 1 through 3 are required reading for the subsequent chapters. The graph shows the dependencies among the chapters and the various paths through the book. The notation nP refers to a partial reading of Chapter n, skipping some sections; nC stands for a complete reading.
The Instructor's Manual discusses different course organizations based on the book. The conventional one-semester project software engineering course may follow the sequence: 1, 2, 3, 7P, SP, 4P, 6P, 8, 9,10. We ourselves prefer the sequence 1, 2, 3, 4P, 5P, 6P, 7P, 8, 9,10. In either case, the students should start on the project after 5PACKNOWLEDGMENTS
We gratefully acknowledge reviews of earlier drafts provided by Reda A. Ammar of the University of Connecticut, Larry C. Christensen of Brigham Young University, William E Decker of the University of Iowa, David A. Gustafson of Kansas State University, Richard A. Kemmerer of the University of California at Santa Barbara, John C. Knight of the University of Virginia, Seymour V Pollack of Washington University, and K. C. Tai of North Carolina State University.
We would also like to thank the following people who have provided valuable feedback on various drafts of the manuscript: Vincenzo Ambriola, Paola Bertaina, David Jacobson, and Milon Mackey.
Hewlett-Packard Laboratories and Politecnico di Milano made it possible to conceive this book by supporting a course offered by Mehdi Jazayeri at the Politecnico di Milano during the spring of 1988. Alfredo Scarfone and HP Italiana provided us with support in Italy. We would like to acknowledge the support of management at Hewlett-Packard Laboratories, especially John Wilkes, Dick Lampman, Bob Ritchie, and Frank Carrubba in Palo Alto, and Peter Porzer in Pisa. We would like to thank Bart Sears for his help with various systems, and John Wilkes for the use of his data base for managing references. We have also received support from Consiglio Nazionale delle Ricerche.
Palo Alto, California