在用例x＆＃x27中创建的实体何时何地，如何使用实体。另一个用例中的序列y＆＃x27;顺序？
我有一个用例X'序列，在其中创建一个实体Z。 我还有另一个用例y'序列，我想使用已经创建的实体z的相同的序列。
如何做？我必须以某种方式指定它吗？
例如，如果用例x'序列以窗口w边界结束，用例y序列y从窗口w边界开始，我可以假设（内部用例y序列图）用例X）在用例y中可用吗？
另一个问题，如果我想做一个裁判（包括一个），如何将实体z传递给ref'会用例？？
I have a use case X' sequence in which I create an Entity Z.
I have another use case Y' sequence where I want to use the SAME already created Entity Z.
How to do that? Do I have to specify it in some way?
For example, if use case X' sequence ends in a Window W Boundary and sequence of use case Y starts with Window W Boundary, can I just assume (inside use case Y sequence diagram) that Entity Z (that I didn't destroy in use case X) is available in use case Y?
Other question, if I want to do a ref (so an include), how to "pass" the Entity Z to the ref'd use case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我从您的问题中了解，您正在使用序列图来描述用例。没错。
当您在一个用例中创建某些东西后来在另一种用例中需要的东西时，这并不意味着两个用例之间存在正式连接。第二用例的前提仅仅是该对象存在。它不需要知道，它来自哪里。只需使用对象，就可以明确或隐式。
当您包括或延长用例时，情况有所不同。如果用序列图描述了此类用例，则必须将一种相互作用的寿命映射到另一个相互作用的寿命。这可以使用参数来完成。
当然，通常不需要这种形式。您可以简单地使用约定使用相同的名称。还应明智地使用«include''和«扩展。制作复杂的用例图不是目标，而是了解系统的用途。
I understand from your question that you are using sequence diagrams to describe use cases. Nothing wrong with that.
When you create something in one use case that is later needed in another use case, that doesn’t mean there is a formal connection between the two use cases. The precondition of the second use case is simply that this object exists. It doesn’t need to know, where it comes from. This precondition can be explicit or implicit by just using the object.
The situation is different, when you are including or extending use cases. If such use cases are described with sequence diagrams it becomes necessary to map the lifelines in one interaction to the ones in the other one. This can be done with parameters.
Of course, such formality is often not required. You can simply have the convention to use the same names. Also «include» and «extend» should be used wisely. It is not the goal to make a sophisticated use case diagram, but to understand the uses of the system.