下载文档原格式
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标准的主要版本,并简要描述每个版本的主要特点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最新版⼊门图解⼀、UML概述 UML（UnifiedModelingLanguage）统⼀建模语⾔，是⾯向对象软件的标准化建模语⾔。
由于⾯向对象软件开发需要经过OOA（⾯向对象分析），OOD（⾯向对象设计），OOP（⾯向对象编程）三个阶段，每个阶段都需要统⼀的符号设计描述和交流，⽽UML就是这种统⼀的符号表⽰。
本⽂主要讲述UML2.0（最新版本）的各种图的定义及⽤法，UML2.0⼀共包括13种图形（⼤致分成静态图和动态图两类）：活动图，类图，通信图（对应UML1.x的协作图），组件图，复合结构图（UML2.0新增），部署图，交互概观图（UML2.0新增），对象图，包图，顺序图，状态机图，定时图（UML2.0新增），⽤例图，如下图所⽰： 其中，最常⽤的UML图包括：⽤例图，类图，组件图，部署图，顺序图，活动图，状态机图等。
⼆、⽤例图⽤例图主要应⽤于系统需求分析阶段，从⽤户⾓度描述系统的需求功能，⽅便与客户交流，保证需求的唯⼀性。
⽤例图包括⽤例、⾓⾊、⽤例和⾓⾊的关系，其中，⽤例以⼀个椭圆表⽰，⽤例的名称放在椭圆得中⼼或下⾯；⾓⾊以⼀个⼈形符号表⽰与系统交互的实体；⽤例和⾓⾊的关系⽤线段来表⽰。
⽤例图所表⽰的要么是整个系统的全部⽤例，要么是某⼀具体功能的⼀组⽤例。
下图是⼀个简单的⽤户管理模块的部分⽤例⽰意图：从⽤例图中可以很容易看出，普通⽤户有登录、修改密码、查看个⼈信息的功能；管理员功能包括：新增⽤户、查看⽤户信息、修改⽤户信息、删除⽤户、修改密码。
三、类图 类图表⽰系统中有哪些实体及其它们之间的关系，⽤于系统设计阶段。
类图⽤三个矩形表⽰，最上⾯的部分标识类的名称；中间的部分标识类的属性；最下⾯的部分标识类的⽅法，如下图所⽰： 类之间的基本关系：关联（包含聚合和组合）、泛化（继承）、实现、依赖♣关联 关联是⼀种拥有的关系，具有⽅向性，如果⼀个类单⽅向的访问另⼀个类，则称为单向关联（⽤⼀个箭头的实线表⽰）；如果两个类对象可以互相访问，则称为双向关联（⽤两个箭头或不⽤箭头的实线表⽰）；⼀个对象能访问关联对象的数⽬叫做“多重性”。
uml建模实例100例UML（统一建模语言）是一种用于软件开发的标准建模语言，它可以帮助开发人员更好地理解、设计和实现软件系统。
下面是100个UML建模实例。
1. 用例图：描述系统功能和外部用户的行为。
2. 活动图：描述系统中的过程和活动，通常用来描述系统的业务流程。
3. 类图：描述系统中的类、属性和方法、关系等。
4. 对象图：描述系统中的对象及其关系。
5. 状态图：描述系统中的对象或类的状态和状态转换。
6. 序列图：描述系统中的对象或类之间的交互过程。
7. 协作图：描述系统中的对象或类之间的协作过程。
8. 构件图：描述系统的组成部分和它们之间的关系。
9. 部署图：描述系统的物理部署结构和组件之间的关系。
10. 通信图：描述系统中的对象之间的消息传递。
11. 包图：描述系统中的包和它们之间的关系。
12. 组合结构图：描述系统中的组成部分和它们之间的组合关系。
13. 时序图：描述系统中的对象或类之间的时间关系。
14. 交互概述图：描述系统中的对象或类之间的协作过程。
15. 系统顺序图：描述系统中的对象或类之间的时间关系。
16. 概念图：描述系统中的概念和它们之间的关系。
17. 数据流图：描述系统中的数据流和处理过程。
18. 流程图：描述系统中的过程和流程。
19. 参与者图：描述系统中的参与者和它们之间的关系。
20. 视图图：描述系统中的视图和它们之间的关系。
21. 规则图：描述系统中的规则和它们之间的关系。
22. 用例图扩展点：描述用例图中的扩展点和它们之间的关系。
23. 活动图扩展点：描述活动图中的扩展点和它们之间的关系。
24. 类图扩展点：描述类图中的扩展点和它们之间的关系。
25. 对象图扩展点：描述对象图中的扩展点和它们之间的关系。
26. 状态图扩展点：描述状态图中的扩展点和它们之间的关系。
27. 序列图扩展点：描述序列图中的扩展点和它们之间的关系。
28. 协作图扩展点：描述协作图中的扩展点和它们之间的关系。
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”。
