用例分析方法是站在用户的角度定义软件系统外部特征的一种方法。作为UML的一种重要表示法，用例分析在软件开发中占据着决定性的地位。

开始一项新的项目，难如登月。但是，如果你组建了强大的小组，乘上需求的航船，就有希望到达成功的彼岸。成功的彼岸没有失败的项目，利润率很高，满地铺满了黄金。
　　但是，从项目开始到成功会遇到很多危险，很多项目半路就夭折了。有人说，差不多80％的项目从未获得成功。你可以询问一下那些曾经尝试过的人。他们总是会这样说："使用面向对象作为工具吧，Booch、OMT、OOSE和UML都是可供选择的良好模型。同时你也需要一幅图表来描绘开发过程中的风险和主要的体系结构。最后，还需要绘制一系列的用例图来达到你的目的。"
　　用例包含于统一建模语言（UML）中，应用于Rational Unified Process的整个过程、它们在不同的商业和工业领域获得了广泛的认可。通常，用例被用在软件项目和企业级的应用中。
　　本书为那些在项目开发中对用例技术感兴趣的人而写。但是我们不能保证使用用例开发的项目一定会获得成功。本书可以使你从不同的角度来观察正在开发的项目，并提供一些工具，以增加项目开发成功的可能性。
　　如果你有一些面向对象的基本概念和知识，你将在本书中获得更大的益处。我们使用统一建模语言作为表示法，并解释这些表示法。比较好的一本关于表示法的参考书是Fowler所写的UML Distilled，这是一本极好的书，通俗易懂。
　　本书使用Rational Unified Process作为框架来进行组织。在过程的各阶段中，我们将讨论阶段中的活动，重点放在基于用例的活动上。我们将简要谈论一些与用例相关的活动，例如软件体系结构。项目管理和面向对象的分析与设计。这些都是非常重要的活动，每一个话题都可用一本书的篇幅进行论述。因此，在附录A的资源列表中，你将发现关于这些话题的一些推荐书籍。
　　用一个为邮购公司设计的订单处理系统作为贯穿全书的例子。这将使我们的思维保持连贯，并组建合理而复杂的例子。这一解决方案的不同部分在不同的章节给出，来阐明用例的观点。
　　本书以一系列连贯的步骤进行介绍，尽管现实生活从未那么简单。每一部分都与其余的部分相连，直到整个系统完成为止。因此如果某一个章节说要创建一个体系结构，你只要应用你自己所掌握的知识，做当时能够做的就可以了。你将在工作过程中随着知识的增长对先前的项目进行补充与完善。
　　在开始使用用例之前，并不需要读完整本书。一到六章给出了使用用例的基本知识。我们推荐所有的读者首先阅读这些章节。第9章论述了体系结构和将用例映射到体系结构之中的内容。第7章包含了归档用例的内容。第10章包含了使用用例进行项目规划的内容，第8章论述了如何评审用例文档。第11章讨论了从用例到OOAD过渡的有关内容。
　　最后，要用用例来归档系统。附录A提供了我们所参考的书目列表，同时还有一些在项目开发过程中十分有用的书籍。附录B给出了所使用的文档模板。这些为你自己的项目提供了范例和基点。你可以根据需要对它们进行修改，1995年10月，Rational Software Corporation与Objective Systems合并，从而引入了Ivar Jacobson和他的用例。1996年2月，我为Rational公司编写了第一个用例课程，并且将其和Grady Booch以及Jim Rumbaugh的面向对象方法学结合在一起。从那时起，我开始为Rational公司的客户和我自己的咨询公司（Wyyzzk）的客户讲授有关用例的知识。在为他们讲述用例知识的同时，我也从这些客户身上学到了很多东西。这本书出自我在工作实践中的实际经历。
　　第2版前言
　　自从1998年9月第1版发行以来，我们和UML语言都发生了许多变化。本书将反映最新内容。
　　第2版包含了第1版的内容，只是章节不同。我们将面向工程的内容移到了本书的末尾，将面向商务的内容移到了本书的开头。这将使不同的读者更容易发现他们感兴趣的资料。
　　我们将本书更新到UML1.3。第3章和第4章发生了许多变化，因为我们在那里给出了绝大多数表示法。使用关系变成了 UML1.3中的包含和泛化两个关系。多扩展关系变成了单扩展关系。在这两种情况下，表示法也发生了相应的变化。对特定场景的定义也有一点变化。我们过去称之为场景（scenario）的现在称之为路径（path）。
　　我们补充了一些十分有用和重要的材料。第6章是在用例中设置细节层次的新的一章，包含有关商业处理层次用例的信息和在不同层次细节上保持用例之间的可追溯性。第7章的归档用例包含了有关处理诸如登录、创建、读取、更新和删除等用例的思想。第8章评审增加了我们所遇到的常见错误及其更正方法。我们在第5章和第9章对于时序图加进了更多的信息。
　　我和贾森的情况也发生了变化。 Jason离开了Octel，现在是Cadence Design Systems的助理工程师。我喜欢拥有自己的公司，但是不喜欢管理账目，因此，到Andrews Technology公司负责面向对象的部门。我们仍然拥有Wyyzzk公司， Jason为该公司提供周末业务咨询。出版商方面甚至也发生了变化。Addison－Wesley现在是
Pearson Education的一部分，并且我们有一个全新的团队来管理对象技术系列丛书。他们很容易共同协作，使过渡尽可能的平滑。
　　我们被问及到的最多的一个问题是：脚印和对话图标代表什么意思？脚印图标主要是表示进入过程，对话图标表示进入故事场景。
　　感谢所有为此书而发E－mail的人。由于时间原因我们不能-一回复，但是我们阅读了所有来信，并且希望在第2版中回答了您的绝大多数问题。
　　非常感谢我们的著名评论家，他们与我们一样努力工作，使这本书得以出版：
　　 Lauren Thayer
　　 Venkat Narayanan
　　 Gily Rish
　　 Kelli A．Houston，Rational Sottware Corporation
　　　 John Sunda Hsia
　　Pain Becker、Ross yenables、Tyrrll Albaugh和她在Addison－Wesley的生产小组工作非常认真刻苦，很高兴能与他们一起工作。我们衷心地感谢他们的支持和耐心。为使本书得以出版，他们做了许多艰苦的工作。
　　最后，要提到几个特别的人。感谢Lauren　Thayer和Krists　Hughes，他们是我近15年的老朋友。感谢我的两只小猫：Patches和Joker，是它们陪伴我度过了在计算机前的时光。感谢Jason Winters的爱、支持和鼓励。他们一直在帮助我前进。
　　Geri Schneider Winters
　　Santa　Clara，California

