UML实战-BUG管理系统

概述

根据 UML建模的过程来进行一个完整系统的设计–Bug 管理系统。下面是一个标注 UML 设计过程的参考。

• 需求分析：用例图。
• 系统分析：分析业务规则–状态图。
• 系统分析：分析业务流程–活动图。
• 系统设计：设计静态结构–类图和包图。
• 系统设计：Action类被调用关系–序列图。
• 系统设计：用户调用 Action类的过程–协作图。
• 系统架构：组件图和部署图。
• 编码实现。

一、需求分析：用例图

随着社会的蓬勃发展，软件行业的激烈竞争也日益明显，人们对软件的质量要求也越来越严格。软件测试作为保证软件质量的一种手段，也日益被软件开发商所重视，软件测试也是软件开发过程中不可缺少的组成部分，而软件测试过程中的 Bug 管理是软件测试的重要工作，是重中之中，因此对 Bug进行跟踪管理，确保每个被发现的缺陷都能够及时得到处理是测试工作的一项重要内容。

目前流行的 Bug管理系统已经有很多，例如，JRA、Bugzila、DotProject等，它们的管理核心都是系统的 Bug 的发布、分配、解决、检查的功能，这些功能由4种不同的参与者来完成：

• 测试人员来新建 Bug。
• 分配人员负责分配 Bug 给开发人员。
• 开发人员负责解决 Bug，并报告给检查人员检查。
• 检查人员负责检查 Bug，决定是否关闭。

根据上述需求，可以首先绘制出用例图，如图9-1所示。

该图从系统用户的角度展示了系统应该提供的功能。

二、系统分析：分析业务规则–状态图

Bug 管理系统的核心是业务规则–Bug的状态变更。通常的Bug 状态包括如下几种。

• Unassigned–未分配状态:新建的Bug 处于该状态，任何需要重新分配的 Bug 都可以转换到该状态，该状态的 Bug 如果是不必要的可以直接关闭。
• Resolving–正在解决中:表示该 Bug 被分配给了开发人员正在进行解决,如果发现该 Bug不是自己的任务，可以重新分配;如果解决了Bug则可以设置为解决状态。
• Resolved–已解决状态:表示该Bug已经被解决，如果审查人员发现该Bug依然存在，则可以返回给修改人继续解决;如果发现需要分配，可以返回未分配状态;如果已经没有问题了，则可以关闭。
• Closed–关闭状态:表示该Bug已经解决，或者不再需要解决。

其状态转换如图 9-2 所示。