软件体系结构原理、方法与实践总结
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
第1章:软件体系结构概论
什么是软件危机,软件危机的具体表现有哪些?
软件危机:落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象。
软件危机的表现:
软件成本日益增长,开发进度难以控制,软件质量差,软件维护困难
产生软件危机的原因,如何克服软件危机?
产生软件危机的原因有用户需求不明确,缺乏正确的理论指导,软件规模越来越大,软件复杂度越来越高。
人们面临的不光是技术问题,更重要的是管理问题。要提高软件开发效率,提高软件产品质量,必须采用工程化的开发方法与生产技术。在技术上,应该采用基于重用的软件生产技术;
在管理上,应该采用多维的工程管理模式。
构件:(components,也译为组件,部件):
是指语义完整、语法正确和有可重用价值的单位软件,是软件重用过程中可以明确辨识的系统;结构上,它是语义描述、通讯接口和实现代码的复合体。是具有某种功能的可重用的软件模板单元,表示了系统中主要的计算元素和数据存储。
软件架构师的关注点:
关注的首先不是功能,而是品质关注点(非功能性需求)。涉众关注的是那些品质,如性能,安全,可伸缩性,还是可变性,可维护性,可用性等。理解的涉众的品质关注点后,考虑折中。分而治之,保持概念完整性
软件体系结构的定义
软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述,这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构,并且显示了系统需求和构成系统的元素之间的对应关系,提供了一些设计决策的基本原理。
软件体系结构的意义
体系结构是风险承担者进行交流的手段,体系结构是早期设计决策的体现,它明确了对系统实现的约束条件,决定了开发和维护组织的组织结构,制约着系统的质量属性,可以预测软件的质量,是推理和控制更改更简单,有助于循序渐进的原型设计。同时,软件体系结构是可传递和可重用的模型。
软件体系结构的应用现状
目前,软件体系结构领域研究非常活跃,归纳现有体系结构的研究活动,主要包括以下几个方面
1.软件体系结构描述语言
2.体系结构构造与表示
3.体系结构分析、设计与验证
4.体系结构发现、演化与重用
5.基于体系结构的软件开发方法
6.特定领域的体系结构框架
7.软件体系结构支持工具
8.软件产品线体系结构
9.建立评价软件体系结构的方法
架构分析、设计与验证,发现、演化与重用
架构分析的内容可分为结构分析、功能分析和非功能分析。生成一个满足软件需求的架构的过程即为架构设计。
架构设计过程的本质在于将系统分解成相应的组成成分,并将这些成分重新组装成一个系统。架构设计有两大类方法:过程驱动方法和问题列表驱动方法。
架构测试着重于仿真系统模型,解决架构层的主要问题。由于测试的抽象层次不同,架构测试策略可以分为单元/子系统/集成/验收测试等阶段的测试策略。
架构发现从既存系统中提取软件的架构,属逆向工程。
架构重用属于设计重用,比代码重用更抽象。由于软件架构是系统的高层抽象,反映了系统的主要组成元素及其交互关系,因而较算法更稳定,更适合于重用。
软件架构演化是指由于系统需求、技术、环境、分布等因素的变化而导致软件架构的变动。软件系统在运行时的架构变化称为架构的动态性,而将架构的静态修改称为架构扩展。两者都是架构适应性和演化性的研究范畴。
第2章软件体系结构建模。
软件体系结构建模的种类
结构模型、框架模型、动态模型、过程模型和功能模型
什么是“4+1视图”,分别给出每个视图的名称和主要关注点。
“4+1”的视图模型是Kruchten于1995年提出的用于描述软件体系结构的方式,主要用5个不同的视图:逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面,5个视图结合在一起才能反映系统的软件体系结构的全部内容
软件体系结构的生命周期模型
软件体系结构的非形式化描述,软件体系结构的规范描述和分析,软件体系结构的求精及其验证,软件体系结构的实施,软件体系结构的演化和拓展,软件体系结构的提供、评价和度量,软件体系结构的终结
容器
容器是指一个在其内部可以执行构件或驻留数据的东西。它可以是从网络或应用服务器直到富客户端应用或数据库的任何东西。容器通常是可执行文件,但未必是各自独立的流程。
C4模型
在面向对象的系统中,通常系统由多个容器组成,容器由多个构件组成,构件由多个类组成
第3章软件体系结构风格。
软件架构风格的定义
诸风格的特征
◎数据流风格:批处理序列;管道/过滤器。
管道与过滤器风格的软件体系结构的特点
(1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;(2)允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;(3)支持软件重用。(4)系统维护和增强系统性能简单。(5)允许对一些如吞吐量、死锁等属性的分析;(6)支持并行执行。但是,这样的系统也存在着若干不利因素。
(1)通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据,但它们是独立的,所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
(2)不适合处理交互的应用。当需要增量地显示改变时,这个问题尤为严重。
(3)因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性。
◎调用/返回风格:主程序/子程序;面向对象风格;层次结构。
面向对象的优点
能形象地表现现实世界的领域,重用性高,对应变化很强。即易扩展,维护性强
数据抽象和面向对象组织缺点
性能损失。面向对象编程为了:重用性、灵活性和扩展性等特性而作出的牺牲。测试比较麻烦,对整体系统设计要求高
◎独立构件风格:进程通讯;事件系统。
基于事件的隐式调用优点:
为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中。为改进系统带来了方便。当用一个构件代替另一个构件时,不会影响到其它构件的接口。
基于事件的隐式调用缺点:
构件放弃了对系统计算的控制。数据交换的问题。有时数据可被一个事件传递,但
有时系统必须依靠一个共享的仓库进行交互。这时全局性能和资源管理便成了问题。
既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。
分层系统优点:
支持基于抽象程度递增的系统设计,使设计者可以把一个复杂系统按递增的步骤进行分解;
支持功能增强,因为每一层至多和相邻的上下层交互,因此功能的改变最多影响相邻的上下层;支持重用。只要提供的服务接口定义不变,同一层的不同实现可以交换使用。这样,就可以定义一组标准的接口,而允许各种不同的实现