2.3 BMS顺序图（需求模型）
在UML中，我们将顺序图分为两类，一类用于描述系统需求，构造系统的需求模型（分析模型）；另一类用于指导设计与实现，构造系统的实现模型（设计模型）。
在系统分析时，可以通过顺序图来对执行者和系统的交互过程进行建模，方便用户更好地理解系统的工作流程。对于需求模型顺序图，一般使用用户熟悉的业务语言来进行系统描述，不涉及到实现细节，一方面方便用户理解，另一方面可以指导后续类图的设计。顺序图可显示不同的业务对象如何交互，对于交流当前业务如何进行很有用，一个业务级的顺序图能被当作一个需求文件使用，为实现一个未来系统传递需求；同时，顺序图能够使用更为清晰形象的表达，将用例带入下一层次，通常一个用例可以被细化为一个或者更多的顺序图。顺序图的主要用途之一，是把用例表达的需求，转化为进一步、更深层次的精细表达。
根据需求我们绘制了每一个用例的顺序图，由于篇幅关系，未将每个用例的顺序图一一列举。图2-3、2-4、2-5、2-6分别是用例“登录”、“提交bug信息”、“查看bug信息”和“更新bug信息”的顺序图。（部分顺序图）
图2-6 用例“更新bug信息”顺序图（需求模型）
在实际开发中，我们可以使用顺序图来描述用例的路径，此时，顺序图可以画得更加简单，最简单的顺序图只有两个交互角色，即“执行者”和“系统”。上述四个顺序图还是有点点偏技术的，微笑，在真正与用户交流时可以用更简单的形式。
2.4 状态图（需求模型）
在需求分析过程中，我们发现BMS系统的核心对象是bug，因此可以使用状态图对其进行建模。UML中的状态图可以用来描述一个特定对象的所有可能状态及其引起状态转移的事件。只有那些具有重要交互行为的类，才会使用状态图来描述，一个状态图包括一系列对象的状态及状态之间的转换。在实际建模中，并不需要给出每个对象的状态图，而需要将注意力集中在整体系统或少数关键的对象上，特别是那些状态比较多的对象。
在BMS系统中，最复杂也最为重要的对象是bug，它在系统中拥有多种不同的状态，不同类型的用户可以对其进行操作，为了更好地描述bug对象状态的转换，我们绘制了bug对象状态图，如图2-7所示：
在图2-7中，我们可以清晰了解bug对象在系统中所具有的状态以及这些状态之间的转换过程，如测试人员提交的bug其状态为“新提交bug”，开发组长查看后该bug的状态将变为“开发组长已查看bug”。
2.5 活动图（需求模型）
在状态图中，我们描述了BMS系统中bug对象的各种状态以及状态之间的转换关系，但是这些状态在转换的过程中无法确定何种状态由哪类执行者负责操作，因此可以通过活动图来进行建模，此时的活动图用于对需求模型进行进一步细化。在系统分析过程中，我们使用活动图取代传统的流程图，在表示系统业务流程的同时通过泳道来确定每一个活动的执行者。在活动图中我们还使用了对象流来表示活动与对象之间的依赖关系，描述在活动中对象的状态。通过活动图建立的模型比状态图建立的模型具有更多信息，在BMS中，我们描述了不同用户对bug的操作活动以及在每一次活动之后bug对象所处于的状态，对操作流程进行图形化建模，如图2-8所示：
图2-8 BMS活动图
Bug管理系统UML2.0建模实例（一）
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
