软件工程课件Ch_7 OOA.pptVIP

需求获取阶段:关注理解用户及使用要求 需求分析阶段:关注理解系统需要构建的内容,核心是产生一个准确的、完整的、一致的和可验证的系统模型，称为分析模型。 面向对象的分析模型 功能模型：由用例和场景表示 分析对象模型：由类图和对象图表示 动态模型：由状态图和顺序图表示 内容提要 分析的概念 – 分析类 – 分析活动 基于用例的分析建模 –理解用例模型 –识别分析类 –定义交互行为 –建立分析类图 –检查分析模型 7.1 分析的概念 分析 分析是对需求的精化和构造，产生一个反映真实世界的准确的、简洁的和可理解的模型。 分析是至关重要的，不正确的分析结果将导致开发出来的系统不是用户所期望的。 面向对象分析 注重分析业务领域和系统责任，忽略与实现有关的问题。 发现和描述对象（或概念），分析对象的内部构成和外部关系，建立面向对象的分析模型。 7.1.1 分析类 分析类的概念 在分析模型中，分析类是概念层次上的内容，用于描述系统中较高层次的对象。 分析类直接与应用逻辑相关，而不关注于技术实现的问题。 分析类的类型 实体类：表示系统存储和管理的永久信息。 边界类：表示参与者与系统之间的交互 控制类：表示系统在运行过程中的业务控制逻辑 7.1.1 分析类 UML表示 entity：表示实体类 boundry：表示边界类 control：表示控制类 7.1.1 分析类 实体类 描述必须存贮的信息及其相关行为 通常对应现实世界中的“事物” 实体类的 UML 表示： 7.1.1 分析类 边界类 描述外部的参与者与系统之间的交互 类型：用户界面、系统接口、设备接口 边界类的 UML 表示： 7.1.1 分析类 控制类 描述一个用例所具有的事件流控制行为 实现对用例行为的封装，将用例的执行逻辑与边界和实体进行隔离。 控制类的 UML 表示： 7.1.1 分析类 7.1.2 分析活动 7.1.2 分析活动 需求分析将需求获取阶段产生的用例和场景转换成分析模型。其主要活动包括： 理解最初的用例模型，识别出系统的分析类 通过建立系统的顺序图发现可能遗漏的对象类，并定义分析类的属性和行为，确定之间的关系 开发人员和用户一起检查模型，保证模型的正确、完整和一致。 内容提要 分析的概念 – 分析类 – 分析活动 基于用例的分析建模 –理解用例模型 –识别分析类 –定义交互行为 –建立分析类图 –检查分析模型 7.2 分析建模过程 理解用例模型 理解用例模型和词汇表，适当补充系统内部情况的描述。 识别分析类 找出可能的能够执行用例行为的分析类 定义交互行为 将用例行为分配到分析类中 建立分析类图 确定分析类的关键属性和责任，定义分析类之间的关系。 检查分析模型 示例：MiniLibrary 7.2.1 补充用例描述 补充用例描述 为了发现分析类，有必要补充说明系统的内部行为，即系统内部必须做什么才能响应外部的要求。 可能的情况 用例描述的内容足够充分，不用补充直接可用； 现有事件流中没有明确定义系统内部应该执行的行为，直接在现有用例描述中作出补充行为； 独立于原始用例描述系统的内部行为 注意：没有必要规定系统的哪些部分完成哪些特定任务 MiniLibrary：补充用例描述 举例：“登记还书”用例 7.2.2 识别分析类 识别边界类 通常，一个参与者与一个用例之间的交互或通信关联对应一个边界类。 7.2.2 识别分析类 识别边界类应当注意的问题 边界类应关注于参与者与用例之间交互的信息或者响应的事件，不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面； 边界类实例的生命周期并不仅限于用例的事件流，如果两个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。 思考：如何识别 MiniLibrary 的边界类？ MiniLibrary：识别边界类 7.2.2 识别分析类 识别控制类 控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物，负责接收边界类的信息，并将其分发给实体类。 一般来说，一个用例对应一个控制类 7.2.2 识别分析类 识别控制类应当注意的问题 当用例比较复杂时，特别是产生分支事件流的情况下，一个用例可以有多个控制类。 在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为。 举例：MiniLibrary系统中的用例“登录” 如果不同用例包含的任务之间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以便降低复杂性 通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控制类，再分析这些控制类找出它们之间的共同之处。 MiniLibrary：识别控制类 7.2.2 识别