当前位置:   article > 正文

NJU SE 软件系统设计期末复习——架构设计部分_architecturally significant requirements

architecturally significant requirements

软件架构

基础知识

什么是软件架构

某个软件或计算系统的软件架构是该系统的一个或多个结构,它们由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。

(架构是设计的一部分,是设计的最早期的阶段最重要的决定)

架构师是做什么的

架构师的工作不是创造性的一种设计,更多的是在和不同的stakeholder去交流沟通各方面的需求、限制、约束的,最终达成妥协的结果。在技术方面,他对于实现的技术要有所了解;在工程管理方面,也要有一定的经验。

架构的来源

  • NFRs,即非功能化需求。功能化需求描述的是系统要实现的功能,非功能化需求就是除此以外的部分。非功能化需求是架构的主要来源。非功能化需求进一步划分,可以分为质量需求和约束。质量需求就是指完成功能化需求所定义的工作的质量,如做得有多好、让客户多满意等;约束是做架构设计之前已有的,没有任何妥协的余地,不能修改,只能平衡其他方面来满足约束条件
  • ASRs,即架构攸关的需求。ASRs是从各种需求中识别出来的需求,如安全性、可用性等
  • 架构还可以通过不同的因素考虑,不同的利益相关者或涉众对自身的利益有不同的考虑。比如,最终用户可能更关注外部的质量属性,如系统的易用性、安全性等;而开发人员可能更关心系统的内部即不可观测到的质量属性,比如系统的可修改性、可测试性等。一个架构要满足不同的stakeholder的利益、不同组织的商业目标、具体制约架构设计的技术环境等等因素。

架构视图

概念
  • 视图是架构元素的内聚集的表示,由系统涉众编写和阅读。它由一个元素集的表示和元素之间的关系组成。

  • 结构是元素本身的集合,它们存在于软件或硬件中。

例如,模块结构是系统的模块和其组织的集合。模块视图时该结构的表示,由某些系统涉众编档和使用。

视图4+1
  • 逻辑视图(Logical view)
    • 描述系统的静态结构、组成关系
  • 过程视图(Process view)
    • 描述系统运行起来的时候,各部分之间的关系、行为
  • 物理视图(Physical view)
    • 描述软件系统,将虚拟的软件用物理的方式描述展现
  • 开发视图(Development view)
    • 开发人员使用,与逻辑视图关联。描述了开发人员的分工、过程
    • 还会考虑跟项目管理有关的内容,比如交付日期、成本等

这四类视图从不同的角度看系统,同时都在描述一个使用案例场景场景(Use case scenarios)

每一个场景都会涉及到这四类视图

架构活动与过程

架构相关活动
  • 架构设计
  • 架构实现
  • 架构维护
  • 架构演化
架构过程

课程主要关心架构设计阶段的相关活动

20200101231847

主要由以下四个活动串联起来:

  • 识别ASR
  • 架构设计
  • 文档化
  • 架构评估
识别ASR

要知道为谁、为什么去设计,找到设计依据,并不是所有需求都要在架构阶段完成设计,只是一少部分需求,那么就要把这些需求从很多需求中挑选出来,形成ASR。

架构设计

识别出ASR后,把它作为输入,进行架构设计,采用ADD方法。输入除了ASR之外,还有跟这些ASR相关Pattern和tactics成了候选考虑。

文档化

完成设计后,生成一系列视图。

架构评估

生成的文档作为输入Evaluation,进行评估。除了架构文档之外,还有Stakeholders参与,因为他们是最初的需求来源。此外,这其中还会存在迭代,即如果没有通过评估,还会再回到架构设计,进行进一步的设计和改进。

以上就是课堂所关注的架构设计

质量属性

  • 功能化需求 Software Requirements

  • 质量属性 Quality Attributes

  • 架构攸关需求 Architecturally Significant Requirements

往往交替互换使用上述三个名词,把它们看作近似等价

质量属性建模

使用刺激—响应方式,对每一个质量属性由以下6个元素组成描述:

  • 源 Source
  • 刺激 Stimulus
  • 制品 Artefact
  • 环境 Environment
  • 响应 Response
  • 响应度量 Measure
