本文介绍了基于架构的软件设计（ABSD）方法，强调其递归特性和在软件开发生命周期中的位置。内容涵盖软件模板、ABSD方法与生命周期的关系、需求获取和架构设计过程。重点讨论了用例、质量需求、架构选项和约束在ABSD中的角色，以及基于架构的软件开发模型的六个子过程。
#版权声明
主要针对希赛出版的架构师考试教程《系统架构设计师教程（第4版）》，作者“希赛教育软考学院”。完成相关的读书笔记以便后期自查，仅供个人学习使用，不得用于任何商业用途。
文章目录
第六节 基于架构的软件设计
基于架构的软件设计（Architecture-Based Software Design，ABSD）是一种架构驱动方法。
基于架构的软件设计有 3 个基础：
（1）功能的分解。在功能分解中，ABSD 方法使用已有的基于模块的内聚和耦合技术。
（2）通过选择架构风格来实现质量和业务需求。
（3）软件模板的使用。软件模板利用了一些软件系统的结构。
ABSD 方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
软件模板
软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能，这些功能的例子有：每个元素必须记录某些重大事件，每个元素必须为运行期间的外部诊断提供测试点等。在软件产品线系统中，软件模板显得格外重要，因为新元素的引入是一个通用的技术，这种技术用来使产品线架构适应一个特定的产品。
ABSD 方法与生命周期
图 6-8 描述了 ABSD 方法在生命周期中的位置。尽管没有描述需求获取、组织或跟踪的特定方法，但还是假设一个需求阶段至少部分地完成，从需求阶段（包括功能需求、质量和业务需求、约束等）获得了输出。
ABSD 方法的输出是三个视图的概念构件的集合，包括能够产生每个概念构件的假定、软件模板的集合和那些已经做出的具体实现的决策，我们把具体实现决策当作附加约束来维护。
在 ABSD 方法中，必须记录所有做出的决策及这些决策的原理，这有利于决策的可跟踪性和决策评审。
ABSD 方法的输入
抽象功能需求
ABSD 方法假定需求阶段的输出之一是功能需求的抽象描述，包括这些需求的粗略变化的描述。当获取需求时，考虑所有最终用户是重要的。
对一个特定系统来说，通常有不同类型的最终用户。不同的系统管理员（数据库管理员、系统管理员、网络管理员等）都可以是最终用户。维护工程师也可以是系统的最终用户。总之，一个最终用户就是当系统运行时使用系统的任何人员。
与抽象功能需求相联系的是对公共需求和与这些需求相关的粗略变化的描述，在设计阶段，理解这些需求之间的依赖关系是至关重要的。
我们必须在某种抽象级别上获取功能需求，产品的详细需求往往要等具体产品开发完成后才能知道。当详细需求明确时，抽象功能的获取为详细需求提供了分类。
用例
用例是一个或多个最终用户与系统之间的交互的具
最低0.47元/天 解锁文章
扫一扫
1131
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
