绪论 哈尔滨工业大学计算机学院 唐好选 Email:tanghx@hit.edu.cn.

Presentation on theme: "绪论 哈尔滨工业大学计算机学院 唐好选 Email:tanghx@hit.edu.cn."— Presentation transcript:

1 绪论 哈尔滨工业大学计算机学院 唐好选

2 主要内容 先谈软件危机 软件工程、软件体系结构、软件设计模式的概念及其相互之间的关系 软构件与面向服务的思想

3 软件危机 “软件危机”于1968年首次提出，“软件工程”概念也由 此产生 软件危机是指计算机软件开发和维护过程中所遇到的一系 列严重问题。
“软件危机”于1968年首次提出，“软件工程”概念也由 此产生 软件危机是指计算机软件开发和维护过程中所遇到的一系 列严重问题。 (1) 能否满足对软件日益增长的需求？ (2) 能否维护数量日益增长的现有软件？ 云计算会带来更加严重的软件危机

4 软件危机的具体表现 （1）对软件开发成本和进度的估计常常不准确（成本估计不足，拖延工期）
（2）用户对“已完成”的软件系统不满意的现象经常发生（用户需求了解不清，闭门造车，导致不符合要求） （3）软件产品的质量往往靠不住（没有严格执行质保技术） （4）软件常常不可维护，不能适应新环境，程序错误不容易纠正 （5）软件成本占总成本的比例逐年上升 （6）软件开发速度跟不上计算机应用普及深入的趋势

5 软件危机的原因 （1）软件是逻辑部件：研发阶段难衡量；开发质量较难评价，开发过程管理和控制较难；运行过程才能暴露没有检测出来的事故，相当于修改设计，软件维护困难 （2）软件规模庞大，有技术问题，也有管理方法问题 （3）早期开发的个体化；忽视需求分析；认为软件开发就是写程序；轻视维护；对用户不了解 （4）对软件开发前期工作忽视，未做好软件定义时期的工作 （5）忽视了软件维护阶段极端艰巨复杂的工作，维护通常占总代价的55%-70%

6 软件危机的原因（另一种解释） 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 just add staff and will be able to catch up easily but how much effort will you spend in getting your new staff up to speed?

7 软件危机的原因（另一种解释） Customer myths
–A general statement of objectives is sufficient to start programming –Project requirements continually change, but change can easily be accommodated since software is so flexible and easy to change

8 软件危机的原因（另一种解释） Practitioner's 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

9 软件危机的本质难题 软件工程不能解决软件危机，“没有任何一项技术或方法 可以让软件工程的生产力在十年内提高十倍”、“复杂的 软件工程问题无法靠简单的答案来解决” 软件危机的本质难题 软件体系结构（或连接关系）越来越复杂 软件程序代码数量越多，隐藏BUG越多

10 解决软件危机的可能 FO（Fact-Oriented）方法 软件复杂度可以通过软件体系结构来描述，任何体系 结构都是可以通过维来构建的
软件复杂度可以通过软件体系结构来描述，任何体系 结构都是可以通过维来构建的 任何一个复杂的用户需求都是可分解的，把不能再分 解的构成部分叫“对象” 任何一个对象必须包含两个部分，即对象的外部属性 和对象的内部属性 对象的连接方式即结构，就是用户需求的体系结构

11 软件=功能模块+表现程序+连接方式(体系结构)
解决软件危机的可能 FO方法的组成 FOA (Fact-Oriented Analysis) ：即面向事实的分析，把客户需求当成存在的事实 FOD (Frame-Oriented Design)：面向结构的设计，把分析过程中得到对象的连接形式整理出来，并采用维的方式表述，得到软件的体系结构 FOP (Form-Oriented Programming)：面向形式的编程，对形式部分编写程序代码，得到无具体含义的功能模块。将模块和配置(描述参数)结合，可得到一个对象 软件=功能模块+表现程序+连接方式(体系结构)

12 思考 你对软件危机的表现和原因的见解 你身边软件项目的完成及评估情况

