当前位置: 首页 > >

2011年软考系统架构设计师学*笔记第五章

发布时间:

软件架构设计

  Software Architecture 简称 SA


  5.1.1 软件架构设计与生命周期


  1、需求分析阶段


  需求 和 SA设计 面临的是不同的对象:一个是问题空间;另一个是解空间。保持二者的可跟踪性和转换。


  2、设*锥


  1.传统的设计概念只包括 构件,随着研究的深入,构件间的 互联机制 逐渐独立出来,成为与构件同等级别的实体,称为 连接子。


  2.体系结构描述语言(Architecture Description Language ADL)对 连接子 的重视成为区分 ADL和其他建模语言的重要特征之一。


  3.不同的视角 得到多个视图,组织起来以描述整体的SA模型;不同侧面的视图反映所关注的系统的特定方面,体现了关注点分离的思想。


  3、实现阶段


  团队的 结构 应该和体系结构模型有一定的对应关系,提高软件开发 效率和质量。


  分析和记录 不同版本构件和连接子之间的演化。


  填补高层 SA模型 和 底层实现 之间的鸿沟,典型的方法如下:


  1.引入实现阶段的概念。


  2.SA模型 逐步精化。


  3.封装底层称为较大粒度构件。


  4、构件组装阶段


  可复用构件 组装 可以在较高层次上实现系统,研究内容包括:


  1.如何互联。


  2.如何检测并消除体系结构失配问题。


  中间件跨*台交互。


  产品化的中间件更好地保证最终系统的质量,中间件导向的体系结构风格。


  失配是指复用过程中,待复用构件对最终系统的体系结构和环境的架设(Assumption)与实际状况下不同而导致的冲突。


5、部署阶段


  软件构件的互联性、硬件的*私峁埂⒂布试凑加谩


  6、后开发阶段


  实现中的软件往往具有动态性,一类是软件内部执行所导致的体系结构改变,另一类变化是软件系统外部的请求对软件进行的重配置。


  升级或进行其他修改时 不能停机。


  SA重建是指 从已实现的系统中 获取体系结构的过程。


  5.2 基于架构的软件开发方法


  5.2.1 体系结构的设计方法概述


  基于体系结构的软件设计(Architecture-Based Software Design ABSD)方法。


  体系结构驱动,指 构成体系结构的 商业、质量、功能 需求的组合驱动。


  设计活动的开始 并不意味着 需求抽取和分析活动 就可以终止,而应该 并行,快速开始设计 至关重要。


  ABSD 方法有三个基础,功能分解、选择体系结构风格、软件模板的使用。


  5.2.2 概念与术语


  1、设计元素


  ABSD方法是一个 自顶向下,递归细化 的方法。


  2、视角与视图


  重要的是从不同的视角(perspective)来检查,考虑体系结构的不同属性。


  3、用例和质量场景


  在使用用例捕获功能需求时,通过定义特定场景来捕获质量需求,称为质量场景。捕获变更、性能、可靠性、交互性,质量场景必须包括 预期的 和 非预期的。


  5.2.3 体系结构需求


  可以从需求库中取出,加以利用和修改。


  获取需求,体系结构需求一般来自三个方面:系统的质量目标、系统的商业目标、开发人员的商业目标。


  5.2.4 体系结构文档化


  体系结构规格说明 和 测试体系结构需求的质量设计说明书。


  需求模型构件的 精确形式化描述,作为 用户和开发者 之间的一个协约。


  从使用者的角度进行编写,必须保证开发者手上的文档是最新的。


  5.2.5 体系结构复审


  根据架构设计,搭建一个可运行的最小化系统 用于 评估 和 测试 体系架构是否满足需要。是否存在可识别的技术和协作风险。


  复审的目的是 标识潜在风险,及早发现 缺陷和错误。


  5.2.6 体系结构实现


  分割成规定的构件,按规定方式互相交互。


  5.3 软件架构风格


  体系结构设计 核心目标是 重复的体系结构模式,体系结构级的 软件重用。


