如何在Uml用例图中显示工具栏

问题描述

我是面向对象设计的新手，我想在一个简单的应用程序（包含左上角的工具栏）上做我的第一个UML用例图。该工具栏称为文件，当用户单击时，将打开一个下拉菜单，其中包含用于打开幻灯片，保存幻灯片，制作新幻灯片并退出应用程序的选项。
我的问题是，我使用用例继承（通用化）正确吗？
这是我的图。

解决方法

很抱歉让您失望，但是我必须告诉您，这种做法完全是错误的：

• 从语义学的角度来看，use-case specialization表示Open presentation 是{{1 }}和Check file，并且演员可以互换和独立使用它们。但这不是您的意思：退出演示文稿最多只是检查文件的子部分

• 从目的的角度来看，用例应代表用户目标。这是问题空间的一部分，即用户想要实现的目标。它不是解决方案空间的一部分，即用户将如何实现它。工具栏不是目标：它是用户界面元素。

• 从工程实践的角度来看，用例不应用于用户界面设计。这不是我自己的声明，而是UML的创建者Jacobson，Booch和Rumbaugh的声明：

  问题在于[用例]描述通常包含有关用户界面的隐式决策。稍后，当用户界面设计人员为用例建议合适的用户界面时，它们可能会受到这些决定的限制。
  在统一软件开发过程，第164

  页

因此，总而言之，从用户界面启动用例是一个坏主意。它使您陷入自己的设计中，而忽略了用户体验。您应该只关注用户需求。无论您要使用GUI界面，聊天机器人界面还是基于语音的界面来实现，都可以使用相同的用例。

,

在绘制用例图时，您应注意的一件事是它的实际含义和绘制目的。

用例指的是用户就其类型而言可以在您的系统中执行的操作...边界内的所有内容都是系统可以执行的操作或可以为用户提供的服务。

在命名用例时，仅应使用动词和动作，例如：

1-登录| 2-提交请求| 3-更新配置文件说明

您应避免在其中使用任何名词。

在用例图中，用例之间存在几种关系，并且系统的参与者和用例之间存在关系，并且它们之间的关系如下：

关联：参与者与用例之间可能存在的唯一关系；其中说参与者是该用例的发起者，或者是操纵该用例的领头羊。

在上面的示例中，用户已登录并提交投诉。

包含：用例可以包含一个或多个用例。如果一个用例包含另一个用例，则意味着包含的一个或多个用例一直在发生，并且是初始用例的一部分。

已包括支付费用，因为用户必须在注册过程中支付费用，因此必须完成，并且这是方案基线路径的一部分。

扩展：当用例并非一直都发生，并且是替代路径（此用例的完整方案的替代路径）的一部分时，应将用例扩展到基本用例。

“忘记密码”已扩展到“登录”用例，因为它并非一直都发生，并且是“登录”方案的另一种路径。

通用化：当存在执行和完成用例的几种不同方式时，我们使用通用化。继承的用例应与继承的用例具有相同的类型。

可以通过几种不同的方式提交投诉，在这种情况下，我们需要将每个用例分开，并从提交的包含费用的投诉用例中继承，这表明，支付费用是提交的每种类型投诉的一部分。