我的用例图和场景是否正确？

Question

大家度过美好的一天，我正在学习UML，我需要有关用例的建议。我正在设计一个会员经理系统。国家/地区管理员可以管理所有（子）组织和用户。我还创建了一个客户管理员，以便客户能够管理其（子）组织的用户。客户管理员无法管理组织，他只能看到自己的（子）组织及其用户。我画了这个用例图：

我用这种方式写了这个场景：

--- BEGIN ---
Use-case name: Set Up Organization Tree
Description: Allow country admins or customer admins to set up the organization
  structure. Country admins can see or update all members of their country. Customer
  admins can see or update members of their own organization only. 
Actors:
  - Primary actor - Country admin
  - Secondary actor – Customer admin

Basic-flow: Set up an organization structure in the country root
  1) Log in
  2) View organization tree
  3) Create a new organization
  4) Create a new user within the organization
  5) Set the password of the user
  6) 2 to 5 may repeat
  7) Log out

Alternate fow: Set up user accounts within the existing organization
  1) Log in
  2) View organization tree
  3) Create a new user within the selected organization
  4) Set the password of the user
  5) 2 to 5 may repeat
  6) Log out
--- END ---

我不确定它是否正确。可以在基本流程中创建组织，以便描述国家/地区管理员可以执行的操作。在备用流程中，只能创建用户，因此它描述了国家管理员和客户管理员都可以做的事情。但是，客户管理员只能看到自己的组织这一事实在此处不可见。此外，我不确定是否可以在单个用例备用流程中描述所有内容，或者我是否应该创建两个单独的用例。一个用于国家管理员，一个用于客户管理员。如果我为国家管理员创建了单独的用例图表，我想我不会在那里提及客户管理员，那么我也不应该绘制客户管理员演员和演员的概括？ 非常感谢提前。

Vojtech

编辑1：

这是更新版本：

并更新了情景：

--- BEGIN ---
Use-case name: Create New Customer Organizational Structure
Description: Allow country admin to create new organizational structure of the customer including users. Allow customer admins to create new users within the existing organizational structure. The country admin can see or update all members of the country. The customer admin can see or update users of his/her own organization only.

Actors:
- Country admin
- Customer admin


Basic-flow: Country admin creates new customer organizational structure

Pre-conditions:
- The country admin is logged in
- The customer organizational hierarchy doesn't exists in the Member Manager

Flow of events: Create New customer Organizational Structure 
1) The country admin views the organization tree
2) The country admin creates a new organization
3) The country admin creates a new user within the organization
4) The country admin sets the password of the user
5) 1 to 4 may repeat

Post-condition:
- Customer organizational hierarchy is created
- Customer users are created
- Each user has a password


Alternate fow: Country admin creates new user in the existing organizational structure

Pre-conditions:
- The country admin is logged in
- The country admin can see or edit all members of the country
- The customer organizational hierarchy exists in the Member Manager
- The user that is going to be created doesn't exist

Flow of events:
1) The country admin views organization tree
2) The country admin creates a new user within the selected organization
2) The country admin sets the password of the user
4) 1 to 3 may repeat

Post-condition:
- New users are created in the selected organization
- Each user has a password


Alternate fow: Customer admin creates new user in the existing organizational structure

Pre-conditions:
- The customer admin is logged in
- The customer admin can see or edit members of his own organization only
- The customer organizational hierarchy exists in the Member Manager
- The user that is going to be created doesn't exist

Flow of events;
1) The customer admin views organization tree
2) The customer admin creates a new user within the selected organization
2) The customer admin sets the password of the user
4) 1 to 3 may repeat

Post-condition:
- New users are created in the selected organization
- Each user has a password

--- END ---

现在我的方案中有两个备用flws：

- Alternate fow: Country admin creates new user in the existing organizational structure
- Alternate fow: Customer admin creates new user in the existing organizational structure

是否有必要提及它们？它们与国家管理员是客户管理员的专业化相同。 我还提到客户管理员只能看到他自己组织的成员，而国家管理员可以在场景描述，前提条件和图表说明中看到该国家的所有成员。这是应该的方式吗？

谢谢。 Vojtech

Answer 1

你的图表看起来不错。您的模型读者可以得出结论，两个参与者都有相同的UCs和CountryAdmin。特殊规则和限制（例如，客户管理员只能单独指定他自己的组织）。

关于流程，它们有几个应该修复的错误。我假设您在UC标题中有误（在描述中标题为＆＃34;设置组织树＆＃34;在图表上＃34; Creatr Organization＆＃34;）。即使情况并非如此，大多数错误都是一般的：

1. 您似乎在UC的范围内过多地扩展了UC场景。大多数步骤对应其他UC！你不应该有＃34;登录＆＃34;，＆＃34;注销＆＃34;和每个UC中的其他类似行为，这就是它们被单独定义的原因。所以，你应该只关注UC本身的原子动作。
2. UC的描述根本不适合这些场景！在您创建新用户的方案中，标题是＆＃34;设置组织＆＃34;。目前还不清楚。 UC标题应该清楚地标明它的目标，这应该通过一个成功的场景来实现。
3. 应该在什么条件下清楚地指出每个流程都会被调用。

我建议你解决这个问题并发布新版本的方案。然后我们可以进一步微调它们。

更新（第一次返工后）：

您的UC必须首先自我完善，因此场景编写将自然而然。你现在错过了一些UC，而其他的则太大了。

• 登录和注销必须作为单独的用例存在。登录具有后置条件＆＃34;用户已登录＆＃34;。您正确使用了相应的前提条件！
• 前提条件/后置条件适用于UC作为一个整体，而不适用于个别流程，如以下具体要点所述。
• 我将打破2个UC中的主要流程：前两个步骤对应于UC＆＃34;创建新组织＆＃34;，而步骤3-4可以给UC＆＃34;创建用户＆＃34; 。步骤5不是必需的
• 替代流程完全依赖于＆＃34;创建用户＆＃34;，您应该稍微改进前提条件。它们总是很常见，但您可以分为2个流程，具体取决于用户
• 我会改进先决条件/后置条件。你应该保持低计数，因为它们只是表明UC是否可以启动。所有其他规则应在具体方案中移动。例如＆＃34;每个用户都有一个密码＆＃34;有点明显/太详细，足以说用户是创建的。 ＆＃34;将要创建的用户不存在＆＃34; - 这没有意义，因为在那一刻无法评估。 :)

尝试看看UCs更具体和封闭。他们应该有一个简单的目标。替代流程应该显示实现目标的不同方式，不应该做出不同的事情。所有流都具有相同的前提条件，并且所有流都应具有相同的后置条件（当然，除了那些有错误的条件）。使用UC方案中的规则来定义替代流程（例如，主要方案是针对＆＃34;客户管理员＆＃34;并且alt。流程针对＆＃34;国家/地区管理员＆＃34;。

我建议你再次修改模型并将其发回。 ：）