SECII@NJUSE-Chapter09 软件体系结构基础

软件体系结构的发展

重要性

• “Architecture is the linchpin for the highly complex, massively large-scale, and highly interoperable systems that we need now and in the future” — Rolf Siegers, Raytheon
• “Fundamentally, there are three reasons:
  • Mutual communication
  • Early design decisions
  • Transferable abstraction of a system” — [Clements1996]

软件体系结构的十年

体系结构的黄金年代

理解软件体系结构

概念和定义

什么是软件架构

Kruchten

• Philippe Kruchten (Director of Process Development, Rational Software Corporation, Vancouver, B.C.): Software Architecture encompasses the significant decisions about
  • the organization of a software system,
  • the selection of the structural elements and their interfaces by which the system is composed together with - their behavior as specified in the collaboration among those elements,
  • the composition of these elements into progressively larger subsystems,
  • the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition.
• Software architecture is not only concerned with structure and behavior, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics. (With G. Booch and R. Reitman) Citation: Rational Unified Process 5.0, Rational, Cupertino, 1998; PBK, The Rational Unified Process—An Introduction, Addison-Wesley-Longman (1999)

Shaw

• [Shaw1995]将软件体 系结构模型定义为:
  • 软件体系结构={部件(Component),连接件(Connector),配置(Configuration)}
    • “部件”是软件体系结构的基本组成单位之⼀,承载系统的主要功能,包括处理与数据;
    • “连接件”是软件体系结构的另⼀个基本组成单位,定义了部件间的交互,是连接的抽象表示;
    • “配置”是对“形式”的发展,定义了“部件”以及“连接件”之间的关联⽅式,将它们组织成系统的 总体结构。
• 按照这个模型,[Shaw1996]给出了⼀个简洁的软件体系结构定义:
  • “⼀个软件系统的体系结构规定了系统的计算部件和部件之间的交互”

Perry

Bass

• “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” [Bass1998]
• Every software has one or more architecture structures

Wiki

• Software architecture is the realization of non-functional requirements, while software design is the realization of functional requirements

什么是软件架构

• High level abstraction
• Concern of stakeholders
• Design decision

区分物理与逻辑

逻辑与物理

• High-level vs low-level
• Abstraction vs Implementation
• Logical implies a higher view than the physical.
  

模块

• 逻辑：⼀个模块调⽤另⼀个模块
• 物理实现
  • 基本：接⼝调⽤
  • 需要传递数据对象怎么办？
• 逻辑：⼀个模块给另⼀个模块传递数据流
• 物理实现
  • 读写共享数据、pipe

物理实现的载体

• 低层：基本类型+基本控制结构
• 中层：OO编程语⾔机制
  • 类声明、实例创建与撤销、实例⽣命期管理
  • 类权限控制机制
  • 复杂机制：继承…
• ⾼层
  • 导⼊导出和名称匹配

导出导入机制

抽象vs实现

• Architecture as-design

• Functional organizations
  

• Architecture as-implementation

• implemented mechanisms to software

高层抽象

• Components are the locus of computation and state
• Connectors are the locus of relations among components
  

理解高层抽象

• 连接件是⼀个与部件平等的单位
• 部件与连接件是⽐类、模块等软件单位更⾼层次的抽象

部件（Components）

• Elements that encapsulate processing and data in a system’s architecture are referred to as software components
• Components typically provide application-specific services
  

原始部件和复合部件

• 部件可以分为原始(Primitive)和复合(Composite)两种类型
• 原始类型的部件可以直接被实现为相应的软件实现机制
• 复合部件则由更细粒度的部件和连接件组成,复合部件通过局部配置将其内部的部件和连接件连接起来,构成⼀个整体

原始部件常⽤的软件实现机制

连接件（Connectors）

• In complex systems interaction may become more important and challenging than the functionality of the individual components
  

原始连接件和复合连接件

• 与部件相似,在实现上连接件也可以分为原始(Primitive)和复合(Composite)两种类型。原始类型的连接件可以直接被实现为相应的软件实现机制。
• 复合连接件则由更细粒度的部件和连接件组成,复合连接件通过局部配置将其内部的部件和连接件连接起来,构成⼀个整体

原始连接件常⽤的软件实现机制

Configurations

• Components and connectors are composed in a specific way in a given system’s architecture to accomplish that system’s objective

高层抽象的好处

• 直观，便于理解
• 验证正确性
• 关注度分离，降低复杂度

体系结构风格初步

体系结构风格

Main Program and Subroutine Style

• Components:
  • procedures , functions and module.
• Connectors:
  • calls between them
    

设计决策与约束