5.3.1 软件架构风格概述


  一个体系结构 定义 一个词汇表 和 一组约束。词汇表中包含 构件和连接件类型约束指出 如何 组合起来。


  体系结构风格 反映了 共有的结构和语义特性,并指导如何 组织成一个完整的系统。


  5.3.2 经典软件体系结构风格


  每个构件都有一组输入和输出,数据输入构件,经过内部处理,然后产生数据输出。这里的构件称为 过滤器。


  构件是对象。


  分层系统,每一层为上层提供服务,并作为下层的客户。除一些精心挑选的 输出函数外,内部的层接口只对 相邻层可见。由于一层最多只影响两层,为软件重用提供了强大的支持。


  仓库风格中,两种不同的构件:中央数据结构、独立构件。


  若构件控制共享数据,则仓库是一传统型数据库;若中央数据结构 的当前状态触发进程执行的选择,则仓库是一黑板系统。


  C2 体系结构 通过连接件绑定在一起 按照一组规则运作的并行构件网络。构件与构件之间的连接是不允许的。


  5.3.3 客户/服务器 风格


  宿主机应用程序 既负责与用户的交互(前端),又负责对数据的管理(后端)。


  C/S 体系结构 定义了工作站如何与服务器相连,实现部分数据和应用 分布到多个处理机上。


  C/S三个主要组成部分:服务器、客户机、网络。


  易于对系统进行扩充和缩小。


  功能构件充分隔离,客户应用程序的开发集中于数据的显示和分析,数据库服务器的开发集中于数据的管理,将大应用处理任务分布到许多通过网络连接的低成本计算机上,模型思想简单。


  开发成本高,尤其是软件不断升级,客户端变得越来越臃肿。


  信息内容和形式单一,用户获得的只是单纯的字符和数字。


  软件移植困难,维护升级困难。


  5.3.4 三层 C/S 结构风格。


  三层 C/S 体系结构中,可以将 整个应用逻辑 驻留在应用服务器上,只有表示层存在于客户机上,称为“瘦客户机”。表示层、功能层、数据层。


  表示层一般要使用图形用户界面 GUI。


  功能层之间的数据交互 要 尽可能简洁,一次性传输。


  数据层不同层构件 相互独立,层间接口简洁,适合复杂事务处理。


 5.3.5 浏览器/服务器风格


  浏览器/服务器 风格 就是 三层应用结构的一种实现方式。浏览器/web服务器/数据库服务器。


  系统安装、修改、维护 全在服务器端解决。仅仅需要一个浏览器就可运行全部模块。


  B/S 体系结构还提供了 异种机、异种网、异种应用服务 的 连机、联网 等。


  扩展能力差。响应速度慢。交互性不强,不利于在线事务处理 OLTP。


  5.4.1 特定领域软件体系结构


  主要目的 在一组相关的应用中 共享 体系结构。


  DSSA的必备特征:


  1、一个严格定义的 问题域 和 解域。


  2、具有普遍性。


  3、对整个领域的 构件 组织模型 其当抽象。


  4、具备该领域 固定的、典型的 可重用元素。


  5.4.2 DSSA 的基本活动


  1、领域分析


  主要目标是 获得 领域模型,描述领域中 系统之间的共同需求,定义领域的边界。从而明确分析的对象,识别信息源,确定哪些需求是领域中的系统广泛共享的,从而建立领域模型。


  2、领域设计


  目标是获得 DSSA,DSSA描述在领域模型中表示的需求 的解决方案。不是单个系统的表示,而是能够适应领域中 多个系统的需求的 一个高层次设计。


  3、领域实现


  主要目标是 依据 领域模型 和 DSSA 开发和组织 可重用信息。领域模型 和 DSSA 定义了这些可重用信息的 重用时机。


  以上过程是 反复的、逐渐求精 的过程。


  5.4.3 参与 DSSA 的人员


  4种角色:领域专家、领域分析师、领域设计人员、领域实现人员。


  1、领域专家 可能包括 有经验的用户、从事该领域中系统的需求分析、设计、实现 以及项目管理的有经验的软件工程师等。


  主要任务 提供 需求规约和实现的知识,组织规范的、一致的领域字典,选择样本系统,复审领域模型、DSSA。


  应该 熟悉该领域 软件设计和实现、硬件限制、未来的用户需求、技术走向 等。


  2、领域分析人员 应由 系统分析员来担任。


  知识获取 组织到领域模型中,根据 现有系统、标准规范 等 验证模型的 准确性 和 一致性。


  应熟悉软件重用和领域分析方法,具有一定的该领域经验,较高的 抽象、关联、类比 能力,较高的 交互合作能力。


  3、领域设计人员 控制整个软件设计过程,根据领域模型和现有系统 开发出DSSA,对DSSA的准确性和一致性进行验证,建立领域模型和DSSA之间的联系。


  应熟悉软件重用和领域设计方法,熟悉软件设计方法,有一定的该领域经验。


  4、领域实现人员 根据领域模型和DSSA,从头开发可重用构件,或 利用再工程技术 从现有系统中提取可重用构件。


