软件架构设计 ABSD/DSSA/SAAM/ATAM

ABSD：自顶向下、递归细化；虚设档，复现演

DSSA：并发、递归、反复的螺旋模型

SAAM/ATAM：评估

1. 什么是基于架构的软件开发方法ABSD？它的6个过程是什么？(ABSD虚设档，复现演)

ABSD方法是架构驱动，强调由业务、质量和功能需求组合驱动架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。用例描述的是功能需求，质量属性场景描述的是质量需求。

开发过程包括6步：架构需求，设计，文档化，复审，实现，演化。

1. 什么是特定领域软件架构DSSA？它的2个领域，3个阶段，4种角色分别是什么？

特定领域软件架构DSSA是在一个特定应用领域中为一组应用提供组织结构参考的标准软件架构，是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标是支持在一个特定领域中多个应用的生成。
2个领域：垂直域是在一个特定领域中通用的软件架构，是一个完整的架构。水平域是在多个不同的特定领域之间相同的部分的小工具。（如收费系统）。
3个阶段：领域分析(获得领域模型)、领域设计(获得DSSA)、领域实现(开发和组织可重用信息)。
4种角色：领域专家、领域分析师、领域设计人员、领域实现人员。

5个阶段：定义领域范围、定义领域特定元素、定义领域特定的设计和实现约束、定义领域模型和体系结构、产生&搜集可重用单元

1. 质量属性中性能，互操作性，功能性，安全性，可用性，可变性，可靠性，可修改性（幸福公安用遍可靠修改）是什么？以及系统架构风险、敏感点、权衡点、风险点和非风险点是什么?

1. 性能：指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。如响应时间、吞吐量。设计策略：优先级队列、引入并发、资源调度等。
2. 互操作性：作为系统组成部分的软件不是独立存在的，经常与其它系统或自身环境相互作用。
3. 功能性：系统所能完成所期望的工作的能力。
4. 安全性：指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。如保密性、完整性、不可抵赖性、可控性等。设计策略：入侵检测、用户认证、追踪审计。
5. 可用性：系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。如故障间隔时间。设计策略：心跳、Ping/Echo、冗余、选举。
6. 可变性：指体系结构经扩充或变更而成为新体系结构的能力。
7. 可靠性：软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。如MTTF、MTBF。设计策略：心跳、Ping/Echo、冗余、选举。
8. 可修改性：指能够快速的以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价来衡量。包括可维护、可扩展、可移植、结构重组。设计策略：接口与实现分离、抽象、信息隐藏。
9. 可测试性：指软件发现故障并隔离和定位其故障的能力。设计策略：记录/回放、内部监视。

系统架构风险：指架构设计中潜在的、存在问题的架构决策所带来的隐患。
敏感点：为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
风险点：架构设计中潜在并存在问题的架构决策所带来的隐患。
非风险点：如果某件事是可行的，可接受的，则为非风险点。

SAAM vs ATAM

1. 软件架构分析方法SAAM，它的6个步骤是什么？

软件架构分析方法SAAM是一种基于场景的系统架构评估方法，最初是用来分析架构的可修改性的，但实践证明也可用于对许多其它质量属性及系统功能的快速评估。它的6个步骤包括：
1，形成场景；
2，描述架构；
3，对场景进行分类和确定优先级；
4，对间接场景的单个评估；
5，评估场景的相互作用；
6，形成总体评价；

1. 架构权衡分析方法ATAM，它的含义是什么？它的四个阶段9个步骤是什么？

架构权衡分析方法ATAM是一种基于场景的系统架构评估方法，主要在系统开发之前，针对性能、可用性、安全性和可修改性等质量属性进行评价和折中。ATAM分为4个主要的活动包括场景和需求收集、架构视图描述、属性模型构造和分析、架构决策和折中，整个评估过程强调以属性作为架构评估的核心概念。
它的四个阶段9个步骤是：
一．描述和介绍阶段（包括1.描述ATAM方法 2.描述业务动机 3.描述架构）；
二．调查和分析阶段（包括4.确定架构方法 5.生成质量属性效用树 6.分析架构方法）；
三．测试阶段（包括7.讨论和对场景分级 8.分析架构方法）；
四．报告阶段（包括9.描述评估结果）；

1. 采用面向对象方法开发软件，通常需要建立三种形式的模型，它们是什么以及区别是什么？

功能模型定义“做什么”，描述系统功能。一般使用数据流图或用例图来建模。
动态模型定义“何时做”，描述系统控制结构。一般使用状态图来建模。
对象模型定义“对谁做”，描述系统静态数据结构。一般使用对象图或类图来建模。它是整个体系中最基础，最核心的部分。

1. 采用面向对象方法进行软件系统的分析与设计时，一项重要的工作是建立分析类图和设计类图，它们两者的差异是什么？什么是边界类、实体类和控制类？什么是接口对象、实体对象和控制对象？

分析类图是从业务领域获取信息的，在描述上更多的使用了业务领域的语言和词汇。
设计类图是从编程实现的角度来设计类图的，更多的考虑类编码的实现。
边界类：一种用于对系统外部环境与内部运作之间的交互进行建模的类。接口对象是用来表示用户与系统之间交互方式的对象类型。如窗口、通信协议、打印机接口等。
实体类：用于对必须存储的信息和相关行为进行建模的类。实体对象是用来表示业务域的事实数据并需要持久化存储的对象类型。如事件、人员等。
控制类：对一个或几个用例所特有的控制行为进行建模的类。控制对象是用来表示业务系统中应用逻辑和业务规则的对象类型。通常控制其它对象。

1. 软件架构的4+1视图分别是什么？（进场勿开锣4+1视图）

1. 进程视图（对应UML进程视图）：侧重于系统的运行特性。一般用状态图或活动图来表示。
2. 场景视图（对应UML用例视图）：是最重用的需求抽象。一般用用例图表示。
3. 物理视图（对应UML部署视图）：考虑如何将软件映射到硬件上。一般用部署图来表示。
4. 开发视图（对应UML实现视图）：侧重于软件模块的组织和管理。一般用构件图来表示。
5. 逻辑视图（对应UML逻辑视图）：描述系统的功能需求。一般用类图来表示。