UML：构建 SRS Class 图：太复杂？
UML: Building an SRS Class Diagram: Too complicated?
我正在我的学校参加 UML class，我的老师希望我们完成基本的、最低限度的作业，并且不会回答任何问题。也就是说，系统的要求有注册、学生记录、登录、课程记录和 Class 记录的用例。它真正需要做的是：
- 学生将登录系统，他们唯一能做的就是
登记。在注册页面，它会列出可用的课程，一个
学生会 select 一个或多个然后他们会列出 classes
可用于每门课程。必须检查学生的记录
以验证它们是否满足先决条件。
- 注册员可以登录系统，他们不仅可以注册学生，还可以查看和修改课程记录、class记录和学生记录。
- 此外，classes 可以是在线的也可以是现场的，我想知道是否应该定义它...
- 如果需要理解，我可以提供更多细节。
好吧，我想我想得太过火了，我想我想就如何确定基本要求发表意见。
我还有几个问题：
- SRS 是否需要登录对象？还是应该简单地假设用户已经登录？
- 关于基数和多重性，是同一个概念吗？
- 看看我所做的多重性，我是否犯了任何明显的错误？
就使其不那么复杂而言，仅具有：class-类型、课程、class、注册、学生和注册商有意义吗？
系统需求规范远比简单的图表复杂。完成 SRS 的方法有很多，因此您的问题可能会被标记为 off-topic 过于宽泛。无论如何，这就是我所做的。
第一步，您需要自己对需求进行分组。第一个大的划分是将功能需求和 non-functional 需求分开。 Non-functional 是那些不能固定到单个函数的要求。例如。性能、法律、安全、保障，应有尽有。这些是您首先构建的类别，最终您在 SRS 创建过程中拥有了一组类别。
对功能需求进行分组有点棘手。您可以通过综合用例来做到这一点。每个功能需求都需要通过单个用例来实现。您不需要为用例提供详细信息，而只需提供一个粗略的故事。但是一旦您将所有功能需求连接到用例，您的 SRS 就准备好了。
请注意，non-functional 要求尚未相关。这是因为它们对后期的很多功能和系统设计都有影响。只需要结构清晰即可。
另一件需要注意的事情是，需求本身应该可以追溯到它们的来源。这意味着您需要参考论文、会议、phone 电话、个人谈话等来源。
有很多细节使 SRS 的创建和维护成为一门科学，但以上是您的出发点。
class 图不一定是 SRS 的一部分。它是后来设计规范的一部分。
现在回答您的其他问题。
- Log-in 在任何情况下都不是生意 object。它是从需求 "user must be logged in to..."
派生的约束
- 见cardinality vs multiplicity
- 我会简单地放弃 .. 符号。如果离开它意味着相同（未指定）。我将从凭证管理器中删除 'Log-in' 词，因为它还将处理 log-out 等等。所以重点不对。否则，如前所述，class 设计实际上并不是 SRS 的一部分。
我正在我的学校参加 UML class，我的老师希望我们完成基本的、最低限度的作业，并且不会回答任何问题。也就是说，系统的要求有注册、学生记录、登录、课程记录和 Class 记录的用例。它真正需要做的是：
- 学生将登录系统，他们唯一能做的就是 登记。在注册页面，它会列出可用的课程，一个 学生会 select 一个或多个然后他们会列出 classes 可用于每门课程。必须检查学生的记录 以验证它们是否满足先决条件。
- 注册员可以登录系统，他们不仅可以注册学生，还可以查看和修改课程记录、class记录和学生记录。
- 此外，classes 可以是在线的也可以是现场的，我想知道是否应该定义它...
- 如果需要理解，我可以提供更多细节。
好吧，我想我想得太过火了，我想我想就如何确定基本要求发表意见。
我还有几个问题：
- SRS 是否需要登录对象？还是应该简单地假设用户已经登录？
- 关于基数和多重性，是同一个概念吗？
- 看看我所做的多重性，我是否犯了任何明显的错误？
就使其不那么复杂而言，仅具有：class-类型、课程、class、注册、学生和注册商有意义吗？
系统需求规范远比简单的图表复杂。完成 SRS 的方法有很多，因此您的问题可能会被标记为 off-topic 过于宽泛。无论如何，这就是我所做的。
第一步，您需要自己对需求进行分组。第一个大的划分是将功能需求和 non-functional 需求分开。 Non-functional 是那些不能固定到单个函数的要求。例如。性能、法律、安全、保障，应有尽有。这些是您首先构建的类别，最终您在 SRS 创建过程中拥有了一组类别。
对功能需求进行分组有点棘手。您可以通过综合用例来做到这一点。每个功能需求都需要通过单个用例来实现。您不需要为用例提供详细信息，而只需提供一个粗略的故事。但是一旦您将所有功能需求连接到用例，您的 SRS 就准备好了。
请注意，non-functional 要求尚未相关。这是因为它们对后期的很多功能和系统设计都有影响。只需要结构清晰即可。
另一件需要注意的事情是，需求本身应该可以追溯到它们的来源。这意味着您需要参考论文、会议、phone 电话、个人谈话等来源。
有很多细节使 SRS 的创建和维护成为一门科学，但以上是您的出发点。
class 图不一定是 SRS 的一部分。它是后来设计规范的一部分。
现在回答您的其他问题。
- Log-in 在任何情况下都不是生意 object。它是从需求 "user must be logged in to..." 派生的约束
- 见cardinality vs multiplicity
- 我会简单地放弃 .. 符号。如果离开它意味着相同（未指定）。我将从凭证管理器中删除 'Log-in' 词，因为它还将处理 log-out 等等。所以重点不对。否则，如前所述，class 设计实际上并不是 SRS 的一部分。