计算器的用例建模
我需要帮助从一个主题建模用例图,它将在 java GUI 中
设计一个计算器,
1.允许用户键入涉及数字、运算符 +、- 和括号“(”和“)”的合法算术语句;
2.当用户按下“计算”按钮时,显示结果;
3.一些合法的语句是((3+2)-4+2)(等于3)和(-2+3)-(3-1)(等于-1);
4.您不应该使用仅将语句作为参数并返回结果的预先存在的函数,但您应该编写解析代码中每个字符的逻辑。
5.存储最后的陈述和答案,以便当用户按下“最后计算”按钮时显示。
我在 Netbeans 6.5.1 上使用 UML 设计了两个用例图,其中一个用例我不确定它是否包含太多用例等,而另一个用例我认为对于该主题来说可能过于模糊。希望得到一些关于用例图是否合适的反馈,谢谢。我在 GUI 中包含了它的样子
i need help modelling a use case diagram from a topic, it will be in java GUI
Design a Calculator that
1.Allow user to key in a legitimate arithmetic statement that involves number, operator +, - and bracket '(' and ')' ;
2.When user press “Calculate” button, display result;
3.Some legitimate statement would be ((3+2)-4+2) (equals 3) and (-2+3)-(3-1) (equals -1);
4.You should NOT use a pre-existing function that just take in the statement as a parameter and returns the result but you should write the logic of parsing every character in your code.
5.Store the last statement and answer so it is displayed when user press the “Last calculation” button.
i have designed two use case diagrams using UML on netbeans 6.5.1, one of the use case i am not sure whether is it containing too much use cases etc, while the other is what i think could be too vague for the topic.i hope to get some feedback on whether the use case diagram are appropriate, thanks.i included a what it would be like in GUI
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
关于用例图,您必须了解的第一件事是它应该描述哪个参与者的系统的功能。它应该达到如此高的水平,任何没有编程知识的人都可以理解它。作为一名程序员,用例对您来说可能看起来非常模糊,但这没关系。它不应该说明该系统的任何内容,而只是说明它可以做什么。
一些更具体的评论:
正如我提到的,用例应该描述高级功能。
PressCalculate
不是函数,Calculate
才是。Press Last Calculation
应该是Store Last Calculation
等尚不清楚
Press Backspace
的作用。退格键只是一个键,而不是用例。ParserSys
包尝试描述系统的内部结构。这不属于用例图。为此应使用其他图表。用例
存储结果
(第一张图片)不应在此图中。但如果这是用户可以做的事情,它应该与用户相关联。编辑:
识别用例的一个好方法就像问自己这个问题一样简单:“[Actor]应该能够[什么]”(或类似的东西) 。 [什么]就是你的用例。如果它不适合这句话,那么它可能不是一个用例。
First thing you must know about use case diagrams is that its supposed to describe functionality of a system for which actor. It should be on such a high level that anyone without knowledge of programming can understand it. As a programmer, use cases might look very vague to you but thats fine. Its not supposed to say anything about the system, just what it can do.
Some more specific comments:
As i mentioned use cases should describe high level functions.
Press Calculate
is not a function,Calculate
is.Press Last Calculation
should beStore Last Calculation
, etcIts not clear what
Press Backspace
does. Backspace is just a key, not a use case.The
ParserSys
package tries to describe internals of a system. This does not belong in a use case diagram. Other diagrams should be used for this.Use case
Store Result
(first pic) should not be in this diagram. But if thats something User can do, it should be associated with User.Edit:
A good way of identifying use cases is as simple as asking yourself the question: "[Actor] should be able to [what]" (or something similar). [What] is then your use case. If it doesn't fit in this sentence, its probably not a use case.
在第二个用例图中,用户的用例基于为实现第一个用例而执行的操作序列。这些可以更好地表示为活动图或状态机 - 用户关心获取计算结果,并且偶然需要键入需要按下的按钮来获取这些结果表达式。创建用例时,重点关注用例发起者的目标,而不是系统如何帮助他们实现这些目标。
另一方面,您给出的规范没有提及使用 Java GUI 模拟键盘或模型中的退格键。与利益相关者核实“允许用户键入”是否只是意味着给他们提供打字的地方,或者提供屏幕键盘。
In the second use case diagram, you have user having use cases based on the sequence of actions performed to implement the use cases in the first. These would be better represented as either an activity diagram or state machine - the user cares about getting the results of a calculation, and it is incidental that to get these results expressions need to be keyed in buttons need to be pressed. When creating use cases concentrate on the goals that the originator of the use case has, rather than how the system might help them achieve these goals .
On another point, the spec you give says nothing about simulating a keyboard using a Java GUI, or a backspace key as in your mock-up. Check with the stakeholders whether 'allow the user to key in' just means giving them somewhere to type, or providing an on-screen keypad.