面向对象的需求分析基于面向对象的思想，以用例模型为基础。开发人员在获取需求的基础上，建立目标系统的用例模型。所谓用例是指系统中的一个功能单元，可以描述为操作者与系统之间的一次交互。用例常被用来收集用户的需求。
首先要找到系统的使用者，即用例的操作者。操作者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。"在系统之外"是指操作者本身并不是系统的组成部分，而是与系统进行交互的外界事物。这种交互应该是"有意义"的交互，即操作者向系统发出请求后，系统要给出相应的回应。而且，操作者并不限于人，也可以是时间、温度和其他系统等。比如，目标系统需要每隔一段时间就进行一次系统更新，那么时间就是操作者。
可以把操作者执行的每一个系统功能都看作一个用例。可以说，用例描述了系统的功能，涉及系统为了实现一个功能目标而关联的操作者、对象和行为。识别用例时，要注意用例是由系统执行的，并且用例的结果是操作者可以观测到的。用例是站在用户的角度对系统进行的描述，所以描述用例要尽量使用业务语言而不是技术语言。关于用例模型的详细创建方法，本书的实践部分会进行介绍。图2-13所示为某图书馆信息管理系统的用例图。
 |
| （点击查看大图）图2-13 图书馆信息管理系统的用例图 |
确定了系统的所有用例之后，就可以开始识别目标系统中的对象和类了。把具有相似属性和操作的对象定义为一个类。属性定义对象的静态特征，一个对象往往包含很多属性。比如，读者的属性可能有姓名、年龄、年级、性别、学号、身份证号、籍贯、民族和血型等。目标系统不可能关注对象的所有属性，而只是考虑与业务相关的属性。比如，在"图书馆信息管理"系统中，可能就不会考虑读者的民族和血型等属性。操作定义了对象的行为，并以某种方式修改对象的属性值。
目标系统的类可以划分为边界类、控制类和实体类，如图2-14所示。
 |
| 图2-14 边界类、控制类和实体类的图符 |
边界类代表了系统及其操作者的边界，描述操作者与系统之间的交互。它更加关注系统的职责，而不是实现职责的具体细节。通常，界面控制类、系统和设备接口类都属于边界类。
控制类代表了系统的逻辑控制，描述一个用例所具有的事件流的控制行为，实现对用例行为的封装。通常，可以为每个用例定义一个控制类。
实体类描述了系统中必须存储的信息及相关的行为，通常对应于现实世界中的事物。
确定了系统的类和对象之后，就可以分析类之间的关系了。对象或类之间的关系有依赖、关联、聚合、组合、泛化和实现。
依赖关系是"非结构化"的和短暂的关系，表明某个对象会影响另外一个对象的行为或服务。
关联关系是"结构化"的关系，描述对象之间的连接。
聚合关系和组合关系是特殊的关联关系，它们强调整体和部分之间的从属性，组合是聚合的一种形式，组合关系对应的整体和部分具有很强的归属关系和一致的生存期。比如，计算机和显示器就属于聚合关系。
泛化关系与类间的继承类似。
实现关系是针对类与接口的关系。
明确了对象、类和类之间的层次关系之后，需要进一步识别出对象之间的动态交互行为，即系统响应外部事件或操作的工作过程。一般采用顺序图将用例和分析的对象联系在一起，描述用例的行为是如何在对象之间分布的。
最后，需要将需求分析的结果用多种模型图表示出来，并对其进行评审。由于分析的过程是一个循序渐进的过程，合理的分析模型需要多次迭代才能得到。面向对象需求分析的示意图如图2-15所示。
 |
| （点击查看大图）图2-15 面向对象的需求分析 |
