软件架构设计(三)——软件架构评估、软件产品线

superSmart_Dong

墨衍会员 · AI 创作全网分发码龄10年

关注

原创最新推荐文章于 2026-03-29 10:39:24 发布 3.2k 阅读 AI 写同款· GEO 优化 ›

软件架构评估软件质量属性包括性能、可用性、安全性、可修改性、功能性、可变性、互操作性，重点把握性能、可用性、安全性、可修改性，可用性和可靠性同时出现时，优先选择可用性。阅读详情

一、软件架构评估质量属性

架构设计要满足功能需求，这是底线。除此之外还需要满足非功能需求。比如性能，可用性，安全性，可修改性，可靠性，功能性，可变性，互操作性等.

性能：反映工作效率的指标
可用性：反映整个系统不崩溃的运行时长。
安全性：反映信息安全的指标
可修改性：反映系统变更能力的指标
可靠性：反映系统不产生异常的指标
功能性：反映系统功能正确的指标
可变性：反映架构变更能力的指标
互操作性：反映与外部系统交互的能力

二、软件架构评估方法

架构评估有几个重要的方面：风险点，敏感点，权衡点：

风险点：需要在评估架构设计中，分析出潜在的，存在架构决策所带来的隐患，这种问题可能会在未来的某个时间爆发。
敏感点：需要在评估架构设计中，分析出能够给系统带来重大影响的质量属性。
权衡点：权衡点属于敏感点。需要在评估架构设计中,分析出能够给系统带来重大影响的某些质量属性，但质量属性间可能会发生冲突，向跷跷板一样，加强了其中一个质量指标，可能会伴随着另外一个指标的下降。比如安全性和性能，有时候很难兼顾。因此需要找到一个折中的方案，这就是权衡点。

评估方式主要有三种，有问卷调查的方式，也有基于度量的方式。所谓问卷调查，就是在设计出架构之后，通过问卷的形式，由一些人员来向问卷中填充系统哪些地方做的好，哪些地方做的不好，对系统提出意见。而度量的方式，就是打上一些量化的指标，提前制定好一个标准，在评估时分析系统是否达到指标的要求。这种方法太过理想，实现起来比较困难。而两者的折中就是基于场景的方式。

场景就是指模拟用户使用系统，对系统进行操作，并得到期望结果的某个过程。基于场景的方式，就是提前制定好一些场景，分析架构是否能满足这些场景中的要求，并对架构进行评估。

三、基于场景的架构评估方式

用例获取功能需求，用场景来获取非功能需求。基于场景的架构评估方式首先需要确定应用邻域的功能和软件架构结构之间的映射；设计用于体现待评估质量属性的场景；分析软件架构对场景的支持程度。

它主要由三种方法：软件架构分析法(SAAM)，架构权衡分析方法(ATAM)；成本效益分析法(CBAM)；

(1)软件架构分析法

此方法最初用于分析架构的可修改性强不强，后来扩展到安全性，性能等其他质量属性。

在SAAM评估之前，首先需要分析要哪些素材，要哪些信息输入。

问题描述：最初用户要解决的问题是什么
需求说明：根据用户需求，分析系统要做的工作由哪些
架构描述：设计的架构是什么样子的

首先要进行场景开发，来反映用户对系统有哪些非功能需求。与架构进行对照，评估架构对单个或多个场景的适应程度。之后进行总结。某些架构对于某个场景十分有优势，但是可能对于其他场景有劣势。

(2)架构权衡分析方法

ATAM在SAAM基础上发展而来。主要针对性能、可用性、安全性、可修改性的性能指标。找出一个平衡点，对这些质量属性进行评价和折中。

与SAAM差不多，首先要进行场景和需求的收集，之后用架构设计过程中的架构描述来解决场景中的要求。第三阶段就是分析架构中的每个单一质量属性的支持程度；第四阶段进行分析哪些质量属性之间存在冲突，需要进行折中。通常情况会根据需求来定义场景的优先级，就是当发生冲突时分析哪一个场景的实现对系统更为重要。

四、软件产品线

一个公司的业务集聚在某个邻域，通常有经验的积累。那么就希望得到一个通用的方法论。不需要每次开发类似的产品都要重零开始，而是将系统进行产品化，只要小修小改就可以满足新系统的需求。而软件产品线就是由软件架构、邻域工程、特定领域架构(DSSA)相结合得到的行业解决方案。

(1) 软件产品线的双生命周期的模型

和DSSA一样。首先现有系统的需求进行分析，哪些需求是整个行业都可能需要涉及的。将此类需求输入邻域工程。得到了邻域工程的模型。在开发新系统时，分析哪些需求时邻域工程中包含的，将已存在的需求、涉及、实现直接从邻域工程获取。对于有差异的，再进行单独的开发。因此，邻域工程做行业间的共性的东西，应用系统负责实现用户的特有需求。