- 软件体系结构={部件(Component),连接件(Connector),配置(Configuration)}
- “部件”是软件体系结构的基本组成单位之一,承载系统的主要功能,包括处理与数据;
- “连接件”是软件体系结构的另一个基本组成单位,定义了部件间的交互,是连接的抽象表示;
- “配置”是对“形式”的发展,定义了“部件”以及“连接件”之间的关联方式,将它们组织成系统的总体结构。
- 依照这个模型,[Shaw1996]给出了一个简洁的软件体系结构定义:
- 一个软件系统的体系结构规定了系统的计算部件和部件之间的交互”。
模块
- 逻辑:一个模块调用另一个模块
- 物理实现
- 基本:接口调用
- 需要传递数据对象怎么办?
- 逻辑:一个模块给另一个模块传递数据流
- 物理实现
- 读写共享数据、pipe..
物理实现的载体
- 低层:基本类型+基本控制结构
- 中层:00编程语言机制
- 类声明、实例创建与撤销、实例生命期管理
- 类权限控制机制
- 复杂机制:继承…
- 高层
- 导入导出和名称匹配
高层抽象
- 连接件是一个与部件平等的单位
- 部件与连接件是比类、模块等软件单位更高层次的抽象
原始部件和复合部件
- 部件可以分为原始(Primitive)和复合(Composite)两种类型。
- 原始类型的部件可以直接被实现为相应的软件实现机制。
- 复合部件则由更细粒度的部件和连接件组成,复合部件通过局部配置将其内部的部件和连接件连接起来,构成一个整体。
原始连接件和复合连接件
- 与部件相似,在实现上连接件也可以分为原始(Primitive)和复合(Composite)两种类型。原始类型的连接件可以直接被实现为相应的软件实现机制。
- 复合连接件则由更细粒度的部件和连接件组成,复合连接件通过局部配置将其内部的部件和连接件连接起来,构成一个整体。
高层抽象的好处
- 直观,便于理解
- 验证正确性
- 关注度分离,降低复杂度
体系结构风格
主程序/子程序风格
- 部件
- 流程,功能,模块
- 连接件
- 之间的调用
设计决策与约束
- 基于声明-使用(程序调用)关系建立连接件,以层次分解的方式建立系统部件,共同组成层次结构。
- 每一个上层部件可以“使用”下层部件,但下层部件不能“使用”上层部件,即不允许逆方向调用。系统应该是单线程执行。主程序部件拥有最初的执行控制权,并在“使用”中将控制权转移给下层子程序。
- 子程序只能够通过上层转移来获得控制权,可以在执行中将控制权转交给下层的子子程序,并在自身执行完成之后必须将控制权还交给上层部件。
实现
- 功能分解
- 集中控制
- 每个构件一个模块实现
- 主要是单向依赖
- 使用utility或tools等基础模块
主程序/⼦程序⻛格主要⽤于能够将系统功能依层次分解为多个顺序执⾏步骤的系统
面向对象式风格
- 部件
- 对象或者模块
- 连接件
- 功能或调用(方法)
设计决策及约束
- 依照对数据的使用情况,用信息内聚的标准,为系统建立对象部件。每个对象部件基于内部数据提供对外服务接口,并隐藏内部数据的表示。
- 基于方法调用(Method Invocation)机制建立连接件,将对象部件连接起来。
- 每个对象负责维护其自身数据的一致性与完整性,并以此为基础对外提供“正确”的服务。
- 每个对象都是一个自治单位,不同对象之间是平级的,没有主次、从属、层次、分解等关系。
实现
- 任务分解
- (委托式)分散式控制
- 每个构件一个模块实现
- 使用接口将双向依赖转换为单向依赖
- 将每个构件分割为多个模块,以保证单向依赖
- 每个模块内部可以是基于面向对象方法,也可以基于结构化
- 使用utility或tools等基础模块
效果
- 面向对象式风格的优点有:
- 内部实现的可修改性。
- 易开发、易理解、易复用的结构组织。
- 面向对象式风格的缺点有:
- 接口的耦合性。
- 标识(ldentity)的耦合性。
- 副作用。
- 面向对象式风格借鉴了面向对象的思想,也引入了面向对象的副作用,因此更难实现程序的“正确性”。例如,如果A和B都使用对象C,那么B对C的修改可能会对A产生未预期的影响。再例如对象的重入(Peentry问题:如果A的方法0调用了B的方法p0,而p0又调用了A的另一方法q0,那么就可能使得q0失败,因为在q0开始执行时,A正处于f0留下的执行现场,这个现场可能是数据不一致的。
⾯向对象式⻛格适⽤于那些能够基于数据信息分解和组织的软件系统
分层风格
- 部件
- 通常是程序或对象的集合
- 连接件
- 通常是指在受限可见性下的过程调用或方法调用
设计决策与约束
- 从最底层到最⾼层,部件的抽象层次逐渐提升。每个下层为邻接上层提供服务, 每个上层将邻接下层作为基础设施使⽤。也就是说,在程序调⽤机制中上层调⽤下层。
- 两个层次之间的连接要遵守特定的交互协议,该交互协议应该是成熟、稳定和 标准化的。也就是说,只要遵守交互协议,不同部件实例之间是可以互相替换的。
- 跨层次的连接是禁⽌的,不允许第 I 层直接调⽤ I+N(N>1)层的服务。
- 逆向的连接是禁⽌的,不允许第 I 层调⽤第 J(J<I)层的服务。
实现
- 关注点分离(每层逐次抽象)
- 层间接⼝使⽤固定协议(固定控制)
- 每层⼀或多个模块实现
- 单向依赖
- 层间数据传递建⽴专⻔模块
- 使⽤utility或tools等基础模块
分层⻛格适⽤于具备下列特性的系统:
- 主要功能是能够在不同抽象层次上进⾏任务分解的复杂处理;
- 能够建⽴不同抽象层次之间的稳定交互协议;
- 没有很⾼的实时性能要求,能够容忍稍许的延迟;
Model-View-Controller Style MVC风格
模型子系统的设计使其不依赖于任何视图或控制器子系统。
状态的更改会传播到视图子系统
- 部件
- 模型组件负责维护领域知识,并通知视图发生变更
- 视图组件负责向用户显示信息,并将用户手势发送到控制器
- 控制器
- 更改模式状态
- 将用户操作映射到模型更新
- 选择用于响应的视图
- 更改模式状态
- 连接件
- 程序调用、消息、事件
设计决策和约束
- Model负责维护数据与通知View信息的变更
- View负责显示信息给用户与传送用户操作给Controller
- Controller负责改变Model的状态与View的选择
- 模型、视图、控制是分别是关于业务逻辑、表现和控制的三种不同内容抽象。
- 如果视图需要持续地显示某个数据的状态,那么它⾸先需要在模型中注册对该数据的兴趣。 如果该数据状态发⽣了变更,模型会主动通知视图,然后再由视图查询数据的更新 情况。
- 视图只能使⽤模型的数据查询服务,只有控制部件可以调⽤可能修改模型状态的程序。
- ⽤户⾏为虽然由视图发起,但是必须转交给控制部件处理。对接收到的⽤户⾏为, 控制部件可能会执⾏两种处理中的⼀种或两种:调⽤模型的服务,执⾏业务逻辑;提供下⼀ 个业务展现。
- 模型部件相对独⽴,既不依赖于视图,也不依赖于控制。虽然模型与视图之间存在 ⼀个“通知变更”的连接,但该连接的交互协议是⾮常稳定的,可以认为是⾮常弱的依赖。
实现
- 模型-视图-控制⻛格需要为模型、视图和控制的每个部件实例建⽴模块实现,各模块间 存在导⼊/导出关系,程序调⽤连接件不需要显式的实现。
- 特定技术实现,通常专⽤于WEB
- Model与Controller单向
- Controller与View双向
- Model与View双向
- 典型实现
- View:JSP,HTML
- Controller:Servlet
- Model:JavaBean
适用于的应用:
- 用户界面的更改应易于在运行时进行,并且是可能的。
- 调整或移植用户界面不应影响应用程序功能部分的设计或代码。
观察者模式