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

1. 目录 • 软件生命周期与软件架构介绍 2 • 软件架构风格 75 • UML与面向对象程序设计 145 • UML建模与分析 248 • 技术架构视图-设计原则与模式 487 • 软件系统坏死的症状 558 • liskov替换原则（LSP） 560 • 接口隔离原则（ISP） 591 • 依赖倒置原则（DIP） 601 • 设计模式 658 • 策略（Strategy）模式 715 • 桥接（Bridge）模式 769 • 命令（command）模式 782 • 其它设计模式 816

2. 软件生命周期与软件架构介绍

3. 软件架构辨析 • 市场体系结构 • 软件架构

5. MS e-Gov Architecture Framework

7. MS Application Reference Architecture

8. 市场体系结构的特点 • 面向客户而非面向软件开发者。 • 对于商业产品的特色宣传非常有效，但对开发者远远不够。 • 市场体系结构与开发流程脱节。

9. 软件构架的特点 • 好的软件构架满足它们的需求，并富有弹性和基于构件。 • 一个富有弹性的软件构架能够： • 改进可维护性和可扩展性 • 实现经济性显著的可重用度 • 将开发团队成员间的工作清楚地分割开 • 封装对硬件和系统的依赖

10. 为什么需要软件构架 • 最终开发出的目标系统总是由多个组成部分所构成，这种结构如果没有预先定义，很难保证系统的构建过程能自发创建出一个一致而满足需求的交付。 • 当前的软件规模已大到需要采用团队开发的模式，多个开发人员的分工协作，必然依赖于一种对开发内容的合适划分，以减少相互干扰、缩短工期的关键路径，从而提高开发效率、加快项目进度－－软件构架无疑是其中最关键的一类划分，它将被用来计划、管理与执行系统开发的各项活动。 • 模块/构件化

11. 为什么需要软件构架 • 目标系统总是要面临各种变数，项目组期望系统在发生变更、部署到新环境中时，仍然保持既有的稳定、可靠和性能——目标系统应具备一种健壮性。 • 系统的构建要经历一个不断增添新功能、加入新行为的过程，项目组期望做得比较容易、开销较低，且在此过程中不存在重大的风险——目标系统应具备一种可扩展。 • 这些质量属性归根结底要落实到软件构架之上。

12. 增量式开发的前提 • 迭代生命周期模型开始逐渐替代传统的瀑布模型，然而要真正实现其增量式开发的目标，却需要满足若干关键的前提条件：向已有交付添加新功能非常容易(可扩展)；后续的增量不会破坏已有的交付，使得迭代退化为返工(健壮)。 • 这些条件最终归结为在大批量的增量开发之前，要构建一个构架基线，它同时提供可扩展性与健壮性。 • 设计良好的对象可以方便地添加新的行为，而封装性为其对变化提供免疫力，基于对象的构架在微观上便具有更强的可扩展性与健壮性。 • 分层(分包、子系统)架构在大粒度上隔离关注面，同样从宏观上增强了可扩展性与健壮性。

13. 健壮性与可扩展性 • 要实现健壮性与可扩展性等质量特性，主要有两个途径——尽可能降低系统的冗余程度，同时隔离不同的关注面(实质是高内聚、低耦合，例如：将稳定部分与可变部分隔离，将用户交互与业务、数据等功能域分离，将功能和非功能的实施代码分离)。 • 隔离关注面，使得扩展或变更时，对系统的修改局部化，对其它部分造成的影响被限制在较小范围内，避免出现那种牵一发而动全身的情形；高内聚的结构也利于聚焦于各部分的设计适应性上。 • 低冗余，使得即使要变更，变更所触及的部分也尽可能地少；系统被改动的地方越少当然就越健壮，同时开销也小、实施也更容易。

14. 如何理解软件构架 • 软件系统进行分解的顶层结构，包括其组成元素，元素之间、元素与外部的关系关注构架的静态方面，即系统大粒度(宏观)的总体结构(例如分层、子系统的划分等) • 系统中解决各类关键的重复问题的通用解决方案关注构架的动态方面，侧重于系统内部关键行为的共同特征(已经包含了微观细节，例如构架机制) • 系统设计中影响深远(构架敏感)的各项最重要决定：这些决定严重影响系统的实施，一旦作出并被贯彻，其变更的代价将及其高昂(例如构架的样式、复用策略、开发中将贯彻的设计原则等)

15. 软件构架的意义 • 软件构架的静态方面，其着眼点在于———保持目标系统的最终交付在结构上的一致性；为分工协作提供划分依据，并避免结构上的重叠和冗余。 • 软件构架的动态方面，其着眼点在于——保持目标系统在关键行为实现上的一致性，突出系统的既有风格；同时通过为各类关键重复问题提供通用解决方案来提高复用度，避免实施代码的冗余。 • 上述两个方面，共同提供了构造目标系统过程中的健壮性与可扩展性——大量的功能实现将在这个构架基础上被不断添加，而同时系统整体上仍然保持既有的一致和完整。

16. 架构的分层 • 业务应用层 (Business Application) • 由应用开发者开发 • 应用框架层 (Application Framework) • 特定领域框架层 • 跨领域框架层 • 基础框架层 (Foundation Framework) • 操作系统层

18. 从经济的角度考虑架构 软件架构的设计与开发 用户培训

19. 软件体系结构 • 软件体系结构至少有十几种思想流派。 • Zachman框架 • 开放分布式处理 • 领域分析 • Rational4＋1视图模型 • 软件体系结构风格 • 供应商驱动的方案 • Sun Enterprise JavaBeans • MS .Net 体系

20. Zachman框架 • 来源于IBM • 传统的体系结构，设计为非面向对象。

22. 开放分布式处理（ODP） • 构件可以最大程度的进行互操作和重用。 • 对系统和处理方式加以标准化，只是增强软件可操作性和重用性的一种权宜之计，并不能彻底解决问题。 • 分布式处理：借助计算机网络将分布在不同地点的构件(对象)组织在一起，进行信息处理。 • 分布式处理中的构件可能由不同的厂商开发、生产，因而构件之间可能存在不一致的接口；另外，构件之间的通信也可能使用不同的协议。 • 这种兼容异质成分的分布式处理，称为开放分布式处理。

23. RM—ODP的元模型体系 • ISO/ITU－T RM－ODP定义的抽象层次(视角)： • 企业视点(Enterprise Viewpoint) • purpose， scope and policies • 信息视点(Information Viewpoint) • semantics of information and information processing • 计算视点(Computational Viewpoint) • functional decomaosition • 工程视点(Engineering Viewpoint) • infrastructure required to support distribution • 技技术视点　(Technology Viewpoint ) • choices of technology for implementation

24. 领域分析 • 是一种支持软件复用的系统的管理过程。 • 将项目专有需求转化为一般的领域需求。 • 通用功能被用来做水平框架和可复用软件体系结构的基础。

25. 4＋1视图模型 • 逻辑 实现 进程 部署 • 用例 • 与UML紧密相连

26. 软件体系结构风格 • MVC风格 • 管道－过滤器风格 • 客户－服务器风格 • 层次系统 • 仓储（数据库和黑板）风格 • 面向对象风格 • 基于消息广播且面向图形用户界面的Chiron2风格 • 基于事件的隐式调用风格

27. 基本理念 • IT行业的人才结构与软件架构师的定位 • 软件架构师应掌握的知识体系 • 软件架构设计的特点、层次、分类 • 软件架构的主要理论、方向和趋势 • 软件工厂，实现软件开发的产业化

28. 软件架构师在干什么？ • 思考、思考、再思考 • 深入理解、准确把握建设的业务需求 • 分析所有可见的问题、障碍、风险 • 充分参考已有的成功方案，降低风险 • 交流、讨论、博弈、质疑 • 对构思中的方案不断提出质疑，避免漏洞 • 广泛听取各层面的意见，开拓思路 • 反复质疑、逐步完善已有的设计构思 • 在动手实现之前验证设计方案的正确性

29. 软件架构师的知识结构 • 软件知识 • 最好要有系统开发全过程经验。 • 对 IT 建设生命周期各个环节有深入了解，包括：系统/模块逻辑设计、物理设计、代码开发、项目管理、测试、发布、运行维护等。 • 深入掌握1-2种主流技术平台上开发系统的方法。 • 了解多种应用系统的结构。 • 了解架构设计领域的主要理论、流派、框架。

30. 软件架构师的知识结构 • 业务知识 • 深入了解系统建设的业务需求。 • 了解系统的非功能需求和运行维护需求。 • 了解企业 IT 公共设施、网络环境、外部系统。

