[课业] 18 | 软工 | 软件体系结构基础

软件体系结构的发展

软件架构发展历史

1. 60年代
   计算机领域经过发展，到达第三代语言结合商业应用的阶段
   这样进行了十年，到了60年代末的时候，爆发了软件危机，开了NATO会议
   此次会议中，没有明确提出架构的定义，但是谈到了好多架构的朴素观点，今天看来依旧是很好的想法
2. 80年代末之前
   80年代末之前，架构多指物理架构，架构的概念还没有过多应用于软件领域
   1975到1986，Brooks、Lampson、Parnas等开始研究软件系统的组织，并发表研究成果
3. 1992年
   Perry和Wolf发表了文章，明去定义了软件架构的定义和概念，这是真正对软件架构有了清晰定义
   Perry文章里提出公式：{element, forms, rationale} = software architeture（软件架构基本元素（即指部件和连接件），构件方法，构建理由组合构成软件架构）；Barry Boehm又增加了constraints（限制条件）进入公式
   提出定义后，人们热衷于用形式化方法表述软件架构框架，火了一段时间，但是没有在工业界得到广泛应用
4. 图示——软件体系结构的十年(by Kruchten)
   
5. 图示——软件体系结构的黄金发展年代(by Shaw)
   
   这是体系结构的历史示意图
   由上到下：
   基础工作(Foundations)：信息隐藏，抽象数据类型，对质量的度量标准
   基础研究(Basic Researchs)：系统结构，风格分类
   概念提出(Concept Formulation)：架构描述语言，视角，体系结构评估等
   大量发展：专业术语，形成规范
   内在增强：开始提炼出架构模式，总结形式化方法等
   对外在的软件工程产生影响
   标准化、产业化

软件架构的重要性

1. 架构是高复杂度的、大规模的、高交互性的系统的关键连接部位
2. 使用架构的基本原因
   架构是共同交流的器件
   架构有助于做出好的早期设计决策（前期决策做得好，后面出错的代价就小，故很重要）
   架构是一种对系统的抽象表征，能降低复杂度，易于理解
   架构时可转换的（意为可从架构过渡到后面的内容如详细设计）

理解软件体系结构

概念和定义

1. Kruchten的定义
   软件架构包括：
   the structure and organisation by which modern system components and subsystems interact to form systems, and the properties of systems that can best be designed and analysed at the system level
   软件系统的组织
   组合成系统的结构化的元素和他们的接口，这种呢结合使元素们形成更大的系统
   组成系统的整体的指导性的架构风格
   软件架构不只与结构与行为有关，也与用途、功能、性能、弹性、重用性、可理解性、经济因素、技术限制和美学因素等有关
2. Shaw的定义
   软件体系结构 = {部件(Component)，连接件(Connector)，配置(Configuration)}
   部件是软件体系结构的基本组成单位之一，承载系统的主要功能，包括处理与数据
   连接件是软件体系结构的另一个基本组成单位，定义了部件之间的交互，是连接的抽象表示
   配置是对形式的发展，定义了部件以及连接件之间的关联方式，将它们组织成系统的总体结构
   一个简洁的软件体系结构定义：一个软件系统的体系结构规定了系统的计算部件和部件之间的交互
3. Perry的定义
   Software Architecture = {Elements, Form, Rationale)
   elements - what
   form - how
   rationale - why
   Process + Data + Connection
4. Wiki的定义
   软件架构设计主要考虑非功能需求，软件详细设计主要考虑功能性需求
   任何一种非功能属性都会影响架构，如秒杀购买和普通购买
5. 总结
   软件架构是一种高级抽象，代表从逻辑上对组织的思考（降低复杂性表示系统，可以逐渐化为系统的具体实现）
   软件架构是利益相关人等关注点（不同的利益相关有不同的关注点），不同人从不同角度看设计——多视角来表达高层抽象
   软件架构是一系列设计决策（早期设计决策）：每个决策都对后面的影响很深远，不容易修改；如果软件架构（早期决策）没做好，后面可能都没法写；如如果将秒杀系统与普通购买系统一起写，可能导致将普通购买系统挤崩溃；每个决策都一定要有理由，便于评判

区分物理和逻辑

1. 物理与逻辑
   高层与低层、抽象与实现
   逻辑层比物理层更高层

2. 举例
   从A地到B地，逻辑上是从A到B，中间过程具体怎么走是物理实现
   系统中物理上只有一块硬盘，C盘、D盘等概念是逻辑盘

3. 概念的、逻辑的、物理的
   概念的：只含有实体的名字和他们的关系
   逻辑的：在概念的基础之上，丰富了属性、主键、外键
   物理的：在逻辑的基础上，增加了表名、每一列的字段名称、类型等具体信息
   概念的、逻辑的、物理的，从简单到复杂，从高抽象到低抽象
   先有高层抽象
   例如数据库设计就涉及概念模型、逻辑模型、物理模型
   数据库设计中的三种模型及他们中的元素图例
   
   

4. 模块操作的逻辑表达和物理实现

   逻辑表达	物理实现
   一个模块调用另一个模块	接口调用（再加上如何传递数据对象的考虑）
   一个模块给另一个模块传递数据流	读写共享数据、pipe等

5. 物理实现的载体
   物理实现也是分层实现的
   低层：基本类型 + 基本控制结构
   中层：（以OO编程语言机制为例）类声明、实例创建与撤销、实例生命期管理；类权限控制机制；复杂机制：继承等
   高层：导入导出和名称匹配（详细见下）

6. 导入导出机制
   
   “一个模块依赖另一个模块”、“一个包依赖另一个包”

   A import B
   

   代表逻辑上的依赖关系
   实现时，为了知道具体是哪个包的哪个类，要进行名称匹配；匹配好类后，又要看是哪个类的哪个方法——实现过程也是物理上的逐层细化

7. 抽象与实现
   举例：一个方法，输入数据流，输出结果中将原来的大写字母转化为小写字母，将原来的小写字母转化为大写字母
   抽象图示
   
   实现图示
   
   逻辑上四个模块，这是逻辑上、概念上的模块，功能的的组织和描述
   逻辑上的模块是设计架构，展示的是功能
   实现视角中，增加配置和IO等模块，实现视角的模块能转化成代码，实现视角更接近代码
   抽象架构代表功能、实