7章OOA实例电子教案.ppt

第7章 OOA&UML应用实例;（1）获取用户的基本需求，识别系统边界和主要服务 创建用例图 编写用例说明文档 （2）分析用例说明，识别出系统执行的活动流程 创建活动图 （3）标出需求中提及的“事物”，识别“实体类” 确定类的属性、方法和类之间的关系 创建类图 （4）将活动图中的活动状态分解为对象协作； 创建协作图 补充类图中的遗漏 （5）对行为模式复杂的对象，分析状态变化序列 为必要的对象创建状态图 （6）复审OOA模型;7.2 在线购物的例子;;（1）用例文档;“订购计算机”的用例说明;7.2.2 活动建模;“订购计算机”的活动模型;系统的活动识别 活动图;6.2.3 类建模;发现类的一般性技术指南（P89） 每个类在系统中必须有存在的目的 每个类应是对一组实例对象的框架描述。孤类的合理性值得商榷（例如仅仅应用到一个图书馆的信息管理系统中，是否应该定义“图书馆”为一个类） 每个类应该有一组属性（复合信息） 每个类应该有一组自己的方法承担系统的部分职责。;在需求信息中识别“名词性事物”作为“候选类”，再基于类的判定原则确定系统的类集合。 在需求分析阶段，主要识别的是在业务领域内有明确意义的事物——实体类，对于软件系统来说，还存在完成其他任务的类，如边界类（用于定义GUI界面的对象框架）和控制类（用于协调、调度其他类的协作），它们的识别和定义一般在设计阶段完成。;“在线购物”系统的类;发现和说明类的属性;“在线购物”系统的类（属性）;发现类的关系;“在线购物”系统的类图;类的方法;7.2.4 交互建模;如果直接产生一个复杂用例的协作模型比较困难，可以首先根据活动模型局部地考虑每个活动的对象协作过程，然后在根据活动间的事件流建立完整用例的交互模型。 ;用例“订购配置计算机”的交互模型;交互建模的副产品;7.2.5 状态建模;类的状态变化相对独立于用例，因此状态模型的建立要遵循完整的业务规则。 假设“在线购物”系统允许用户对定单进行分期付款，系统在全款支付后打印发票，仓库得到“全款发票”后提货，组装计算机并连同发票一起配送。;“在线购物”系统中的定单状态