一般场景(General scenarios)
可用性
场景的组成部分可能的值
系统内部、系统外部
刺激错误;疏忽、崩溃、时间、响应
制品系统的处理器、通信信道、持久存储器、进程
环境正常操作、降级模式(也就是更少的特性,这是一种后退(fall back)的解决方案)
响应系统应该检测到事件,并进行如下一个或多个活动:
1. 将其记录下来
2. 通知适当的各方,包括用户和其他系统
3. 根据已定义的规则禁止导致错误或故障的事件源
4. 在一段预先指定的时间间隔内不可用,其中,时间间隔取决于系统的关键程度
5. 继续在正常或降级模式下运行
响应度量1. 系统必须可用的时间间隔
2. 可用时间
3. 系统可以在降级模式下运行的时间
4. 修复时间
可修改性
场景的组成部分可能的值
最终用户、开发人员、系统管理员
刺激希望增加/删除/修改/改变功能、质量属性、容量
制品系统用户界面、平台、环境或与目标系统交互的系统
环境在运行时、编译时、构建时、设计时
响应查找架构中需要修改的位置,进行修改且不会影响其他功能,对所做的修改进行测试,部署所做的修改
响应度量根据所影响的元素数量度量的成本、努力、资金;该修改对其他功能或质量属性所造成影响的程度
性能
场景的组成部分可能的值
大量的独立源中的一个,可能来自系统内部
刺激定期事件到达;随机事件到达;偶然事件到达
制品系统
环境正常模式;超载模式
响应处理刺激;改变服务级别
响应度量等待事件、期限、吞吐量、抖动、缺失率、数据丢失
安全性
场景的组成部分可能的值
正确识别、非正确识别或身份未知的个人或系统它来自内部/外部;
经过了授权/未经授权
刺激试图显示数据、改变/删除数据、访问系统服务、降低系统服务的可用性
制品系统服务、系统中的数据
环境在线或离线、联网或断网、连接有防火墙或直接连接到了网络上
响应对用户进行身份验证
隐藏用户的身份
阻止对数据和/或服务的访问
允许对数据和/或服务的访问
授予或收回对访问数据和/或服务的许可
根据身份记录访问/修改或试图访问/修改数据/服务
通知用户或另外一个系统,并限制服务的可用性
响应度量用成功的概率表示避开安全防范措施所需要的时间/努力/资源
检测到攻击的可能性
确定攻击或访问/修改数据和/或服务的个人的可能性
在拒绝服务攻击的情况下仍然可以获得的服务的百分比
恢复数据/服务
被破坏的数据/服务和/或拒绝的合法访问的范围
可测试性
场景的组成部分可能的值
单元开发人员
增量集成人员
系统验证人员
客户验收测试人员
系统用户
刺激已完成的分析、架构、设计、类和子系统集成
所交付的系统
制品设计、代码段、完整的应用
环境设计时、开发时、编译时、部署时
响应提供对状态值的访问
提供所计算的值}
准备测试环境
响应度量已执行的可执行语句的百分比
如果存在缺陷出现故障的概率
执行测试的时间
测试中最长依赖链的长度
准备测试环境的时间
易用性

具体场景(Concrete scenarios)

设计的时候主要使用具体场景

质量属性对应的战术(Tactics)
可用性战术
  • 错误检测
    • 命令/响应(ping/echo)
    • 心跳(heartbeat)
    • 异常
  • 错误恢复
    • 表决
    • 主动冗余(热重启)
    • 被动冗余(暖重启/双冗余/三冗余)
    • 备件
    • shadow操作
    • 状态再同步
    • 检查点/回滚
  • 错误预防
    • 从服务中删除
    • 事务
    • 进程监视器
可修改性战术
  • 局部化修改
    • 维持语义的一致性
    • 预期期望的变更
    • 泛化该模块
    • 限制可能的选择
  • 防止连锁反应
    • 信息隐藏
    • 维持现有的接口
    • 限制通信路径
    • 仲裁者的使用
  • 推迟绑定事件
    • 运行时注册
    • 配置文件
    • 多态
    • 组件更换
    • 遵守已定义的协议
性能战术
  • 资源需求
    • 提高计算效率
    • 减少计算开销
    • 管理事件率
    • 控制采样频率
    • 限制执行时间
    • 限制队列大小
  • 资源管理
    • 引入并发
    • 维持数据或计算的多个副本
    • 增加可用资源
  • 资源仲裁
安全性战术
  • 抵抗攻击
    • 对用户进行身份验证
    • 对用户进行授权
    • 维护数据的机密性
    • 维护完整性
    • 限制暴露的信息
    • 限制访问
  • 检测攻击
  • 从攻击中恢复
可测试性战术
  • 输入/输出
    • 记录/回放
    • 将接口与实现分离
    • 特化访问路线/接口
  • 内部监视
    • 内置监视器
易用性战术
  • 运行时战术
    • 维持任务的一个模型
    • 维持用户的一个模型
    • 维持系统的一个模型
  • 设计时战术
    • 将用户接口与应用的其余部分分离开来
战术与架构模式的关系

任何模式都会实现几个战术,它们通常与不同的质量属性有关;并且该模式的任何实现都对战术做出了选择

Architecturally Significant Requirements

怎样去找到ASR
  • 需求
    • 可能会发现一些质量属性,但不一定足以支撑设计,可能缺乏度量方法;需要对其进行评估,选取一些重要的需求
  • 与Stakeholders交流(Interviews)
  • 商业目标(系统是用来干什么)
    • 不同的需求可能都很重要,但它们可能会竞争资源,最终判断依据就是它
  • 质量属性效用树
    • 识别需求的过程中,识别出哪些是重要需求,可以被纳入到ASR中的时候,把它加入质量属性效用树

架构模式

一个架构模式是用来解决在某一个具体的上下文环境(context)中所出现的问题,对于这个问题的一个解决方案构成了架构模式。(Solution:元素之间的关系满足什么样的约束)

Module Patterns 模块

模块看的是在设计时系统的分解,分成不同的模块。一旦完成设计模块,就变成了架构的component

  • Layered pattern
