构建这些用例的最佳方式是什么? [英] What is the best way to structure these use cases?

问题描述

目前，我已经定义了 3 个不同的用例，它们实际上只是业务流程中的 3 个步骤......

At the moment, I have defined 3 different use cases that are really just 3 steps in a business process ...

假设我有一份人员名单，所有这些人都对获得一种或多种有限资源感兴趣(例如，他们在音乐会上有座位).

Say I have a list of people, and all these people are interested in obtaining one or more limited resources (say for example, they are seats at concerts).

最终，我想自动公平地将这些人分配到可用的座位上.我有几种不同的算法来执行此操作.

Ultimately, I want to automatically and fairly allocate these people to the available seats. I have a few different algorithms I use to do this.

我正在记录一个已经存在的系统(追溯)，所以即使整个过程有点复杂，我也无法改变它.我必须使用的过程如下:

I am documenting a system that already exists (retrospectively), so even through the process is a little convoluted, I can't change it. The process I have to use is as follows:

1) 定义一组标准.标准可以是人的属性或事件的属性.

1) Define a set of criteria. The criteria can be attributes of the people, or attributes of the event.

例如，其中任何一个都可能是集合"- 罗德斯图尔特音乐会的女性- 麦当娜音乐会的所有人- 所有摇滚音乐会的金人"和银人"

For example, any of these might be a "set" - Female people for the Rod Stewart Concert - All people for the Madonna concert - "Gold" people and "Silver People" for all Rock Concerts

2) 通过执行以下操作来定义分配作业":给它一个名称，选择一种算法，然后选择一个集合"(从所有先前定义的集合中).

2) Define an "allocation job" by doing the following: Give it a name, choose ONE of the algorithms, and choose a "set" (out of all the previously defined Sets).

3) 启动您在第 2 步中定义的分配作业.它在后台运行，您可以稍后查看结果.

3) Kick-off the allocation job you defined in Step 2. It runs in the background and you can look at the results later.

现在，任何步骤 1、2 和 3 都可以在计算机上的单个会话中完成.或者，你可以做 #1，保存它，离开，然后再回来做 #2 并保存它.然后第二天你可以做 3 号.显然 1、2 和 3 之间存在依赖关系，但它们不必立即一个接一个地完成.#1 和 #2 本身并没有任何商业价值，他们只是坐在那里，直到有人出现并执行 #3.

Now, any of the steps 1, 2, and 3 can be done in a single session at the computer. OR, you can do #1, save it, go away, and then come back later and do #2 and save it. Then the next day you can do number 3. Obviously there is a dependency between 1, 2, and 3 but they don't have to be done immediately one after another. #1 and #2 don't really have any business value on their own, they just sit there until someone comes along and does #3.

从用例的角度来看，我最初将 1 和 2 作为包含"用例，但现在我认为这是错误的，因为我认为每次运行用例时都应该始终包含包含".一个用例应始终限于单个会话.

From a Use Case perspective, I originally had 1 and 2 as "includes" Use Cases but now I think that is wrong, because I think an "includes" should ALWAYS be included, every time you run the Use Case. And a Use Case should always be confined to a single session.

现在我在想:

1 和 2 是否扩展"了 3?

Do 1 and 2 "extend" 3?

或者，因为 1 和 2 在你做 #3 之前并没有真正实现任何东西......我是否将它们全部编写为一个用例，使所有 3 个步骤成为可选?

OR, since 1 and 2 don't really achieve anything until you do #3 ... do I write them all as a single Use Case, making all 3 steps optional?

或者，它们只是 3 个不同的用例吗?并且在#2 上有一个集合"存在的先决条件，在#3 上有一个工作"存在?

OR, are they simply 3 different Use Cases? And there is a pre-condition on #2 that a "Set" exists, and on #3 that a "job" exists?

推荐答案

将它们作为单独的用例编写.只有明显增加价值的用例才对其参与者有用.我想说所有命名的 UC 都增加了这样的价值并且是独立的.但是，在不知道您的域的情况下，我无法确定.也许他们形成了一个单一的UC.这需要一个详细的视图.

Write them as separate use cases. Only a use case that clearly adds value is of use to its actor. I'd say that all of the named UCs add such value and are self-standing. However, without knowing your domain I can not be sure. Maybe they form a single UC. This needs a detailed view.

扩展/包含在 UML 中是糟糕的设计(意味着 OMG 在这里做得不好).尝试使用 E/I 几乎总是尝试使用功能分解的标志.但是用例是完全相反的:功能的综合.

Extend/include are bad design in UML (means OMG did not do a good job here). Trying to use E/I is almost always a sign of trying to use functional decomposition. But use cases are about the absolute opposite: synthesizing of functionality.

如有必要，使用前置和后置条件来控制一个用例是否只能在另一个用例之后执行.

If necessary use pre and post conditions to control if a use case can be performed only after another one.

这篇关于构建这些用例的最佳方式是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！