管理信息系统第五章2.ppt

2、面向对象的分析建模 用例分析：从面向对象需求模型（用例模型为主体）中的用例开始的分析过程。 分析类：在用例分析阶段定义的类。其目的是为后续的设计活动提供必要的铺垫，无须确定详细的属性和操作。 属性、操作、协作者 对象-行为模型 对象- 关系模型 类/对象 模型 以用例模型 为主体的 需求模型 ⑴识别与确定分析类 分析类的类型 边界类boundary：代表系统与外部环境交互的边界。提供了系统对参与者或外部系统交互协议的接口，将系统和外部变化隔开，使外界环境的变化不会影响系统内部元素。 用户界面类：用于和系统用户进行通信 系统接口类：用于和其他软件系统进行通信 硬件接口类：为硬件设备提供接口 控制类control：代表系统在运行中的控制逻辑。用于封装一个或几个用例所特有的流程控制行为，有效地分离了边界类对象和实体类对象。 实体类entity：代表系统要存储和维护的信息。用于对系统必须存储的信息及其相关行为建模。 分析类的三种类型 用例 查找分析类 查找分析类以每一个用例作为一个研究对象 为每对参与者/用例确定一个边界类 为每个用例设置一个控制类：此时的控制类将负责对相关用例所描述的功能实现的处理流程。 确定相关的各个实体类（包括属性与方法） 为 “选课系统”中“注册课程”用例确定边界类 注册课程 用户界面类 系统接口类 为 “选课系统”中“注册课程”用例确定控制类 注册课程 为 “选课系统”中“注册课程”用例确定实体类 开设课程 CourseOffering 课程表 Schedule 学生 Student 学生选课 的课程表 本学期开设课程的详细情况 ⑵建立对象-行为模型 内容：根据用例规约中的事件流描述，绘制动态图（如：时序图、协作图等）。 时序图：按时间顺序描述系统元素之间的交互。 参与者→边界类对象→控制类对象→实体类对象 协作图：按照时间和空间的顺序描述系统元素之间的交互及相互关系。 为分析类分配职责：动态图的消息与分析类的职责具有对应关系。消息的接收者通过承担相应的职责，作为对消息发出的响应。一个分析类的实例在事件序列中接收的消息集合，就是该分析应承担的职责的依据。如果职责尚不存在，则创建一个新的职责以便提供需要的行为。 绘制“注册课程”用例“创建课程表”事件流的时序图 2.1.1创建课程表 ①系统从课程目录系统中得到可选择的课程列表，并将列表显示给学生。 ②学生从课程列表中选择4门主要的和两门备选的课程。 ③一旦学生确定了选课情况，系统为他创建一个包含所选课程的课程表。 ④执行提交课程表子事件流。 绘制出“注册课程”用例“创建课程表”事件流的协作图 消息与职责的对应关系 ⑶建立对象-关系模型 分析类的属性 分析类本身具有的信息。命名：名词 属性在逻辑上支撑分析类所承担的职责。 分析类的关联 通过关联可以找到其他分析类 协作图中对象之间的链与分析类之间关联的对应关系 分析类图 表现分析类及其关系 用于描述某个用例的分析类图称为参与类图VOPC（View of participating classes） 分析类的合并 保持类的一致性。每个分析类都代表一个明确定义的概念，具有不相重叠的职责，但一个类可能参与任何数量的用例，因此就整个系统而言，需要合并分析类。 链与关联的对应关系 “注册课程”用例的参与类图 RegisterForCoursesForm boundary CourseOffering entity Schedule entity 0.. * primaryCourses 0..4 Student entity 0.. * 1 RegistrationController control 1 1 0..1 currentSchedule 0..1 CourseCatalogSystem boundary 0..1 1 0..1 0..1 0.. * alternateCourses 0..2 “注册课程”用例与“关闭注册”用例的分析类的合并 小结 软件分析将软件需求阶段产生的需求模型转变为软件分析模型。分析模型其实就是从软件开发者的角度，在静态组织结构和动态行为两个方面来描述的待开发的软件系统。 面向对象分析利用面向对象的技术来分析问题、建立问题域的静态模型和动态模型，并用UML等工具来表示这一需求对应的类对象模型、对象-关系模型和对象-行为模型等，从而完成对问题域建模，形成面向对象的分析模型。 软件分析通常从用例分析开始，建立系统需求的静态结构模型和动态行为模型。 管理信息系统 主讲：周宇葵 第五章 面向对象的开发方法 第二节 面向对象分析 一、概述 1、内容 运用面向对象方法，对问题域和系统责任进行分析和理解，找出描述问题域及系统责任所需的