构架模式、 UML 与组件设计

1. 构架模式、UML与组件设计 竞争的优势

2. 议程 • 软件架构与模式 • UML: 通用建模语言 • 组件设计过程

3. 议程 • 软件架构与模式 • 架构的定义 • 优秀软件的标准 • 模式 • UML: 通用建模语言 • 组件设计过程

4. Load Load 民用建筑中的受力 负载的种类 - 固定的负载 - 变化的负载 - 动态负载 防止失败 - 安全因素 - 冗余 - 均衡 压缩 拉伸 任何时间你必须放弃原有经验, 使用10倍的力量, 再加以10倍的调研. 对于大的项目尤为如此.

5. 技术因素 功能性 性能 恢复力 吞吐量 失效安全 容量 容错能力 可用性 软件构架中的受力 区别 - 没有运动的部分 - 可以创建新材料 - 可以改变物理现象 避免失败 - 将关键部分分散开来 - 语义上的一致性 - 职责分散 Have an architecture that makes sense before you write 3.5 million lines of code.

6. Walker Royce, Rational An average software project: - 5-10 people - 10-15 month duration - 3-5 external interfaces - Some unknowns & risks Defense Weapon System Telecom Switch National Air Traffic Control System Commercial Compiler Embedded Automotive Software CASE Tool Large-Scale Organization/Entity Simulation Small Scientific Simulation IS Application Distributed Objects (Order Entry) Defense MIS System Enterprise IS (Family of IS Applications) IS Application GUI/RDB (Order Entry) Business Spreadsheet 复杂性度量 更高的技术复杂性 - 内嵌的，实时的，分布的，容错的 - 定制的，空前的，结构重新设计 - 高性能 更低的管理复杂性 - 小规模 - 非正式的 - 单个资金保管者 - “产品” 更高的管理复杂性 - 大规模 - 契约的 - 多个资金保管者 - “工程” 更低的技术复杂性 - 大多数是 4GL, 或者是基于组件的 - 应用程序重新创建 - 交互式性能

7. 构架的定义 • 软件构架是围绕着一系列关于软件系统组织的重要决定 • 选择组成系统的结构单元和接口 • 这些单元之间的协作行为 • 这些单元之间的协作行为 • 综合这些小的结构和动作单元为较大的子系统 • 管理整个组织的结构形式

8. 构架的定义 • 软件构架同时包括 • 用法 • 功能性 • 性能 • 可恢复性 • 可重新利用率 • 综合性 • 经济和技术的相互约束和权衡关系 • 审美学的观点

9. 以构架为中心 • 目的 • 智能控制 • 以可重复利用为基础 • 以项目管理和减小危险性为基础 • 表示方法 • 4+1 视图模型 • 步骤 • 迭代的和增量的发展 • 从可执行的构架中进行连续地提炼

10. 构架的前后联系 • 选择在什么规章或契约之下组建软件是一个构架级的决定 • 但这绝不是一个完整的构架级决定

11. 空间计划 服务 材料 结构 外表 站点 除去变化的层

12. 分层设计的 MS Search 2.5 • 代码的组件化（模块化）是第一位的。相比2.0版本三个主要的搜索功能。而 Search 2.5 由于把应用程序分割为不同模块，分别处理代码的执行和用户界面的表示，从而实现了代码与界面的分离。这是通过 XML 和 XSL 来实现的。

13. 构架的定义 • 查询先被提交给解析器 (Parser) 进行词条分割和词表解析 • 找到项目的显示术语 (Display Term) 被传给 Best Bets • 找到项目的首选术语 (Preferred Term) 和剩余项目被传给 Search Results • 使用 XSL 编译生成并转换为 XML 格式的结果文档 • HTML 被提交到用户 Web 浏览器

14. 完成优秀的设计 通过如下方法达到： 以用户为中心的方法 与企业架构相一致 构建时规划 基于解决方案的设计 迭代过程 完全的MSF团队输入

15. 优秀的设计 • 有用的 • 解决商业问题 • 保证信息、服务和产品的交付 • 可用的 • 保证生产率 • 直觉的 • 无错的 • 期望的 • 性价比高的 • 灵活的 • 可扩展的 • 可维护的