当我在1967年根据从事大型电信交换系统及其系统设计工作的经验，首次提出一组新型建模概念的时候，将用例作为一种分析方法还只是很粗略的想法。伴随着面向对象思想的出现，以及我后来在80年代应用面向对象方法以及对Objectory规则进行规范化所做的一系列工作，用例分析开始有了显著的发展，并且开始在问题分析领域占据重要地位。今天，用例所体现出的思想已经成熟，并且这项技术已经成为分析员必不可少的重要工具。
　　随着周例与工业标准的建模语言UML的结合，需要一本新书以实用易懂的方式来阐明当前的表示法和语意。用例分析也已经在新的软件开发统一过程中占据重要地位。于是，对于经理、设计师、设计人员、分析员、专家、程序员以及测试人员来说，理解如何使用用例变得十分重要。
　　在《用例分析技术》这本书中，Geri Schneider和Jason Winters已经为介绍这一强有力的工具和演示它们在现实生活中如何实现做了大量出色的工作。不是预先给出完整答案，书中的例子与实际项目的进展状况一样，早期的模糊模型随着小组对项目理解的加深而变得精确起来。这种方式有利于对实际项目中发生的问题进行介绍。
　　本书清晰地反映出Geri作为Rational软件公司的培训人员所具有的经验，她在指导和培训Wyyzzk Training and Consulting公司客户方面的大量倾注以及Jason使用该技术指导Lucent Technologies工程师的经验一并呈献在本书中。我极力推荐那些需要了解用例分析的人阅读本书。
　　 伊瓦尔·雅各布森
　　 （Ivar Jacobson）

