Design Patterns Lecture 6 1960 1968 NATO software

Design Patterns Lecture 6

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

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

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

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

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

软件架构Big Picture

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

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

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

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

Logical view Example

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)

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)

Process View example

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)

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

Physical view example

Scenarios (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

Scenario example

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

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

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

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

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 具有已经被熟知的特性，并且可以复用 45

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 这些组件的拓扑分布 46

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 一些对风格的成本和益处的非正式的描述，例如：如果你 需要重用性并且性能不是很重要，那么可以使用管道风格 47

Architectural Styles Garlan and Shaw compiled a catalog of architectural styles in 1995. 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. 一个系统通常表现出多种风格 48

Types of Architectural Styles 49

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 understand the strength and weaknesses of the style as well as the consequences of deviating from the style 作为一个架构师，你必须理解“纯”的风格。理解它的优点与缺陷， 也要理解背离此种风格之后会带来什么结果 50

References: Programming-in-the-large v. s. Programming-inthe-small David Garlan and Mary Shaw(1993). An introduction to software architecture. Advances in Software Engineering and Knowledge Engineering: pp. 1 -39.

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

ADL 实例(4) Revised ADL (component)

ADL 实例(5) Revised Design

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