16. 降低设计风险 MSF设计过程是一个有效的工具，用以降低那些因为不满足商业需求而产生的设计风险。

17. 模式 • 模式是针对一个特定问题的解决方案 • 模式是从一个领域的经验中所提炼出来的特定的知识 • 所有具有良好结构的系统都有非常丰富的模式 • 习惯用语 • 设计模式 • 构架的模式

18. 设计模式 • 创造性的模式 • 抽象factory • 原型 • 构架的模式 • 适配器 • 桥 • 代理 • 动作的模式 • 职责链 • 协调者 • 访客 • 机制是构架的灵魂

19. 方法 方法 借鉴 借鉴 直觉 直觉 不可预知的系统 古典的系统 模式与架构的来源

20. 受关注的程度 发现 发明 实施 注意力 时间

21. 讨论 • 一个典型的设计 • 优秀的架构 • 吸取的教训 • 得到的经验

22. 议程 • 软件架构与模式 • UML: 通用建模语言 • OODA: 面对对象的分析与设计 • UML介绍 • 使用案例视图 • 类图表 • 交互图表与行为图表 • 模块与组件 • 组件设计

23. OODA: 面对对象的分析与设计 • 类、对象以及元件 • 一般概念

24. 类、对象以及元件 • 类：蓝图，对象的模版 • 对象：类的实例 • 元件：一个系统的物理执行单元 • 包括一个或多个类，很强的依存关系 • 物理的、可用二进制表示的应用程序 • 可运行一个或以上的界面 • 包含一个或以上的类别 • 可替换性

25. Person First name Last name Date of birth 类和对象 • 对象的状态有时间变化的趋势 • 类是对象的抽象 Jane Lewis 1/27/56 Don Smith 7/9/63 Debby Bloom 6/18/67 Warren Johnson 8/28/52

26. OOAD的一般概念 • 抽象 • 封装 • 模块 • 继承

27. Asset Value Person Name owns OOAD的基本概念：抽象 • 管理复杂性 • 关注实际的特性 • 忽略详细说明 • 从不同的角度看待问题

28. OOAD的基本概念：封装 • 隐藏信息 • 黑箱操作 • 降低连锁反应的影响 Buy 100 shares of FM Stocks at market price. • 购买者不需要了解实现的具体细节

29. Sell Stock Buy Stock Close Account Create Account OOAD的基本概念：模块 • 分块降低复杂性 • 各部分协同工作

30. OOAD的基本概念：继承 • 抽象的层次 Higher level of abstraction Asset Cash Stock Real estate Bond Lower level of abstraction Commercial Residential

31. 议程 • 软件架构与模式 • UML: 通用建模语言 • OODA: 面对对象的分析与设计 • UML介绍 • 使用案例视图 • 类图表 • 交互图表与行为图表 • 模块与组件 • 组件设计

32. 什么是 UML? • 统一模型语言™ (Unified Modeling Language)是一种用来定义，形象表示，创建和文档记载软件系统的工业标准语言。 它简化了软件设计的复杂流程，为整个的构架建立一个“蓝图”。

33. 为什么使用UML? • 一种形象，准确的表达软件功能和结构的标准方法，有效的避免误解 • 规划者/开发者/测试者/项目经理并不真正了解我尝试规格化的内容 • 写作规范很费时，但是产品周期越来越短

34. UML 使用在什么地方? • 高层的介绍总览的文档/规范 • 规范 • 开发设计文档

35. 什么是 UML 图表? • 软件系统的蓝图，每个类型的图表都说明了系统的不同的方面 • 软件代码生成的一种方法 • 图形化表示系统如何工作， 更快，更好 • 简练易懂的表述，讨论复杂的系统的一种方法

36. 使用案例图表 行为图表 类图表 顺序图表 其它类型的UML图表: 协作图表 数据流图表 包装图表 状态图表 物理图表 UML 图表的类型

