《精编》软件详细设计专题讲座

上传人:tang****xu1 文档编号:133357693 上传时间:2020-05-26 格式:PPT 页数:74 大小:6.95MB
返回 下载 相关 举报
《精编》软件详细设计专题讲座_第1页
第1页 / 共74页
《精编》软件详细设计专题讲座_第2页
第2页 / 共74页
《精编》软件详细设计专题讲座_第3页
第3页 / 共74页
《精编》软件详细设计专题讲座_第4页
第4页 / 共74页
《精编》软件详细设计专题讲座_第5页
第5页 / 共74页
点击查看更多>>
资源描述

《《精编》软件详细设计专题讲座》由会员分享,可在线阅读,更多相关《《精编》软件详细设计专题讲座(74页珍藏版)》请在金锄头文库上搜索。

1、 软件详细设计讲座 主讲人 内容 第二部分 软件设计 第一部分 软件架构 第一部分软件架构 内容 需求 架构 设计关系 软件架构定义 什么是架构 如果你问五个不同的人 可能会得到五种不同的答案 很多人都试图给 架构 下定义 而这些定义本身却很难统一 软件架构是一种无法以简单的一维方式进行说明的复杂实体 软件架构 softwarearchitecture 是一系列相关的架构视图 用于指导大型软件系统各个方面的设计 多重软件架构视图之所以必不可少 是因为各类型人员 用户 开发人员 测试人员 维护人员 操作人员 需要从各自的角度理解和使用架构 软件架构的实际意义 做正确的架构正确的表达架构让别人能遵

2、守架构 软件架构视图 单一的视图无法完整的表达架构 因此需要具备完整的视图集 软件架构视图是从特定的视角出发 专注于该视角系统的结构 模块划分 基本组件职责和主要控制流 软件架构视图的四要素 图示化主要元素和元素之间的关系 具有明确的图例 定义和说明元素 每个元素具备明确的接口和行为规范 设计的原理和设计决策信息 常见软件架构视图 逻辑视图开发视图部署视图进程视图场景视图数据视图实现视图 4 1 模式 逻辑视图 开发视图 进程视图 部署视图 场景视图 逻辑视图 面向对象 客户 用户 开发组织管理者 视角 系统的功能元素 以及它们的接口 职责 交互等 主要元素 系统 子系统 功能模块 子功能模块

3、 接口用途 开发组织划分 成本 进度评估 逻辑视图样例一 系统框架图 逻辑视图样例二 软件结构图 逻辑视图样例三 前置子系统结构图 逻辑视图样例四 监控子系统结构图 逻辑视图样例五 防误子系统结构图 开发视图 面向对象 开发相关人员 测试人员视角 系统如何开发实现主要元素 描述系统的层 分区 包 框架 系统通用服务 业务通用服务 类和接口 系统平台和相关基础框架用途 指导开发设计和开发实现 开发视图样例一 开发视图样例二 对象请求代理ORB 开发视图样例三 复制数据库技术架构 开发视图样例四 进程和服务管理 开发视图样例五 数据库专用平台 开发视图样例六 前置子模块间关系 部署视图 也称物理视

4、图面向对象 系统集成商 系统运维人员视角 系统逻辑组件到物理节点的物理部署 节点之间的物理网络配置主要元素 物理节点以及节点的通讯用途 指导系统采购以及网络 节点布局 部署视图样例一 部署视图样例二 部署视图样例三 部署视图样例四 进程视图 面向对象 性能优化 开发相关人员视角 系统运行时线程 进程的情况主要元素 系统进程 线程以及处理队列等用途 指导系统进程 线程分布 进程视图样例 场景视图 也称用例视图面向对象 设计和开发人员视角 囊括了架构上最重要的场景 最典型或最有风险 及其非功能性需求 通过这些场景的实现 阐明了架构的广度或众多架构元素的运行方式 场景视图样例一 场景视图样例二 数据

5、视图 面向对象 数据架构师 开发相关人员视角 系统数据模型以及数据存储 存取方式主要元素 系统的核心实体模型以及相应的数据存储模型和存储方式系统的数据存储相关策略系统核心的数据流 数据视图样例一 数据视图样例二 RAC模式 数据视图样例三 HA模式 数据视图样例四 DataGuard模式 总结 架构设计以多视图的模式呈现多视图的目的是为了指导不同的团队思维和实现多视图是分而治之的多视图可以并行多视图可以组合 第二部分软件设计 内容 内容 软件设计金字塔软件设计的价值观优秀设计遵循的原则破窗效应和技术债务代码的坏味道重构技术 设计金字塔 关注软件维护成本 软件系统维护工作量所占比重超乎想象 CO