• 基于声明-使⽤(程序调⽤)关系建⽴连接件,以层次分解的⽅式建⽴系统部件, 共同组成层次结构。
• 每⼀个上层部件可以“使⽤”下层部件,但下层部件不能“使⽤”上层部件,即不 允许逆⽅向调⽤
• 系统应该是单线程执⾏。主程序部件拥有最初的执⾏控制权,并在“使⽤”中将 控 制权转移给下层⼦程序。
• ⼦程序只能够通过上层转移来获得控制权,可以在执⾏中将控制权转交给下层的⼦程序,并在⾃身执⾏完成之后必须将控制权还交给上层部件

实现

• 功能分解
• 集中控制
• 每个构件⼀个模块实现
  • 主要是单向依赖
• 使⽤utility或tools等基础模块

效果

• 主程序/⼦程序⻛格的优点有:
  • 流程清晰,易于理解。
  • 强控制性。
• 主程序/⼦程序⻛格的缺点有:
  • 程序调⽤是⼀种强耦合的连接⽅式,⾮常依赖交互⽅的接⼝规格,这会使得系统难以修改和复⽤。
  • 程序调⽤的连接⽅式限制了各部件之间的数据交互,可能会使得不同部件使⽤隐含的共享数据交流,产⽣不必要的公共耦合,进⽽破坏它的“正确性”控制能⼒

应用

• 主程序/⼦程序⻛格主要⽤于能够将系统功能依层次分解为多个顺序执⾏步 骤的系统。
• [Shaw1996]发现,在很多受到限制的编程语⾔环境下,这些编程语⾔没有模块 化⽀持, 系统通常也会使⽤主程序/⼦程序⻛格,这时主程序/⼦程序⻛格的实 现是程序实现,即主程 序和⼦程序都被实现为单独的程序。
• ⼀些使⽤结构化⽅法(⾃顶向下或⾃底向上)建⽴的软件系统也属于主程序/⼦程序⻛格

Object-Oriented Style

• Components:
  • object or module
• Connectors:
  • function or invocations (methods).
    

设计决策及约束

• 依照对数据的使⽤情况,⽤信息内聚的标准,为系统建⽴对象部件。每个对象 部件基于内部数据提供对外服务接⼝,并隐藏内部数据的表示
• 基于⽅法调⽤(Method Invocation)机制建⽴连接件,将对象部件连接起来
• 每个对象负责维护其⾃身数据的⼀致性与完整性,并以此为基础对外提供“正 确”的服务。
• 每个对象都是⼀个⾃治单位,不同对象之间是平级的,没有主次、从属、层次、 分解等关系

实现

• 任务分解
• （委托式）分散式控制
• 每个构件⼀个模块实现
  • 使⽤接⼝将双向依赖转换为单向依赖
  • 将每个构件分割为多个模块，以保证单向依赖
  • 每个模块内部可以是基于⾯向对象⽅法，也可以基于结构化
• 使⽤utility或tools等基础模块

效果

• ⾯向对象式⻛格的优点有:
  • 内部实现的可修改性。
  • 易开发、易理解、易复⽤的结构组织。
• ⾯向对象式⻛格的缺点有:
  • 接⼝的耦合性。
  • 标识(Identity)的耦合性。
  • 副作⽤。
    • ⾯向对象式⻛格借鉴了⾯向对象的思想,也引⼊了⾯向对象的副作⽤,因 此更难实现程序的“正确性”。例如,如果 A 和 B 都使⽤对象 C,那么 B 对 C 的修改可能会 对 A 产⽣未预期的影响。再例如对象的重⼊(Reentry)问题:如果 A 的⽅法 f()调⽤了 B 的 ⽅法 p(),⽽ p()⼜调⽤了 A 的另⼀⽅法 q(),那么就可能使得 q()失败,因为在 q()开始执⾏时,A 正处于 f()留 下的执⾏现场,这个现场可能是数据不⼀致的

应用

• ⾯向对象式⻛格适⽤于那些能够基于数据信息分解和组织的软件系统,这些系统:
  • 主要问题是标识和保护相关的数据信息;
  • 能够将数据信息和相关操作联系起来,进⾏封装。
• 实践中,基于抽象数据类型建⽴的软件系统⼤多属于⾯向对象式⻛格

Layered Style

• Components: typically collections of procedures or objects.
• Connectors: typically procedure calls or methods invocations under restricted visibility
  

设计决策与约束

• 从最底层到最⾼层,部件的抽象层次逐渐提升。每个下层为邻接上层提供服 务, 每个上层将邻接下层作为基础设施使⽤。也就是说,在程序调⽤机制中上 层调⽤下层。
• 两个层次之间的连接要遵守特定的交互协议,该交互协议应该是成熟、稳定和标准化的。也就是说,只要遵守交互协议,不同部件实例之间是可以互相替换的。
• 跨层次的连接是禁⽌的,不允许第 I 层直接调⽤ I+N(N>1)层的服务。
• 逆向的连接是禁⽌的,不允许第 I 层调⽤第J(J<I)层的服务