37. 最终用户： 功能性 程序员： 软件开发管理 逻辑视图 实施视图 使用案例 视图 分发视图 过程视图 系统工程师： 拓扑结构、联系 综合： 性能、扩展性 4+1 视图模式 • 使用案例视图( “+1” 视图) • 使用案例模型 • 逻辑视图 • 设计模型 • 实施视图 • 实施模型 • 过程视图 • 包括在设计模型中 • 分发视图

38. 议程 • 软件架构与模式 • UML: 通用建模语言 • OODA: 面对对象的分析与设计 • UML介绍 • 使用案例视图 • 类图表 • 交互图表与行为图表 • 模块与组件 • 组件设计

39. 使用案例 • 情景, 在线消费情景 • 为了一个满足共同的用户的要求，而产生的一系列相互联系的情景 • 使用案例图表 • 辅助作用 • 可以使用其他形式 • 表达行为者与使用案例,及使用案例之间的关系

40. 使用案例图表

41. 使用案例文本 • 售票员为顾客买电影票: • 主要情景: • 售票员在顾客挑选座次, 电影和时间后, 为顾客定票. • 售票员输入顾客的信用卡信息, 收取购票费用 • 信用卡认证系统授权交易 • 售票员将票交给顾客 • 扩展情景” • 1a. 顾客是一般顾客: 1a1: 在保留季节票的前提下销售 1a2: 顾客可以开始购买季节票 • 1b. 顾客持有季节票, 1b1: 顾客可以使用季节票 1b2: 顾客也可以够买普通票 • 3a. 信用卡授权失败, 3a1: 售票员可以取消交易, 3a2: 售票员可以要求顾客提供正确的信用卡信息.

42. 使用案例图表 • 行为者 • 指用户在系统中扮演的角色 • “行为者”可能是用户，或者另一个系统 • 同一个用户根据扮演的角色, 可以成为多个不同行为者 • 在图表中可以只列出主要的行为者或者引起使用案例的行为者 • 使用案例描述“行为者”如何使用系统来达到特定的目标 • 列出行为者可以帮助发现使用案例 • 行为者的细节无关紧要

43. 使用案例图表 • 使用案例之间的关系:包涵,概括,延伸 • 当两个使用案例有重叠的部分时, 将重叠的部分独立出来成为一个单独的使用案例,此使用案例包涵于原使用案例 • 当一个使用案例A与另一个使用案例B类似, 但有更多的内容时, 可以将B作为A的一个特例使用案例, 这时, A是B的概括

44. 使用案例图表 • 延伸 • 如果基本使用案例A宣称某些延伸点,使用案例B只在这些延伸点上进行了扩充, B就成为A的延伸使用案例 • 规则 • 使用包含来避免重复的使用案例, • 使用概括来泛泛描述案例的特殊情况, • 使用延伸来严格描述案例的特殊情况

45. 使用案例的识别 • 确定使用案例 • 确定对象、参与者的关系与交互 • 在类图表与交互图表中描述细节 • 在逻辑视图中跟踪使用案例 • 危险：步骤太多或者太少。 • 如果在Use Case中有超过15个步骤，它可能包含一些实现明细。如果它只有非常少的步骤则检查它的目标是否是达到一个没有很多分支的活动的单一线索。

46. 使用案例的类别 • Business Use Case：系统都用于同一商业领域。不假定任何公司内部的结构 • System Use Case：整个系统看作是一个黑盒 • Implementation Use Case：设计子系统和系统内部组件。 • 每个Use Case只描述没有大的分支的行为的单个线索

47. 议程 • 软件架构与模式 • UML: 通用建模语言 • OODA: 面对对象的分析与设计 • UML介绍 • 使用案例视图 • 类图表 • 交互图表与行为图表 • 模块与组件 • 组件设计

48. 类图表 • 什么是类图表？ • 描述了系统中的对象类型，和其相互之间的各种不同的静态联系 • 描述了各个对象属性 • 提示 : 常在开发中使用

49. 类图表

50. 定义完善的类 • 拥有唯一确认的名字，容易识别 • 代表了类的操作及属性 • 与其他类协作良好 • 按照项目或企业的标准命名