任务:记录服务的非功能需求
此任务根据包含的设计元素和外部子系统/接口的协作来定义和指定面向服务的解决方案的服务和结构。
用途
  • 根据包含的设计元素和外部子系统/接口的协作,定义面向服务的解决方案的服务和结构。
  • 要分析服务的共同点和可变性(请参阅指南:可变性分析)。
  • 记录服务规范。
  • 确定服务间的依赖关系和通信。
关系
主要描述
本任务优化了在活动:确定服务过程中确定并取得资格的一组工件:服务规范,并提供了其他结构和详细信息。此设计级别的详细信息包括接口、消息、服务组合以及供应商的服务分配。
步骤
记录非功能需求

利用面向服务的体系结构可提供机会选择工件:服务供应商,不仅根据它提供的功能,而且还根据它可以保证的服务质量(QoS)。 更改服务供应商的原因之一通常可能是非功能需求发生更改,因此必须达到现有供应商不支持的新级别的 QoS。 还可能是由于服务使用者预期的 QoS 降低导致。 通常而言,与其他体系结构风格相比,面向服务的体系结构允许较低成本的灵活性。

可以从两个方面查看 QoS:使用者和供应者。服务供应者保证提供并维护其每个服务或服务组的服务质量。 另一方面,服务使用者综合比较以获取所需的 QoS,并根据此 QoS 选择供应商。 需要重点注意的是在商业环境中,当使用者和供应商在服务的使用方面签订了法律合同,即会在服务级别协议中将这些服务质量保证具体化,如果供应商未能满足此协议,则通常会受到惩罚。

因此,为某个服务或一组服务清楚地指定使用者所需的非功能需求(例如事务成本、性能、可用性和安全性等)非常重要。 在此服务规范任务中,我们将为期望的 QoS 确定非功能需求。 非功能需求将用于为提供服务的服务组件落实资源,还用于为服务组件的实现和维护提供资金,以确保 QoS 的按时交付。 必须制定关键的体系结构决策以确保能够达到承诺的服务质量(基于非功能需求)。

此指南中没有定义如何将非功能需求附加到工件:服务规范中。 也没有为构成此需求的内容设置边界,显然上面已提到了 QoS 和安全性,示例可能包括:

  • 可用性(即平均故障间隔时间)
  • 可操作窗口(是否存在并不希望使用服务的情况?)
  • 响应时间(服务需要多少时间来响应请求)
  • 高峰吞吐量(服务在每个单位时间(如每秒、每分钟或每小时)内可响应多少请求)
属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息