概念:补充需求分解
补充需求分解是用于派生分析(和设计)元素的非功能需求的技术。
关系
主要描述

简介

在分析流程中,架构设计师开发了初始位置图。位置视图是非功能注意事项的合成,提供了关于如何解决非功能需求(例如:可靠性和容量)问题的环境。

标准工程实践可对容量、允许的错误率等进行预算。 该工作可为每个位置元素生成一组派生的补充需求。根据这些需求确定位置的特征。确定和优化子系统分区(跨多个位置)时再次访问派生的需求和特征。

系统级的补充需求也会对子系统(硬件、软件、人员)本身、子系统特征和位置特征有影响,综合这些影响就会产生所需的系统特征。

服务质量评估

服务质量(QoS)是包含非功能需求方面的概念。此类特征的列表可能很大,它包含许多“性能”(例如可靠性、可维护性和可用性),还可能包含完整的工程专业技术(例如安全性、人为因素等)。重大工程专业问题通常由熟悉相关规程的专家处理。经常需要系统和软件工程师解决的问题是这些问题:

  • 性能 - 系统执行其功能的情况(针对时间而言),即响应率、吞吐量以及是否达到时限。
  • 可靠性/容错 - 系统在出现故障之前能持续执行其所需功能的时间,以及它处理局部故障的情况(良好程度)。系统平均故障间隔时间是衡量可靠性的标准。
  • 可维护性 - 保持系统运行、诊断和修正系统问题的难易程度。系统平均修复时间是衡量可维护性的标准。

在构造系统之前,系统工程师必须经常依靠系统模型,以作为定义备选解决方案、分配以及预算非功能需求的一种方法。分析这些模型以查看它们满足所需服务级别质量的情况如何,然后可以选定一种解决方案(通常将成本作为因素)。在所有级别的改进上,贸易研究对于系统设计很重要。候选解决方案的综合在很大程序上依赖于架构设计师的能力和经验。对这些解决方案的分析(通过数学建模、模拟等)应该是相对机械的。即使这样,这些分析的可靠性将随着输入数据的优度和模型的精确度而有显著变化。

对于上面列出的 QoS 评测标准,提供了一些技术使模型分析易于处理,例如速率单调分析(用于检查实时嵌入式软件系统性能)[请参阅 Klein, M. H., et al. A Practitioners' Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993] 和故障方式影响及致命度分析(FMECA)(用于确认和描述硬件故障和安全风险)[请参阅 Kececioglu, Dimitri, Reliability Engineering Handbook, Vol.2, PTR Prentice Hall, 1991]。

通过提供概要文件(特别是“可调度性、性能和时间规范的 UML 概要文件”“服务的建模质量、容错特征和机制的 UML 概要文件”),将对这几种分析的支持添加到 UML。这些概要文件(可从 www.omg.org 获取)定义了 UML 模型的注释,通过使用各种现有的和将来的模型分析技术和工具,这些注释使您可针对概要文件中定义的特征和根据这些特征做出的数量预测来分析这些模型。