章OOA实例

第7章OOA&UML应用实例（1）获取用户的基本需求，识别系统边界和主要服务创建用例图编写用例说明文档（2）分析用例说明，识别出系统执行的活动流程创建活动图（3）标出需求中提及的“事物”，识别“实体类”确定类的属性、方法和类之间的关系创建类图（4）将活动图中的活动状态分解为对象协作；创建协作图补充类图中的遗漏（5）对行为模式复杂的对象，分析状态变化序列为必要的对象创建状态图（6）复审OOA模型7.1OOA的基本步骤7.2在线购物的例子需求描述（P37、P38）用户可以查看（标准）计算机配置用户可以自己配置计算机。用户可以在线购买计算机，这个过程中可能需要与“在线销售人员”讨价还价。用户必须为订单进行支付用户可以随时查询自己发出的定单状态。销售人员要为通知仓库按订单备货7.2.1用例建模通过对需求信息的分析，回答“谁”用系统“干什么”。用例建模（用例的本质特性—P107）寻找参与者寻找系统的用例，分析过程——P39表2-1分析参与者及用例之间的关系，创建用例图编写用例文档（1）用例文档用例文档对每个识别到的用例进行详细的描述，重点在于解释用例执行过程中的交互序列（用户与系统如何打交道）对每个用例的描述一般包括以下内容：用例名简述参与者前置条件标准事件流/特殊事件流/异常事件流后置条件（执行结果）“订购计算机”的用例说明简述：允许用户输入定单，提供订购的详细信息。参与者：用户前置条件：系统显示被选择计算机的详细信息，用户决定订购并通过界面按钮激活该用例。主流和其他流详见P42后置条件：用例成功则系统保存定单记录，否则系统状态不变。7.2.2活动建模活动模型对用例的执行过程（控制流）进行建模。“活动状态”主要从用例描述中选取，任何动词性的语句都可视为“候选活动”活动模型与用例说明的区别用例说明立足于“参与者”的角度活动图更强调表达“系统干了什么事”。“订购计算机”的活动模型首先可以从“系统活动”的角度重新整理该用例的描述：参与者系统显示计算机配置点击订购按钮获取订购要求显示定单窗口填写定单内容并确定获取定单内容并验证存储定单内容Email回复定单细节系统的活动识别活动图6.2.3类建模类是对包含在系统业务领域内的事物的抽象。类图用于表示这些事物的内部结构和相互关系，是OO开发过程中十分重要的基础模型。如何发现类（P87）词性分析公共类模式用例导出CRC（类-职责-合作者）方法发现类的一般性技术指南（P89）每个类在系统中必须有存在的目的每个类应是对一组实例对象的框架描述。孤类的合理性值得商榷（例如仅仅应用到一个图书馆的信息管理系统中，是否应该定义“图书馆”为一个类）每个类应该有一组属性（复合信息）每个类应该有一组自己的方法承担系统的部分职责。在需求信息中识别“名词性事物”作为“候选类”，再基于类的判定原则确定系统的类集合。在需求分析阶段，主要识别的是在业务领域内有明确意义的事物——实体类，对于软件系统来说，还存在完成其他任务的类，如边界类（用于定义GUI界面的对象框架）和控制类（用于协调、调度其他类的协作），它们的识别和定义一般在设计阶段完成。“在线购物”系统的类识别过程（P45）发现和说明类的属性属性的识别是在发现类的同时进行的，在需求信息中属性也对应为名词性描述。属性用于说明该类对象“需要被使用”的数据特征，通常属性应该是不包含结构的（基本数据类型）；对于有结构的复合信息和概念应考虑将其定义为“类”。“在线购物”系统的类（属性）发现类的关系需求分析阶段所发现的是业务领域内的实体类，因此类之间的关系体现为业务实体间基于业务规则所形成的自然联系。通过分析在线购物系统的业务规则得到：每个用户的一次采购要产生一个定单一个定单至少要指定一台计算机每个定单必须采取一种支付形式可能要为一个定单打印一张发票计算机可以是标配或自配的计算机由可选择的硬件配置而成。……“在线购物”系统的类图类的方法概括的说，类的方法有两种作用维护对象的私有数据响应其他对象的协作请求，为其提供某种服务因此类方法集合的定义不仅依赖于类的属性集合，更取决于该类对象以什么方式参与协作。关于类方法的寻找需要结合“交互模型”的动态协作信息。7.2.4交互建模交互建模捕获参与一个用例执行的对象间的协作过程。系统的任务分解为对象的方法用例的执行过程表示为对象间的协作活动模型和交互模型都用于表示单个用例动态执行过程。但是活动模型在一个较高的抽象层次上分解用例，活动的执行者是系统整体，交互模型则更详细的体现出“对象”是如何协作以完成用例的如果直接产生一个复杂用例的协作模型比较困难，可以首先根据活动模型局部地考虑每个活动的对象协作过程，然后在根据活动间的事件流建立完整用例的交互模型。用例“订购配置计算机”的交互模型交互建模的副产品发现类的方法对象交互与类的方法之间的对应是直接的，即若对象A请求对象B的协作，则对象B（的类）必然包含能够向对象A提供服务的指定方法。确认类之间的关系对象间动态的协作链是类之间静态关系的实例化。即若对象之间存在协作，则对应的类之间必然存在某种形式的关系。7.2.5状态建模状态模型一般针对某一个“类”的对象建立，用以捕获该对象在生命期内状态的动态变化过程。这种状态变化可能跨越了几个用例的行为。OOA阶段并不需要为每个识别到的类建立状态模型对象的行为模式比较复杂，状态的变化将影响到它参与协作的方式需求中明确包含对于特定事物进行状态管理（如在线购物系统中的定单）类的状态变化相对独立于用例，因此状态模型的建立要遵循完整的业务规则。假设“在线购物”系统允许用户对定单进行分期付款，系统在全款支付后打印发票，仓库得到“全款发票”后提货，组装计算机并连同发票一起配送。“在线购物”系统中的定单状态需求中要求：用户可以随时查询定单状态以了解订购活动进展到什么程度。