如何对在事件表中执行相同操作的 >1 种方法进行建模？
假设有> 1种做某事的方法，在用例图中，我可以使用概括、包含，然后在事件表中？我要把他们分开吗？
假设客户可以在线或通过柜台“购买图书”。在这种情况下，我想来源是不同的？例如。 “在线买书”“客户”是与在线系统交互的源头。通过柜台，是“收银员”与POS交互？
我想我将它们分成事件表中的不同事件？
Suppose there are >1 ways of doing something, in use case diagrams, I could use generalize, include, then in event table? Do I separate them?
Suppose "Buy Book" a customer could do it online or through the counter. In this case, I suppose the source is different? eg. "Buy Book Online" the "Customer" is the source interacting with the online system. Through the counter, its the "Cashier" interacting with the POS?
I suppose I separate these into different events in an event table?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，泛化通常不用于用例；
<> 可能就是您所追求的，尽管它并不完全相同。其次，如果有多种方法可以做同一件事，那么这就是设计的问题，而不是分析的问题。分析涉及系统的用途，而不是实现这些目标的不同方式。
然而，最重要的是，在您提到的示例中，您实际上正在谈论两个不同的系统。用例代表一个或多个参与者与恰好一个系统之间的交互。
书店的 POS 系统可能包括一个用例“购买书籍”，涉及参与者收银员和顾客。在线书店的 Web 系统可能还包括用例“购买书籍”（仅涉及客户参与者），但它们只是碰巧具有相同的名称和相同的用途。
事实上，一个真实的人可以在商店和网上购买书籍，这一事实没有影响，因为分析的重点是系统，而不是参与者。
在事件表中，来源将是相同的（客户）并且事件将是相同的（客户想要购买书籍），但是会有两个不同的表，并且很可能有两个不同的文档，因为我们正在讨论两个不同的系统。
First off, generalization is not usually used for use cases;
<<extend>>is probably what you're after although it isn't quite the same.Secondly, if there are multiple ways of doing the same thing, then that's a question for the design, not the analysis. The analysis deals what what the system will be used for, not the different ways it can achieve those goals.
Most importantly, however, in the example you mention you are in fact talking about two different systems. A use case represents an interaction between one or more actors and exactly one system.
A POS system for a book store might include a use case "Buy Book", involving the actors Cashier and Customer. A web system for an on-line book store might also include a use case "Buy Book" (involving just the Customer actor), but they just happen to have the same name and the same purpose.
The fact that an actual, physical person can shop for books both in stores and on-line has no bearing, because the focus of the analysis is on the system, not the actors.
In event tables, the source would be the same (Customer) and the event would be the same (Customer wants to buy book), but there would be two different tables and quite possibly two different documents, because we are talking about two different systems.