实现

• 关注点分离（每层逐次抽象）
• 层间接⼝使⽤固定协议（固定控制）
• 每层⼀或多个模块实现
  • 单向依赖
  • 层间数据传递建⽴专⻔模块
• 使⽤utility或tools等基础模块

效果

• 分层⻛格的优点有:
  • 设计机制清晰,易于理解。
  • ⽀持并⾏开发。
  • 更好的可复⽤性与内部可修改性。
• 分层⻛格的缺点有:
  • 交互协议难以修改。
  • 性能损失。
  • 难以确定层次数量和粒度

应用

• 分层⻛格适⽤于具备下列特性的系统:
  • 主要功能是能够在不同抽象层次上进⾏任务分解的复杂处理;
  • 能够建⽴不同抽象层次之间的稳定交互协议;
  • 没有很⾼的实时性能要求,能够容忍稍许的延迟;
• 此外,那些需要进⾏并⾏开发的软件系统也可能会使⽤分层⻛格,以便于任务分配和⼯作开展。在现有的软件系统中,分层⻛格是⼀种经常被⽤到的体系结构⻛格,像⽹络通信、交互 系统、硬件控制系统、系统平台等都会使⽤分层⻛格。
  • 例如,ISO ⽹络通信模型、TCP/IP 的 ⽹络通信模型等都使⽤了分层⻛格

Model-View-Controller Style

• The model subsystems are designed such that they do not depend on any view or controller subsystems.
• Changes in their states are propagated to the view subsystems
  
• Components
  • Model components are responsible for maintaining domain knowledge and notify view of changes
  • View components are responsible for displaying information to the user and send user gestures to controller
  • Controller
    • Changes the state of the model
      • Maps user actions to model updates
    • Selects view for response
• Connectors:
  • Procedure calls, Messages, Events

设计决策和约束

• 模型、视图、控制是分别是关于业务逻辑、表现和控制的三种不同内容抽象
• 如果视图需要持续地显示某个数据的状态,那么它⾸先需要在模型中注册对该数据的兴趣。 如果该数据状态发⽣了变更,模型会主动通知视图,然后再由视图查询数据的更新 情况。
• 视图只能使⽤模型的数据查询服务,只有控制部件可以调⽤可能修改模型状态的程序
• ⽤户⾏为虽然由视图发起,但是必须转交给控制部件处理。对接收到的⽤户⾏为, 控制部件可能会执⾏两种处理中的⼀种或两种:调⽤模型的服务,执⾏业务逻辑;提供下⼀个业务展现。
• 模型部件相对独⽴,既不依赖于视图,也不依赖于控制。虽然模型与视图之间存在 ⼀个“通知 变更”的连接,但该连接的交互协议是⾮常稳定的,可以认为是⾮常弱的依赖

实现

• 模型-视图-控制⻛格需要为模型、视图和控制的每个部件实例建⽴模块实现,各模块间 存在导⼊/导出关系,程序调⽤连接件 不需要显式的实现。
• 特定技术实现，通常专⽤于WEB
  • Model与Controller单向
  • Controller与View双向
  • Model与View双向
• 典型实现
  • View：JSP，HTML
  • Controller：Servlet
  • Model：JavaBean

效果

• 模型-视图-控制⻛格的优点有:
  • 易开发性。视图和控制的可修改性
  • 模型封装了系统的业务逻辑,所以是三种类型中最为复杂 的系统部件。MVC 中模型是相对独⽴的,所以对视图实现和控制实现的修改不会影响到模 型实现。再考虑到业务逻辑通常⽐业务表现和控制逻辑更加稳定,所以 MVC 具有⼀定的可 修改性优势。
  • 适宜于⽹络系统开发的特征。MVC 不仅允许视图和控制的可修改性,⽽且其对业务逻辑、表现和控制的分离使 得⼀个模型可以同时建⽴并保持多个视图,这⾮常适⽤于⽹络系 统开发。
• 模型-视图-控制⻛格的缺点有:
  • 复杂性。MVC 将⽤户任务分解成了表现、控制和模型三个部分,这增加了系统的复 杂性,不利于理解任务实现。
  • 模型修改困难。视图和控制都要依赖于模型,因此,模型难以修改

应用

• Suitable for applications:
  • Changes to user interface should be easy and possible at run-time.
  • Adapting or porting the user interface should not impact the design or code in the functional part of the application.
• Examples:
  • Web applications

分层与MVC

总结

• Main Program tends to be space efficient and may offer potential to enhance functionality. Generally applicable.
• Abstract Data Type (OO) supports change of data representation. Generally applicable.
• Implicit Invocation attempts to achieve both data and functional abstraction - loose coupling. However, this can be at the cost of a loss of control and understanding.
• Pipe and Filters offers simplicity and maintainability but is of limited applicability - ‘batch’ style