Uml 用例中的前提条件

我正在为学校的一个项目创建一个用例，我对前提条件字段感到困惑。我可以理解诸如“必须登录”或“需要帐户”之类的先决条件

但是，如果该软件是本地设置，该怎么办？对我来说，先决条件是“软件需要安装”，这听起来是合乎逻辑的。但另一方面，这个先决条件看起来很奇怪，因为否则，您首先就不会有这个用例

---

因此，简而言之，我的问题是：系统需求或软件安装是否可以作为前提条件的一部分？

对我来说，系统需求和/或软件安装可以作为前提条件的一部分，但它必须始终与您的用例上下文相关。

---

例如，如果安装或未安装硬件或第三个工具，您的系统将有不同的行为。

解决UML问题核心的一个非常好的问题-它的语义很弱。因此，你的问题的答案是——可能是对的，也可能是错的。UML设置了符号规则，并且只定义了基本的元素语义（例如，“必须满足一个先决条件才能……”）

我们甚至可以在“操作系统应该正确配置”或更糟的“计算机有电”等前提条件上更进一步。。。这些讨论很容易变成哲学性的。：）

根据我的经验，有一种使用例高效的方法——构建另一个UML模型，一个补充模型，它将用于制定前提条件、后条件，甚至用例场景（您针对前提条件提出的同样问题也可以针对场景提出——哪一个是场景的正确抽象？或者“打开计算机？”场景中的有效步骤？）

为了实现这一点，我通常使用概念类图——我对我的领域建模，然后根据这些元素（类及其属性）表达前置/后置条件和场景并且只使用这些元素。这很有意义，特别是知道前置/后置条件查询系统的状态，它们由对象/值巧妙地反映出来

回到您的示例，如果您想知道“软件需要安装”的前提条件，您只需问自己“我真的需要一个属性为“isInstalled”的类“software”吗？”

然后您很可能会意识到，您可能不需要这个前提条件，因为它太“低级”，超出了我的域的范围。。现在您只需要定义您的域。：）下面是一个类似情况的简单示例，演示了这个想法（请记住，用例和类模型绘制在单独的图表上）：

这种方法不仅使指定用例变得更容易，而且还使补充类模型成为可能，从而允许领域规范、业务规则识别和系统设计的第一个抽象

---

祝你好运，玩得开心！

让我们记住，用例对于你的软件/系统需要实现什么是真正的高层次要求。这样，前提条件应该只与你正在构建的软件（或系统）相关，而不与外部元素相关（例如，“计算机已连接并打开“这不是一个好的先决条件）。例如，当您开始以序列图或活动图的形式实现用例时，前提条件为您提供了一些可能需要在软件中进行检查的线索，可能需要调用其他操作/模块/类。此实现练习将帮助您确定前提条件将采用的形式，即使它是仍然需要，具体取决于应用程序的结构

以您为例，如果您希望用户登录或未登录时有不同的行为，或者操作需要不同的权限，则可能需要“必须登录”前提条件

---

因此，一些系统需求可能是先决条件（例如，与设备的连接），而一些软件安装可能是先决条件（例如，所需的配套产品集成），但前提是它们对用例本身有直接影响。为您的应用程序安装软件不应该是一个先决条件：应用程序无法检查它是否未安装，因为它无法运行，并且它确实执行，然后它显然已安装…

Thanx太多了！这解决了我的问题！学校项目正在编写用例，但不是为了已经创建的软件。有点颠倒了…但这是我们必须理解的概念。我选择了梨状体的Ccleaner程序。我已经编写了一个用例…用户采取行动清洁硬盘。Thanx的图片和解释！fosa