Uml 如何从用例创建类图？

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

可以从用例派生类吗？ 当IvarJacobson发明用例时，他瞄准的是一种由用例驱动的开发方法，并允许有条不紊地从用例中派生实现。这就是他在80年代末的愿景。他的第一次尝试被称为Objectory，它被一家更大的公司收购，并导致Rational统一流程，该流程被普遍化为对（统一流程，简称UP）不太专有

特别有一种实践允许将用例转换为类：方法：用例变成

«控制»

类，用例和参与者之间的链接变成

«边界»

类，并且为中标识的业务对象创建

«实体»

类（或源自）用例叙述

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

但在你的情况下，这是最好的方法吗？ UP是迭代和增量的，非常适合的现代版本，因为精化阶段的早期迭代旨在稳定架构和组件（或子系统）

然而，这可能是一种非常耗时的方法，尤其是考虑到您拥有的大量用例。如果您查看建模用例通常会提出的所有问题，尤其是如果您添加

«include»

和

«extend»

，您可能会花费大量时间（超过300天？）绘制健壮的用例图。然后，使用ECB，在您完成设计之前，您的需求可能已经过时了

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

在一个类似的想法中，IvarJacobson已经将他的方法适应了当前的软件工程现实，使用这种方法（与用例模型相比，现代框架对边界设计的影响要大得多，实体是使用更加集中的方法建模的，如DDD）

---

用例2.0背后的想法是将主要用例分成几个较小的部分，并开始开发对用户有意义的东西，然后再进一步细化。

用例定义了要做什么，系统在外部刺激下必须做什么，而类是实现的一部分，因此您的标题如下“如何从需求中实现”，用例中使用的符号（如include、extend等）是否帮助我创建类图就像“知道要做什么帮助我实现”一样"…也许你知道答案，知道这叫做编程1000个需求很多，你说它们写得很好，似乎你不熟悉UML，你确定在用例中翻译它们会帮助你以后实现吗？你冒着在大量用例中迷失的风险，只是失去了没有附加值的时间。@bruno首先，目前的数字接近700，包括产品规格和从产品规格派生的HLR，以及从HLR派生的DLR。这是一个汽车级项目，700对我来说似乎还可以。其次，是的，我第一次使用UML，但我认为图表在进入实施阶段时必须相互派生。因此，应该有一些在实现系统的类图时，为类图设计NPUT。否则，一切都是在我的脑海中设计的。我不想这样做。@例如，bruno，在与ex-Lead合作时，我用状态机设计了系统行为。没有文档化的需求，一切都在我们的脑海中。输入是我们的脑海：）现在，我想用正确的输入设计一个类和活动图，而不是头脑：）。所以，通过逐个分析从700个需求创建类似乎不符合逻辑。对我来说，用例似乎是一个更好的起点。但是由于我的经验较少，而且没有人能给我提供建议，我需要以某种方式验证我的方法。但是你说你已经有了书面要求，所以时间不仅仅是在你的脑海中。使用cas