5.4.4 DSSA 的建立过程


  一般情况下,需要用 开发者*惯使用的工具和方法 建立DSSA模型。


  DSSA建立过程分为5个阶段,过程是 并发的、递归的、反复的,可能每个阶段经历几遍,每次增加更多的细节。


  1、定义领域范围,一系列用户的需求。


  2、定义领域特定的元素,编译领域字典、领驭属于的同义词词典。


  3、定义特定的设计和实现需求约束,不仅要识别出约束,并且要 记录 约束对设计和实现 造成的后果,还要记录对处理这些问题时所产生的所有问题的讨论。


  4、定义领域模型和体系结构,产生一般的体系结构,并说明构成它们的模块或构件的语法、语义。


  5、搜集可重用的产品单元,为DSSA增加构件。


  5.5.1 系统架构的评估


  评估 可以只针对一个体系结构,也可以针对一对一组体系结构。关注的是 质量属性。


  1、性能,是指系统的响应能力,多长时间 对某个事件做出响应,或者 某段时间内系统所能处理的事件的个数。


  2、可靠性,是最重要的软件特性,*均失效等待时间 MTTF,*均失效间隔时间 MTBF


  1.容错,内部修复。


  2.健壮性,不受错误使用和错误输入的影响。


  3、可用性,正常运行的时间比例。经常用两次故障之间的时间长度或恢复正常的速度来表示。


  4、安全性,阻止非授权用户。分为 机密性、完整性、不可否认性、可控性 等特性。


  5、可修改性,通过考察 变更的代价 衡量可修改性。


  1.可维护性,主要体现在问题修复上,做局部性的修改并能使对其他否见的负面影响最小化。


  2.可扩展性,新特性来扩展软件系统,改进版本来替换构件并删除不需要的特性构件,需要松散耦合的构件。


  3.结构重组,需要精心设计构件之间的关系。


  4.可移植性。


  6、功能性,完成所期望的工作 的能力。


  7、可变性。


  8、互操作性,精心设计的软件入口。


  5.5.2 评估中重要概念


  敏感点 权衡点,是关键的体系结构决策。


  敏感点是 构件(和/或 构建之间的关系)的特性。研究敏感点可使人员明确在实现质量目标时 应注意什么。


  权衡点 是多个质量属性的 敏感点。


  风险承担着 或称为 收益相关人。


  场景,首先要精确地得出具体的质量目标,为得出这些目标采用的机*凶龀【啊4臃缦粘械U叩慕嵌扔胂低车慕换サ募蚨堂枋觥


  刺激、环境、响应,三个方面描述场景。


5.5.3 主要评估方法


  1、SAAM 非功能质量属性的体系结构分析方法,是最早形式成文档并得到广泛使用的分析方法。最初它用于比较不同的软件体系结构,以分析SA的可修改性。


  1.特定目标,目标是对描述应用程序属性的文档,验证假设和原则,有利于评估固有的风险。


  2.评估技术,使用场景技术,描述了各种系统 必须支持的活动 和 将要发生的变化。


  3.质量属性,可修改性 是 SAAM分析的主要 质量属性。


  4.风险承担者,SAAM 协调不同参与者所感兴趣的方面,作为后续决策的基础,提供了对系统结构的 公共理解。


  5.体系结构描述,描述形式 应该被所有参与者理解。功能、结构、分配,三个主要方面。


  6.方法活动,SAAM 的主要输入问题是 描述、需求声明、体系结构描述。


  SAAM 分析评估 体系结构过程包括 5个 步骤:场景开发、体系结构描述、单个场景评估、场景交互、总体评估。


  通过各类 风险承担者协商讨论,开发一些 任务场景,体现系统所支持的 各种活动。


  通过对场景交互的分析,得出系统中所有场景对系统中构件所产生影响的列表。总体的 权衡 和 评价。


  2、ATAM


  体系结构权衡分析方法,主要针对 性能、实用性、安全性、可修改性。


  确定多个质量属性之间 这种 的必要性。


  体系结构空间 受到 历史遗留系统、互操作性 和 以前失败的项目 约束。


  逻辑视图被分为 功能结构 和 代码结构。这些结构加上他们之间适当的映射可以完整地描述一个体系结构。


  用一组 消息顺序图 显示运行时的 交互 和 场景。


  从不同的体系结构角度,有三种不同场景,用例、增长场景、探测场景。


  ATAM 使用定性的 启发式分析方法 QAH,构造 精确分析模型时 要进行分析。


  4个主要的活动领域(或阶段),场景和需求收集、结构视图和场景实现、属性模型构造和分析、分析、折中。


  属性分析是互相依赖的。获得属性交互的方法有两种,敏感度分析来发现折中点、通过检查假设。


  迭代的改进。除了通常从场景派生而来的需求,还有很多对 行为模式和执行环境的 假设。


  由于属性之间存在折中,每一个架设都要被 检查、验证、提问,完成所有操作后,把分析的 结果和需求 进行对比。


  领驭知识库通过基于属性的 体系结构风格ABAS 维护,变得更为惯例化、更可预测,得到一个标准问题集合。


?


?


?



友情链接: