问题描述
您好，Stackoverflow成员们，祝大家愉快。我正在为我的素描（绘画）桌面程序创建此用例图，这是我为大学设计的项目。
这是我的项目的场景：
正确访问他的帐户后，该程序将打开。
他可以做很多事情，例如：使用钢笔工具写一些东西，突出显示一些东西，创建一个形状（圆形或直线，正方形）并更改其坐标（在画布上的位置）。以及用户可以添加图像或注释。
用户可以按后退按钮（“撤消”按钮）删除添加到板上的最新内容。当然，如果板子是干净的，则后退按钮将被隐藏。
通过按回收站，用户可以删除板上的所有项目。但是在系统显示对话框消息之前，不会删除任何内容，
如果您按“确定”，则将删除板上绘制的所有内容。 如果按“取消”，则不会删除任何内容。
如果用户按下“另存为”，则他可以选择项目文件路径，其中该路径将在其中存储投影图像。 如果用户按“保存”而不是“另存为”，则有两种可能性：
首先：他没有在--->之前选择项目路径，所以在这种情况下，程序将允许他首先标识文件路径，然后，图像将存储在该路径中。 其次：他已经选择了该文件并将其保存在该路径--->中，因此在这种情况下，将保存对投影图像的最后编辑。
首先：他选择了文件路径并将图像保存在那里，从那一刻开始，他还没有在板上画任何东西。 --->在这种情况下，程序将关闭。 其次：在保存过程之后，他添加或绘制了新内容--->在这种情况下，系统将显示警报保存对话框，告诉他以下内容： -如果按“是”，则将存储最近的更改，并退出程序。
- 如果按“否”，则将不存储最后的更改，并且程序将退出。
- 如果按“取消”，则将返回程序。
第三：他已经绘制或添加了一些东西，但是在--->之前没有保存图像，在这种情况下，系统将显示“保存”对话框，直到他看到以下内容：
第四：打开程序时，他没有绘制或添加任何内容--->在这种情况下，程序将直接关闭。
该用例可在以下pdf链接中找到： 请放大（图很大） https://docdro.id/qWWC0GZ
解决方法
您的UML用例图看起来令人印象深刻。但是，从语法角度来看，这看起来没什么问题，但这并不是用例的目的：
- 用例应描述用户的需求
- 每个用例应对应一个用户目标
- 用例不应表现出功能分解，即将用户需求分解为描述如何解决需求的详细步骤。
- 用例不应描述用户界面 从UML的角度来看，
-
loginuse-cases很好，但是它们通常是功能分解或用户界面描述的症状。因此，只要您有一个用例图，并在登录用例周围有一个蜘蛛网，就应该问您自己。
由于所有这些原因，您的用例图显得过于详细，并且使用了错误的分解。同样，这没错，但这不是推荐的使用方式。
最后，用例图的目的是什么？与利益相关者和同伴交流。这样的超详细图表非常难以阅读，并且不会帮助您实现这些图表的主要目标：与利益相关者和同行讨论需求。