13 我们的目标 解决软件危机 告诉人们如何设计软件、开发软件、管理软件 软件工程方法/软件体系结构/软件设计模式 的合理应用
软件工程方法/软件体系结构/软件设计模式 的合理应用 提高软件产品的质量! 降低软件开发的成本!

14 主要内容 先谈软件危机 软件工程、软件体系结构、软件设计模式的概念及其相互之间的关系 软构件与面向服务的思想

15 软件工程的基本概念 软件工程是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中
软件工程主要强调软件开发过程各个阶段的方法论

16 软件工程的三要素 开发过程 开发方法 开发工具

17 典型的开发模型 1.Build-and-Fix Model 2.Warer-fall Model
3.Rapid Prototype Model 4.Incremental Model 5.Spiral Model 6.Intelligent Model 7.Hybrid Model

18 软件工程的局限性 软件工程充满了“方法论”的内容 如何分析、如何设计、如何编程、如何测试、如何维护、……
软件模型与软件系统的质量在很大程度上依赖于开发者本身的经验和水平 因为缺乏对软件开发过程的理论层面的刻画，没有将大量的方法论总结并提升为理论，故而只能是“工程”

19 从工程提升到理论

20 研究软件体系结构的目的 弥补软件开发领域“工程上有余而理论上不足”的缺陷
借助于计算机科学中其他领域的理论研究方法，试图用模型分析与理论推理的方法解决软件研发过程中涉及到的各类功能与非功能性问题 将软件工程上总结出来的各类方法论提升为模型与理论，进而用这些理论来指导软件的开发

21 软件体系结构的定义 软件体系结构(Software Architecture, SA) – 提供了一个结构、行为和属性的高级抽象
– 从较高层次来考虑组成系统的构件、构件之间的连接，以及由构件与构件交互形成的拓扑结构 – 这些要素应该满足一定限制，遵循一定设计规则，能够在一定环境下进行演化

22 软件体系结构的组成 – 构件：基本软件构造模块(对象、模式等) – 连接件：将它们组合起来形成完整的软件系统 – 物理分布（拓扑结构）
– 约束 – 性能

23 关于软件体系结构的看法 程序员说，SA是要决定需要编写哪些类、使用哪些现成框架 程序经理说，SA是模块的划分和接口的定义

24 SA研究要回答的基本问题 软件的基本构造单元是什么？ 这些构造单元之间如何连接？ 最终形成何种样式的拓扑结构？
每个典型应用领域(例如CAD、ERP)的典型体系结构是什么样子？ 如何进行软件体系结构的设计与实现？ 如果对已经存在的软件体系结构进行修改？ 使用何种工具来支持软件体系结构的设计？ 如何对软件的体系结构进行描述，并据此进行分析和验证？

25 SA在软件生命周期中的位置

26 SA的演化 无体系结构阶段 萌芽阶段 初期阶段 高级阶段 以汇编语言进行小规模程序开发为特征 以控制流图和数据流图为特征
出现了从不同侧面描述系统的结构模型，以UML为典型代表 初期阶段 以描述系统的高层抽象结构为中心，不关心具体建模细节，以“4+1”模型为标志 高级阶段

27 实现 视图 逻辑 视图 用况视图 过程 视图 实施 视图
程序员 与实现有关的部分. 如源代码、库、对象的类等.是事物的静态视图 描述系统的功能性需求，描述系统为最终用户做什么，是设计模型的抽象 设计人员/测试人行为 实现 视图 逻辑 视图 用况视图 描述系统在运行时的并发性-任务、线程、过程以及它们之间的交互作用，针对系统集成人员 系统工程师 系统的拓扑结构、交付、安装、通信. 注重事实和系统必须服从的约束. 过程 视图 实施 视图 SA的4+1视图模型

28 SA的演化 系统 = 算法 + 数据结构 （60年代） 系统 = 子程序 + 子程序 （70年代） 系统 = 对象 + 对象 （80年代）
系统 = 算法 数据结构 （60年代） 系统 = 子程序 + 子程序 （70年代） 系统 = 对象 对象 （80年代） 系统 = 构件 连接件 （90年代） 系统 = 服务 服务总线 （21世纪）

29 SA的演化史

30 经典的软件体系结构风格

