我需要知道,如何表示模块的子模块。
例如我有一个名为X的模块。这个模块X实际上由三个子模块组成,称为x1,x2和x3。用户可以从可用选项中选择任何此子模块。这意味着该模块不会退出这3个子模块。我怀疑的是,在绘制用例图时,我如何表示这个子模块?我必须从主模块的子模块中使用“include”或“extend”吗?
另一个疑问是,当我绘制x1的用例图时。我如何表示一个名为“视图位置”的主要作品和一个名为“更改地图视图”的可选作品
请解释答案。
答案 0 :(得分:3)
第一
用例仅描述“用户可以对您的系统执行的操作”。
这种简单的定义有时让很多人感到困惑:
当我们询问用户可以对您的系统做什么时,他们会告诉您 早期原型GUI上的选项菜单。
在你的问题中,我认为你也谈到了“GUI”。据我所知,你有一个GUI原型, 在哪个用户选择“X模块”选项,然后显示用户“X1,X1,X3”子选项操作......
用例“对您的GUI详细信息不感兴趣。它试图捕捉真正的“动机”......
说清楚:假设您正在为银行设计经典的ATM机。
用户想用ATM制作什么?假设他想从ATM支付账单......
简单用例Digram为此:
但他将如何支付他/她的账单?这是由用例描述[不是图表,用例文本]捕获的...... 并且假设我们的客户说用户可以支付这样的账单:他/她的手机账单,他/她的电费账单,可能是他/她的税。而且你捕捉到这些付款中的每一个都有不同的特征。
您开始在[系统执行此操作,演员执行此操作]表单
中编写您的用例说明使用案例:支付账单 ...................
主要情景:
系统显示付款单操作
A)支付手机账单
B)支付电费账单
C)...
用户选择选项
如果用户选择付费手机账单
5.a)系统要求输入CellPhone ..
........ .......
5.n)系统询问用户是否想要收件人
5.n + 1)用户想要收据
5.n + 2)系统给出收据 .....
.....
如果用户选择付费电话然后 ..... ...
作为一般规则,不要使用大量的脏用例图 “延伸”或“包括”,“概括”
结果是:我们无法知道“更改地图视图”或“视图位置”是否是一个真实的用例[我们应该在图表中显示]或者只是用例senario中的一个步骤。这取决于你的背景......
作为实用建议,您可以应用Craig Larman 3测试以查找这些是否是真实用例:
最后,
用例主要是文本:[Scenarious] Not Diagrams。图只是 概述功能要求。但只是概述不是 细节