一线架构师实践指南
2020-10-10 10:10:57 0 举报一线架构师实践指南-读书笔记-图例
作者其他创作
大纲/内容
用户级
设计过程中的衍生需求会是原始需求的50倍之多。架构师需要清除需求类型、需求影响架构的原理、质量属性间的相互影响关系等。
内存争用
技术可行性
发现场景
用例图
代码视图
用户需求
严格执行人行统一规定的利率
通用程度高
鲁棒图3元素和MVC的相似与不同
5. 把握严格程度
后期账户销户界面
客户资料
网络争用
安全性
功能需求（减法）
场景
架构实践中最常见的短板
分层：职责分离
维护性
与原有行长办公系统集成
Schema相同
发现鲁棒图3中元素的思维方式
通信开销
综合初步设计，确定高层分隔
关键功能
通用
CPU争用
机制：通用单元分离
易分析型易改变性稳定性易测试性
- 计算和通信开销小- 减少计算和通信时内存、硬盘、CPU、网络冲突
工作量比例
项目前期过程
其他非功能需求
需求捕获、需求分析，以及系统分析之间的关系
解决方案复杂度增加100%
更到位地说明
持续可用性
工作量均衡原则
用户界面
复制方式
项目和团队情况对架构设计程度的影响
分层的细化
Separate-Schema（独立模式）
边界对象
模块
CA阶段
开发架构1. 程序单元 2. 程序单元组织
提交《方案书》
职责分离原则
controller
数据访问逻辑
正解
覆盖面窄
实现（implementation）
开发级
6种数据架构策略的二维比较图
控制对象
层次：概念架构与细化架构
软件单元
物理架构图设计的逆行思维框架
经验
*详细设计*编码实现
合成
约束（加法）
二维需求观
人的因素考虑
业务需求
多方涉众
1.25法则（数据来源：《软件工程的事实与谬误》）
设计模式
业界当前技术环境
结果层
愿景
思维要点
Partitioned（分区）
通用专用分离原则
目标
架构、框架、设计模式、模块对比关系图
客户流水
业务逻辑
远程调用接口
技术环境
定量参考
2. 多方涉众利益
框架
架构
打印设备
提供依据
面向对象或结构化
提供目标
效率
实体对象
最初基础
序列图
逻辑架构1. 职责划分 - 逻辑层（layer）- 子系统、模块- 管件类2. 职责间协作- 接口- 协作关系
1. 架构设计应支持多个并行的详细设计2. 架构设计和详细设计之间应该没有缝隙3. 团队、项目影响架构设计程度。架构可以多点、详细设计则会少点。反之也行。之间的线可浮动。
类
“销户”的鲁棒图
非功能需求、性能、持续可用性、安全性、可扩展性
开发实现
时间
作为基础
易理解性易学性易操作性
职责暴露行为
用户群及使用环境
协作基
决策
粒度：分区的引入
约束性需求（上下文）
详细设计
3种子系统划分策略背后的4大原则
最终目标
PA阶段
软件质量属性关系矩阵：https://22bab6f0.wiz03.com/wapp/pages/view/share/s/0yKHrM3Ni4oI2Zua_h2rhGFM25W8WG3PekMF2ze39h37lw5G
场景思维是方法核心
Model
易用性
设备
运行架构1. 控制流 - 进程、线程- 终端服务程序 2. 控制流组织- 系统启动与停机- 控制流通信- 加锁与同步
职责划分
目标层
用户
考虑非功能需求，做出相应决策
1
折衷依据
运用5大原则确定关键质量
机制的提取
约束条件
功能
质量
约束
业务级需求
用户级需求
开发级需求
覆盖面广
概念（conceptual）
使用实例文档
适合性准确性互操作性依从性安全性
运用5大原则的整体思路
系统分析
协作关系
业务层
本书认为的把阶段当视图了。但也许人家只是没有标明这几个视图的阶段。还是比较好的几个视图观念。
VS.
可管理性
- 节点选择、分布、拓扑- 软件单元和数据单元的职责和分布- 增加Cache等设计
场景卡
面向Table或文件
架构设计
大型系统成败的关键
需求分析
非复制方式
设计
以场景为“跳板”的非功能目标设计思维
运行视图
业界影响最为广泛的需求分类法
阶段一：把我需求特点，确定架构驱动力
引起回溯
关键质量
策略
可靠些
可伸缩性
数据一致性
独立
高
集中
分区（水平）
复制
子集
重组
专用
物理架构1. 物理节点 - PC、服务器- 单片机、单板机、专用机- 软件安装、部署、烧写- 系统软件选型 2. 物理节点拓扑- 连接方式、拓扑结构- 物理层- 冗余考虑
鲁棒图
4类约束在矩阵中的位置
需求方及业务环境
利息税率
此时： 需求与架构并行进行
成熟性容错性易回复性
鲁棒性
灰盒包图（包含关键类）
RA阶段
细化架构
使用环境
高层组件及其关系
数据层
分层和机制位于不同维度
Reorganized（重组）
划分依据
思维层
成熟性容错性易恢复性
数据架构1. 持久数据单元- 文件- 关系数据库- 实时数据库2. 数据存储格式- 文件格式- 数据库Schema
架构师应掌握
技术通用部分
明确
银行工作人员
互操作性
子系统
概念架构
基于关键功能，进行初步设计
利息率
4个月就交付上线
利率调整功能
物理架构1. 物理节点 2. 物理节点拓扑
需求捕获
明确关键
数据
性能
问题的广度
- 投资与维护成本合理- 特定性能目标的满足
+
用例
提交《需求规格说明书》
适应业务变化
技能分离原则
分隔与封装
每个视图的技术关注点
阶段三：细化架构设计，关注不同视图
可恢复性
用户逻辑
可移植性
功能+质量（问题）
2
接口
用户确认
提供分隔与封装经验
可扩展性
影响性原则
数据架构1. 持久数据单元2. 数据存储格式
关键质量 + 业务需求与约束
面向文件
经济性
互相促进
系统运行于Unix平台
时间特性资源特性
构建环境
误解
活期账户
view
架构中引入分区，支持迭代开发
业务环境
需求
质量需求（减法）
数据单元
质量属性分类
易维护性
可行性分析
计算开销
磁条读取设备
外部对象
成熟性
硬盘争用
需求复杂度增加25%
实践步骤
面向控制流
设计决策
需求复杂度与解决方案复杂度的关系
1. 分类适合实践
物理节点
领域通用部分
项目负责人需求人员架构师
3. Checklist思维
组织级
架构设计关注点分离原理示意图
数据争用
概念视图
愿景文档
业务需求与约束
任职于各储蓄所和分理处的柜员计算机水平普遍不高
外部和内部质量
接口是关键类
面向节点
Subset（子集）
本文为《一线架构师实践指南-温昱》读书笔记。需看原著，请购买正版书籍。
系统需求
开发架构1. 程序单元 - 源文件、配置文件- 程序库、架构- 目标单元 2. 程序单元组织- Project划分- Project目录结构- 编译依赖关系
功能需求
ISO 9126将质量属性描述成“树”，但实际上应该是“网”
分析师应掌握
Replicated（复制）
目标-场景-决策表
逻辑架构1. 职责划分 2. 职责间协作
销户
实现程度高
架构师
模块视图
特定应用部分
概念性架构
质量属性
分区的引用
计算利息
逻辑架构整体协作关系
可维护性
适应性易安装性共存性易替换性
必要扩充
网络
《ISO 9126》 定义的可靠性就远不及实际设计中的考虑全面
大规模并行开发的基础
行为需求
3
需求分析师
软件需求规格说明
4. 考虑矛盾关系
架构设计应进行到什么程度
提供基础
分解
架构设计（解决方案）
开发方及构建环境
架构师与需求分析师对需求的掌握对比
用例规约
可靠性
展现层
运行架构1. 控制流 2. 控制流组织
提交《架构设计文档》
Centralized（集中）
架构设计依赖：明确的业务需求全面的用户需求典型的行为需求
阶段二：根据重大需求，确定概念架构
Schema不同
架构本身考虑
*逻辑架构 *数据架构*开发架构 *运行架构*物理架构
架构模式
设计内存
功能性
架构思维
问题的深度
笼统
需求调研
项目视图与范围文档
决定性原则
思维要领
可修改性
约束是架构设计要解决的问题的上下文
粒度维：分区的引入
0 条评论
下一页
