用例是否可以包含和前提相同的其他用例? [英] Can a use-case include and precondition the same other use-case?

查看:167
本文介绍了用例是否可以包含和前提相同的其他用例?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

让我们以登录并添加商品作为商品管理系统的两个用例为例。
客户的要求是:(他需要/想要:)

Let's take the example of logging in and add item as two use case of an items management system. the requirements of the client are : (he needs/wants to : )


  1. 获得对系统资源的合法访问权

  2. 添加项目 (创建一个)。

  1. Gain legitimate access to the resources of the system;
  2. Add Item (create one).

我们也知道,任何未经身份验证的用户都不应使用该系统!

we also know that no unauthenticated user should use the system !

我的问题是:

1)是否使用了 访问权限案件 ?其他用例的前提条件?或两者 ? (通过将用例命名为 访问权限而不是登录,我想突出显示需要而不是解决方案

1) Is "Gain Access" a use case ? A precondition to other use-cases ? Or Both ? (knowing that by naming the use-case "Gain Access" and not "Logging in" I wanted to highlight the need rather than the solution to that need.

2)如果 获得访问权限是一个用例,则执行 添加项目 用例包括 获得访问权限用例?

2) if "Gain Access" is a use-case, does the "Add Item" use-case includes the "Gain Access" use-case ?

用例依存关系:

顺序依存关系


  • 用例前提条件反映了用例之间的顺序依赖性。

  • A use case precondition reflects a sequential dependency between use cases.

具有前提条件C的用例B只能在之后开始用例B在用例A之后执行;他们的连接是异步的。

Use case B with precondition C can only start after use case A has produced C as a post-condition. Use case B is executed after use case A; their connection is asynchronous.

功能依赖


  • 相反,包含关系反映了用例之间的功能依赖性。

  • In contrast, an include relationship reflects a functional dependency between use cases.

使用时案例A与用例B具有包含关系,这意味着用例B的功能是用例A的全部功能的 部分。
用例B以执行>用例A的一部分;他们的连接是同步

When use case A has an include relationship to use case B, it means that the functionality of use case B is part of the overall functionality of use case A. Use case B is executed as part of use case A; their connection is synchronous.

https://www.batimes.com/articles/use-case-preconditions-a-best -kept-secret.html

推荐答案

一个用例必须生成业务价值。 登录(或获得访问权限等)本身就是在提供业务价值吗?系统的用户会登录,然后将其保留吗?可能不是。因此,登录本身不是用例。可以将其记录为用例中的一个步骤(如果您对解决方案了解得足够多,并且倾向于说),但请注意不要在用例中指定技术解决方案。您最好指定必须对用户进行身份验证,并将其用作前提条件等。

A Use Case has to generate business value. Is "login" (or gain access etc.) delivering business value in and of itself? Would the user of the system login and then leave it at that? Probably not. Therefore login is not a Use Case itself. It could be documented as a step in a Use Case (if you know enough about the solution and are feeling inclined to say) but be careful not to specify technology solutions in Use Cases. You'd be better to specify that the User must be identified to a certain level of authentication and apply that as a pre-requisite etc.

业务价值是关键。识别业务价值是分析艺术和科学的一部分。例如,如果您不使用用例来建模需求,则情况也是如此-例如形式为作为(角色)需要(行动)以使(业务价值)的用户故事再次关注业务价值。最终,业务价值是任何功能需求的重点,明确识别它应该是您的分析接近其目标的主要指标之一。

Business value is the key. Recognising business value is part of the art and science of analysis. For example, the same would be true if you were not using Use Cases to model requirements -- e.g. a User Story of the form "As a (role) in need to (action) so that (business value)" is again business-value focused. Ultimately, business value is the focus of any functional requirement and clear identification of that should be one of the main indicators that your analysis is closing in on its target.

思维-顺序和功能依赖性。注意不要将系统功能分解为不反映业务价值的单元。经常引用的ATM示例:检查余额是一个用例,输入PIN 不是(出于上述原因)。但是,您可能可行的是在执行提取现金时总是检查余额。如果是这种情况,那么您可以使用 include 来显示提取现金包括支票余额,但是请注意,这两个用例都可以提供业务价值本身。

That in mind -- sequential and functional dependencies. Be careful not to decompose functionality of the system into units that don't reflect business value. The oft-quoted example of an ATM: Check Balance is a Use Case, Enter PIN isn't (for the reasons above). However, you might feasibly want to always Check Balance when performing Withdraw Cash. If this was the case, then you could use an include to show that Withdraw Cash includes Check Balance, but note that both Use Cases provide business value in and of themselves.

这篇关于用例是否可以包含和前提相同的其他用例?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