软件架构设计
2024-11-12 12:59:46 0 举报AI智能生成
软件架构设计
作者其他创作
大纲/内容
软件架构设计
指系统的响应能力，即经过多长时间才能对某个事件做出响应。
设计策略：资源调度、优先队列
性能
系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度类表示。
设计策略：冗余、心跳
可用性
可靠性
指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
设计策略：追踪审计
安全性
指能够快速地以较高的性能价格对系统进行变更的能力。
设计策略：信息隐藏、接口实现隔离
可修改性
质量属性
为实现某种特定的质量属性，一个或多个构件所具有的特性。
敏感点
影响多个质量属性的特性，是多个质量属性的敏感点。
权衡点
指架构设计中潜在的、存在问题的架构决策所带来的隐患。
风险点
XXX要求是可以实现（或接受）的
非风险点
重要概念
某个生成该刺激的实体(人、计算机系统或者任何其他刺激器)。
刺激源
该刺激是当刺激到达系统时需要考虑的条件。
刺激
某个制品被激励。这可能是整个系统(或系统的一部分)
制品
该刺激在某些条件内发生。当激励发生时，系统可能处于过载运行或者其他情况。
环境
该响应是在激励到达后所采取的行动。
响应
当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
响应度量
六个方面
概要
形成场景
描述架构
对场景的分类和确定优先级
对场景进行单个评估
评估场景的相互作用
形成总体评价
分析过程
软件架构分析法SAAM
描述和介绍阶段
场景和需求收集
调查和分析阶段
架构视图和场景实现
测试阶段
属性模型分析和构造
报告阶段
属性模型折中
架构权衡分析法ATAM
树根
属性分类
质量属性场景
质量效应树
场景是从()的角度对与系统的交互的简短描述
评估方法：基于场景的方式
评估方式
6、软件架构评估
领域分析
领域设计
领域实现
现有系统需求
需求分析
系统设计
系统实现
新系统需求
双生命周期模型
领域工程
应用工程
SEI模型
企业工程
三生命周期模型
模型
逐步演化
减少风险
增入较大
演化方式
直接替换
风险较大
增入较少
革命方式
建立方式
对该领域具备长期和深厚的经验
一个用于构建产品的好的核心资源库
好的产品线架构
好的管理支持
成功因素
7、产品线
独立部署单元
作为第三方的组装单元
没有可见状态
构件
一个实例单元，具有唯一的标志。
封装了自己的状态和行为
可能具有状态，此状态外部可见。
对象
构件定义
构件是一组需要同时部署的原子构件。
树形目录
基于关键词检索
不同维度打标签
切面（刻面检索法）
人类思维（百度百科）
超文本检索法
检索与提取构件
理解与评价构件
修改构件
基于功能的组装技术
基于数据的组装技术
面向对象的组装技术
组装构件
由构件引起的失配
由连接子引起的失配
由于系统成分对全局体系结构的假设存在冲突引起的失配等。
组装失配
构件复用
数据库管理系统和操作系统等
独立而成熟的构件
会产生资源冲突、覆盖等影响
有限制的构件
不兼容性、资源冲突等进行了处理
适应性构件
目前一些软件商提供的大多数软件产品都属这一类
装配的构件
可以利用重新“包装”或写接口来实现构件的版本替换。
可修改的构件
构件分类
CORBA
会话Bean：实现业务逻辑
实体Bean：实现O/R映射
消息驱动Bean：处理并发与异步访问
J2EE【EJB】
DNA 2000
三大构件标准
面向需求：精力于业务逻辑本身
设计与实现隔离：构件对外发生作用或构件间的交豆，都是通过接口进行的 ，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
业务的分隔和包容性：可按照不同的业务进行功能划分
隔离复杂的系统资源
获取可复用的资产
管理可复用的资产
使用可复用的资产
软件复用
符合标准的交互模型
屏蔽差异
提供对应用构建的管理
中间件优点
伺服对象Servant：Corba的真正实现，负责完成客户端请求
对象适配器POA：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口
对象请求代理ORB：负责在分布式环境中透明地收发请求和响应
中间件技术Corba
中间件
8、构件与中间技术
MVC、MVP、MVVM、REST、Webservice、微服务
架构
Redis、MemCache、Squid
缓存
集群、CDN
并发分流
主从复制、内存数据库、反规范化技术、NoSQL、分库分表
数据库
Mybatis、Hibernate
持久化
Hadoop、FastDFS、区块链
分布存储
9、Web架构设计
需求之后，设计之前
所处阶段
将需求分配到各个构件上
核心任务
软件系统架构是关于软件系统的结构、行为和属性的高级抽象
软件系统架构不仅指定了软件系统的组织结构和拓扑结构，而且显示了系统需求和构成组件之间的对应关系，包括设计决策的基本方法和基本原理。
定义
是项目关系人进行交流的手段
有助于循序渐进的原型设计
是可传递和可重用的模型
对开发的指导和规范化意义不容忽略
软件架构的作用
连接件
架构配置
三个基本元素
架构描述语言ADL
UML：逻辑视图
最终用户：功能需求 类与对象
逻辑视图
UML：实现视图
程序员 侧重模块的组织和管理
开发视图
UML：部署视图
系统工程人员：侧重软件到硬件的映射
物理视图
UML：进程视图
系统集成人员：侧重系统性能和可用性
过程视图
UML：用例视图
分析测试人员
场景
\"4+1\"视图(类UML)
1、软件架构的概念⭐⭐⭐
架构设计的生命周期
是架构驱动的，强调由业务、质量和功能需求组合的架构设计
ABSD方法是自顶向下，递归细化，直到能产生软件构件和类
功能分解
选择架构风格实现质量和业务需求
作为软件模板的使用
三个基础
需求获取
生成类图
对类进行分组
把类打包成构件
标识构件
需求评审
架构需求
提出架构模型
映射构件
分析构件的相互作用
生成软件架构
设计评审
架构设计
架构规格说明书
测试架构需求的质量设计说明书
输出结果
架构文档化
标识潜在风险
目的
架构复审
分析与设计
构件实现
构件组装
系统测试
架构实现
需求变化归类
制定演化计划
构件变动
更新构件的相互作用
构件组装与测试
技术评审
架构演化
开发过程
2、基于架构的软件开发方法ABSD⭐⭐⭐⭐
架构设计的一个核心问题是能否达到架构级的软件复用。
软件架构风格是描述一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。
交互差;分阶段处理数据，上阶段的结果是下一阶段的输入
特点
大量整体数据、无需用户交互
批处理序列
流式数据、、弱用户交互
良好的复用性
可维护可扩展性强
支持并发
优点
管道-过滤器
网络数据包处理
传统编译器
经典实例
数据流风格
主程序/子程序
高度模块性、封装功能、代码共享、灵活性、易维护性、可扩充性
调用时需要知道对方对象ID，这样会产生紧耦合
缺点
面向对象
B/S C/S
MVC
MVVM
利于复用;每一层只影响两层
分层不易;层次多了影响性能
层次结构
调用/返回风格
不直接调用
进程通信
事件驱动系统(隐式调用)
IDE（联动机制）、订阅发布
独立构件
构建自定义语言的执行引擎
需要自定义规则的场合（低代码）
解释器
基于解释器，适用与专家系统
基于规则的系统
虚拟机风格
数据库系统
语音识别、知识推理
黑板系统
超文本系统
以数据为中心【仓库风格】
空调控温、定速巡航
适用于嵌入式、解决简单的闭环控制问题
闭环控制架构（过程控制）
可以概括为通过连接件绑定在一起按照一组规则运作的并行构件
构建连接件都有一个顶部和底部
C2
计算无关模型（CIM）
平台独立模型（PIM）
平台相关模型（PSM）
代码Code
MDA
其他风格
5大类+3
不分行业领域通用
水平复用
分行业领域，专用
垂直复用
复用维度
开发过程中只要发现有可复用的资产，就对其进行复用
机会复用
开发之前，要进行规划，以决定哪些需要复用
系统复用
复用类型
复用的基本过程主要包括3个阶段:首先构造/获取可复用的软件资产，其次管理这些资产，最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统
基本过程
软件架构复用
3、软件架构风格⭐⭐⭐⭐⭐
目的：建立领域模型
目的：获取DSSA
目的：开发和组织可复用信息
基本活动
提供领域中系统的需求规约和实现的知识
领域专家
领域分析人员
领域设计人员
领域实现人员
参与人员
领域架构师
领域开发环境
应用工程师
领域特定的应用开发环境
操作员
应用执行环境
三层次模型
4、特定领域软件架构DSSA
0 条评论
下一页
