如何在用例图中表示子模块
我需要知道如何表示模块的子模块。
例如，我有一个名为 X 的模块。该模块 X 实际上由名为 x1、x2 和 x3 的三个子模块组成。用户可以从可用选项中选择该子模块中的任何一个。这意味着如果没有这 3 个子模块，该模块就不会退出。我的疑问是，在绘制用例图时，我如何表示这个子模块？我必须对主模块中的该子模块使用“包含”或“扩展”吗？
另一个疑问是，当我绘制x1的用例图时。我如何表示一个名为“查看位置”的主要工作和一个名为“更改地图视图”的可选工作
请解释答案。
I need to know, how to represent the sub modules of a module.
For example i am having a module called X. This module X is actually made up of three sub modules called x1, x2 and x3. User can choose any of this sub module from the available options. That means this module does not exits with out this 3 sub modules. My doubt is that while drawing the use case diagram how can i represent this sub modules? I have to use "include" or "extend" for this sub modules from the main module?
Another doubt is that when i am drawing the use case diagram of x1. How can I represent a main work called "view location" and an optional work called "change map view"
Kindly explain the answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第一的
这个简单的定义有时会让很多人感到困惑：
在你的问题中，我认为你也谈论了“GUI”。据我了解你有一个 GUI 原型，
其中用户选择“X Module”选项，然后向用户显示“X1，X1，X3”子选项操作...
用例对您的 GUI 详细信息“不感兴趣”。它试图捕捉真正的“动机”……
为了说清楚：假设您正在为银行设计经典的 ATM 机。
用户想用 ATM 做什么？假设他想通过 ATM 支付账单...
简单用例图为此：
但是如何他会支付他/她的账单吗？这是通过用例描述捕获的[不是图表，用例文本]...
假设我们的客户说用户可以支付这些账单：他/她的手机账单，他/她的电费账单，可能是他/她的税费。您会发现每种支付都有不同的特征。
中编写用例描述
然后您开始在[系统执行此操作，参与者执行此操作]表单用例：支付账单
...................
主要场景：
系统显示那些 Pay Bill 操作
A) 支付手机话费
B）支付电费
C)...
用户选择一个选项
如果用户选择支付手机账单，则
5.a) 系统询问手机号码..
......
......
5.n) 系统询问用户是否需要收据
5.n+1) 用户想要收据
5.n+2) 系统给出收据
......
.....
如果用户选择支付电费则
……
...
....
....
因此，结果是：我们无法知道“更改地图视图”或“查看位置”是否是一个真实的用例[我们应该在图表中显示]或者只是一个步骤用例场景。这些取决于您的背景...
作为实用建议，您可以应用 Craig Larman 3 测试来确定这些是否是真实的用例：
最后，
First
This simple definion sometimes confuse many people:
In your problem, I think you also talk about "GUI". As I understand you have a GUI prototype,
In which User choose "X Module" option, then you show user "X1,X1,X3" suboptions actions...
Use Cases "does not interested in" your GUI details. It try to capture the real "motivation"...
To make it clear: Suppose that you are designing that classic ATM Machine for a Bank.
What a user wanted to make with an ATM? Suppose that he wanted to Pay his bills from ATM...
Simple Use Case Digram For this:
But how he will pay his/her bills? This is captured by use case descriptions[ not diagram, use case text]...
And suppose that our client say that User can pay those kind of bills: his/her CellPhone Bill, his/her Electricity Bill, may be His/her tax. And you capture that each of these payings have different characteristics.
And you start writing your use case description in [ System do this, Actor do this] form
Use Case : Pay Bill
...................
Main Scenario:
System show those Pay Bill Operations
A) Pay CellPhone Bill
B) Pay Electricity Bill
C)...
User Select an options
If User Select Pay Cell Phone Bill Then
5.a) System ask for CellPhone Number..
........
.......
5.n) System ask for if user want recipt
5.n+1) User want a receipt
5.n+2) System give a receipt
.....
.....
If User Select Pay Electricity Bill Then
.....
...
....
....
So as a result: We can not know if "change map view" or "view location" is a real use case [ which we should show in diagram] or just a step in a use case senario. Those are depends on your context...
As a practical advice you can apply Craig Larman 3 tests in order to find if those are real use cases:
Finally,