《第01讲-软件体系结构绪论解析》由会员分享，可在线阅读，更多相关《第01讲-软件体系结构绪论解析（48页珍藏版）》请在金锄头文库上搜索。
1、哈尔滨工业大学计算机学院 唐好选 Email:,绪论,先谈软件危机 软件工程、软件体系结构、软件设计模式的概念及其相互之间的关系 软构件与面向服务的思想,主要内容,软件危机,“软件危机”于1968年首次提出，“软件工程”概念也由此产生 软件危机是指计算机软件开发和维护过程中所遇到的一系列严重问题。(1) 能否满足对软件日益增长的需求？(2) 能否维护数量日益增长的现有软件？ 云计算会带来更加严重的软件危机,软件危机的具体表现,（1）对软件开发成本和进度的估计常常不准确（成本估计不足，拖延工期） （2）用户对“已完成”的软件系统不满意的现象经常发生（用户需求了解不清，闭门造车，导致不符合要求）
2、（3）软件产品的质量往往靠不住（没有严格执行质保技术） （4）软件常常不可维护，不能适应新环境，程序错误不容易纠正 （5）软件成本占总成本的比例逐年上升 （6）软件开发速度跟不上计算机应用普及深入的趋势,软件危机的原因,（1）软件是逻辑部件：研发阶段难衡量；开发质量较难评价，开发过程管理和控制较难；运行过程才能暴露没有检测出来的事故，相当于修改设计，软件维护困难 （2）软件规模庞大，有技术问题，也有管理方法问题 （3）早期开发的个体化；忽视需求分析；认为软件开发就是写程序；轻视维护；对用户不了解 （4）对软件开发前期工作忽视，未做好软件定义时期的工作 （5）忽视了软件维护阶段极端艰巨复杂的工作
3、，维护通常占总代价的55%-70%,软件危机的原因（另一种解释）,Management myths (when projects go awry) We already have books and standards, that give the programmers all they need to know My people to have state-of-the-art development tools, after all, we buy the always the latest computer hardware If we get behind schedule, we
4、 just add staff and will be able to catch up easilybut how much effort will you spend in getting your new staff up to speed?,Customer myths A general statement of objectives is sufficient to start programming Project requirements continually change, but change can easily be accommodated since softwa
5、re is so flexible and easy to change,软件危机的原因（另一种解释）,Practitioners myths Once we write the program and get it to work, our job is done Until I get the program running, I have no way of assessing and assuring its quality The only deliverable for a successful project is the working program,软件危机的原因（另一种解
6、释）,软件工程不能解决软件危机，“没有任何一项技术或方法可以让软件工程的生产力在十年内提高十倍”、“复杂的软件工程问题无法靠简单的答案来解决” 软件危机的本质难题 软件体系结构（或连接关系）越来越复杂 软件程序代码数量越多，隐藏BUG越多,软件危机的本质难题,FO（Fact-Oriented）方法 软件复杂度可以通过软件体系结构来描述，任何体系结构都是可以通过维来构建的 任何一个复杂的用户需求都是可分解的，把不能再分解的构成部分叫“对象” 任何一个对象必须包含两个部分，即对象的外部属性和对象的内部属性 对象的连接方式即结构，就是用户需求的体系结构,解决软件危机的可能,FO方法的组成 FOA (
7、Fact-Oriented Analysis) ：即面向事实的分析，把客户需求当成存在的事实 FOD (Frame-Oriented Design)：面向结构的设计，把分析过程中得到对象的连接形式整理出来，并采用维的方式表述，得到软件的体系结构 FOP (Form-Oriented Programming)：面向形式的编程，对形式部分编写程序代码，得到无具体含义的功能模块。将模块和配置(描述参数)结合，可得到一个对象,解决软件危机的可能,软件=功能模块+表现程序+连接方式(体系结构),思考,你对软件危机的表现和原因的见解你身边软件项目的完成及评估情况,解决软件危机 告诉人们如何设计软件、开发软
8、件、管理软件 软件工程方法/软件体系结构/软件设计模式 的合理应用,我们的目标,提高软件产品的质量! 降低软件开发的成本!,先谈软件危机 软件工程、软件体系结构、软件设计模式的概念及其相互之间的关系 软构件与面向服务的思想,主要内容,软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中 软件工程主要强调软件开发过程各个阶段的方法论,软件工程的基本概念,软件工程的三要素,1.Build-and-Fix Model,典型的开发模型,2.Warer-fall Model,3.Rapid Prototype Model,4.Incremental Mod
9、el,5.Spiral Model,6.Intelligent Model,7.Hybrid Model,软件工程的局限性,软件工程充满了“方法论”的内容 如何分析、如何设计、如何编程、如何测试、如何维护、 软件模型与软件系统的质量在很大程度上依赖于开发者本身的经验和水平 因为缺乏对软件开发过程的理论层面的刻画，没有将大量的方法论总结并提升为理论，故而只能是“工程”,从工程提升到理论,研究软件体系结构的目的,弥补软件开发领域“工程上有余而理论上不足”的缺陷 借助于计算机科学中其他领域的理论研究方法，试图用模型分析与理论推理的方法解决软件研发过程中涉及到的各类功能与非功能性问题 将软件工程上总结
10、出来的各类方法论提升为模型与理论，进而用这些理论来指导软件的开发,软件体系结构的产生,随着软件系统规模越来越大、越来越复杂，对系统整体结构和规格的说明显得越来越重要 对于大规模的复杂软件系统来说，系统结构的设计和规格说明比算法和数据结构的选择更重要 对软件体系结构的系统、深入的研究将会成为解决软件危机最有希望的途径,软件体系结构的定义,软件体系结构(Software Architecture, SA) 提供了一个结构、行为和属性的高级抽象 从较高层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构 这些要素应该满足一定限制，遵循一定设计规则，能够在一定环境下进行演化,软
11、件体系结构的组成, 构件：基本软件构造模块(对象、模式等) 连接件：将它们组合起来形成完整的软件系统 物理分布（拓扑结构） 约束 性能,程序员说，SA是要决定需要编写哪些类、使用哪些现成框架 程序经理说，SA是模块的划分和接口的定义 分析员说，SA是为业务领域对象的关系建模 配置管理员说，SA是开发以及编译后软件的基本结构 数据库工程师说，SA规定了持久化数据的结构，其他一切都不过是对数据的操作而已 部署工程师说，SA规定了软件部署到硬件的策略 用户说，SA是决定一个个功能子系统如何划分,关于软件体系结构的看法,软件体系结构研究要回答的基本问题,软件的基本构造单元是什么？ 这些构造单元之间如何
12、连接？ 最终形成何种样式的拓扑结构？ 每个典型应用领域(例如CAD、ERP)的典型体系结构是什么样子？ 如何进行软件体系结构的设计与实现？ 如果对已经存在的软件体系结构进行修改？ 使用何种工具来支持软件体系结构的设计？ 如何对软件的体系结构进行描述，并据此进行分析和验证？,SA在软件生命周期中的位置,SA在系统开发的全过程中起中心作用；是设计/开发的起点和依据；是配置、运行和维护的指南,软件体系结构的演化,无体系结构阶段,萌芽阶段,初期阶段,高级阶段,以汇编语言进行小规模程序开发为特征,以控制流图和数据流图为特征,出现了从不同侧面描述系统的结构模型，以UML为典型代表,以描述系统的高层抽象结构
13、为中心，不关心具体建模细节，以“4+1”模型为标志,软件体系结构的4+1视图模型,逻辑 视图,过程视图,开发 视图,物理视图,用况视图,描述系统的功能性需求，描述系统为最终用户做什么，是设计模型的抽象,程序员 与实现有关的部分. 如源代码、库、对象的类等.是事物的静态视图,系统工程师 系统的拓扑结构、交付、安装、通信. 注重事实和系统必须服从的约束.,描述系统在运行时的并发性-任务、线程、过程以及它们之间的交互作用，针对系统集成人员,设计人员/测试人行为,软件体系结构的演化,系统 = 算法 + 数据结构 （60年代） 系统 = 子程序 + 子程序 （70年代） 系统 = 对象 + 对象 （80
14、年代） 系统 = 构件 + 连接件 （90年代） 系统 = 服务 + 服务总线 （21世纪）,软件体系结构的演化史,功能函数,面向过程的分析和设计,基于构件的软件开发,面向对象的分析与设计,面向服务的计算 面向服务的体系结构,经典的软件体系结构风格,体系结构例：Android的分层体系结构,引入设计模式,装修设计问题：使用软件方法可以设计并展现不同风格的布局效果,1、如何使客户端程序依赖少量的或者单一的对象 2、如何保证增加风格时（或风格变化时）不影响原有代码？,设计模式的概念,设计模式是类的联合体以及与之相伴的算法，这些算法能够实现共同的设计目标 设计模式表达了一种思想而不仅仅是固定的类联合
15、体，相伴的算法表示模式的基本操作,设计模式分类,按类型划分，软件设计模式可划分为 创建型模式：如何创建一个对象，一般是通过子类继承（或者接口实现）的方式来生成新的类 结构型模式：利用现有的类来生成新的类，一般通过类的组合来生成新类 行为型模式：类之间的协作，将一个动作分解到不同的类，强调类之间的协作,设计模式、体系结构、框架,框架（Framework）是整个或部分系统的可重用设计，具体表现为一组抽象构件及构件实例间交互的方法 构件是代码重用，而设计模式是设计重用，框架介于两者之间，部分代码重用，部分设计重用 设计模式比框架更为抽象，设计模式在碰到具体问题后才能产生代码；框架已经可以用代码表示
16、设计模式是比框架更小的体系结构元素，框架中可以包含多个设计模式,框架（Framework）与结构（Architecture）,框架是可实例化的、部分完成的软件系统或子系统，它为一组系统或子系统定义了统一的体系结构，并提供了系统的基本构造块，还为实现具体功能定义了扩展点 框架实现了体系结构级别的复用,框架（Framework）与模式（Pattern）,从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案 从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不同方式来实现；而框架则是设计和代码的混合体 设计模式比框架更容易移植：框架一旦设计成形，以其为基础进行应用的开发就要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用 总之，框架是软件，而设计模式是软件的知识体，设计模式的合理利用可以提升框架的设计水平,先谈软件危机 软件工程、软件体系架构、软件设计模式的概念及其相互之间的关系 软构件与面向服务的思想,
