Bug管理系统UML2.0全程建模(V1.0)
教务管理系统UML模型
静态图首页
17
配 置 图
静态图首页
18
动态图
时序图
协作图 状态图 活动图
目錄
19
系统的时序图
• • • • • • • 管理员登录时序图 教务学籍管理时序图 学生注册时序图 学生登录时序图 学生选课时序图 教师登录时序图 教师成绩录入时序图
动态图首页
20
返回
21
教务学籍管理时序图
返回
22
返回
返回
39
学生成绩查询活动图
返回
40
系 统 管 理 员 修 改 学 生 资 料 活 动 图
返回
41
42
4
需求层次图：
流程
5
系统需求分析
（1）基础资料 要求能够对院系、专业、 教师、课程、班级等信息进行查询。 （2）教学管理 要求能够对学生成绩信息 进行查询，修改，删除。
（3）用户管理 要求能够添加用户和修改 密码。
6 流程
角色的确定
UML中，角色代表位于系统之外和 系统进行交互的一类对象，本系统中创 建主要的角色有：
教务管理系统UML模型
11级计科2班 李江慧090511233 沈良慧090511237 符 鹤090511231
分工情况：
前期--------李鸣：主要负责资料的收集和准备工作。
李江慧：主要负责用例图、对象图、类图、状态 图和部分协作图的绘制； 沈良慧：主要负责时序图、协作图、活动图的绘 制。
中期
后期 ------符鹤：主要负责组件图、配置图的绘制，幻灯片和 文档的制作。
2
教务管理系统
软件需求 分析 UML基本模型
系统需求 分析
3
软件需求分析
第2章 统一建模语言UML
UML 2.0
1997年对象管理组织（Object Management Group
，OMG）采纳UML作为其标准建模语言，并通过严 格有序的OMG过程对其进行修订和维护。 1999，UML 1.3，相对稳定成熟阶段 2001-05， UML 1.4 2003年6月宣告完成了UML 2.0 ： Infrastructure（底层结构） Superstructure（上层结构） OCL（对象约束语言） Diagram Interchange（图形交换）
关联类
关联类用来记录与关联（关系）有关的信息，提
供与关联有关的操作。
+Employee +Employer
Person
* 1
Company
Employment +Contract
（2）包图
包图在UML中可以看作是类图的一部分。
包用来对一组元素进行划分，是对复杂模型的一
种分而治之的层次划分。 常用来描述一个复杂系统逻辑上的子系统划分。 包图主要由包和包之间的关系组成。 包的划分应遵循高内聚、低耦合的原则，一个包 中可以包含多个类和子包。 包图的图元： 包、依赖关系、导入关系、合并关系
UML 2.0的建模机制
类图 (Class Diagram) 包图 (Package Diagram) 对象图 (Object Diagram) 结构建模 (Structure) 构件图 (Component Diagram)
组合结构图 (Composite Structure Diagram)
UML 2.0 建模机制
* 1
OrderItem
Order
泛化（继承）关系
Person
Bug管理系统UML2.0全程建模(V1.0)
Bug管理系统UML 2.0全程建模——系统分析与设计报告刘伟(中南大学信息科学与工程学院湖南长沙 410083)目录1．项目概述 (1)1.1需求分析 (1)1.2开发技术 (3)1.3UML2.0全程建模概述 (3)2．系统分析 (4)2.1用例模型 (5)2.2BMS用例图 (5)2.3BMS时序图（需求模型） (6)2.4BMS状态图（需求模型） (8)2.5BMS活动图（需求模型） (9)3．系统设计 (10)3.1体系结构设计 (11)3.2BMS类图 (12)3.3BMS时序图（实现模型） (13)3.4BMS包图 (15)3.5BMS组件图 (15)3.6BMS部署图 (16)4．参考资料 (17)1．项目概述随着软件项目规模和复杂性的增大，有效跟踪和管理项目中存在的缺陷Bug 变得越来越重要。
每一个软件企业都需要妥善处理软件中的缺陷，这将直接关系到软件过程质量与软件产品质量，但并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。
在软件缺陷管理(Software Defect Management)中，软件缺陷的分类和管理非常重要，因此软件缺陷管理工具的开发和使用将在现代软件开发中发挥重要作用。
本报告将使用UML2.0对Bug管理系统进行全程建模，该系统名为缺陷管理系统(Bug Management System, BMS)，并按照软件工程的标准，提供一套完整的解决方案。
1.1 需求分析一个完备的bug管理流程通常包括如下几个步骤，如图1-1所示：图1-1 bug管理流程图图1-1是bug管理的最基本流程，而实际的bug管理要更加复杂，不同的步骤由不同的角色负责，如提交bug、验证修改后的软件是测试人员的工作，分析和定位bug以及修改相应的软件是分析设计人员以及开发人员的工作，在整个过程中项目经理还需要对bug信息进行统计和监控。
在BMS的需求分析过程中，我们发现bug管理流程的某些步骤可以通过一个bug管理系统来完成，一方面可以提高bug的处理速度，另一方面便于对bug信息的跟踪与统计。
UML 2.0的新特性以及在选课系统中的应用
ＵＭＬ２０为 ＭＤ 提 供 了 坚 实 的基 础 。正 如 Ｏ Ｇ 的 主席 和 ． Ａ Ｍ Ｃ Ｏ： ｉ ａｄＳ ｌｙ博 士 所 言 ， Ｅ Ｒｃ ｒ ｏｅ ｈ 一个 重要 的新 标 准 将 对 软 件 开
发的未来产生巨大的影响 。
着ＵＭ Ｌ ２ ０ 约 的最 终 成 型 。 Ｌ ． 克 服 了ＵＭ Ｌ ． ． 规 ＵＭ ２ ０ １ ０的 缺 点 ， 强 了该 建 模 语 言 的可 扩 展 性 。 级 后 的ＵＭ Ｌ ． 规 约 有 增 升 ２０
以下 特 点 ：
（ ） 体 系结 构 上 改 进 与 其他 Ｏ Ｇ 建 模 规 约 的 接 口 ， １在 Ｍ 使
２ ＵＭＬ ２ ０的修 订 过程和 新特 性 ．
虽 然 ＵＭＬ 已经 成 为 软件 开发 行业 中 事 实 上 的 标 准 ， 各 被 企 业 的 开 发 人 员 所 使 用 ， 且 已经 被 植 人 多 个 产 品 中 ， 如 而 例
（） ３ 整理 并 强 化类 和组 件 的 内部 结 构 。 加 了一 种 专 为 复 增
Ｃ ｎｅ 。但 是 近几 年 来 软 件 工 业 在 飞 速 的 发 展 ， 着 ＪＥ 和 ｅ ｔｒ 随 ２Ｅ
微 软 的 Ｃ Ｍ ＋ ，ＮＥ 技 术 的 出现 ， 件 技 术 得 到 很 大 发 展 ， ０ ． Ｔ 组
图 ， 况 图 ， 图 ， 序 图 以及 通 讯 图 相 对 于 ＵＭＬ １０的 改 进 。最 后 还 对 ＵＭＬ 的 未 来 发展 做 了客 观 的 分 析 。 用 类 顺 ．
关键词 ： ＵＭＬ ． 课识码 ： Ａ
１ 前 言
企 业 应 用 中普 遍 使 用 基 于 构 件 的 开 发 ， Ｌ １ｘ已经 不 能 完 ＵＭ ．
UML2.0详细教程
类 是对一组具有相同属性、相同操 作、相同关系和相同语义的对象 的描述
NewClass
节点
是在运行时存在的物理元素 它由在特定语境中共同完成一定 任务的一组对象间交换的消息组 成 它描述了一个对象或一个交互在 生命期内响应事件所经历的状态 序列
NewPro cessor
包：把元素组织成组的机制
注释事物： UML模型的解释部分，用来对模型中的元素进行说明，解释 注释事物
注解：对元素进行约束或解释的简单符号 注解
UML
-5-
1. 前言
1.4 UML关系 关系
1.4.1依赖 依赖
依赖(dependency)是两个事物之间的语义关系，其中一个事物(独立事物)发生变化， 会影响到另一个事物(依赖事物)的语义
UML2.0 详细教程
UML
-1-
目录
1. 前言
1.1前言 前言 1.2UML概述 概述 1.3UML事物 事物 1.4UML关系 关系 1.5各UML图及特征 各 图及特征 1.6各UML图的关系 各 图的关系 1.7UML语法 语法 1.8习题 习题
2. 用例图
2.1用例图概要 用例图概要 2.2用例图中的事物及解释 用例图中的事物及解释 2.3用例图中的关系及解释 用例图中的关系及解释 2.4例子 例子 2.5习题 习题
1.5.8 构件图 构件图(Component Diagram)
※ 构件图为系统的构件建模型—构件即构造应 用的软件单元—还包括各构件之间的依赖关 系，以便通过这些依赖关系来估计对系统构 件的修改给系统可能带来的影响
UML
- 10 -
1. 前言
1.5 各UML图及特征 图及特征
教务管理系统UML模型
§1 建立系统用例模型
(1)角色的确定
UML中，角色代表位于系统之外和系统 进行交互的一类对象，本系统中创建主要 的角色有： 教务员 教师 学生
(2)创建用例 教务管理系统根据运行流程可分为以下的几个用
例： 用户登录 学籍管理 排课管理 成绩管理 选课管理 教学管理 系统维护
§1.1建立用例图
建立如下四个用例图 （一）顶层用例图 （二）学生角色用例图 （三）教师角色用例图 （四）教务员角色用例图
顶层用例图
学 生 角 色 用 例 图
教 师 角 色 用 例 图
教 务 员 角 色 用 例 图
§2 建立系统动态模型
2.1活动图 经过活动图的建模可以比较清楚地了
解整个进程过程的操作过程，本系统中 主要的活动图有如下几个：学生成绩查 询活动图、教务员修改学生资料活动图、 学生选课活动图以及教师成绩录入活动 图
学 生 成 绩 查 询 活 动 图
教 务 员 学 生 资 料 修 改 活 动 图
学 生 选 课 活 动 图
教 师 成 绩 录 入 活 动 图
§2建立动态模型
2.2顺序图 主要包括如下几个顺序图 ①教务学籍管理顺序图 ②学生注册顺序图 ③学生选课顺序图 ④教师成绩录入顺序图
教 务 成 绩 录 入 协 作 图
§3系统类模型
3.1系统包图 将整个教务管理系统划分为人员信息、 接口和事务3个包，分别控制不同的应 用。
系统包图
§3系统类模型
3.2类图 根据系统划分的三类包图，分别讨论
人员信息包，接口包和事务包中的类图 分别为： 1、人员信息包内的类图 2、接口包内的类图 3、事务包内的类图
问题概述
在高校日常管理中，教务管理模式的科学 化与规范化，管理手段的信息化与自动化 对于学校的总体发展产生深远的影响，由 于管理内容过多，处理的过程也非常复杂， 随着学校人员的增加，教务管理系统的信 息量大幅上升，因此往往很难及时准确地 掌握教务信息的运作状态，所以迫切需要 现代化管理要求的教务管理系统。
请说明uml标准的主要版本,并简要描述每个版本的主要特点
请说明uml标准的主要版本,并简要描述每个版本的主要特点UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言。
以下是UML主要版本的简要描述：1. UML 1.x：UML的最早版本，于1997年发布。
它引入了基本的建模概念和图表，包括用例图、类图、对象图、状态图、活动图、顺序图等。
UML 1.x版本相对简单，注重静态结构的建模。
2. UML 2.0：UML的第二个主要版本，于2005年发布。
UML 2.0对UML 1.x进行了扩展和改进，引入了更多的建模概念和图表，如组件图、部署图、通信图等。
它还引入了更多的语义规则和约束，提供了更丰富的建模能力和表达能力。
3. UML 2.1：UML 2.1是UML 2.0的一个更新版本，于2007年发布。
它修复了一些错误和缺陷，并提供了更清晰的规范和指南。
此外，UML 2.1还引入了几个新的图表，如时间图和交互概览图，以及一些新的建模概念。
4. UML 2.2：UML 2.2是UML 2.1的一个小幅更新版本，于2009年发布。
它主要修复了一些错误和缺陷，并提供了更清晰的规范和指南。
此外，UML 2.2还引入了一些新的建模概念和图表，如模型合成和系统分析图。
5. UML 2.3：UML 2.3是UML 2.2的一个小幅更新版本，于2010年发布。
它主要修复了一些错误和缺陷，并提供了更清晰的规范和指南。
此外，UML 2.3还引入了一些新的建模概念和图表，如需求图和结构化活动节点。
总的来说，UML的主要版本包括UML 1.x、UML 2.0、UML 2.1、UML 2.2和UML 2.3。
每个版本都在前一个版本的基础上进行了扩展和改进，引入了新的建模概念、图表和语义规则，提供了更丰富和强大的建模能力和表达能力。
随着UML的不断发展，它已经成为软件系统建模领域的主要标准之一。
UML2.0最新版入门图解
UML2.0最新版⼊门图解⼀、UML概述 UML（UnifiedModelingLanguage）统⼀建模语⾔，是⾯向对象软件的标准化建模语⾔。
由于⾯向对象软件开发需要经过OOA（⾯向对象分析），OOD（⾯向对象设计），OOP（⾯向对象编程）三个阶段，每个阶段都需要统⼀的符号设计描述和交流，⽽UML就是这种统⼀的符号表⽰。
本⽂主要讲述UML2.0（最新版本）的各种图的定义及⽤法，UML2.0⼀共包括13种图形（⼤致分成静态图和动态图两类）：活动图，类图，通信图（对应UML1.x的协作图），组件图，复合结构图（UML2.0新增），部署图，交互概观图（UML2.0新增），对象图，包图，顺序图，状态机图，定时图（UML2.0新增），⽤例图，如下图所⽰： 其中，最常⽤的UML图包括：⽤例图，类图，组件图，部署图，顺序图，活动图，状态机图等。
⼆、⽤例图⽤例图主要应⽤于系统需求分析阶段，从⽤户⾓度描述系统的需求功能，⽅便与客户交流，保证需求的唯⼀性。
⽤例图包括⽤例、⾓⾊、⽤例和⾓⾊的关系，其中，⽤例以⼀个椭圆表⽰，⽤例的名称放在椭圆得中⼼或下⾯；⾓⾊以⼀个⼈形符号表⽰与系统交互的实体；⽤例和⾓⾊的关系⽤线段来表⽰。
⽤例图所表⽰的要么是整个系统的全部⽤例，要么是某⼀具体功能的⼀组⽤例。
下图是⼀个简单的⽤户管理模块的部分⽤例⽰意图：从⽤例图中可以很容易看出，普通⽤户有登录、修改密码、查看个⼈信息的功能；管理员功能包括：新增⽤户、查看⽤户信息、修改⽤户信息、删除⽤户、修改密码。
三、类图 类图表⽰系统中有哪些实体及其它们之间的关系，⽤于系统设计阶段。
类图⽤三个矩形表⽰，最上⾯的部分标识类的名称；中间的部分标识类的属性；最下⾯的部分标识类的⽅法，如下图所⽰： 类之间的基本关系：关联（包含聚合和组合）、泛化（继承）、实现、依赖♣关联 关联是⼀种拥有的关系，具有⽅向性，如果⼀个类单⽅向的访问另⼀个类，则称为单向关联（⽤⼀个箭头的实线表⽰）；如果两个类对象可以互相访问，则称为双向关联（⽤两个箭头或不⽤箭头的实线表⽰）；⼀个对象能访问关联对象的数⽬叫做“多重性”。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Bug管理系统UML 2.0全程建模——系统分析与设计报告刘伟(中南大学信息科学与工程学院湖南长沙 410083)目录1．项目概述 (1)1.1需求分析 (1)1.2开发技术 (3)1.3UML2.0全程建模概述 (3)2．系统分析 (4)2.1用例模型 (5)2.2BMS用例图 (5)2.3BMS时序图（需求模型） (6)2.4BMS状态图（需求模型） (8)2.5BMS活动图（需求模型） (9)3．系统设计 (10)3.1体系结构设计 (11)3.2BMS类图 (12)3.3BMS时序图（实现模型） (13)3.4BMS包图 (15)3.5BMS组件图 (15)3.6BMS部署图 (16)4．参考资料 (17)1．项目概述随着软件项目规模和复杂性的增大，有效跟踪和管理项目中存在的缺陷Bug 变得越来越重要。
每一个软件企业都需要妥善处理软件中的缺陷，这将直接关系到软件过程质量与软件产品质量，但并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。
在软件缺陷管理(Software Defect Management)中，软件缺陷的分类和管理非常重要，因此软件缺陷管理工具的开发和使用将在现代软件开发中发挥重要作用。
本报告将使用UML2.0对Bug管理系统进行全程建模，该系统名为缺陷管理系统(Bug Management System, BMS)，并按照软件工程的标准，提供一套完整的解决方案。
1.1 需求分析一个完备的bug管理流程通常包括如下几个步骤，如图1-1所示：图1-1 bug管理流程图图1-1是bug管理的最基本流程，而实际的bug管理要更加复杂，不同的步骤由不同的角色负责，如提交bug、验证修改后的软件是测试人员的工作，分析和定位bug以及修改相应的软件是分析设计人员以及开发人员的工作，在整个过程中项目经理还需要对bug信息进行统计和监控。
在BMS的需求分析过程中，我们发现bug管理流程的某些步骤可以通过一个bug管理系统来完成，一方面可以提高bug的处理速度，另一方面便于对bug信息的跟踪与统计。
通过对bug管理流程和实际使用过程的需求分析，BMS系统基本需求如下：(1) 系统预设管理员帐号为Admin，初始密码为Admin。
BMS系统管理员在登录系统后可修改密码，系统管理员的主要工作包括增加相关人员初始信息，包括帐号、初始密码和项目角色，项目角色包括测试人员、开发组长、开发人员和项目经理；另外，系统管理员还可以删除人员信息。
(2) 其他用户在登录后方可使用该系统，除了帐号和项目角色外用户可以修改各项个人信息，包括真实姓名、联系电话和电子邮箱等。
(3) 测试人员可以利用BMS提交自己发现的bug信息，提交的信息包括bug 类型、bug严重程度、bug发生的位置（如所处功能模块、测试界面的URL或名称等）、测试环境描述、使用的测试工具和版本信息、测试用例信息（包括测试数据、期望结果和实际结果等信息）、附加描述信息、附件（屏幕截图或录像等）等。
测试人员将尽量填写完整这些信息以便最大程度帮助开发人员重现bug以便调试，在系统数据库中需要记录bug的状态。
(4) 测试人员将bug提交给开发组长，开发组长在查看bug信息之后可将bug 分发给相关开发人员，系统可以记录开发组长的bug查看和分发情况。
(5) 开发人员可以登录系统查看bug详情，系统可以记录开发人员是否已查看bug详情。
在对bug进行修复后，更新bug修复信息（修复内容、修复时间、修复人等），将更新的bug信息发送给测试人员，系统将修改bug的状态，然后通知测试人员以获取最新版本进行验证。
(6) 测试人员如验证无误，可关闭该bug；否则可重新返回开发人员修复。
无论验证是否通过，测试人员需更新bug测试信息（测试结果、测试时间、测试人等）。
(7) 项目经理可以随时查看bug统计报告，对bug信息进行分类汇总与实时跟踪。
1.2 开发技术本系统采用三层B/S结构进行开发，包括客户端浏览器层、Web服务器层和数据库服务器层，系统整体架构如图1-2所示：图1-2 BMS整体架构在实际部署和使用过程中，如果数据量较小，可以将Web服务器和数据库服务器合二为一。
B/S结构具备部署和升级简单等优点，系统安装、修改和维护全在服务器端解决，用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块；同时B/S结构还提供了一种异种机、异种网联机、联网解决方案，开发团队与测试团队可以基于不同的操作系统平台和网络环境进行协同工作。
BMS系统开发技术包括：采用Java EE平台，使用MVC架构，运用JSP + Servlet + JavaBean等技术来实现系统功能，数据库采用MySQL，并使用Navicat 8 for MySQL对MySQL数据库进行可视化管理，服务器中间件使用Tomcat 6.5，开发工具使用MyEclipse 8.0。
1.3 UML2.0全程建模概述为了更为高效快捷地开发BMS，我们采用了UML(Unified Modeling Language, 统一建模语言) 2.0建模技术，并充分使用UML 2.0建模语言的特性，对系统进行全程建模。
在使用UML 2.0的同时，我们提出了UML全程建模(UML-Full Process Modeling, UML-FPM)的概念，将UML 2.0中的13种图应用于系统分析与设计的全过程，通过对UML 2.0十三种图进行分析，并根据这些图之间的关系及作用绘制了如图1-3所示的UML 2.0全程建模流程图，在该图中将系统开发过程分为两个大阶段：需求分析与系统分析，系统设计与实现，该图使用UML活动图绘制，较为全面、清晰地描述如何应用UML技术来构造系统的分析与设计模型以及UML各图形之间的关系。
[是][逻辑划分][是][是]用例图（用例文档）时序图（需求模型）是否存在复杂对象通信图（需求模型）是否需要清晰显示交互对象关系是否存在复杂流程状态图（需求模型）活动图（需求模型）时序图（实现模型）状态图（实现模型）是否需要对时序图进行组织活动图（实现模型）是否需要清晰显示对象间的关系是否需要了解每一个活动的细节通信图（实现模型）交互概览图是否需要标明定时约束是否需要一个类图实例类图定时图对象图组件图部署图包图组合结构图内部结构是否复杂图1-3 UML 2.0全程建模流程图BMS采用UML-FPM进行全程建模，我们构造了BMS的各种视图，包括用户视图、结构视图、动态视图、实现视图和环境视图，每种视图对应一种或多种UML图形，通过这些图形来对系统进行全面而有效的分析与设计。
2．系统分析在BMS的系统分析阶段，我们使用了用例图、时序图、状态图和活动图等UML图形构造系统的分析模型，对系统进行深入的分析，明确系统的开发目标，更好地回答了“做什么”的问题，各种图形相互补充，从不同的角度对系统进行全面的分析。
通过使用UML-FPM方法，我们构造了系统的分析模型，具体分析工作如下：2.1 用例模型在BMS 系统中，我们首先使用用户视图即用例图来将系统功能需求图形化，通过找出执行者与用例来明确和细化系统功能。
UML 用例建模流程如图2-1所示：图2-1 UML 用例建模流程图BMS 的执行者包括系统管理员、开发组长、开发人员、测试人员和项目经理，每个执行者对应的功能有所差异。
系统提供主要功能包括人员信息的管理和bug 信息的管理，因此用例主要包括对人员信息和bug 信息的增删改查等操作。
2.2 BMS 用例图通过对系统进行分析，BMS 用例图如图2-2所示：增加人员信息删除人员信息登录查看bug 统计报告提交bug 信息分发bug修改个人信息查看bug 信息更新bug 修复信息关闭bug 信息修改密码更新bug 测试信息图2-2 BMS 用例图2.3 BMS时序图（需求模型）在UML-FPM中，我们将时序图分为两类，一类用于描述系统需求，构造系统的需求模型；另一类用于指导设计与实现，构造系统的实现模型。
在系统分析时，可以通过时序图来对执行者和系统的交互过程进行建模，方便用户更好地理解系统的工作流程。
对于需求模型时序图，一般使用用户熟悉的业务语言来进行系统描述，不涉及到实现细节，一方面方便用户理解，另一方面可以指导后续类图的设计。
时序图可显示不同的业务对象如何交互，对于交流当前业务如何进行很有用，一个业务级的时序图能被当作一个需求文件使用，为实现一个未来系统传递需求；同时，时序图能够使用更为清晰形象的表达，将用例带入下一层次，通常一个用例可以被细化为一个或者更多的时序图。
时序图的主要用途之一，是把用例表达的需求，转化为进一步、更深层次的精细表达。
根据需求我们绘制了每一个用例的时序图，由于篇幅关系，未将每个用例的时序图一一列举。
图2-3、2-4、2-5、2-6分别是用例“登录”、“提交bug信息”、“查看bug信息”和“更新bug信息”的时序图。
登录界面业务对象数据库操作对象数据库图2-3 用例“登录”时序图（需求模型）提交界面业务对象数据库操作对象数据库图2-4 用例“提交bug信息”时序图（需求模型）bug显示界面业务对象数据库操作对象数据库图2-5 用例“查看bug信息”时序图（需求模型）16: 返回信息15: 返回信息14: 返回信息13: 更新数据库12: 更新bug信息11: 提交修复信息8: 返回bug信息6: 返回bug信息返回bug信息bug信息修改界面业务对象数据库操作对象数据库bug显示界面ref查看bug信息()7: 返回bug信息5: 查询数据库4: 查询bug信息图2-6 用例“更新bug 信息”时序图（需求模型）2.4 BMS 状态图（需求模型）在需求分析过程中，我们发现BMS 系统的核心对象是bug ，因此可以使用状态图对其进行建模。
UML 中的状态图可以用来描述一个特定对象的所有可能状态及其引起状态转移的事件。
只有那些具有重要交互行为的类，才会使用状态图来描述，一个状态图包括一系列对象的状态及状态之间的转换。
在实际建模中，并不需要给出每个对象的状态图，而需要将注意力集中在整体系统或少数关键的对象上，特别是那些状态比较多的对象。
在BMS 系统中，最复杂也最为重要的对象是bug ，它在系统中拥有多种不同的状态，不同类型的用户可以对其进行操作，为了更好地描述bug 对象状态的转换，我们绘制了bug 对象状态图，如图2-7所示：新提交bug开发组长已查看bug已分发bug开发人员已查看bug已关闭bug已修复bugdo / 验证图2-7 bug对象状态图在图2-7中，我们可以清晰了解bug对象在系统中所具有的状态以及这些状态之间的转换过程，如测试人员提交的bug其状态为“新提交bug”，开发组长查看后该bug的状态将变为“开发组长已查看bug”。