Geri Schneider Jason P.Winters：暂无简介

姚淑珍 李巍：暂无简介

用例技术通过用例。执行者和用例以及用例之间的关系来描绘系统外在可见的需求情况，它是用户和开发者共同剖析系统功能需求的起点。随着用例作为UML的一种重要表示法，用例分析开始在软件开发中占据决定性地位，用例技术对于项目管理员、高级分析人员、设计人员、程序员、测试人员、用户都非常重要。在用例技术越来越得到重视的今天，非常需要一本新书以通俗易懂的方式来说明用例表示的语意及其应用技术。
　　本书以一个邮购公司的订单处理系统为实例，通过实际开发人员连续不断的讨论和工作，展现了整个系统的开发过程和技术应用成果。翻译过程中，这种讨论式的系统开发方式经常把我们带入场景，与作者共同去思考可选方案和可能犯的错误，找出有效的解决办法。相信你也会从实际系统开发过程中更进一步体会用例的含义和应用技巧，从而达到最终的目标。
　　《用例分析技术》一书从多个不同的角度观察用例，展示用例如何有助于项目的体系结构设计。进度安排、需求分析、测度和验证。特别从用户的角度观察整个系统，讨论诸如边界。接口和界定范围等问题，讲述如何将一个实际的大型系统划分为可管理的多个部分，即系统功能分解技术。本书适合各种层次的软件开发人员使用。
　　全书共分11章和5个附录。第1到第6章由姚淑珍负责翻译，第7到第 10竟由李巍负责翻译，第11章、附录由李鸣负责翻译。钏伟、张亮、张煜、孙志强、沈燕芳、李搏、牟胜梅、余文舟、张春晓翻译部分内容。姚淑珍完成全文的最后统校。李鸣做了最后的文字修正。由于知识局限和时间仓促，不免有翻译不到位甚至错误之处，敬请读者批评指正。我们会接受批评并向原书作者表示歉意。

第一章 开始
迭代式软件过程
样例项目
项目描述
开始风险分析
本章小结

第二章 确定系统边界
确定执行者
确定用例
描述执行者和用例
处理时间
潜在的边界问题
确定项目的范围
本章小结

第三章 归档用例
基本用例
前置与后置条件
事件流
正确性和完整性的指导原则
表示形式
其他需求
处理复杂的用例
基本路径
可选路径
细化重要的行为
可选项归档
场景
加入通信关联的指向
本章小结

第四章 高级用例归档技术
包含
扩展
继承
接口
本章小结

第五章 图形化用例
活动图
简单时序图
图解用户接口
本章小结

第六章 细节层
决定细节层次
用例之间的可追溯性
事务过程的用例
本章小结

第七章 归档用例
文档模板
其它文档
文档的支持工具
归档登录
归档
本章小结

第八章 评审
完整性评审
潜在问题的评审
端点用户评审
客户评审
开发评审
评审员
增加系统的灵活性
常见错误
用例图表上的工作流
用例太小
把屏幕视为用例
使用模糊术语
业务需求与技术需求
本章小结

第九章 划分大型系统
体系结构模式
三层体系结构模式
管道和过滤器型体系结构模式
面向对象的体系结构模式
订单处理体系结构举例
使用用例图验证体系结构
时序图
定义子系统之间的接口
子用例
创建子系统文档
子、可选、包含的比较
本章小结

第十章 用例和项目计划
计划项目
建立与购买决策的比较
原型开发
以用例来估算工作
给执行者加权
给用例加权
给技术因素加权
用例点
项目估算
本章小结

第十一章 系统的构造与提交
域的主题摘要
在用例中确定主题摘要
将含有主题摘要的场景绘制成图
主题摘要图示化表示
用例视图与子系统视图
迭代进度
提交及其它
用户指南和培训
销售包和市场材料
交付后用例
本章小结

后记
附录 A 参考文献
附录 B 文件模板
系统或者子系统文件
用例文件
附录 C UML表示法
附录D 发送用例估算方法的反馈信息
附录E 订单处理系统
订单处理系统
风险因素
系统级用例
体系结构