31 体系结构例：Android的分层体系结构

32 引入设计模式 显示区 装修设计问题：使用软件方法可以设计并展现不同风格的布局效果 1、如何使客户端程序依赖少量的或者单一的对象
立柜 壁柜 台面 菜单 显示区 现代型 古典型 工艺型 古董型 风格 1、如何使客户端程序依赖少量的或者单一的对象 2、如何保证增加风格时（或风格变化时）不影响原有代码？

33 设计模式的概念 设计模式是类的联合体以及与之相伴的算法，这些算法能够实现共同的设计目标
设计模式表达了一种思想而不仅仅是固定的类联合体，相伴的算法表示模式的基本操作

34 设计模式分类 按类型划分，软件设计模式可划分为 创建型模式：如何创建一个对象，一般是通过子类继承（或者接口实现）的方式来生成新的类
结构型模式：利用现有的类来生成新的类，一般通过类的组合来生成新类 行为型模式：类之间的协作，将一个动作分解到不同的类，强调类之间的协作

35 设计模式、体系结构、框架 框架（Framework）是整个或部分系统的可重用设计，具体表现为一组抽象构件及构件实例间交互的方法
构件是代码重用，而设计模式是设计重用，框架介于两者之间，部分代码重用，部分设计重用 设计模式比框架更为抽象，设计模式在碰到具体问题后才能产生代码；框架已经可以用代码表示 设计模式是比框架更小的体系结构元素，框架中可以包含多个设计模式

36 框架（Framework）与结构（Architecture）
框架是可实例化的、部分完成的软件系统或子系统，它为一组系统或子系统定义了统一的体系结构，并提供了系统的基本构造块，还为实现具体功能定义了扩展点 框架实现了体系结构级别的复用

37 框架（Framework）与模式（Pattern）
从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案 从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不同方式来实现；而框架则是设计和代码的混合体 设计模式比框架更容易移植：框架一旦设计成形，以其为基础进行应用的开发就要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用 总之，框架是软件，而设计模式是软件的知识体，设计模式的合理利用可以提升框架的设计水平

38 主要内容 先谈软件危机 软件工程、软件体系架构、软件设计模式的概念及其相互之间的关系 软构件与面向服务的思想

39 软构件与面向服务的思想 软件系统及其开发方法面临着如下的变化趋势 重复软件越来越多
技术让位于业务：实现技术变得越来越次要，对业务需求的理解变得越来越困难 封闭向开放转移：系统规模变大，复杂性变高，从组织内部转移到企业之间，乃至全球化环境中 内部功能让位于协同：开发一个封闭的功能很容易，难的是多组织之间协同性功能的开发 按需应变：软件系统越来越要求快速、容易变化 传统的软件开发方法/技术越来越力不从心

40 软构件与面向服务的思想 新的要求 构成软件的基本组件或体系结构大量复用，可以缩短软件开发周期（软构件技术）
服务无处不在，服务资源共享，可以更进一步促进协同性功能的开发（面向服务） 按需快速应变： 软件的产出依靠组装 而不是 开发 这才是当前及未来软件的发展趋势

41 SOA基本模型

42 云计算架构

43 云计算的发展 云计算发展 云计算的驱动力 业务需求的拉动，希望解决资源利用率、计算能力不足和成本的问题
技术发展的推动，软件技术发展推动了IT创新的商业价值 技术与产业发展推动 业务需求拉动 云计算发展

44 从应用的角度理解云 用户的公共性 设备的多样性 简化和标准的服务接口 按需计费的商业模式 商业模式的服务性 公有云 私有云 提供方式的灵活性

45 从技术的角度理解云 云计算是多种现有技术的融合体！ 使用方式 云计算 融合 集群计算 技术基础 分区计算 基础设施 软件即服务 SaaS
Cloud Computing 网格计算 Grid Computing 技术基础 融合 集群计算 Cluster Computing 多台虚拟为一台：提高计算能力 虚拟化 Virtualization 基础设施 分区计算 Partition Computing 一台虚拟为多台：提高资源利用率 云计算是多种现有技术的融合体！

46 从产业的角度理解云

47 The End！