软件架构设计风格及对比
本文最后更新于 2024-11-07,文章内容可能已经过时。
软件架构设计风格
架构风格名称 | 关键字及实例 | 简介 |
---|---|---|
数据流-批处理 | 传统编译器,每个阶段产生的结果作为下一个阶段的输入,区别在于整体 | 一个接一个,以整体为单位 |
数据流-管道-过滤器 | 传统编译器,每个阶段产生的结果作为下一个阶段的输入,区别在于整体 | 一个接一个,前一个的输出是后一个的输入 |
调用/返回-主程序/子程序 | 显式调用,主程序直接调用子程序 | |
调用/返回-面向对象 | 对象是构件,通过对象调用封装的方法和属性 | |
调用/返回-层次结构 | 分层,每层最多影响其上下两层,有调用关系 | |
独立构件-进程通信 | 进程间独立的消息传递,同步异步 | |
独立构件-事件驱动(隐式调用) | 事件触发推动动作,如程序语言的语法高亮、语法错误提示 | 不直接调用,通过事件驱动 |
虚拟机-解释器 | 自定义流程,按流程执行,规则随时改变,灵活定义,业务灵活组合 | 解释自定义的规则,解释引擎、存储区、数据结构 |
虚拟机-规则系统 | 自定义流程,按流程执行,规则随时改变,灵活定义,业务灵活组合 | 规则集、规则解释器、选择器和工作内存,用于DSS和人工智能、专家系统 |
仓库-数据库 | 现代编译器的集成开发环境IDE,以数据为中心。又称为数据共享风格 | 中央共享数据源,独立处理单元 |
仓库-超文本 | 现代编译器的集成开发环境IDE,以数据为中心。又称为数据共享风格 | 网状链接,多用于互联网 |
仓库-黑板 | 现代编译器的集成开发环境IDE,以数据为中心。又称为数据共享风格 | 语音识别,知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统,黑板、知识源、控制 |
闭环-过程控制 | 汽车巡航定速、空调温度调节,设定参数,并不断调整 | 发出控制命令并接受反馈,循环往复达到平衡 |
C2风格 | 构件和连接件、顶部和底部 | 通过连接件绑定在一起按照一组规则运作的并行构件网络 |
架构风格对比
架构风格 | 主要特点 | 主要优点 | 主要缺点 | 适合领域 |
---|---|---|---|---|
管道-过滤器 | 过滤器相对独立 | 功能模块复用,可维护性和可扩展性较强;具有并发性;模块独立性高 | 不适于交互性强的应用,对于存在关系的数据流必须进行协调 | 系统可划分清晰的模块;模块相对独立;有清晰的模块接口 |
面向对象 | 力争实现问题空间和软件系统空间结构的一致性 | 高度模块性;实现封装;代码共享灵活;易维护;可扩充性好 | 增加了对象之间的依赖关系 | 多种领域 |
事件驱动 | 系统由若干子系统构成且称为一个整体;系统有统一的目标;子系统有主从之分;每一个子系统有自己的事件收集和处理机制 | 适合描写系统组;容易实现并发处理和多任务;可扩展性好;具有类层次结构;简化代码 | 因为树型结构所以削弱了对系统计算的控制能力;各个对象的逻辑关系复杂 | 一个系统对外部的表现可以从它对事件的处理表征出来 |
分层风格 | 各个层次的组件形成不同功能级别的虚拟机;多层相互协同工作,而且实现透明 | 支持系统设计过程中的逐级抽象,可扩展性好;支持软件复用 | 不同层次之间耦合度高的系统很难实现 | 适合功能层次的抽象和相互之间低耦合的系统 |
数据共享风格 | 采用两个常用构件中央数据单元和一些相对独立的组件集合 | 中央数据单元实现了数据的集中;以数据为中心 | 适合特定领域 | 适合于专家系统等人工智能领域问题的求解 |
解释器风格 | 系统核心是虚拟机 | 可以用多种操作来解释一个句子,灵活应对自定义场景 | 适合特定领域 | 适合于模式匹配系统与语言编译器 |
闭环控制风格 | 通过不断的测量被控对象,认识和掌握被控对象;将控制理论引入架构构件 | 将控制理论引入到计算机软件架构中 | 适合特定领域 | 该系统中一定存在有目标的作用、信息处理闭环控制过程 |
- 感谢你赐予我前进的力量
赞赏者名单
因为你们的支持让我意识到写文章的价值🙏
本文是原创文章,采用 CC BY-NC-ND 4.0 协议,完整转载请注明来自 软件从业者Hort
评论
匿名评论
隐私政策
你无需删除空行,直接评论以获取最佳展示效果