活动图和SwimLanes

时间:2015-05-01 20:14:44

标签: uml jlist activity-diagram

活动图是否应包含有关系统如何从应用程序开始运行的详细信息?

比如说我正在制作一个swing应用程序,其中app在应用程序打开时加载带有图像的JList,所以我应该在活动图中指定它,即使用户自己还没有执行加载图像的任务在JList中。

活动图中的泳道也应根据我的挥杆应用程序可能具有的类别进行划分。

例如,在简单的挥杆应用程序中,每个模型,视图和控制器都有1个泳道。 以下是我制作的图片,

Simple Activity Diagram

OR

Divided Activity Diagram

我觉得即使第一张图片是正确的,第二张图片也可以让我想象出类图将如何以更好的方式塑造。 我应该使用第二张图片吗?

2 个答案:

答案 0 :(得分:1)

游泳道绝对没有模特意义。他们只是一条线。我建议使用(BPMN原型)UML元素的池/通道。它们被相应地分类(通常与演员一起),并且单个动作分别进入每个动作。这为活动提供了清晰的结构,也显示了责任。

答案 1 :(得分:1)

与往常一样,答案是“它取决于”。详细程度不是由图表的类型决定的,而是由使用图表的上下文决定的。

如果该图旨在显示通过用例的流程,它应该将自己限制为显示由actor和整个系统执行的活动,而不是系统的各个部分。

另一方面,如果活动图显示了用例实现的流程,那么它应该显示系统的不同部分。

让我们说在项目的中途你决定改变设计而不是使用MVC。这意味着需要重新绘制图表。如果图表是用例实现的一部分,那就是预期的(因为这就是你所做的,你决定以不同的方式实现用例)。但是,用户本身的一部分图表不需要重新绘制,因为您已经改变了设计;演员和整个系统之间的互动流程不应该改变。

也就是说,MVC是一种众所周知的破坏用户交互的方式,即使在用例中也可以允许进入该级别的细节。因此,假设您正在记录用例而不是实现,如果在您的项目或公司中用户交互总是设计为MVC,那么我说要马上进行 - 但要严格遵守使用“模型”而不是“图像服务”。如果在用例分析阶段无法决定使用MVC设计,我会反对。