我正在为一个 android 应用程序创建一个用例 UML 图。
假设当用户摇晃手机时它会触发警报。当警报触发时,用户有一些选择,例如turn off the alarm
。警报也可以在用户指定的日期和时间触发。我如何将这样的内容添加到用例图中?我唯一想到的是添加所有其他用alarm
例<<extends>>
的用例,但这似乎不正确。
你能给我们一份初稿吗?因为对我来说,这种问题对于用例图来说太详细了。在这种图表中,您必须专注于应用程序的主要功能,并且您的用例不应超过 20 个。
问候,
BR
想想简单实用...
所以第一个问题:谁是主要演员?
Android 手机用户显然是主要参与者。[ 用户 ]
然后问:主要参与者可以用我的应用程序做什么?
忘记细节以及如何实施系统。只需简单地问上面的问题。
从给定的上下文看来,演员 [用户]
所以可能的用例:触发警报、设置警报、停止警报
然后,让我们编写触发警报用例场景的简单步骤,而不是仅仅绘制图表 :
用例名称:触发警报
主要参与者:Android手机用户
触发:演员摇晃手机,或警报触发时间已过
主要成功场景:
A. 用户摇晃手机
- 我们的 Android 应用程序 (OAA) 检测到用户抖动
- OAA 触发警报 X
- .... 4 ....
B. 已达到警报触发时间
- 我们的 Android 应用程序 (OAA) 检查当前时间并检测到时间已过的触发器。
- OAA 触发已达到的时间警报。3....
现在的问题,
Stoping-Alarm 是一个真实的用例吗?或者只是触发警报用例场景的一个步骤?
您可以在为您的上下文编写用例时发现它。对我来说,停止警报似乎只是触发警报场景中的一个步骤。因此,我可以通过删除 Stop-Alarm 来简化我的图表,并使其成为触发警报用例的一个步骤,例如扩展或替代流程,例如
替代流程 [ 用于触发警报 ]
用户可以停止任何触发的警报。
但可能稍后我可能会认为在我的图表上显示替代流程“停止警报”将更完整地了解我的应用程序的整体特性,所以我可以使用扩展关系来显示它:
你可能会问,当用户摇动手机时,很明显是他-她是主角,但是当“到达警报触发时间”时系统会自动触发它,而不是用户。因此可能存在人造时间参与者。但时间不能成为主要参与者,因为时间没有满足类似用户的目标。
但是当您仔细考虑时,用户是警报背后的人,甚至是自动警报,因为他/她设置了这些警报。因此,即使对于自动触发的警报,主要参与者也是实际用户。
也许我们认为我们应该在图表上更清楚地说明“时间”因素,假设对于“纯粹的 UML”家伙 :-)
可以将时间作为我们图表上的“次要演员”。但我认为这只会使您的图表变得丑陋并打开有关用例演员的“哲学”问题。:-)
检查 Rational Nice 论文:亲爱的博士用例:时钟是演员吗?
最后但并非最不重要的
不要在 UML 用例图上浪费太多时间。重要的是用例场景。