9

我想质疑和/或挑战关于 UML 行为图的思想流派。

首先，我想问，首先是什么：用例还是活动？

我被教导首先出现用例图，然后对于每个用例，您有一个或多个活动图来表示成功的和替代的流程。从活动图中，您可以识别名词来建立类。

但是，我读过其他文章说您为端到端流程创建了一个活动图，然后您可以从中识别用例。

我可以看到这两种情况都有效，但我很困惑，对我来说这似乎是一种等级制度。例如，假设我有一个高级业务流程，即“学生成绩评分”。如果我将其映射为活动图，我会在其中看到泳道。我将能够挑选出用例，例如“确定成绩边界”、“提交结果”、“将结果转换为成绩”等。

您可能会争辩说它们是同一个东西，即两个图都可以满足这个过程建模的需要。然后我想为下一个级别建模，例如，您如何“提交结果”。

有人可以就最佳实践提出建议：用例图是在活动图之前还是之后？

4

3 回答 3

20

第一的：

任何 UML 图之间都没有竞争成为“第一个”。有时最好同时迭代地处理一些图表。

第二：

每个图表都可以用于不同的上下文和不同的目的。

用例图与活动图

“用例”是显示用户将如何使用系统来实现其目标的场景。

所以：

您可以使用活动图将其步骤可视化，而不是使用书面用例来展示这个“场景” 。

但是为了找到用例，您应该在一定程度上发现系统需求（例如范围、广泛的功能集、优先级、成本等）。

在某些业务领域中，例如自动化项目，为了发现需求/用例，您可能必须调查当前的业务流程。有时此业务流程可能很复杂，因此您可能希望使用活动图对其进行调查。

所以：

活动图可用于调查业务流程以了解和发现流程，从而更好地发现需求。

所以：

活动图可用于不同目的的软件开发阶段的不同级别。

就像其他图表一样，您可以随时随地使用活动图，只要它可以帮助您提出正确的问题，了解和探索与您的目的相关的任何问题。

以下是活动图的摘要目的：

活动图的目的是对作为较大活动一部分的动作的过程流进行建模。在存在用例的项目中，活动图可以更详细地对特定用例进行建模。但是，活动图可以独立于用例来建模业务级功能， 例如购买音乐会门票或注册大学课程。活动图还可用于对系统级功能建模，例如订票数据集市如何填充公司销售系统的数据仓库。 UML 基础：Donald Bell 的活动图

为了快速掌握哪些图表可用于哪些目的，我建议您查看 Scott W. Ambler 的迷你书：UML(TM) 2.0 风格的元素

于 2013-09-30T14:23:27.047 回答
13

Activity diagram is one of the those with widest abstraction range in UML. An activity can be used for anything between a business process (very abstract, comparing with software system) and a single method algorithm (code-level, practically blue-print, meaning kind of abstraction ground level).

Use Cases on the other side are in practice very limited in their abstraction. They show the interaction between a user and the system and would be somewhere in the middle of the abstraction scale. Not as abstract as a business process, and definitelly a lot more abstract than the implementation diagram.

Software projects tend to start working on a very abstract level (business goal for example) and finish with the abstracion 0 (implemented system). During the project analysts, architects and developers work together to gradually lower this abstraction producing always less abstract artifacts/models - business processes, use cases, architecture, design, code.

After this introduction it is not hard to answer your question - any of those can be used first and that depends on type of your project and its size. SOme examples:

  1. A large project of development an ERP system. It is almost certain that in this kind of project the first thing to model is the business process. A long before even thinking of its functionality, the team must understand the business background. The best UML diagram for this is naturally the activity diagram. Some time after, when the process is clear and the high-level reqs known, the use case modelling can start.
  2. A middle sized of relativelly small project, with no complex processes in background (for example a mobile app development) can start directly with use cases, identifying the users and their features. Later on, these can be further refined using activities.
  3. A very small development of some interface, driver of communication gateway, highely technical, where even the user interaction is minimal, the modelling can start with the activities again, showing the concrete algorithm too be implemented. USe cases can be completelly skipped.

As a summary I would conclude that there are no unbreakable rules of this kind in software development. Each project is unique, each development methodology is unique, even each development team is special and unique. To think about "which diagram" to do first is straight and simply WRONG! Think about what kind of analysis or specification you need in a given moment - what is easiest and most usefull to be modelled. When this is clear - there are 13 UML diagrams to pick up from in order to optimally fulfill the aim.

Choice of UML diagram is the "HOW". More important than that is more often than not - the the "WHAT".

于 2014-05-22T17:52:04.950 回答
0

用例图用于显示功能，活动图用于显示操作（1 个功能可以有多个操作）。例如。用例诊断。是莫赫（可以有很多孩子）和活动诊断。就像描述母亲的孩子，即用例诊断。

于 2016-08-31T04:06:22.987 回答