31. 你知道那些知识？ • MFC，Msf，mof，rup，j2ee，spring，soa，junit，ORM，。net • Mvc，uml，xml，corba，mda，mdd，webservice • Rss，web2。0，ajax，serlet，hibernate • Ioc， aop， • ruby on rails • Rup • Bpel • Workflow engine • LBS • Oracle • CMMI • MQ

32. 软件架构师的思维方式 • 基于框架的思维 • 架构设计的层次（Enterprise， Application， etc） • IT 的生命周期（What， Why， Where， How， When， etc） • 成功经验以及方法论的指导 • 合理把握技术细节 • 把握各个层次应有的内容 • 合理忽略不应有的技术细节

33. 软件架构师的思维方式 • 风险管理意识 • 采用成功经验、避免不应有的风险 • 多方位的开放思维 • 多维度、多方向、包容性、避免排他性 • 分析、质疑、抽象、归纳 • 没有绝对好的架构设计，只有相对优秀的方案

34. 软件架构设计过程举例 • 应用系统逻辑架构设计 • 目标：提供系统架构方案、满足业务需求、为物理设计提供依据。 • 主要环节 • 根据系统主要的应用场景，确定系统概念架构。

35. 软件架构设计过程举例 • 调研已有的成功参考架构和相关模式 • 提出系统逻辑架构，包括分层的整体逻辑架构、子系统/模块组成以及边界划分根据。 • 讨论逻辑架构的依据、优缺点、以及已经考虑和参考的其它方案。 • 设计相关子架构，包括：数据架构、子系统架构、安全架构、网络架构等。 • 验证架构设计、确认能够满足业务需求和其他关键指标，如性能要求、费用限制等。

36. 需求分析 系统设计 系统开发 测试上线 架构设计 软件架构设计的一些特点 • 处于软件系统建设的上游 • 需要全面考虑多方面的因素 • 对于同一个问题，可以有多种设计结果 • 是在各种制约条件下取得的较好折衷方案 • 科学 + 经验 + 艺术 • “系统架构”往往被滥用

37. 软件架构的层次

38. 软件架构的分类

39. 成为软件架构师的途径 • 软件架构 — 巨大的知识海洋 • 门槛相对较高、职业生涯非常长 • 相对独立于技术的新陈代谢 • 适合于喜欢学习的人 • 不断学习、增加积累、注重经验 • 注意学习方法论、框架 • 不断增加各种系统架构的知识 • 经验积累非常重要

40. 成为软件架构师的途径 • 在与高手和同行合作中提高水平 • 与高手的合作是最佳途径 • 同行之间的交流也非常有效 • 在每一个项目中进行创新

41. 软件生命周期进程模型 • RUP与XP • Agile与CMM • MSF

42. 传统的瀑布式开发 • 能够较好地解决：软件项目复杂性和一致一方面的问题

43. 瀑布式开发推迟了风险的规避 • 无法解决：软件项目可变性和不可视性方面的问题

44. 将瀑布开发迭代地应用于系统增量 • 最早的迭代触及最重大的风险(例如需求或项目可行性风险)。 • 每次迭代产出一个可执行(可以通过测试等较客观的途径加以验证)的交付，是系统的一个增量。 • 每次迭代都包含集成与测试。

45. 迭代式开发促进风险规避

46. 迭代式开发的特点 • 严重的风险在(项目)大规模投入之前被解决 • 初期的迭代能获取更早的用户反馈 • 测试与集成是连续的(增量式) • 客观(可验证)的里程碑提供了短期的焦点 • 进度的度量直接依靠对实施成果的评估(而　非主观的估计) • 部分的实现可以被先行部署

47. 迭代：风险驱动的开发模型 • 在RUP先启阶段的迭代中，项目组必须解决开发目标与范围、以及技术和商业可行性的根本风险——值不值得做，能不能做。 • 而到了精化阶段的迭代，项目组关注的焦点则转到构架风险上——可否大量投入去做。 • 进入项目中成本最高的构建阶段后，控制成本、进度和开发质量的风险将成为所有成员的责任——准备好交付给用户了? • 最后到了迁移阶段，项目组将面临从客户和用户方面引入的各种风险(日程安排、需求变更等)——客户是否满意。

50. RUP、XP、Agile 都强调迭代开发的方式