基本细节
相关模式: |
系统间接口 |
预期频率: |
每个系统间接口有零到五个需求 |
模式分类: |
无 |
适用性 使用系统间交互需求模式定义穿越系统间接口的特定类型的交互。
讨论
一个通常的接口涉及很多不同类型的交互。一个信用卡支付服务可能主要用来让零售商借钱给持卡人,但是这个接口需要做很多其他的事,比如取消交易以及检查卡的信用额度。这些是业务相关的功能,但是接口可能也拥有大量的更偏向技术的和支持性的交互:发起一个连接(以及关闭);请求重发前一个消息;通知状态;等等。一个交互类型,为了这个需求模式的目的,意味着交换特定类型的信息——可能涉及双方向的消息。例如,一个请求和相应的响应算作一个交互。
是否需要需求处理特定类型的交互很大程度依赖于谁拥有这个接口。有四种不同的情况需要我们处理,这四种情况对于为什么想要定义某一个类型的交互有直接的影响,反过来又影响描述需求的程度:
情况1: 我们拥有接口。使接口完善是我们的责任,所以定义需求时要避免遗漏任何东西。必须绞尽脑汁思考接口需要的所有的次要的交互;某些能力可以以概括的词汇描述。
情况2: 我们不拥有接口,但是能影响接口的设计。在需求中确定和描述系统接口提供的特性。把接口的所有者当作这些需求的主要读者,所以尽量收集有力的证据使这些特性可以被实现。
记得这些需求不在我们的控制范围内,所以在接口的所有者接受之前,我们不知道接口是否能满足需求。
情况3: 我们不拥有接口,也不能影响接口的设计,但是知道它是什么样的。不要强迫所有需求规格的读者都查阅接口规格,了解接口的详情。在需求中总结每个交互是用的。需求可以抓住接口的本质——例如,可以更容易估算工作量。越早知道实现接口的难度越好。
或者,可以编写一个非正式的接口摘要而不是正式的需求。(尽管仍然需要把它们放在需求规格里。)这样使你有机会包含一些主观判断(比如接口文档的质量,接口的整体复杂度等等)。可以要求开发人员研究这个接口并编写摘要。
情况4: 我们不拥有接口,也不能影响接口的设计,也不知道它是什么样的。陷入这种情况是危险的,但是确实可能。我们有可能被迫承诺开发一个接口,而对接口不了解——接口的范围和棘手程度。把这个标记为需要关注的地方,尽快努力得到必要的信息。直到我们了解了接口的情况我们才能编写交互类型的需求。
内容 系统间交互需求模式需要包括下列内容:
1.交互类型名称 这样可以引用它。
2.接口名称和标识符 通过接口产生的交互必须是清楚的;需求的上下文(例如,遵循接口的主要需求)是不够的。当谈到一个接口时,指出接口标识符以防止误解。
3.交互目的 描述交互是为了什么。搞清楚是谁发起的。
4.传递的信息 这不需要是全面的。(确实,有时候完全没必要描述。)只关注重要的信息。如果交互涉及双方向的信息流,可以详细的描述每个包含的信息——但是如果需求过于庞大(可能是超过半页纸),可以分成独立的需求。
模板
摘要 |
定义 |
《交互摘要》 |
《接口名称》接口(《接口标识符》)将《交互目的描述》【至少传递以下信息:《传递的信息》】。 |
实例 下面是几个我们拥有接口的系统间交互类型需求实例:
摘要 |
定义 |
告警监视系统发出告警 |
告警监视接口(i6)允许系统发出一个告警(也就是说,传递告警信息,通知所有适当的人员)。一个发出告警的请求应该至少包括如下信息: n 消息标识符 n 消息正文 n 发生时间 n 告警被(人员或进程名称)发出 告警监视系统将回应确认(或者回应错误指示不能发出告警)。 |
数据仓库接口状态 |
系统与数据仓库之间的接口(i2)应该提供能力验证接口以及数据仓库系统本身的操作状态。 |
额外需求 无
开发考虑
参考本章的系统间接口需求模式。
测试考虑 参考系统间接口需求模式,可以获得测试接口的整体的概念。
系统间交互需求只是定义交互必须完成什么,它的目标。实现它反而可能会更复杂。例如,需求可能暗示一个请求有一个响应,但是在实际中,可能会有两个请求两个响应。因此,测试交互需求必须要只关注是否完成了定义的目标,而不是实现的细节。应该做一些额外的测试验证物理交互是否工作正常。数据流图会对设计物理交互测试有帮助,但是对测试逻辑交互帮助不大。
简洁的描述有效的情况和无效(错误)的情况。第一种情况下,识别那些有效但是意外的情况。有些交互不是每天发生,但是可能在任何时候出现,是否接口可以正确的处理这些有效的交互?绝对不可能测试所有的可能性,但是要尽量覆盖有代表性的情况及其扩展情况。
责任编辑:小草