Component-Connector Patterns 组件-连接器

从动态的、运行时的角度去观察系统

  • Broker pattern
  • Model-view-controller pattern
  • Pipe-and-filter pattern
    • pipe—connection、filter—component
  • Client-server pattern
  • Peer-to-peer pattern
  • Service-oriented pattern SOA
  • Publish-subscribe pattern
  • Share-data pattern
Allocation Patterns 分配

软件映射到什么硬件的元素上

  • Map-reduce pattern
    • 通过引入并行提高效率
  • Multi-tier pattern
    • 把不同的元素作为一个组合放到某个平台上

设计架构

General Design Strategy
  • Abstraction
  • Decomposition
  • Divide & conquer
  • Generation and test
  • Iteration
  • Reuse
Attribute-Driven Design

ADD是一种定义软件架构的方法,该方法将分解过程建立在软件必须满足的质量属性之上。它是一个递归分解的过程,其中在每个阶段都选择战术和架构模式来满足一组质量属性场景,然后对功能进行分配,以实例化由该模式所提供的模块类型

  • Choose a part to design 选择要设计的部分
  • Marshal all ASRs for that part 把那部分的所有ASR整理好
  • Create and test a design for that part 创建并测试该部件的设计
  • Inputs to and outputs of ADD ADD的输入和输出
8-step process
  1. confirm requirements 确认要求
  2. choose an element to decompose 选择要分解的元素
  3. identify ASRs 识别ASR
  4. choose a design satisfying ASRs 选择满足ASR的设计(选择架构模式)
  5. instantiate elements & allocate responsibilities 实例化元素并分配职责
  6. define interface 定义接口
  7. verify & refine requirements 验证和完善需求
  8. repeat step 2-7 until all ASRs satisfied 重复步骤2-7,直到所有ASR满意

文档化架构

Views and Beyond 视图并超越视图

大部分架构的决定通过视图反映出来

我们通不过不同的视角会生成不一样的视图

视图
结构视图
  • 模块视图
  • C&C视图
  • 分配视图
质量视图

放在架构文档里的是最重要的视图,能反映出架构信息

如何识别视图的重要性
  • 建立Stakeholder/view table
    • 反映了视图对不同stakeholder的重要性、详细程度,找到大部分人关心的视图
  • 组合视图
    • 组合上一步得到的视图,让某一视图展现更多的信息
  • 优先次序和阶段
    • 对于筛选/合并后的视图进行排序,最重要的视图可能作为后面详细设计的依据
beyond

在视图部分,生成的都是单独的;缺少的是跨越不同视图的部分,即系统间的视图关系

架构评估

ATAM: Architecture Tradeoff Analysis Method 体系结构权衡分析方法

ATAM一种进行构架评估的综合方法,ATAM是评估软件构架的一个健壮的方法。在该方法中,项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表(以场景的方式),并说明与实现每个高优先场景相关的构架决策。然后,把这些决策确定为有风险决策或无风险决策,以找到构架中任何存在问题的地方。

ATAM不是需求评估。

ATAM不是代码评估。

ATAM不包括实际的系统测试。

ATAM不是一个准确的手段,但它识别了构架中可能存在风险的区域。这些风险包含在敏感点和权衡中。

选择ATAM的原因
  • 通用的架构评估方法(很多其他方法只关心某一个质量属性)
四个阶段
  • 0阶段(合作关系和准备)确定细节
  • 1阶段,评估阶段,决策者参与,小组开始信息收集与分析;耗时约1周。12周中断期,评估小组进一步以非正式方式了解构架
    • ATAM方法的表述。评估负责人向决策者表述ATAM方法,使大家理解其过程,了解角色布局
    • 商业动机的表述。决策者介绍系统商业动机、重要功能、各种限制(任何相关的技术、管理、经济和政治限制)、商业目标和上下文、主要的涉众、驱动因素等。
    • 构架的表述。首席设计师或架构小组介绍构架,技术限制、所用模式等
    • 对构架方法进行分类。评估小组利用所有已知信息对构架方法进行分类
    • 生成质量属性效用树。生成质量属性效用树,捕获详细的需求信息,为每个场景分配一个级别,如(高,中),前者为重要度,后者为实现难易度,重点放在(高,高)的场景;此处场景具备刺激、环境、响应三要素就可以了
    • 分析构架方法。评估小组分析所有重要场景,设计师解释如何支持该场景,检查所用构架方法,分析风险点、权衡点、敏感点
  • 2阶段,评估阶段,涉众参与,分析继续;约2
    • 集体讨论并确定场景的优先级。集体讨论并分析场景的优先级,以了解更广泛的涉众的想法;该过程可能产生新的场景;使用“有限票数法”投票确定每个场景的优先级——此处不考虑实现难度
    • 分析构架方法。分析新的高优先级的场景,构架师解释构架是怎么满足各场景的
    • 结果表述。总结评估结果,评估负责人展示该结果
  • 3阶段,后续阶段,生成最终报告,进行评估活动总结;1
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/1020479
推荐阅读
相关标签
  

闽ICP备14008679号