6、ST total COST develop COST maintain COST maintain Cost understand 理解 Cost change 变更 Cost test 测试 Cost depoly 现场部署 什么是好的设计 关注软件的可维护性和可复用性区分功能需求和非功能需求一个好的设计应该有如下性质 可扩展性 灵活性 可插入性可扩展性 新的功能可以很容易的加入到系统中灵活性 可以容许代码修改平稳 而不会波及到很多其他模块可插入性 可以很容易的将一个类抽出去 同时将另一个有同样接口的类加入进来 软件的可维护性 大家有没有注意到 原来我们自认为是很漂亮的设计随着时间的推移慢慢

7、 发出腐化的臭味 代码也会慢慢变成由一堆纠缠不清的函数和变量搅和在一起的 代码浆糊 为什么 是什么原因导致的呢 都是客户和老板的错 客户不断的改变需求 如果用户的要求仅限于他们最初所声明的 我们的设计就没有问题 错就错在用户改变了他们的需求 老板没有给我们充足的时间 进行充分的分析 使我们没有时间设计出一个完美的结构 软件的变更 软件是应该不断变更的 我们认为 真实世界中使用的程序必须进行变更 否则它在环境中的作用就会原来越小 软件复杂增加性法则 随着一个不断演进程序的变更 他的结构会变得越来越复杂 软件是应该不断变更的 因为需求是不断变更的 难道变化的需求一定会导致系统 腐烂 吗 为什么一个

8、系统的设计不可以为以后的变化留出足够的空间 如何实现一个优秀的设计 优秀设计原则 优秀设计第一法则 开闭原则优秀设计第二法则 重构 开闭原则 开放 封闭原则 OCP 软件的组成实体 类 模块 函数等等 应该是可以扩展的 但是是不可修改的 即软件实体可以通过增加新代码实现扩展 但是不能修改已有代码 任何一个系统在其生命周期内都会发生变化 如果我们希望开发出的系统不会在第一版本后就被抛弃 我们就必须牢记这一点 发现变化并将其封装 优秀设计精髓就是封装变化 就是将变化进行抽象 封装变化 这样才能保证软件的可扩展性以及模块间的松耦合 一种可变性不应当散落在代码的很多角落里 而应当被封装到一个对象里 一

9、种可变性不应当与另一种可变性混合在一起 共性和可变性分析 CVA 找到变化的地点 称为 共性分析 然后找出如何变化 称为 变性分析 CVA分析步骤先寻找共性 从这些共性创建抽象 从共性的变化派生可变性实现 看共性与其他共性之间的关系如何 CVA样例 主板和插槽 开闭原则的代价 100 开闭原则的代价 遵循开闭原则代价昂贵 正确的抽象 寻找共性并抽象 需要时间和精力 需求的不可预测性 给抽象增加了复杂度 对于应用程序中的每个部分都肆意的进行抽象同样不是一个好主意 应该对程序中呈现频繁变化的那些部分进行抽象 拒绝不成熟的抽象和抽象本身一样重要 亡羊补牢 重构 面对需求的不可预测性 设计师根据经验猜

10、测程序可能遭受的变化 如果猜测正确 获得成功 猜测错误 遭受失败 随着需求的不断变化 软件的不断变更 设计腐化 和 代码浆糊 的现象慢慢呈现出来 为了解决这个问题 我们需要应用优秀设计的第二法则 优秀设计需要不断重构 重构到优秀设计 拙劣设计的影响 如果设计已经出现腐化 代码浆糊已经开始产生 我们最初的设计已经成为拙劣的设计了 我们不去重构的话 将会产生 破窗效应 和 技术债务 问题 破窗效应 破窗理论 破窗效应 BreakPaneLaw 没修复的破窗 导致更多的窗户被打破 破窗效应 破窗效应 没修复的破窗 导致更多的窗户被打破所谓 破窗效应 是关于环境对人们心理造成暗示性或诱导性影响的一种认

11、识 破窗效应 理论是指 一个房子如果窗户破了 没有人去修补 隔不久 其它的窗户也会莫名其妙的被人打破 一面墙 如果出现一些涂鸦没有清洗掉 很快的 墙上就布满了乱七八糟 不堪入目的东西 一个很干净的地方 人们会不好意思丢垃圾 但是一旦地上有垃圾出现之后 人们就会毫不犹疑的拋 丝毫不觉羞愧 这真是很奇怪的现象 技术债务 出来混 迟早要还的 技术债务 TechnicalDebt 开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案 但从长远来看 这种方案会带来更消极的影响 亦即开发团队所欠的债务技术债务类似于金融债务 它也会产生利息 这里的利息其实就是指由于鲁莽的设计决策导致需要在未来

