系统架构设计师 - 软件架构设计(1)

Al_tair

于 2024-08-28 08:00:00 发布

阅读量1.4k

点赞数 53

分类专栏：软考高项文章标签：系统架构架构

本文链接：https://blog.csdn.net/Al_tair/article/details/141595741

版权

软考高项专栏收录该内容

18 篇文章 0 订阅

订阅专栏

软件架构设计

软件架构设计（20多分）最重要

大家好呀！我是小笙，本章我主要分享系统架构设计师 - 软件架构设计(1)知识，希望内容对你有所帮助！！

软件架构设计（20多分）最重要

软件架构的概念 ★ ★ ★

架构的本质

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

架构的作用

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

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

例题

1、以下叙述，表达系统是否满足用户的功能性需求 不是软件架构的主要作用

在设计变更相对容易的阶段，考虑系统结构的可选方案
便于技术人员与非技术人员就软件设计进行交互
展现软件的结构、属性与内部交互关系
表达系统是否满足用户的功能性需求

架构的 4+1 视图

逻辑视图：展示系统的功能性设计，关注系统的静态结构
开发视图：描述系统的模块结构，强调代码的组织和开发过程中的考虑
物理视图：展示系统的物理部署，关注硬件配置和系统组件的分布
场景视图：通过使用案例和场景展示系统的动态行为和交互
过程视图（进程视图）：展示了系统在运行时的行为和动态交互

例题

1、1995年Kruchten提出了著名的.“4+1"视图，用来描述软件系统的架构。在“4+1"视图中， 逻辑视图 用来描述设计的对象模型和对象之间的关系； 开发视图 描述了软件模块的组织与管理； 过程视图 描述了设计的并发和同步特征

逻辑视图
用例视图
过程视图
开发视图

软件架构风格 ★ ★ ★ ★ ★

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

五大架构风格	子风格
数据流风格	批处理、管道 - 过滤器
调用/返回风格	主程序/子程序、面向对象、层次结构
独立构件风格	进程通信、事件驱动系统（隐式调用）
虚拟机风格	解释器、规则系统
仓库风格	数据库系统、黑板系统、超文本系统
…	…

数据流风格

数据驱动：前一步处理结果是后一步的输入内容

数据流子风格

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

优点

松耦合【高内聚-低耦合】
良好的隐蔽性、重用性、可维护性以及可扩展性【标准接口适配】
支持并行

缺点

交互性较差
复杂性较高
性能较差（每个过滤器都需要解析与合成数据)

典型实例

传统编译器
网络报文处理

调用/返回风格

主函数调用子函数之后返回执行的结果

调用/返回子风格

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

优点

良好的重用性，只要接口不变可用在其它处
可维护性好、可扩展性好，支持递增设计

缺点

并不是每个系统都方便分层
很难找到一个合适的、正确的层次抽象方法
不同层次之间耦合度高的系统很难实现

特点

各个层次的组件形成不同功能级别的虚拟机
多层相互协同工作，而且实现透明

独立构件风格

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

优点

松耦合
良好的重用性、可修改性、可扩展性

缺点

构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序
数据交换的问题
既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题

特点

系统由若干子系统构成且成为一个整体；系统有统一的目标；子系统有主从之分；每一子系统有自己的事件收集和处理机制

虚拟机风格

解释器（可以灵活应对自定义场景）
规则为中心（在解释器的基础上增加经验规则，适用于专家系统）

优点：适用于需要“自定义规则”的场合

缺点：复杂度较高

仓库风格

以数据为中心

数据库系统
黑板系统：语音识别、知识推理（在以数据为中心的基础上，使用中心数据触发业务逻辑部件）
超文本系统

闭环控制风格

适合于嵌入式系统，用于解决简单闭环控制问题

经典应用：空调温控，定速巡航

C2架构风格（了解）

C2架构的基本规则：

构件和连接件都有一个顶部和一个底部
构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
一个连接件可以和任意数目的其他构件和连接件连接
当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部

层次架构风格

两层 C/S、三层 C/S、B/S 架构、混合架构

两层 C/S

表示层以及数据层

特点

开发成本较高
客户端程序设计复杂
信息内容和形式单一以及用户界面风格不一
软件移植困难、软件维护和升级困难
新技术不能轻易应用

三层 C/S

表示层、功能层以及数据层

B/S 架构

表现层、中间层、数据访问层以及数据架构层

MVC 架构风格
- Model(模型)：是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据（Entity Bean、Session Bean）
- View(视图)：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的（JSP）
- Controller(控制器)：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据（Servlet）
MVP 架构风格
- MVP是MVC的变种
- MVP实现了V与M之间的解耦（V不直接使用M，修改V不会影响M)
- MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑；可以将一个P用于多个V，而不需要改变P的逻辑）
- MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理

混合架构

主要体现在内外以及查改的区别

基于服务的架构（SOA）

服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持

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

SOA 的实现方式

Web Service（服务请求者、服务提供者以及服务注册中心）
ESB (服务请求者与服务提供者之间解耦，比如企业服务总线)
- 提供位置透明性的消息路由和寻址服务
- 提供服务注册和命名的管理功能
- 支持多种的消息传递范型
- 支持多种可以广泛使用的传输协议
- 支持多种数据格式及其相互转换
- 提供日志和监控功能

微服务架构

微服务顾名思义，就是很小的服务，它属于面向服务架构的一种

特点

小，且专注于做一件事情
轻量级的通信机制
松耦合、独立部署

优势

技术异构性：允许不同服务使用的技术可以不用
弹性、扩展
简化部署
与组织结构相匹配
可组合性
对可替代性的优化

劣势

分布式系统的复杂度
运维成本
部署自动化
Dev0ps与组织结构
服务间依赖测试、依赖管理

微服务架构实现

团队级，自底向上开展实施
一个系统被拆分成多个服务，粒度细
无集中式总线，松散的服务架构
集成方式简单（HTTP/REST/JSON）
服务能独立部署

MDA 架构（了解）

MDA的主要目标：Portability(可移植性)，interoperability(互通性)，Reusability(可重用性)

MDA的3种核心模型：

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

架构描述语言ADL ★ ★ ★

ADL 的三个基本元素

构件：计算或数据存储单元
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则
架构配置：描述体系结构的构件与连接件的连接图

例题

1、架构描述语言(ADL)是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、 连接件 和架构配置

架构风格
架构实现
连接件
组件约束

特定领域软件架构 (DSSA) ★ ★ ★

领域分析：建立领域模型
领域设计：获得 DSSA 架构
领域实现：开发和组织可复用信息

领域人员

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