目录软件生命周期与软件架构介绍2软件架构风格75uml与面向对象程序设计145uml建模与分析248.pptVIP

目录 软件生命周期与软件架构介绍 2 软件架构风格 75 UML与面向对象程序设计 145 UML建模与分析 248 技术架构视图-设计原则与模式 487 软件系统坏死的症状 558 liskov替换原则（LSP） 560 接口隔离原则（ISP） 591 依赖倒置原则（DIP） 601 设计模式 658 策略（Strategy）模式 715 桥接（Bridge）模式 769 命令（command）模式 782 其它设计模式 816 软件架构辨析 市场体系结构 软件架构 MS e-Gov Architecture Framework MS Application Reference Architecture 市场体系结构的特点 面向客户而非面向软件开发者。 对于商业产品的特色宣传非常有效，但对开发者远远不够。 市场体系结构与开发流程脱节。 软件构架的特点 好的软件构架满足它们的需求，并富有弹性和基于构件。 一个富有弹性的软件构架能够： 改进可维护性和可扩展性 实现经济性显著的可重用度 将开发团队成员间的工作清楚地分割开 封装对硬件和系统的依赖 为什么需要软件构架 最终开发出的目标系统总是由多个组成部分所构成，这种结构如果没有预先定义，很难保证系统的构建过程能自发创建出一个一致而满足需求的交付。 当前的软件规模已大到需要采用团队开发的模式，多个开发人员的分工协作，必然依赖于一种对开发内容的合适划分，以减少相互干扰、缩短工期的关键路径，从而提高开发效率、加快项目进度－－软件构架无疑是其中最关键的一类划分，它将被用来计划、管理与执行系统开发的各项活动。 模块/构件化 为什么需要软件构架 目标系统总是要面临各种变数，项目组期望系统在发生变更、部署到新环境中时，仍然保持既有的稳定、可靠和性能——目标系统应具备一种健壮性。 系统的构建要经历一个不断增添新功能、加入新行为的过程，项目组期望做得比较容易、开销较低，且在此过程中不存在重大的风险——目标系统应具备一种可扩展。 这些质量属性归根结底要落实到软件构架之上。 增量式开发的前提 迭代生命周期模型开始逐渐替代传统的瀑布模型，然而要真正实现其增量式开发的目标，却需要满足若干关键的前提条件：向已有交付添加新功能非常容易(可扩展)；后续的增量不会破坏已有的交付，使得迭代退化为返工(健壮)。 这些条件最终归结为在大批量的增量开发之前，要构建一个构架基线，它同时提供可扩展性与健壮性。 设计良好的对象可以方便地添加新的行为，而封装性为其对变化提供免疫力，基于对象的构架在微观上便具有更强的可扩展性与健壮性。 分层(分包、子系统)架构在大粒度上隔离关注面，同样从宏观上增强了可扩展性与健壮性。 健壮性与可扩展性 要实现健壮性与可扩展性等质量特性，主要有两个途径——尽可能降低系统的冗余程度，同时隔离不同的关注面(实质是高内聚、低耦合，例如：将稳定部分与可变部分隔离，将用户交互与业务、数据等功能域分离，将功能和非功能的实施代码分离)。 隔离关注面，使得扩展或变更时，对系统的修改局部化，对其它部分造成的影响被限制在较小范围内，避免出现那种牵一发而动全身的情形；高内聚的结构也利于聚焦于各部分的设计适应性上。 低冗余，使得即使要变更，变更所触及的部分也尽可能地少；系统被改动的地方越少当然就越健壮，同时开销也小、实施也更容易。 如何理解软件构架 软件系统进行分解的顶层结构，包括其组成元素，元素之间、元素与外部的关系关注构架的静态方面，即系统大粒度(宏观)的总体结构(例如分层、子系统的划分等) 系统中解决各类关键的重复问题的通用解决方案关注构架的动态方面，侧重于系统内部关键行为的共同特征(已经包含了微观细节，例如构架机制) 系统设计中影响深远(构架敏感)的各项最重要决定：这些决定严重影响系统的实施，一旦作出并被贯彻，其变更的代价将及其高昂(例如构架的样式、复用策略、开发中将贯彻的设计原则等) 软件构架的意义 软件构架的静态方面，其着眼点在于———保持目标系统的最终交付在结构上的一致性；为分工协作提供划分依据，并避免结构上的重叠和冗余。 软件构架的动态方面，其着眼点在于——保持目标系统在关键行为实现上的一致性，突出系统的既有风格；同时通过为各类关键重复问题提供通用解决方案来提高复用度，避免实施代码的冗余。 上述两个方面，共同提供了构造目标系统过程中的健壮性与可扩展性——大量的功能实现将在这个构架基础上被不断添加，而同时系统整体上仍然保持既有的一致和完整。 架构的分层 业务应用层 (Business Application) 由应用开发者开发 应用框架层 (Application