软件工程 史济民

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
员之间的交流; (3)对需求的变化具有较强的适应性; (4)很好地支持软件复用; (5)确保从需求模型到设计模型的一致性。
• 分析模型的特点
• 全面覆盖软件的功能需求 • 分析模型与软件的实现无关 • 分析模型的表述方法与所采用的分析技术有关
面向对象分析方法
面向对象分析方法有许多不同的版本,典型的有:
在这一点,提交课程表子事件流被执行
绘制出选课用例创建课表事件流的协作图
5: // display course offerings( ) 6: // display blank schedule( )
: RegisterForCoursesForm
: Course Catalog
4: // get course offerings( ) : CourseCatalogSystem
• 分析类图
• 表现分析类及其关系 • 描述某个用例的分析类图称为参与类图(VOPC)。从逻辑上说,每
个用例可对应于一张完整的参与类图。具体实践中,一个用例可以 绘制多张类图,用每张类图展示不同的侧重点。
• 分析类的合并
• 每个分析类都代表一个明确定义的概念,具有不相重叠的职责。一 个类可以参与任何数量的用例,就这个系统而言,需要把具有相似 行为的类合并为一个。
• 有些类所涉及的用例行为比较复杂,并且分 散到不同的事件序列中,这时就需要为这个 类创建一个状态图。
• 针对一个类的状态变化。 • 研究该类的动态行为。
建立对象—关系模型
• 分析类的属性
• 指分析类本身具有的信息。类可以用属性来存储信息。
• 分析类的关联
• 通过关联可以找到其他分析类 • 链与关联的对应关系
OOA OOD OOP OOT
软件需求模型 分析模型 设计模型 实现模型 软件成品
6.2 面向对象分析建模
• 通常把从用例开始的分析过程称为用例分 析,这一阶段定义的类称为分析类。
• 基于用例的面向对象分析步骤是:
• 回顾需求阶段产生的用例规约,补充必要的 详细信息;
• 研究用例的事件流,将用例的职责分配给若 干分析类;
面向对象分析模型
属性、操作、协作者
类/对象 模型
以用例模型 为主体的 需求模型
对象关系模型
对象-行为模型
从客户需求到分析模型
• 认真听取客户陈述他们的需求之后, 分析人员就可以挑选出关键字,将这 些关键字转换成特定的模型元素。
5
从客户需求到分析模型的一些可能的映射:
单词类型 示 例
名词
人、组织、软件系统、数据项 或存在的对象
分析类的合并
• 选课和关闭选课两个类的合并
Register for Courses
Close Registration
RegisterFor CoursesForm
Registration Controller
Course Catalog System
Course Offering
Student Schedule
• 用户界面
• 系统接口
• 硬件接口
• 控制类<< control>>:用于封装一个或几个 用例所特有的流程控制行为,通过它可以建 立系统的动态行为模型。它分离了边界类对 象和实体类对象,还将用例所特有的行为与 实体类对象分开。
• 边界类和实体类之间并非始终需要一个控制 类,只有当用例的事件流比较复杂并具有可 以独立于系统的接口(边界类)或者存储信 息(实体类)的动态行为时才需要控制类。
• 全面地理解和分析用户需求(多视角检验需求) • 明确所开发的软件系统的职责 • 形成文件并规范地加以表述
• 进行分析,提取类和对象,并结合分析进行建模。 基本步骤(反复进行):
• 标识类,定义属性和方法;刻画类的层次;表示对象间的 关系;为对象的行为建模 。
• OOA的模型
• 需求模型 • 类/对象模型 • 对象-关系模型 • 对象-行为模型
• 在后续的开发活动中,分析类将逐步演变为具体的设计元 素,相应地,分析类的职责逐步演变为设计元素的行为, 即设计类的操作和子系统接口的行为。
交互图
:Client
:Supplier
// PerformResponsibility
类图
Supplier // PerformResponsibility
绘制状态图
学生
课程表
课程目录
建立对象—行为模型
• 用例规约中给出了事件流,依据这些事 件流来绘制动态图,包括时序图和协作 图。
绘制出选课用例创建课表事件流的时序图
: Student
: RegisterForCoursesForm
: RegistrationController : CourseCatalogSystem
• 实体类<<entity>>:用于对必须存储的 信息和相关的行为建模,其主要职责是 存储和管理系统中的信息。它通常具有 持久性,即属性和关系需要长期保存。
• 一个实体类对象通常不是某个用例所特 有的,甚至不专用于一个系统,其属性 和关系的值通常来自于参与者。实体类 对象独立于外部环境。
查找分析类
第6章 面向对象分析
软件分析概述 面向对象分析建模 面向对象分析示例
湘潭大学
6.1 软件分析概述
• 软件需求与软件分析
• 软件需求:用户角度,注重软件外在表现 • 软件分析:开发者角度,注重软件内部逻辑
结构
• 面向对象软件分析 • 面向对象分析模型
面向对象软件分析OOA
• OOA的主要任务
• 理解用户需求
CloseRegistration Form
Course Catalog System
Billing System
CloseRegistration Student Controller
• 基于这些职责分配以及分析类之间的协作, 即可开始为分析类间的关系建模了。
• 一旦分析了用例,就需要查看确定的类,确 保它们被详尽地描述并确保分析模型各个部 分之间的一致。
识别与确定分析类
• 从以文字说明的软件需求过渡到以图形来 描述的分析模型,是一个渐进的过程。
• 查找一种备选的分析类,通常是这个过程 的第一步。三种分析类:
: Student
10: // add schedule(Schedule) 9: // create with offerings( ) : Schedule
: Student
为分析类分配职责
• 动态图将用例所要求的行为分派到分析类的过 程,是从软件需求过渡到OOD的重要环节。其 核心概念是消息和职责的对应关系。
• 分析类对象可区分为消息的发出者和接收者。 接收者通过承担相应的职责,作为对发出者的 回应,一个分析类的实例在事件序列中接收的 消息集合,就是该分析类应承担职责的依据。
为分析类分配职责
• 分析类的职责可以从交互提供的消息中得到,对每一条消 息,首先检查接收它的对象所属的类,如果职责不存在, 则创建一个新的职责以便提供需要的行为。职责大多沿用 消息的名称,它还不是类的操作。
2: // get course offerings( ) 8: // create schedule with offerings( )
1: // create schedule( ) 7: // select 4 primary and 2 alternate offerings( )
3: // get course offerings(forSemester) : RegistrationController
1
<<control>> RegistrationController 1
0..1
<<entity>>
Student 1
currentSchedule 0..1
<<entity>>
Schedule
0..*
0..*
primaryCourses <<entity>> CourseOffering
0..4
OOA分析方法的共同特征
• OOA分析方法的共同特征
• 类和类层次的表示 • 建立对象-关系模型 • 建立对象-行为模型
• OOA建模步骤
• 需求理解 • 定义类和对象 • 标识对象的属性和操作 • 标识类的结构和层次 • 建立对象---关系模型 • 建立对象---行为模型 • 评审OOA模型
OOA模型在软件开发中的地位
: Schedule
: Student
: Course Catalog
1: // create schedule( )
2: // get course offerings( )
新建一个 课程表
3: // 百度文库et course offerings(forSemester) 4: // get course offerings( )
G.Booch的
OOD,
J.Rumbaugh的 OMT,(对象,动态,功能模型)
I.Jacobson的 OOSE,(特别强调use case)
Coad&Yourdon的 OOAD, (最易学)
和综合了OOD,OMT,OOSE 而提出的 UM
教材主要介绍基于OOAD(Coad&Yourdon方法)
的需求建模方法。
动词
动作、用户可做的事情或可能 发生的事件
分析模型组件
端点或数据存储 (DFD)
参与者(用例图) 实体或属性(ERD) 类或类属性(类图)
加工(DFD)
用例(用例图) 关系(ERD) 转换(STD) 活动6 (活动图)
面向对象分析
• OOA的优点(与传统分析方法相比)
(1)同时加强了对问题域和软件系统的理解; (2)改进包括用户在内的与软件分析有关的各类人
RegisterForCoursesForm
CourseCatalogSystem
查找分析类
• 为每个用例设置一个控制类
学生
课程注册
课程目录系统
RegistrationController
随着分析的逐步深入, 该控制类有可能分解为 多个控制类或与其他控 制类合并。
查找分析类
• 确定相关的各个实体(包括属性与方法)。实体信息 可以定义成类,或定义成类的属性。如果一个拟建的 实体类A仅被另一个实体类B引用,可将A作为B的属性。 如果某一个实体信息可能被多个类引用,或者该实体 信息具有明显的行为特征,则通常将其定义为一个独 立的实体类。
显示本学期有效的 课程提供的清单
5: // display course offerings( )
显示空的课程 表让学生选择 课程
6: // display blank schedule( )
7: // select 4 primary and 2 alternate offerings( ) 8: // create schedule with offerings( ) 9: // create with offerings( ) 10: // add schedule(Schedule)
• 边界类<<boundary>>:代表系统与外部环境交 互的边界。
• 控制类<< control>>:代表系统在运行中的控 制逻辑。
• 实体类<<entity>>:代表系统要存储和维护的 信息。
三种分析类
边界类 系统边界
控制类 协调用例行为
实体类 系统信息
• 边界类<<boundary>>:提供对参与者或外部 系统交互协议的接口,隔离系统与外界的变 化。用于对系统中依赖于环境的那些部分建 模。
8
面向对象分析方法
• Coad&Yourdon方法,采用五层次的OOA模型。
五层次图
• 主题(或范畴)的概念。
• 主题是指导读者(包括系统分析员、软件设 计人员、领域专家、管理人员、用户等,总 之,“读者”泛指所有需要读懂系统模型的 人)理解大型、复杂模型的一种机制。
• 也就是说,通过划分主题把一个大型、复杂 的对象模型分解成几个不同的概念范畴。
• 查找分析类通常以每一个用例作为一个 研究对象,其活动有:
• 为每对参与者/用例确定一个边界类 • 为每个用例设置一个控制类 • 确定相关的各个实体(包括属性与方法)
查找分析类
• 为每对参与者/用例确定一个边界类
学生
显示学期开设课 程,供学生选择
课程注册
课程目录系统
提供完整课程目 录,可与系统交 互。
链与关联的对应关系
协作图
:Client
PerformResponsibility :Supplier
类图
链 Client
Supplier
Client
0..* 关联
0..*
Supplier
Prime suppliers
PerformResponsibility()
选课用例的参与类图
<<boundary>> RegisterForCoursesForm
相关文档
最新文档