本章的主要内容是面向对象分析
分析的概念
分析类
在分析对象模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象。从软件的功能需求来看，分析类可以划分为：1. 实体类：表示系统存储和管理的永久信息；2. 边界类：表示参与者与系统之间的交互；3. 控制类：表示系统在运行过程中的业务控制逻辑。
分析活动
首先，开发人员进一步理解最初的用例模型和词汇表，识别出系统的分析类；其次，通过建立系统的顺序图发现可能遗漏的对象类，并定义分析类的重要属性和行为，确定分析类之间的关系，从而得到进一步细化的分析模型；最后，开发人员和用户一起检查模型，保证模型的正确、一直、完整和可行。分析过程是一个循环渐进的过程，识别分析类和细化分析模型不是一蹴而就的，需要多次的循环迭代出现。
识别分析类
识别边界类
通常，一个参与者与一个用例之间的交互或通信关联对应一个边界类。边界类收集来自参与者的信息，这些信息可以被实体类和控制类使用。识别边界类应注意以下问题：1. 边界类应关注于参与者与用例之间交互的信息或者响应的事件，不要描述窗口组件等界面的组成元素；2. 在分析阶段，力求使用用户的术语描述界面；3. 边界类实例的生命周期不限于用例的事件流，如果两个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。
识别控制类
控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物，它负责接收边界类的信息，并将其分发给实体类。控制类与用例存在着密切的关系，他在用例开始执行时创建，再用例结束时取消。识别控制类应当注意以下问题：1. 当用例比较复杂时，特别是在产生分支事件流的情况下，一个用例可以有多个控制类；2. 在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为，例如，MiniLibrary 系统中的用例“登陆”就属于这种情况；3. 如果不同用例半酣的任务之间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以便降低复杂性。通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控制类，在分析这些控制类找出它们之间的共同之处。
识别实体类
实体类通常是用例中的参与对象，对应着现实世界中的“事物”。识别实体类需要开发人员进一步理解应用领域，可以通过分析用例描述和词汇表等发现备选的实体对象。启发分析人员发现实体类的因素包括以下几点：人员、组织、物品、设备、时间和表格。识别实体类开发应该注意的问题如下：1. 实体类的识别质量很大程度上取决于分析人员书写文档的风格和质量；2. 自然语言是不精确的，因此在分析自然语言描述时，应该尽量使描述文档中的一些措辞规范化，以弥补这种不足；3. 在自然语言描述中，名词可以对应类、属性或同义词等多种类型，开发人员需要花费大量的时间进行筛选。
定义交互行为
顺序图可以将用例和分析对象联系在一起，实现将用例的行为分配到所识别的分析类中，并且帮助开发人员发现和补充前面遗漏的分析类。顺序图可以结合一下步骤绘制：1. 列出启动该用例的参与者；2. 列出启动用例时参与者使用的边界对象；3. 列出管理该用例的控制对象；4. 根据用例描述的所有流程，按时间顺序列出分析对象之间进行消息访问的序列。绘制用例图需要注意一下问题：1. 用例的事件流包含一个基本流和若干个备选流，通常对于基本流和每一个备选流都要分别绘制一个顺序图；2. 在备选流过于简单的情况下，可以将其与基本流合并在一个顺序图中；3. 在一个事件序列过于复杂的情况下，应该考虑在时间维度上将其分为多个顺序图；4. 在顺序图中，实体对象一般不访问边界对象和控制对象。
建立分析类图
定义关系和属性
对于每一个分析类，可以从以下方面考虑并发现分析类的属性：1. 按照一般常识，找出对象的某些属性，如人员的姓名、性别等；2. 认真研究问题域，找出对象的某些属性，如商品的条形码和学生的学生号等；3. 根据系统责任的要求，找出独享的某些属性；4. 考虑对象需要系统保存和管理的信息，找出对象的相应属性，如“课程”需要保存和管理的信息；5. 对象为了在服务中实现其功能，需要增设一些属性；6. 识别对象需要区别的状态，考虑是否需要增加一个属性来区别这些状态；6. 确定属性表示整体与部分结构和是实例连接。
分析模型应用
分析模型是描述在系统业务领域发现的通用部分，提高复合性和一致性。
评审分析模型
1. 检查“正确性”的问题列表；2. 检查“完整性”的问题列表；3. 检查“一致性”的问题列表；4. 检查“一致性”的问题列表。