【系统架构师】-软件架构设计

1、软件架构的概念

架构的本质
1、软件架构为软件系统提供了一个结构、行为和属性的高级抽象。
2、软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束。

架构的作用
1、软件架构是项目干系人进行交流的手段。
2、软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。
3、软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

架构设计就是需求分配，满足需求的职责分配到组件上。

通过不同的视角和视图

架构的4+1视图

以场景为核心、

逻辑视图为最终用户描述功能需求。

UML4+1视图

以用例为核心、建立需求分析模型

逻辑视图为系统分析、设计人员提供类与对象。

2、软件架构风格

架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

2.1、数据流风格

前一步的结果是后一步的输入内容【数据驱动】、分步处理

批处理序列：大量整体数据、无需用户交互
管道-过滤器：流式数据、弱用户交互

2.2、调用/返回风格

构件之间直接交互、紧耦合

主程序/子程序：面向过程
面向对象：对象的方法调用
分层：层与层之间的方法调用，包含OSI七层

2.3、独立构件风格

构件之间不直接交互、松耦合

丢失了对子函数的控制权、

事件触发，添加了事件管理机制、隐式调用

 2.4、虚拟机风格

解释器、规则引擎

2.5、仓库风格

以数据为中心，建立仓库，实现数据共享

1、数据库系统

2、黑板系统：记录、交换、跟进信息、触发知识源。如语音识别、知识推理。

3、超文本系统

现代软件编译器：以仓库风格为主，以 源码编译后作为数据中心 ，集成各类开发、调试工具

传统编译器：数据流-批处理

断点调试->事件风格

操作系统注册表->仓库风格

2.6、闭环控制架构（过程控制）

适合于嵌入式系统，用于解决简单闭环控制问题。
经典应用：空调温控，定速巡航。

2.7、C2风格

构件和连接件都有一个顶部和一个底部。

构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。

一个连接件可以和任意数目的其他构件和连接件连接。

当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

层次性架构风格、总线系统

2.8、层次架构风格

属于调用/返回风格

2.8.1、两层C/S架构

客户端：表示层、业务处理

服务端：数据层、数据读取/存储

2.8.2、三层C/S架构

表示层：客户端，只用于内容显示、提交请求

功能层：应用服务器，接受表示层数据，并读取数据层数据，业务处理。

数据层：数据服务器，数据存储

2.8.3、B/S架构

B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能

B/S架构的安全性难以控制

采用B/S架构的应用系统，在数据查询等响应速度上，要远远低于C/S架构

B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用

2.8.4、三层B/S架构

2.8.4.1、MVC架构风格

Model(模型)是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。

View(视图)是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。

Controller(控制器)是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

打破了层与层的独立交互

J2EE体系结构中:
视图(View): JSP
控制(Controller): Servlet
模型(Model): EntityBean、Session Bean 、EJB

2.8.4.2、MVP架构风格

MVP是MVC的变种
MVP实现了V与M之间的解耦(V不直接使用M，修改V不会影响M)
MVP更好的支持单元测试(业务逻辑在P中，可以脱离V来测试这些逻辑;可以将一个P用于多

个V，而不需要改变P的逻辑)
MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理

主要的程序 逻辑在Presenter里实现 。

通过定义好的接口进行交互

用于处理view频繁的修改

如：点赞、收藏等。

定时异步发送请求

2.8.4.3、MVVM架构

视图View

View-Model：动态渲染、监听数据变动

模型Model

2.8.4.4、RIA架构

富互联网 rich internet

Flex 相当于小程序，伪客户端

RIA结合了C/S架构反应速度快、交互性强的优点，及B/S架构传播范围广及容易传播的特性
RIA简化并改进了B/S架构的用户交互
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面

2.8.5、混合架构风格

内外有别模型

查改有别模型

 2.9、基于服务的架构SOA

对象、构件、服务

服务构件粗粒度，传统构件细粒度居多

服务构件的接口标准化，主要是WSDL接口，传统构件常以具体API形式出现服务构件的实现与语言无关，传统构件绑定某种特定语言

服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制

Web Service、ESB

特点：

提供位置透明性的消息路由和寻址服务

提供服务注册和命名的管理功能

支持多种的消息传递范型

支持多种可以广泛使用的传输协议

支持多种数据格式及其相互转换

提供日志和监控功能

WSDL就是WebService接口对应的WSDL文件，该文件通过xml格式说明如何调用，可以看作WebService的接口文档(使用说明书) 

2.10、微服务

特点

小,且专注于做一件事情

轻量级的通信机制

松耦合、独立部署

优势

技术异构性

弹性

扩展

简化部署

与组织结构相匹配

可组合性

对可替代性的优化

挑战

分布式系统的复杂度

运维成本

部署自动化

服务间依赖管理
DevOps与组织结构
服务间依赖测试

2.11、MDA模型驱动架构

1）平台独立模型(PIM)：具有高抽象层次、独立于任何实现技术的模型。
2）平台相关模型(PSM)：为某种特定实现技术量身定做，让你用这种技术中可用的实现上构造来描述系统的模型。PIM会被变换成一个或多个PSM。
3）代码Code：用源代码对系统的描述(规约)。每个PSM都将被变换成代码。

 

3、架构描述语言ADL

形式化的语言

基本元素：

1、构件：计算或数据存储单元

2、连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。

3、架构配置：描述体系结构的构件与连接件的连接图

4、特定领域软件架构DSSA

基本活动：

1、领域专家:有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。
领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
2、领域分析人员:领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
3、领域设计人员:领域设计人员应由有经验的软件设计人员来担任。
4、领域实现人员:领域实现人员应由有经验的程序设计人员来担任。

建立过程 

 

 

5、基于架构的软件开发ABSD

ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。

ABSD方法有三个基础。

第一个基础是功能的分解。在功能分解，ABSD方法使用已有的基于模块的内聚和耦合技术;

第二个基础是通过选择架构风格来实现质量和业务需求;

第三个基础是软件模板的使用。

视角与视图:从不同的视角来检查，所以会有不同的视图。4+1

用例用来捕获功能需求、特定场景用来捕获质量需求

开发过程：