软件架构概述

基于架构的软件开发模型明确地把整个软件过程划分为架构需求、设计、文档化、评审（评估）、实现、演化等6个子过程。

• 在面向对象技术中，通过抽象、封装、继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

架构需求与软件质量属性

架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为了满足架构需求（质量需求）寻找适当的战术。软件属性包括功能属性和质量属性，但是软件架构重点关注的是质量属性，因为在大量的可能结构中，可以使用不同的结构来实现相同的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着对结构选择的决策，而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。

软件质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等6个方面。

软件架构风格

软件架构设计的一个核心问题是能否使用重复的软件架构模式，即能否达到架构级别的软件重用。

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。其中，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

架构风格最关键的四要素内容，即提供一个词汇表、定义一套配置规则、定义一套语义解释原则、定义对基于这种风格的系统所进行的分析。Garlan 和 Shaw 根据次框架给出了通用架构风格的分类 ：

• 数据流风格：批处理序列；管道/过滤器
• 调用/返回风格：主程序/子程序；面向对象风格；层次结构
• 独立构件风格：进程通信；事件系统
• 虚拟机风格：解释器；基于规则的系统
• 仓库风格：数据库系统；超文本系统；黑板系统

数据流风格

所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构，就像工厂中的汽车流水线一样，数据就像汽车零部件一样在流水线的各个节点上被加工，最终输出所需要的结果。主要包括两种具体的架构风格：批处理序列和管道-过滤器。

批处理序列

批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传送在步与步之间作为一个整体。典型应用：

• 经典数据处理
• 程序开发
• windows下的BAT程序

管道-过滤器

过滤器必须是独立的实体，它不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。典型的例子是以UNIX shell 编写的程序；传统的编译器。该风格架构具有好处如下：

• 使得软构件具有良好的隐蔽性和高内聚、低耦合特点；
• 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成
• 支持软件重用。只要提供适合在两个过滤器之间传输的数据，任何两个过滤器都可以被连接起来
• 系统维护和增强性能简单。新的过滤器可以添加到现有系统中来，旧的可以被改进的过滤器替换掉
• 允许对一些如吞吐量、死锁等属性的分析
• 支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行
  

存在的若干不利因素如下：

• 通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
• 不适合处理交互的应用
• 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，导致系统性能下降，增加编写过滤器的复杂性

2者风格比较

共同点：把任务分成一系列固定顺序的计算单元（组件），组件间只通过数据传递交互
区别：批处理是全部的、高潜伏性的，输入时可随机存取，无合作性、无交互性。而管道/过滤器是递增的，数据结果延迟小，输入时处理局部化，有反馈、可交互。批处理强调数据传送在步与步之间作为一个整体，而管理/过滤器无此要求。

仓库风格–黑板系统

黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。

• 知识源： 包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成
• 黑板数据结构：黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断改变黑板数据来解决问题
• 控制：控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识

ps： 黑板系统，个人看定义，感觉有点像训练模型。

层次系统架构风格

二层及三层C/S架构风格

二层C/S结构为单一服务器且以局域网为中心，难以扩展至大型企业广域网或Internet ；软、硬件的组合集成能力有限；服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；数据安全性不好，因为客户端程序可以直接访问数据服务器。

因此，三层C/S结构应运而生，将应用功能分成表示层、功能层、数据层。

• 表示层负责处理用户的输入和向客户的输出
• 功能层负责建立数据库的连接，根据用户的请求生成访问数据库的SQL语句，并将结果返回给客户端
• 数据层负责实际的数据库存储和检索，响应功能层的数据处理请求，并将结果返回给功能层

ps :其实就是前端输入（表示层）、接口逻辑（功能层）、数据库sql 执行（数据层）

MVC

该架构采用关注点分离的方针来将可视化界面呈现、UI处理逻辑、业务逻辑分离出来，包括 模型（model）-视图（view）-控制器（controller）

• model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。model 接受controller 的请求并完成相应的业务处理，在状态改变的时候向view 发出相应的通知
• view 实现可视化界面的呈现并捕捉最终用户的交互操作
• view捕捉到用户交互操作后直接转发给controller ，后者完成相应的ui 逻辑。如果需要涉及业务功能的调用，controller 会直接调用model。在完成ui处理后，controller 会根据需要控制原view 或者创建新的view 对用户交互操作予以响应。

ps : model 完成业务逻辑，controller 完成ui处理逻辑 ，view 完成可视化界面呈现

MVP

从MVC演化而来，全称是 Model-View -Presenter ,Model 提供数据，View负责显示，Presenter 负责逻辑处理。与MVC主要的区别在于：MVC中元素之间混乱交互主要体现在允许view 和model直接进行 交流，这在mvp 是不允许的，而且MVP不仅避免了view 和model 之间的耦合，还进一步降低presenter 对view 的依赖。本质上，presenter 依赖的是一个抽象化的view ，这样的好处是使定义在presenter 中的ui 处理逻辑变得易于测试。

ps ：相当于将所有的交互都放在presenter ，由于依赖一个抽象的view ，还可以脱离用户接口来进行单元测试。

面向服务的架构