Design Patterns Lecture 6.

Presentation on theme: "Design Patterns Lecture 6."— Presentation transcript:

1 Design Patterns Lecture 6

2 软件体系结构 简介 体系结构视图 体系结构风格 体系结构描述语言 实例分析

3 软件设计方法演化

4 软件体系结构的背景 我们需要的是软件 符合质量要求！！ 软件需求是进行“质 量”度量的基础，与 需求不符就是质量不 高。
通常有一组“隐含需 求”是不被提及的 （如对维护性的需 求）。如果软件符合 了明确的需求却没有 满足隐含需求，软件 质量仍然值得怀疑。 性能Performance 可用性Usability 可靠性Availability 可扩展性Extensibility 安全性 Security 功能性Functionality

5 软件体系结构起源 软件体系结构思想来源于建筑业 结构设计师：设计图纸 管理人员： 施工计划 施工人员： 建造建筑物

6 对于大规模的，分布的，需要协作的，需要交互的，需要监测的，需要扩展的，需要演化的复杂软件系统的规划。
软件体系结构的本意 对于大规模的，分布的，需要协作的，需要交互的，需要监测的，需要扩展的，需要演化的复杂软件系统的规划。

7 软件体系结构发展简史 1960年代，软件危机爆发 1968年，软件工程被提出 1968年，软件体系结构思想被提出
NATO software engineering conference 1968年，软件体系结构思想被提出 “The Structure of the ‘THE’ Multiprogramming System” authored by Edsger Dijkstra ( 艾德勒 戴克斯加,荷兰） 1975年，软件体系结构思想被升华 “Architecture is the complete and detailed specification of the user interface” by Frederick Brooks (弗兰德里克 布鲁克斯，美国） Edsger Dijkstra Frederick P. Brooks

8 软件体系结构发展简史 1972~1976年，现代软件开发思想被提 出
information hiding and usage of interface（Parnas，1972) structure separation (Parnas, 1974） the relationships between software structure and its quality （Parnas，1976） 戴维 帕纳斯，美国 1991年，”Software Architecture”在正 式文献中被使用 Software Architecture: Integrating Process and Technology authored Walker E. Royce and Winston W. Royce 沃克 罗伊斯；温斯顿 罗伊斯， 美国 David Parnas Walker E. Royce

9 软件体系结构发展简史 1993年, Software Architecture被定义，此定义成为软 件体系结构研究的公认基础
An Introduction to Software Architecture authored by David Garlan and Mary Shaw 20世纪90年代 ，软件体系结构描述语言(ADL)兴盛 Darwin, Wright, C2, Rapide, MetaH, ACME, … 20世纪90年代，软件体系结构评估方法兴起 SAAM, ATAM, … 2000年， IEEE 标准 IEEE Recommended practice for architectural description of software-intensive systems

10 软件体系结构发展简史 2000年, Software Architecture Product Line 2003年，UML2.0 发布
The Design and Use of Software Architecture authored by Bosch 2003年，UML2.0 发布 2000年至今，动态软件体系结构 π-ADL，LIME， dynamic Wright, … THU SAGroup

11 体系结构——最重要的决定 The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

12 SA理解的不同视角——抽象

13 SA理解的不同视角——结构

14 SA——结构的抽象

15 SA——结构的抽象

16 SA理解的不同视角——组件与环境 不存在普遍适用的解决方案

17

18

19

20 问题3

21 软件架构Big Picture

22 SA定义的总结 软件架构 = 抽象 +元素 + 交互 软件架构 = 重要决策的集合 软件架构 = 受环境影响的高层设计
软件架构 = 抽象 +元素 + 交互 软件架构 = 重要决策的集合 软件架构 = 受环境影响的高层设计 软件架构 = 不同模型的组合方式

23 SA 要素 组件 (component) 连接件(connector) 配置(configuration) 约束(constraints)

24 如何理解软件体系结构 体系结构 模型 视图

25 Views A view is a representation of a set of architectural
elements and the relations associated with them. Not all architectural elements -- some of them. A view binds element types and relation types of interest, and shows those. All information Some information

26 软件体系结构的4+1 View 4+1 :The 4+1 View Model of Architecture
由Philippe Kruchten设计 主要特色：多视图共同表达不同涉众的观点 逻辑视图(Logical View):表示系统功能 开发视图(Development View):表示开发分工和任务 管理 进程视图(Process View):表示系统进程，线程，分布等信息 物理视图(Physical View):表示系统物理部署情况 场景(Scenarios):用一些场景、用例来描述系统各个部分之间， 以及与环境之间的交互 。

27 SA的表示——4+1 View Logical view Development view Scenarios Process View
End user Logical view Development view Programmers & software managers Scenarios Process View Physical View System Engineer

28 Logical View (Object-oriented Decomposition) Viewer: End-user
considers: Functional requirements- What the system should provide in terms of services to its users. Notation: The Booch notation (OMT) (object and dynamic models) Tool: Rational Rose

29 Logical view Example UNIX OS

30 Process View (The process decomposition) viewer: Integrators
considers: Non - functional requirements (concurrency, performance, scalability) style: Several styles would fit in this view (Garlan and Shaw ‘s Architecture styles)

31 Process view (cont.) Uses multiple levels of abstractions, a logical network of processes at the highest level A process is a grouping of tasks that form an executable unit: Major Tasks: Arch. relevant tasks Minor Tasks: Helper tasks. (Buffering)

32 Process View example

33 Development View (Subsystem decomposition) Basis of a line of product
Viewer: Programmers and Software Managers considers: software module organization (Hierarchy of layers, software management, reuse, constraints of tools) Style: layered style Notation: the Booch notation (module, subsystem, layer)

34 Physical View (Mapping the software to the Hardware)
Viewer: System Engineers Considers: Non-functional req. regarding to underlying hardware (Topology, Communication) Notation: May have several forms and may Tightly connected to the process view There may be two architecture: Test and development deployment

35 Physical view example

36 Scenarios Help illustrate and validate the document
(Putting it all together) Viewer: All users of other views and Evaluators. Considers: System consistency, validity Notation: almost similar to logical view Tool: Rational Rose Help illustrate and validate the document Help Architect during the architecture design

37 Scenario example

38 Correspondence between views
Views are interconnected. Start with Logical view (Req. Doc) and Move to Development or Process view and then finally go to Physical view. Development View Physical View Logical View Process View

39 From Logical to development
They are very close, but the larger the project, the greater the distance Grouping to subsystems based on: Classes Class packages Line of codes Team organization

40 The Iterative process Not all SA Need all views.
A scenario-driven approach to develop the system Documentation: Software architecture document Software design guidelines

41 4+1 View 的5视图演化

42 Styles -Moving from Qualities to Architectures
Architectural styles help software engineers to reason about architectural qualities. 体系结构风格帮助软件工程师 推断软件体系结构的质量

43 Styles -Moving from Qualities to Architectures
A style describes a class of architectures 描述一类体系结构 is found repeatedly in practice 在实践中被多次设计、应用 is a package of design decisions 是若干设计思想的综合 has known properties that permit reuse 具有已经被熟知的特性，并且可以复用

44 Architectural Styles A style is determined (described) by
a set of component types (e.g., data repository, process, object) 一组组件类型（例如：数据容器，过程，对象） a set of connector types/interaction mechanisms (e.g., subroutine call, event, pipe) 一组连接件类型/交互机制（例如：过程调用，事件，管 道） a topological layout of these components 这些组件的拓扑分布

45 Architectural Styles A style is determined (described) by
a set of constraints on topology and behavior (e.g., a data repository is not allowed to change stored values, pipelines are acyclic) 一组对拓扑和行为的约束（例如：数据容器不能自己改变 数据，管道不能是循环的 an informal description of the costs and benefits of the style, e.g.: “Use the pipe and filter style when reuse is desired and performance is not a top priority 一些对风格的成本和益处的非正式的描述，例如：如果你 需要重用性并且性能不是很重要，那么可以使用管道风格

46 Architectural Styles Garlan and Shaw compiled a catalog of architectural styles in Others, such as Buschmann, have augmented this. There is no complete list. 没有完备的列表 There is no unique, non-overlapping list. 没有无重叠的列表 Styles overlap. 风格是彼此重叠的 Systems exhibit multiple styles at once. 一个系统通常表现出多种风格

47 Types of Architectural Styles

48 Notes about Architectural Styles
When we introduce a new style, we will typically first examine its “pure” form. pure architectural style are rarely found in practice 纯粹的体系风格在实际中很难遇到 systems in practice regularly deviate from the academic definitions of these systems. 循规蹈矩地背离了对这些系统的学术定义 typically feature many architectural styles simultaneously 典型地，融合很多体系风格的特色 as an architect you must understand the “pure” styles to un derstand the strength and weaknesses of the style as well a s the consequences of deviating from the style 作为一个架构师，你必须理解“纯”的风格。理解它的优点与缺陷， 也要理解背离此种风格之后会带来什么结果

49 管道-过滤器风格 在管道-过滤器风格下，每个功能模块都有一组输入和输 出。功能模块称作过滤器（filters）；功能模块间的连接 可以看作输入、输出数据流之间的通路，所以称作管道 （pipes）。 管道-过滤器风格的特性之一在于过滤器的相对独立性， 即过滤器独立完成自身功能，相互之间无需进行状态交互。

50 管道-过滤器风格特性 过滤器是独立运行的构件 过滤器对其处理上下连接的过滤器“无知” 结果的正确性不依赖于各个过滤器运行的先后次序
非临近的过滤器之间不共享状态 过滤器自身无状态 过滤器对其处理上下连接的过滤器“无知” 对相邻的过滤器不施加任何限制 结果的正确性不依赖于各个过滤器运行的先后次序 各过滤器在输入具备后完成自己的计算。完整的计算过程 包含在过滤器之间的拓扑结构中。

51 管道-过滤器风格优点 设计者可以将整个系统的输入、输出特性简单的理 解为各个过滤器功能的合成。
设计人员将整个系统的输入输出行为理解为单个过滤器行 为的叠加与组合。 可以将问题分解，化繁为简。将系统抽象成一个“黑箱”， 其输入是系统中第一个过滤器的输入管道，输出是系统中 最后一个过滤器的输出管道，而其内部各功能模块的具体 实现对用户完全透明。

52 管道-过滤器风格优点 支持功能模型的复用 任何两个过滤器，只要它们之 间传送的数据遵守共同的规约， 就可以相连接。每个过滤器都 有自己独立的输入输出接口， 如果过滤器间传输的数据遵守 其规约，只要用管道将它们连 接就可以正常工作。 可维护性和可扩展性 旧的过滤器可以被替代，新的过滤器可以添加到已有的系统上。在管道-过滤器模型中，只要遵守输入输出数据规约，任何一个过滤器都可以被另一个新的过滤器代替，同时为增强程序功能，可以添加新的过滤器。这样，系统的可维护性和可升级性得到了保证。 支持死锁检测等分析 可以很容易的得到系统的资源使用和请求的状态图。然后，根据操作系统原理等相关理论中的死锁检测方法就可以分析出系统目前所处的状态，是否存在死锁可能及如何消除死锁等问题 潜在的并行支持 每个过滤器作为一个单独的执行任务，可以与其它过滤器并发执行。过滤器的执行是独立的，不依赖于其它过滤器的。在实际运行时，可以将存在并发可能的多个过滤器看作多个并发的任务并行执行，从而大大提高系统的整体效率，加快处理速度。

53 管道-过滤器风格不足 交互式处理能力弱 管道-过滤器模型适于数据流的处理和变换，不适合为与 用户交互频繁的系统建模。在这种模型中，每个过滤器都 有自己的数据，这些数据或者是从磁盘存储器中读取来， 或者是由另一个过滤器的输出导入进来，整个系统没有一 个共享的数据区。这样，当用户要操作某一项数据时，要 涉及到多个过滤器对相应数据的操作，其实现较为复杂。 由以上的缺点，可以对每个过滤器增加相应的用户控制接 口，使得外部可以对过滤器的执行进行控制。

54 管道-过滤器的改进 改进的过滤器

55 管道-过滤器风格不足 管道-过滤器风格往往导致系统处理过程的成批操作。
设计者也许不得不花费精力协调两个相对独立但又 存在某种关系的数据流之间的关系，例如多过滤器 并发执行时数据流之间的同步问题等。 根据实际设计的需要，设计者也需要对数据传输进 行特定的处理（如为了防止数据泄漏而采取加密等 手段），导致过滤器必须对输入、输出管道中的数 据流进行解析或反解析，增加了过滤器具体实现的 复杂性。

56 管道-过滤器风格实例——数字通信系统 通信的目的是传递消息。消息具有不同的形式，例 如：符号、文字、语音、音乐、数据、图片、图像 等等。因而，根据所传递消息的不同，目前通信业 务可以分为电报、电话、传真、数据传输及可视电 话等。对于基本的点对点通信，是把发送端的消息 传递到接收端。 发送端 接收端 数字通信概念模型

57 管道-过滤器风格实例——数字通信系统 将上图发送端进一步细分为信息源和发送设备，将 接收端细分为接收设备和受信者；同时，在通信过 程中会有噪声干扰，在模型中添加噪声源可得到图 所示的数字通信系统粗略模型。 噪声源 信息源 发送设备 接收设备 受信者 信道 数字通信系统粗略模型

58 管道-过滤器风格实例——数字通信系统 数字通信系统详细模型

59 管道-过滤器风格实例（OS） 过滤器状态转换图

60 使用示例 Unix系统中的管道过滤器结构 ls –al | grep my （显示文件中包含”my”字串的所有文件的详细信息列 表）
通讯协议的信息封装(e.g. SDH)

61 软件体系结构待解决的核心问题 既然是根本选择，如何对不同的体系结构进行有效的比较？ 如何描述、表示、设计体系结构（ADL)
The System UI Functions.. DBMS WS (1) WS (…) WS (n) 这些盒子和线在每个图的内部以及图与图之间都是相同的含义吗? 如何描述、表示、设计体系结构（ADL) 如何验证一个体系结构是否符合期望的系统需 求(形式化，Z语言） 如何基于体系结构开发实例化的软件系统

62 References: Programming-in-the-large v.s. Programming-in-the-small

63 软件体系结构描述语言 ADL是在底层语义模型的支持下，为软件系统的概念体系 结构建模提供了具体语法和概念框架。基于底层语义的工 具为体系结构的表示、分析、演化、细化、设计过程等提 供支持。 基本元素：构件、连接件、体系结构配置。 主流语言： Aesop、MetaH、C2、Rapide、SADL、 Unicon和Wright等； 这些ADL强调了体系结构不同的侧面，对体系结构的研究和应用起 到了重要的作用，但也有负面的影响。 每一种ADL都以独立的形式存在，描述语法不同且互不兼容，同时 又有许多共同的特征，这使设计人员很难选择一种合适的ADL，若 设计特定领域的软件体系结构又需要从头开始描述。 ADL是在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。其三个基本元素是：构件、连接件、体系结构配置。 主要的体系结构描述语言有Aesop、MetaH、C2、Rapide、SADL、Unicon和Wright等，尽管它们都描述软件体系结构，却有不同的特点。 这些ADL强调了体系结构不同的侧面，对体系结构的研究和应用起到了重要的作用，但也有负面的影响。每一种ADL都以独立的形式存在，描述语法不同且互不兼容，同时又有许多共同的特征，这使设计人员很难选择一种合适的ADL，若设计特定领域的软件体系结构又需要从头开始描述。

64 软件体系结构描述语言 ADL与其他语言的比较 构造能力：ADL能够使用较小的独立体系结构元素来建造大型软件 系统；

65 ADL 实例 一个常规的Client-Server架构

66 ADL 实例(2)

67 ADL 实例(3) 可容错的C/S架构

68 ADL 实例(4) Revised ADL (component)
缺点：违反了constraints,只有一个server与 client相连接

69 ADL 实例(5) Revised Design

70 ADL 实例(6)

71 ADL 实例(7)

72 ADL 实例(8)

73 ADL 实例(9) 一致性分析，举例：

74 Reference: Architecture-Based Runtime Software Evolution
P. Oreizy et al. ICSE 1998

75 Questions: Q1:总结一下五种创建型模式的联系和区别.
Q2:简析一下MVC(Model-View-Controller)中用 到的设计模式，以及这些模式的合作. Q3: 试着举出影响架构的情境因素并说明原因. to: