假设你必须为这个简单的问题做一个用例图(这是我正在做的更大的练习的一部分):
注册用户(网络应用程序)可以通过两种方式搜索旅游景点:按类别(例如:博物馆,公园,剧院,考古遗址)或按地点(城市,县)。
我该如何为这个UCD建模?
最简单的方法是:演员(注册用户),两个用例(按类别搜索旅游景点和按位置搜索),第二个演员(Web应用程序的服务器,它将处理查询并发送返回结果)。
我担心的是,通过这种方式,用例中不会出现四种类别和两种类型的位置。
我在考虑使用“扩展”关系。例如,我将添加一个名为“搜索公园”的用例,该用例扩展了用例“按类别搜索”。扩展点将是用户选择搜索公园的事件。
或者我可以使用“按类别搜索”和“搜索公园”之间的继承关系...... mmmm ......我有点困惑......
你如何使用USD?
模拟这个小问题谢谢你, 卢卡
答案 0 :(得分:2)
首先,您必须意识到,用例图不能替代实际(书面)用例。用例描述包含许多重要的细节,在用例图中省略了这些细节。用例图适用于描述参与者的层次结构,相关用例和用例之间的关系,但仅此而已。
另一个重要的事情是实现用例实际上是什么。思考这些问题的好方法是找到一个演员的目标,他/她希望在系统的帮助下实现这个目标。实现这一目标应该给演员一些商业价值。我的观点是,根据您的描述,注册用户可能想要搜索观光和/或购买门票。所以这是他的目标,这应该是一个用例,不要将用例与不同搜索方式等功能/特征混淆等。
在您的第一个建议中,您有两个用例,它们仅在数据方面有所不同(例如,它可能与表单中的组合框不同)。这些差异,如果它们不影响系统和参与者的交互方式,则与您在用例中引用的数据词汇表中的用例分开描述。这样可以避免在用例描述中出现许多不必要的细节。另一方面,如果描述中的步骤发生变化(例如,当注册用户选择位置系统时,他/她可以选择另一个注册用户作为朋友并预先选择两者的喜欢位置或类似的东西......) ,您可以通过使用替代/扩展来捕获它。
您提到您正在开发的系统作为次要角色。不要忘记,正在开发的系统是一个隐式actor,并没有将图表显示为单独的actor。使用边界框(包含不包括演员的用例的矩形)来描述系统的范围。
最后关注你。这些都只是有关数据的详细信息,不属于用例。您可以使用上面提到的数据词汇表在文本中捕获这些详细信息(通过namicng所有类别等)。如果您认为数据之间的结构和关系很重要并且需要使用图表来捕获,您可以使用类图来创建数据/域模型。
关于用例关系的最后注意事项 - 如果您不需要,请不要使用它们。它们通常难以理解和模糊定义。永远不要使用它们来分解功能,这取决于设计,而不是用例分析。
答案 1 :(得分:0)
我讨厌在用例中描述搜索。变量太多了。这就像尝试编写使用浏览器的用例一样。
搜索是早期原型设计的理想选择,并辅以业务规则。