软件工程Chapter_7 OOA.pptVIP

第七章 面向对象分析 (Object Oriented Analysis);;内容提要;7.1 分析的概念;7.1.1 分析类;UML表示 entity：表示实体类 boundry：表示边界类 control：表示控制类;实体类 描述必须存贮的信息及其相关行为 通常对应现实世界中的“事物” 实体类的 UML 表示： ;边界类 描述外部的参与者与系统之间的交互 类型：用户界面、系统接口、设备接口 边界类的 UML 表示： ;控制类 描述一个用例所具有的事件流控制行为 实现对用例行为的封装，将用例的执行逻辑与边界和实体进行隔离。 控制类的 UML 表示： ;7.1.1 分析类;7.1.2 分析活动; 需求分析将需求获取阶段产生的用例和场景转换成分析模型。其主要活动包括： 理解最初的用例模型，识别出系统的分析类 通过建立系统的顺序图发现可能遗漏的对象类，并定义分析类的属性和行为，确定之间的关系 开发人员和用户一起检查模型，保证模型的正确、完整和一致。 ;内容提要;7.2 分析建模过程;示例：MiniLibrary;7.2.1 补充用例描述;MiniLibrary：补充用例描述;7.2.2 识别分析类;识别边界类应当注意的问题 边界类应关注于参与者与用例之间交互的信息或者响应的事件，不要描述窗口组件等界面的组成元素； 在分析阶段，力求使用用户的术语描述界面； 边界类实例的生命周期并不仅限于用例的事件流，如果两个用例同时与一个参与者交互，那么它们有可能会共用一个边界类，以便增加边界类的复用性。 思考：如何识别 MiniLibrary 的边界类？ ;MiniLibrary：识别边界类;识别控制类 控制类负责协调边界类和实体类，通常在现实世界中没有对应的事物，负责接收边界类的信息，并将其分发给实体类。 一般来说，一个用例对应一个控制类;识别控制类应当注意的问题 当用例比较复杂时，特别是产生分支事件流的情况下，一个用例可以有多个控制类。 在有些情况下，用例事件流的逻辑结构十分简单，这时没有必要使用控制类，边界类可以实现用例的行为。 举例：MiniLibrary系统中的用例“登录” 如果不同用例包含的任务之间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以便降低复杂性 通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控制类，再分析这些控制类找出它们之间的共同之处。 ;MiniLibrary：识别控制类;识别实体类 实体类通常是用例中的参与对象，对应着现实世界中的“事物” ;识别实体类应当注意的问题 实体类的识别质量在很大程度上取决于分析人员书写文档的风格和质量； 自然语言是不精确的，因此在分析自然语言描述时应该规范化描述文档中的一些措辞，尽量弥补这种不足； 在自然语言描述中，名词可以对应类、属性或同义词等多种类型，开发人员需要花费大量的时间进行筛选 思考：如何识别 MiniLibrary 的实体类？;MiniLibrary：识别实体类;27;28;29;7.2.3 定义交互行为;顺序图绘制步骤 列出启动该用例的参与者 列出启动用例时参与者使用的边界对象 列出管理该用例的控制对象 根据用例描述的所有流程，按时间顺序列出分析对象之间进行消息访问的序列。;MiniLibrary：“登记借书”基本流;MiniLibrary：“登记借书”基本流;;MiniLibrary：分析类;7.2.4 建立分析类图;MiniLibrary：分析类图;应用分析模式;7.2.5 检查分析模型;检查“完整性” 每一个分析类都是用例需要的吗？它在什么用例中被创建、修改和删除？是否???在边界类可以访问它？ 每一个属性是在什么时候设置的？其类型是什么？它是限定词吗？ 每一个关系是在什么时候被遍历？为什么选定指定的重数？一对多和多对多的关系能被限定吗？ 每一个控制类对象是否有必要访问参与用例的对象？;检查“一致性” 类或用例有重名吗？ 具有相同名字的实体表示相同的现象吗？ 所有的实体都以同样的细节进行描述吗？ 是否存在具有相同属性和关系却不在同一继承层次的对象？ 检查“可行性” 系统中有什么创新之处？建立了什么计划或原型来确保这些创新的可行性？ 性能是否符合可靠性需求？这些需求是否已被运行在指定硬件上进行原型验证？;本章小结;作业