Uml 我的用例图和场景正确吗？

大家好，我正在学习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 ---

我不确定这是否正确。可以在基本流程中创建组织，因此它描述了国家/地区管理员可以做什么。在备用流程中，只能创建用户，因此它描述了国家/地区管理员和客户管理员可以做什么。但是，客户管理员只能看到自己的组织这一事实在这里是不可见的。另外，我不确定我是否可以在单个用例交替流中描述它，或者我是否应该创建两个单独的用例。一个用于国家/地区管理员，一个用于客户管理员。如果我为国家管理员创建了单独的用例图，我想我不应该在那里提到客户管理员，那么我也不应该画客户管理员角色和角色概括？ 非常感谢

沃伊特

编辑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 ---

现在在我的场景中有两个备选FLW：

- 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

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

关于流，它们有几个错误需要修复。我假设您在UC标题中弄错了（在描述中，标题是“设置组织树”，在图表上是“创建者组织”）。即使不是这样，大多数错误都是一般性的：

似乎您将UC场景扩展得太多，超出了UC的限制。大多数步骤对应于其他UCs！您不应该在每个UC中都有“登录”、“注销”和其他类似的操作，这就是为什么它们被单独定义的原因。所以，你应该只关注UC本身的原子行为

UC的描述完全不符合场景！在该场景中，您将创建新用户，标题为“设置组织”。这还不清楚。坎特伯雷大学的标题应该清楚地标明它的目标，这应该通过一个成功的场景来实现

应该明确指出在什么条件下调用每个流 我建议您解决这个问题，并发布新版本的场景。然后我们可以进一步调整它们

更新（第一次返工后）：

您的UCs必须首先进行自我完善，这样场景编写将变得自然。你现在错过了一些UCs，其他的太大了

• 登录和注销必须作为单独的用例存在。登录具有后条件“用户已登录”。您正确地使用了相应的前提条件
• 先决条件/后决条件适用于整个UC，而不适用于单个流，如以下具体要点所述
• 我将主要流程分为两个UC：前两个步骤对应一个UC“创建新组织”，而步骤3-4可以给出一个UC“创建用户”。步骤5不是必需的
• 备选流程完全映射到“createuser”上，您只需稍微细化前提条件。它们总是很常见，但根据用户的不同，您可以将它们分成两个流
• 我将完善先决条件/后决条件。您应该保持低计数，因为它们仅指示UC是否可以启动。所有其他规则都应该在具体场景中移动。例如，“每个用户都有一个密码”有点明显/太详细，可以说用户是创建的。“将要创建的用户不存在”-这没有意义，因为此时无法进行评估。：）

尝试将UCs看得更具体、更封闭。他们应该有一个简单的目标。替代流程应显示实现目标的不同方式，而不应做出不同的事情。所有流都具有相同的前置条件，并且所有流都应该具有相同的后置条件（当然，有错误的流除外）。使用UC场景中的规则来定义备选流程（例如，主场景用于“客户管理”，备选流程用于“国家/地区管理”）

---

我建议您再次修改模型并将其发回。

非常感谢您的反馈。我根据你的建议更新了我的图表和场景。你能告诉我现在应该改进什么吗？我仍然不确定如何正确地描述场景中的演员概括。非常感谢。好多了，但是仍然需要一些“结构性”的改进。请查看答案中的更新。这可能有助于登录/注销：