夜雨聆风
软考架构师|软件架构设计 (19–28 分)核心考点② 质量属性与架构评估
4.4特定领域软件架构DSSA
DSSA（Domain Specific Software Architecture），特定领域软件架构以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成给你的开发基础架构，支持一个特定领域中多个应用的生成。
垂直域：相同领域，深入
水平域：不同领域，平移
4.4.1DSSA的基本活动
（1）领域分析：获得领域模型。领域模型描述领域中系统之间的共同需求
（2）领域设计：主要目的是获得DSSA。DSSA描述在领域模型中标识需求的解决方案
（3）领域实现：依据领域模型及DSSA开发和组织可重用信息
4.4.2参与DSSA人员
领域专家、领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识
领域分析师、主要任务包括控制整个领域分析过程,进行知识获取,将获取的知识组织到领域模型中
领域设计人员、主要任务包括控制整个软件设计过程,根据领域模型和现有的系统开发出DSSA,对DSSA的准确性和一致性进行验证,建立领域模型和DSSA之间的联系
领域实现人员、主要任务包括根据领域模型和DSSA,或者从头开发可重用构件,或者利用再工程的技术从现有系统中提取可重用构件,对可重用构件进行验证,建立DSSA与可重用构件间的联系
4.4.3 DSSA的建立过程
5个阶段：定义领域范围；定义领域特定的元素；定义领域特定的设计和实现需求约束；定义领域模型和架构；产生、搜集可复用的产品单元。并发、递归、反复、螺旋。
4.4.4 三层次模型
领域架构师：领域开发环境
应用工程师：领域特定的应用开发环境
操作员：应用执行环境
4.5 软件架构评估(SAAM/ATAM)
4.5.1软件质量属性
开发期质量属性:易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性
运行期质量属性：性能、安全性、可伸缩性、互操作性、可靠性、可用性、鲁棒性、
4.5.1.1性能：系统的响应能力
性能战术：
资源需求：提高计算效率，减少计算开销，管理事件率，控制采样频率
资源管理：引入并发，维持多个副本，增加可用资源
资源仲裁：资源调度策略（先进/先出，固定优先级，动态优先级，静态调试），队列调度
4.5.1.2可用性:系统正常运行的时间比例
可用性战术：
错误检测：命令/响应（ping/Echo）,心跳，异常
错误恢复：表决，冗余（主动/被动），备件
错误预防：进程监视器，事务，从服务器删除
4.5.1.3安全性：
在向合法用户提供服务的同事能够阻止非授权用户使用的企图。
包含：机密性（信息不泄露给未授权用户），完整性（防止信息被篡改），不可否认性（不可抵赖），可控性（对信息的传播及内容具有控制能力）
安全性战术：
抵抗攻击：身份验证，用户授权，数据加密，限制暴露，限制访问，
检测攻击：入侵检测
从攻击中恢复：识别：审计追踪，恢复：冗余（与可用性重叠）
4.5.1.4可修改性：
以较高的性能价格比对系统进行变更的能力
可修改性战术：接口–实现分离、抽象、信息隐藏等。 丰富的插件也属于可修改
包含：可维护性，可扩展性，结构重构，可移植性
4.5.1.5易用性和可测试性
4.5.1.6 可靠性:
指软件系统在一定的时间内持续无故障运行的能力，
包括：容错性和健壮性
4.5.2 敏感点权衡点与风险点非风险点
敏感点:一个或多个构件的特性
权衡点:多个质量属性的敏感点
风险点:架构设计中潜在的，存在问题的架构决策所带来的隐患
非风险点:不会带来隐患，“XXXX要求是可以实现（或接受的）”方式表达
优先考虑是不是非风险点（有关键字：可以实现，可以接受）。
4.5.3架构评估方法
4.5.3.1架构评估方法
4.5.3.2场景评估方法
为了精确描述软件系统的质量属性，通常采用:质量属性场景作为描述质量属性的手段
刺激源：产生刺激的实体或活动（如用户、外部系统、设备等，即“谁 / 什么引发刺激”）。
刺激：刺激源向制品发出的具体请求或条件变化（如用户点击按钮、系统接收数据更新指令等“触发事件”）。
制品：被刺激的对象（通常是待分析的系统、子系统或构件，即“被作用的目标实体”）。
环境：刺激发生时的上下文（如系统负载、网络状态、时间约束等“背景条件”）。
响应：制品接收到刺激后所采取的行动（即“激励到达后执行的操作 / 行为”）。
响应度量：衡量响应是否符合要求的量化指标（如响应时间、准确性、资源消耗等“评估标准”）。
4.5.3.3软件架构分析法（SAAM）
最初关注可修改性，后扩充到可移植性，可扩充性。
架构描述：这一步骤主要用于用易于理解的方式描述软件架构，体现系统的计算构件、数据构件以及构件之间的关系，而非体现系统支持的活动。场景开发：这一步骤通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。单个场景评估：这一步骤主要是对场景（直接场景和间接场景）生成一个关于特定架构的场景描述列表，而非开发体现系统活动的场景。场景交互：这一步骤主要分析场景对系统构件的影响，而非开发体现系统活动的场景。
4.5.3.4架构权衡分析法（ATAM）
从SAAM发展而来，关注系统的需求说明（质量属性）,主要针对：性能，可用性，安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。
步骤：场景和需求收集、架构视图和场景实现、属性模型构造和分析、折中
用ATAM方法评估软件体系结构，其工作分为4个基本阶段，即演示（描述和介绍）、调查和分析、测试和报告ATAM
演示（描述和介绍）：介绍ATAM、介绍业务驱动因素和介绍要评估的体系结构。
调查和分析阶段：确定架构方法、生成质量属性效用树和分析体系结构方法。
测试阶段：头脑风暴和优先场景以及分析架构方法。
报告阶段：则是总结和呈现评估结果。
ATAM头脑风暴的三种场景：
用例场景：表示系统在典型工作负载或使用情况下的行为。
增长场景：描述系统随着需求变化或规模扩展的能力。
探索性场景：表示非典型或异常使用情况下的表现，强调鲁棒性和边界条件。
树形结构从根部到叶子节点：树根,质量属性，属性分类，质量属性场景
4.5.3.5成本效益分析法（CBAM）
从ATAM基础建立，软件的“经济”模型
4.6软件产品线
软件产品线主要由两部分组成，分别是核心资源和产品集合。
软件产品线开发有4个基本技术特点，即过程驱动、特定领域、技术支持和架构为中心。
双生命周期
产品、产品线、产品集之间的关系:
从产品到产品线:一个单一的产品可以演化为一个产品线的起点，通过识别并标准化共享组件和架构，逐步发展出满足不同需求的多个产品。
从产品线到产品集:多个产品线集合起来构成一个更广泛的产品集，每个产品线专注于特定的市场需求或技术领域，而产品集则提供跨产品线的综合解决方案。
产品集管理:在最高层面，组织需要管理其产品集，以确保公司资源得到最优配置，并且各产品线和产品之间能够相互支持和补充，实现业务战略目标。
建立方式
组织结构
4.7构件与中间件技术
4.7.1软件复用
软件复用：多次不同的软件开发过程中重复使用相同或相似「软件元素」的过程
软件元素：需求分析文档，设计过程，设计文档，程序代码，测试用例，领域知识
复用的维度：
水平复用：不分行业领域，通用的
垂直复用：分行业领域，专用的
4.7.2构件复用
检索与提取构件：基于关键字的检索、刻面检索法、超文本检索法
理解与评价构件：必须要求构建的开发过程遵循公共标准
修改软件：理想状态是直接复用构件库中现成的构件
组装构件：基于功能组装，基于数据组装，面向对象组装。补充：基于服务组装
构件组装失配问题：由构件引起的失陪，由连接子引起的失配
4.7.3构件概念
—个构件不能有任何（外部的）可见状态，但是可以利用容器管理自身对外的可见状态
原子构件可以单独部署，但是几乎不会被单独部署
构件框架是一种专用的体系结构，同时也是一组固定得，作用于构建层次机制的策略
构件是一组通常需要同时部署的原子构件，构件和原子构件之间的区别在于，大多数原子构件永远不会被单独部署，尽管它们可以被单独部署
一个原子构件是由一个模块和一组资源
4.7.4中间件介绍
采用中间件技术的优点：面向需求，业务的隔离和包容性，设计与实现隔离，隔离复杂的系统资源，符合标准的交互模型，软件复用，提供对应用构件的管理。
中间件可以:负责客户端与服务器之间的连接和通信，以及客户端与应用层之间的高效率通信机制。提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发。屏蔽硬件、操作系统、网络和数据库的差异。提供一组通用的服务去执行不同的功能，避免重复工作，使应用之间可以协作。
4.7.5构件标准
会话Bean：实现业务逻辑，负责完成服务的与客户端的交互
实体Bean：实现O/R映射，简化数据库开发工作
消息驱动Bean：处理并发与异常访问。
CORBA(Common Object Request Broker Architecture)分布式系统通信技术解析
伺服对象：CORBA对象的真正实现，完成客户端请求
对象适配器：屏蔽ORB内核的实现细节，为服务器对象的是现在提供抽象接口，以便他们使用ORB内部的某些功能。
对象请求代理：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置，通信方式，实现，激活或者存储机制。