软件工程6史济民研讨.pptVIP

面向对象分析示例 --维护个人信息 面向对象分析示例--维护购物车 面向对象分析示例--从购物车中删除商品 面向对象分析示例 --修改购物车中的商品信息 面向对象分析示例 --生成订单 面向对象分析示例--管理订单 小结 软件分析将软件需求阶段产生的需求模型转变为软件分析模型。分析模型其实就是从软件开发者的角度，在静态组成结构和动态行为两个方面来描述的待开发的软件系统。 面向对象分析利用面向对象的技术来分析问题、建立问题域的静态模型和动态模型，并用UML等工具来表示这一需求对应的类对象模型、对象--关系模型和对象--行为模型等，从而完成对问题域建模，形成面向对象的分析模型。 软件分析通常从用例分析开始，建立系统需求的静态结构模型和动态行为模型。 * 湘 潭 大 学 湘 潭 大 学 第6章 面向对象分析 软件分析概述 面向对象分析建模 面向对象分析示例 6.1 软件分析概述 软件需求与软件分析 软件需求：用户角度，注重软件外在表现 软件分析：开发者角度，注重软件内部逻辑结构 面向对象软件分析 面向对象分析模型 面向对象软件分析OOA OOA的主要任务 理解用户需求 全面地理解和分析用户需求 明确所开发的软件系统的职责 形成文件并规范地加以表述 进行分析，提取类和对象，并结合分析进行建模。基本步骤（反复进行）： 标识类，定义属性和方法；刻画类的层次；表示对象间的关系；为对象的行为建模 。 OOA的模型 需求模型 类/对象模型 对象-关系模型 对象-行为模型 面向对象分析模型 属性、操作、协作者 对象-行为模型 对象- 关系模型 类/对象 模型 以用例模型 为主体的 需求模型 面向对象分析 OOA的优点（与传统分析方法相比） （1）同时加强了对问题域和软件系统的理解； （2）改进包括用户在内的与软件分析有关的各类人员之间的交流； （3）对需求的变化具有较强的适应性； （4）很好地支持软件复用； （5）确保从需求模型到设计模型的一致性。? 分析模型的特点 全面覆盖软件的功能需求 分析模型与软件的实现无关 分析模型的表述方法与所采用的分析技术有关 面向对象分析方法 OOA分析方法众多，典型的是Coad-Yourdon方法，采用五层次的OOA模型。 五层次图 主题（或范畴）的概念。 主题是指导读者（包括系统分析员、软件设计人员、领域专家、管理人员、用户等，总之，“读者”泛指所有需要读懂系统模型的人）理解大型、复杂模型的一种机制。 也就是说，通过划分主题把一个大型、复杂的对象模型分解成几个不同的概念范畴。 OOA分析方法的共同特征 OOA分析方法的共同特征 类和类层次的表示 建立对象-关系模型 建立对象-行为模型 OOA建模步骤 需求理解 定义类和对象 标识对象的属性和操作 标识类的结构和层次 建立对象---关系模型 建立对象---行为模型 评审OOA模型 OOA模型在软件开发中的地位 软件需求模型 软件成品 分析模型 设计模型 实现模型 OOA OOD OOP OOT 6.2 面向对象分析建模 通常把从用例开始的分析过程称为用例分析，这一阶段定义的类称为分析类。 基于用例的面向对象分析步骤是： 回顾需求阶段产生的用例规约，补充必要的详细信息； 研究用例的事件流，将用例的职责分配给若干分析类； 基于这些职责分配以及分析类之间的协作，即可开始为分析类间的关系建模了。 一旦分析了用例，就需要查看确定的类，确保它们被详尽地描述并确保分析模型各个部分之间的一致。 识别与确定分析类 从以文字说明的软件需求过渡到以图形来描述的分析模型，是一个渐进的过程。 查找一种备选的分析类，通常是这个过程的第一步。三种分析类： 边界类boundary：代表系统与外部环境交互的边界。 控制类 control：代表系统在运行中的控制逻辑。 实体类entity：代表系统要存储和维护的信息。 三种分析类 边界类boundary：提供对参与者或外部系统交互协议的接口，隔离系统与外界的变化。用于对系统中依赖于环境的那些部分建模。 用户界面 系统接口 硬件接口 控制类 control：用于封装一个或几个用例所特有的流程控制行为，通过它可以建立系统的动态行为模型。它分离了边界类对象和实体类对象，还将用例所特有的行为与实体类对象分开。 边界类和实体类之间并非始终需要一个控制类，只有当用例的事件流比较复杂并具有可以独立于系统的接口（边界类）或者存储信息（实体类）的动态行为时才需要控制类。 实体类entity：用于对必须存储的信息和相关的行为建模，其主要职责是存储和管理系统中的信息。它通常具有持久性，即属性和关系需要长期保存。 一个实体类对象通常不是某个用例所特有的，甚至不专用于一个系统，其属性和关系的值通常来自于参与者。实体类