没有合适的资源?快使用搜索试试~ 我知道了~
Object-Oriented Software Engineering
4星 · 超过85%的资源 需积分: 9 149 下载量 193 浏览量
2009-10-18
01:08:08
上传
评论
收藏 5.06MB PDF 举报
温馨提示
试读
505页
This book is based on object-oriented techniques applied to software engineering. It is neither a general software engineering book which surveys all available methods nor a programming book about algorithms and data structures. Instead, we focus on a limited set of techniques and explain their application in a reasonably complex environment, such as a multi-team development project including twenty to sixty participants. Consequently, this book also reflects our biases, our strengths, and our weaknesses. We hope, nevertheless, that all readers will find something they can use. The book is structured into twelve chapters organized into four parts which can be taught as a semester long course.
资源推荐
资源详情
资源评论
Object-Oriented Software Engineering
Conquering Complex and Changing Systems
Bernd Bruegge & Allen H. Dutoit
Carnegie Mellon University
School of Computer Science
Pittsburgh, USA
Technische Universitaet Muenchen
Institut fuer Informatik
Munich, Germany
Preprint made available with the permission of Prentice Hall.
© 1999 Bernd Bruegge and Allen H. Dutoit
DRAFT - DO NOT DISTRIBUTE
iii of viii
Preface
The K2 towers at 8.611 meters in the Karakorum range of the western Himalayas. It is the
second highest peak of the world and is considered the most difficult 8000er to climb. An
expedition to the K2 typically lasts several months in the summer when the weather is most
favorable. Even in summer, snow storms are frequent. An expedition requires thousands of
pounds of equipment, including climbing gear, severe weather protection gear, tents, food,
communication equipment, and pay and shoes for hundreds of porters. Planning such an
expedition takes a significant amount of time in the life of a climber and requires dozens of
participants in supporting roles. Once on site, many unexpected events, such as avalanches,
porter strikes, or equipment failures will force the climbers to adapt, find new solutions, or
retreat. The success rate for expeditions to the K2 is currently less than 40%.
The United States National Airspace System (NAS) monitors and controls air traffic in the
United States. The NAS includes more than 18,300 airports, 21 air route traffic control
centers, and over 460 control towers. This adds up to more than 34,000 pieces of equipment,
including radars, communication switches, radios, computer systems, and displays. The
current infrastructure is aging rapidly. The computers supporting the 21 air route traffic
control centers, for example, are IBM 3083 mainframes which date back to the early eighties.
In 1996, the US government initiated a program to modernize the NAS infrastructure,
including improvements such as satellite navigation, digital controller/pilot
communications, and a higher degree of automation in controlling the air routes, the order
in which aircrafts land, and control of ground traffic as aircrafts move from and to the
runways. Modernizing such a complex infrastructure, however, can only be done
incrementally. Consequently, while new components offering new functionality are
introduced, older components still need to be supported. For example, during the transition
period, a controller will have to be able to use both analog and digital voice channels to
communicate with pilots. Finally, the modernization of the NAS coincides with a dramatic
increase in global air traffic, predicted to double within the next 10 to 15 years. The previous
modernizing effort of the NAS, called the Advanced Automation System (AAS), was
suspended in 1994 because of software related problems, after missing its initial deadline by
several years and exceeding its budget by several billions of dollars.
Both of the above examples discuss complex systems, where external conditions can trigger
unexpected changes. Complexity puts the problem beyond the control of any single
individual. Change forces participants to move away from well known solutions and to
invent new solutions. In both examples, several participants need to cooperate and develop
new techniques to address these challenges. Failure to do so results in the failure to reach
the goal.
This book is about conquering complex and changing software systems.
DRAFT-DO NOT DISTRIBUTE
iv of viii
The theme
The application domain (mountain expedition planning, air traffic control, financial
systems, word processing) usually includes many concepts that software developers are not
familiar with. The solution domain (user interface toolkits, wireless communication,
middleware, database management systems, transaction processing systems, wearable
computers, etc.) is often immature and provides developers with many competing
implementation technologies. Consequently, the system and the development project is
complex, involving many different components, tools, methods, and people.
As developers learn more about the application domain from their users, they update the
requirements of the system. As developers learn more about emerging technologies or about
the limitations of current technologies, they adapt the system design and implementation.
As quality control finds defects in the system and users request new features, developers
modify the system and its associated work products, resulting in continuous change.
Complexity and change represent challenges which make it impossible for any single
person to control the system and its evolution. If controlled improperly, complexity and
change defeat the solution before its release, even if the goal is in sight. Too many mistakes
in the interpretation of the application domain make the solution useless for the users,
forcing a retreat from the route or the market. Immature or incompatible implementation
technologies result in poor reliability and delays. Failure to handle change introduces new
defects in the system and degrades performance beyond usability.
This book reflects more than ten years of building systems and of teaching software
engineering project courses. We have observed that students are taught programming and
software engineering techniques in isolation, often using small problems as examples. As a
result, they are able to solve well defined problems efficiently, but are overwhelmed by the
complexity of their first real development experience, when many different techniques and
tools need to be used and different people need to collaborate. Reacting to this state of
affairs, the typical undergraduate curriculum now often includes a software engineering
project course, organized as a single development project.
We wrote this book with such a project course in mind. This book can be used, however, in
other situations as well, such as short and intensive workshops or short term R&D projects.
We use examples from real systems and examine the interaction between state-of-the art
techniques, such as UML (Unified Modeling Language), Java-based technologies, design
patterns, design rationale, configuration management, and quality control. Moreover, we
discuss project management related issues that are related to these techniques and their
impact on complexity and change.
DRAFT - DO NOT DISTRIBUTE
v of viii
The principles
We teach software engineering following five principles.
Practical experience. We believe that software engineering education must be linked with
practical experience. Understanding complexity can only be gained by working with a
complex system; that is, a system that no single student can completely understand.
Problem solving. We believe that software engineering education must be based on
problem solving. Consequently, there are no right or wrong solutions, only solutions that
are better or worse relative to stated criteria. Although we survey existing solutions to real
problems and encourage their reuse, we also encourage criticism and the improvement of
standard solutions.
Limited resources. If we have sufficient time and resources, we could perhaps build the
ideal system. There are several problems with such a situation. First, it is not realistic.
Second, even if we had sufficient resources, if the original problem rapidly changes during
the development, we would eventually deliver a system solving the wrong problem. As a
result we assume that our problem solving process is limited in terms of resources. The
acute awareness of scare resources moreover encourages a component-based approach,
reuse of knowledge, design, and code. In other words, we support an engineering approach
to software development.
Interdisciplinarity. Software engineering is an interdisciplinary field. It requires
contributions from areas spanning electrical and computer engineering, computer science,
business administration, graphics design, industrial design, architecture, theater, and
writing. Software engineering is an applied field. When trying to understand and model the
application domain, developers interact regularly with others, including users and clients,
some of whom know little about software development. This requires viewing and
approaching the system from multiple perspectives and terminologies.
Communication. Even if developers built software for developers only, they would still
need to communicate among themselves. As developers we cannot afford the luxury of
being able to communicate only with our peers. We need to communicate alternatives,
articulate solutions, negotiate trade-offs, review, and criticize others’ work. A large number
of failures in software engineering projects can be traced to the communication of inaccurate
information or to missing information. We must learn to communicate with all project
participants, including, most importantly, the client and the end users.
These five principles are the basis for this book. They encourage and enable the reader to
address complex and changing problems with practical and state-of-the-art solutions.
剩余504页未读,继续阅读
cicelyxq1987
- 粉丝: 1
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
- 1
- 2
前往页