如何从用例创建类图？ [关闭]答案

【问题标题】：How do I create class diagrams from Use Cases? [closed]如何从用例创建类图？ [关闭]
【发布时间】：2021-03-14 09:46:50
【问题描述】：

我来自嵌入式系统领域，拥有 3 年以上的经验。在我目前的项目中，一开始我只负责软件开发，团队由 3 人组成。但是，随着时间的推移，硬件工程。和项目负责人。分别离职。到目前为止，该项目采用了零架构文档，以尽可能快地提供输出。后来，新的项目负责人接管了项目，并从应用V-model开始。我们开始在 EXCEL 上创建产品规格->HLR->DLR。但是现在，他也离开了工作:)。现在，我一个人带着将近 700 条写得很好的产品需求在路上。无论如何，我开始将需求收集和分类为非功能性、功能性、业务、利益相关者等。在收集非功能性时，我还将它们分类为可扩展性、性能、监管、设计约束等。到目前为止，我没有画出任何用处-案子。请在这里验证我，我知道用例的输入是功能需求。所以，我创建了一个用例卡，现在我计划为每个功能需求编写用例卡，然后为每个用例卡编写一个序列图。现在到这里，我走对了吗？用例中使用的符号（例如包含、扩展等）是否可以帮助我创建类图？这也是正确的方法吗？

【问题讨论】：

用例定义了要做什么，系统必须对外部刺激做什么，而类是实现的一部分，所以你的标题就像“如何从需求中实现”，而 用例中使用的符号（例如包含、扩展等）是否可以帮助我创建类图就像“知道要做什么来帮助我执行实现”......也许你知道答案并且知道这就是编程
1000个需求很多，你说写得很好，看来你对UML不熟悉，你确定翻译成用例会帮助你以后实现吗？您冒着迷失在大量用例中的风险，只是浪费时间而没有附加价值。
@bruno 首先，目前的数字接近 700，包括产品规范和衍生自产品规范的 HLR 以及衍生自 HLR 的 DLR。这是汽车级项目，我觉得 700 还可以。其次，是的，我第一次使用 UML，但我认为图表在进入实施阶段时必须相互推导。因此，在实现系统的类图时，应该有一些类图的输入。否则，一切都是在我的脑海中设计的。我不想这样。
@bruno 例如，在与 ex-Lead 合作时，我在脑海中设计了带有状态机的系统行为。没有书面要求，一切都在我们的脑海中。输入是我们的想法 :) 现在，我想设计一个具有适当输入的类和活动图，而不是头脑 :)。因此，通过一一分析从 700 个需求创建类似乎不合逻辑。用例对我来说似乎是一个更好的起点。但由于我的经验较少，没有人可以给我建议，我需要以某种方式验证我的方式。
但是您说您已经有书面要求，所以那时它们不仅在您的脑海中。用例只是对需求建模的一种方式，没有“魔法”，同样，每个需求都不能一个一个地分析（例如单独），用例也不能太。您将没有关联 1 用例 -> 1 类。编程是一项更复杂的任务

标签： uml system class-diagram use-case ooad

【解决方案1】：

可以从用例派生类吗？

当 Ivar Jacobson 发明用例时，他的目标是一种由用例驱动并允许有条不紊地从用例中派生实现的开发方法。那是他 80 年代末期的愿景。他的第一次尝试被称为 Objectory，它被一家更大的公司收购并导致了 Rational Unified Process，它被推广为较少专有到 Unified Software Development Process（Unified Process，简称 UP）。

特别是一种允许将用例转换为类的做法：Entity Control Boundary 方法：用例变为«control» 类，用例和参与者之间的链接变为«boundary» 类和 «entity» 类是为用例叙述中标识（或派生）的业务对象创建的。

一旦对这些第一个候选类进行建模，在设计过程中就会进行进一步的工作，并且类可能会被重新组织以最适合解决方案（例如，为了设计 GUI，几个边界类被重新组合，然后可能被分解为 UI 元素，等等……）。

但这对你来说是最好的方法吗？

UP 是迭代和增量的，并且非常适合 V-model 的现代版本，因为细化阶段的早期迭代旨在稳定架构和组件（或子系统）。

但是，这可能是一种非常耗时的方法，尤其是考虑到您拥有的大量用例。如果您查看建模用例通常会引发的所有问题，特别是如果您添加 «include» 和 «extend»，您可能会花费大量时间（超过 300 天？）来绘制强大的用例图.然后，使用 ECB，您的要求可能在您完成设计之前就已经过时了！

替代方案

另一方面，some non-academic authors 声称每个系统都有 3 到 5 个真正的主要用例：作为用户，我没有 700 个使用系统的目标。因此，您最好识别这些并查看它们之间的关系。很可能许多其他需求过于详细，很容易被指定为主要用例的附加信息。

以类似的想法，Ivar Jacobson 采用use-case 2.0 方法将他的方法调整到当前的软件工程现实。不要误会我，UML 还是一样，但是 ECB 不再出现（现代框架对边界设计的影响比用例模型大得多，并且实体使用更集中的方法建模，例如 DDD） .

用例 2.0 背后的理念是将主要用例分成几个较小的部分，然后开始开发对用户有意义的东西，然后可以进一步完善。

【讨论】：

实体、边界、控制技术似乎最好。