12、的开发中付出更多努力的后果 我们可以选择继续支付利息 也可以通过重构之前鲁莽的设计来将本金一次付清 虽然一次性付清本金需要代价 但却可以降低未来的利息 技术债务 技术债务的种类无意的 由于经验的缺乏导致初级开发者编写了质量低劣的代码 有意的 团队根据当前而非未来进行设计选型 这种方式可能很快就能解决当前的问题 但却很拙劣 技术债务 很多敏捷团队都能认识到技术债务相关的罪状 就跟财务上的负债一样 技术债务也会产生利息 要支付这些利息 就要付出额外努力维护和改进正在 腐化 或基础并不牢固的软件 诸多敏捷人士推荐尽早偿还技术债务 然而 大多数敏捷团队无法成功以金钱的方式计算技术债务 因此无法得到有价

13、值的深入理解和思考 技术债务 代码的坏味道 产生破窗效应和技术债务的一个原因就是代码产生了坏味道 代码坏味道是指在代码之中潜在问题的警示信号 并非所有的坏味道所指示的确实是问题 但大部分坏味道需要加以详细查看 并做出相应决定 代码坏味道是需要重构的症状 或者是潜在的问题 或者是缺陷 代码的坏味道重点在代码层次 与拙劣的设计相比是低的层次 伟大程序员的标准 避免坏味道 我不是什么伟大的程序员 我只是一个有着很多好习惯的程序员 任何一个傻瓜都能写出机器能读懂的代码 好的程序员应该写出人能懂的代码 我们不是要告诉别人什么才是好的程序的标准 而应该告诉别人不应该出现的错误 22种常见的代码的坏味道 重

14、复代码过长函数过大类过长参数列发散式变化散弹式修改依恋情结 22种常见的代码的坏味道 数据泥团基本类型迷恋分支语句 switch 平等继承体系冗赘类夸夸其谈未来性令人迷惑的暂时值域 22种常见的代码的坏味道 过度耦合的消息链中间转手人狎昵关系异曲同工的类不完美的程序库类纯粹的数据类被拒绝的遗赠过多的注释 代码静态分析 代码静态分析工具是一种软件 可以利用它对程序的源代码进行分析 自动测试应用系统的很多方面 在软件测试中 静态分析工具并不执行所测试的程序 只是扫描所测试程序的正文 对程序的源代码进行分析 它类似于编译程序中的词法分析和语法分析 但工作量远不止于此 使用代码静态分析工具可以发现一些

15、代码坏味道 但不会解决代码的坏味道 坏味道的解决之道 重构 代码的坏味道 设计师必知代码坏味道 坏味道的名称症状 有助于找出问题的线索原因 对问题如何会发生的说明采取的措施 可能的重构收益 在那些方面有所改善不适应情况 在哪些情况下不适用 重构的定义 名词定义 对软件内部结构的一种调整 目的是在不改变功能的前提下 提高其可理解性 降低其修改成本 动词定义 使用一系列重构准则 在不改变软件功能的前提下 调整其结构 重构的3次法则 事不过三 第一次做某事时尽管去做 第二次做类似的事情时会产生反感 但无论如何还是做了 第三次再做类似的事 你就应该重构 坏味道与重构 重复代码 在一个以上的地方看到相同

16、的程序结构同一个class内的两个函数含有相同表达式两个互为兄弟的subclass内含有相同的表达式一般重构方法 提炼方法 提取类 方法上移 替换算法 链构造方法 坏味道与重构 发散式变化 软件应该能够更容易的被修改 一旦需要修改 我们希望能够集中到系统的某一点 只在此处做修改 散弹式修改 如果每遇到某种变化 你必须在许多不同的class内作出许多小修改以响应之 即需要修改的代码四处散布 不但很难找到 而且容易遗漏 一般重构方法 提取类 转移方法 转移字段 坏味道与重构 过多的注释 代码中常常看到一段很长的注释 然后发现 这些注释存在的原因是因为代码很糟糕 加入注释的目的是让大家能够知道我的代码是干什么的 如果我们找到这些代码的坏味道 并使用重构的方法把坏味道清除掉 就会发现注释已经变得多余了 坏味道与重构 不同的坏味道 其重构方法方法不尽相同 坏味道还可以使用模式的方法进行重构 在此我们不做具体说明 总结 我们应该了解设计的金字塔 我们应该明确自己设计的价值观 是注重可维护性还是更注重性能 维护成本的计算 我们应该知道优秀设计的原则 我们应该知道怎样才是一个好的程序员 我们应该知道破

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号