UML用例图后条件实现(带图)

UML用例图后条件实现(带图),uml,use-case,Uml,Use Case,我正在学习UML,尝试用图表和文档来模拟汽车维修车库的工作方式。我的一个问题是后置条件(或者更确切地说,GOTO)语句 虚线>关系是否仅适用于前提条件?用例气泡可以相互连接并遵循逻辑路径吗 这就是我到目前为止得到的。。 1) “结算支付”泡沫出现在错误的地方吗?它是否应该与其他泡沫相关联? 2) 我是否也应该将“请求服务”气泡与技师联系起来,因为他将是修理汽车的人 形象 用例就像类一样。它们具有继承(扩展)和包含和使用等关系 先决条件是常见的关系约束。我们中的一些人在用例文本中编写前提条件和后条

我正在学习UML,尝试用图表和文档来模拟汽车维修车库的工作方式。我的一个问题是后置条件(或者更确切地说,GOTO)语句

虚线>关系是否仅适用于前提条件?用例气泡可以相互连接并遵循逻辑路径吗

这就是我到目前为止得到的。。 1) “结算支付”泡沫出现在错误的地方吗?它是否应该与其他泡沫相关联? 2) 我是否也应该将“请求服务”气泡与技师联系起来,因为他将是修理汽车的人

形象


用例就像类一样。它们具有继承(扩展)和包含和使用等关系

先决条件是常见的关系约束。我们中的一些人在用例文本中编写前提条件和后条件。您可以绘制它,但它不是必需的

不要尝试对用例气泡进行排序。这就是活动图和序列图的用途。这就是叙事文本的目的。这是用户已经知道的

另外,不要浪费太多时间将用例视为超高级编程语言。记住,演员们已经知道他们在做什么;他们不需要帮助排序

您需要重点捕获参与者、用例以及用例中的基本“扩展”、“使用”、“包括”。用例模型不是编程。用例图是“谁”和“什么”的知识捕获

可以将其视为定义参与者可以做什么的安全模型。顺序、顺序和其他细节不像演员做什么那么重要

当您将Actor与Actor(如技术人员和前台)关联时,您的意思是Actor在系统之外进行交互。你是说技术人员从来不会登录系统来完成他们的工作或记录他们的时间

如果技术人员实际上将登录以获取工作并记录时间,那么技术人员将参与一些用例

用例不是编程。他们是演员做的事情。用例通过构建在一个大的、通用的软件中而连接起来。您不需要在用例之间绘制数据流或逻辑箭头。它们在很大程度上都是独立的


在设计系统时,您将实现UI功能和数据库功能,这些功能以某种顺序连接用例。

感谢您的帮助,我知道现在需要做得更好。