框架设计总结
温昱老师的《一线架构师实现指南》读完好几天了,本书很多大牛都有推荐,自己从头到底一字不漏的看了,很多关键的方法,做了标记,看了多次,是一本介绍构架设计方面很好的书,准备把它做为工具书,在开始中用好其中的方法。
大学学的软件工程,软件设计要从需求分析、可行性分析、概要设计、软件设计、软件开发和测试,说的是一个大的过程,具体到针对一个项目时还是会感觉无从下手;本书提供的ADMEMS方法体系,把这一过程形成方法体系,让框架设计的操作性更强,四个核心主张:
1) 方法体系是大趋势。ADMEMS
2) 质疑驱动的架构设计。质疑“缺点儿什么”
3) 多阶段方法。多阶段多视图,提供了5视图方法。
4) 内置最佳实践的方法。ADMEMS中包括了10条经验、架构设计的整体思路、用鲁棒图进行初步设计、矩阵方法、约束的四大类型。。。
ADMEMS(Architectural Design Method has been Extended to Method System)架构设计方法已扩展到方法体系,主要包括:3个阶段,1个贯穿环节,
作者:pyy
目录
1. 预备架构(Pre-architecture)阶段(简称PA阶段).......................................... 2
2. 概念架构(Conceptual-architecture)阶段(简称CA阶段)............................. 6
1.1. 初步设计....................................................................................................... 7
1.2. 高层分割....................................................................................................... 9
1.3. 考虑非功能需求......................................................................................... 11
3. 细化架构(Refined-architecture)阶段(简称RA阶段)................................. 12
3.1. 逻辑架构..................................................................................................... 13
1. 先从划分子系统的3种必用手段讲起................................................ 13
2. 逻辑架构设计的10条经验要点.......................................................... 16
3. 逻辑架构设计中设计模式应用............................................................ 17
4. 贯穿案例................................................................................................ 17
3.2. 物理架构、运行架构、开发架构............................................................. 19
1. 物理架构视图........................................................................................ 19
2. 运行架构视图........................................................................................ 20
3. 开发架构视图........................................................................................ 21
4. 贯穿案例................................................................................................ 22
1. 预备架构(Pre-architecture)阶段(简称PA阶段)
概括为一句话:全面理解需求;提供明确的以ADMEMS矩阵为核心的“四步法”:
1) 需求结构化
2) 分析约束影响
3) 确定关键质量
4) 确定关键功能
矩阵方法,二维需求表如下,从各角度分析需求
银行系统示例
需求层次——需求方面矩阵,要考虑的要素
2. 概念架构(Conceptual-architecture)阶段(简称CA阶段)
重大需求塑造概念架构,概念架构满足“架构=组件+交互”的基本定义,只不过更改关注高层组件,不应涉及接口细节.
三个步骤:
1. 初步设计,借助鲁棒图进行以发现职责为目的的初步设计
2. 高层分割,对系统这个墨盒进行高层切分,例如切分为多个二级系统,或者直接切分为具体子系统。
3. 考虑非功能需求,使用目标-场景-决策表.
1.1. 初步设计
鲁棒图,下图所示的三个要素,进行表示
10条经验
1) 守建模原则
2) 简化建模语言
3) 宁3种元素的发展思路
4) 增量建模
5) 实体对象#持久化对象
6) 只对关键功能(用例)画鲁棒图
7) 每个鲁棒图有2-5个控件对象
8) 勿关细节
9) 勿过分关注UI,除非是辅助或验证UI设计
10) 鲁棒图#用例规约的可视化
例子:
.1.2. 高层分割
二种套路:切系统为系统,切系统为子系统
切系统为系统是指
系统比较复杂,须要进行两组高层切分.
首先把系统切成更小一级的系统,每个更小一级的系统都可以有单独的需求,设计,实现。。。
之后,针对每个“更小一级的系统”进行“切系统为子系统”
示例:
切系统为子系统,最常见的方式就是分层,PM系统示例
4层架构方式
分层有不同的角度,而且互相不矛盾。
① Layer:逻辑层
重视职责的划分,职责之间常常是上层使用下层的关系——但是根本不关心上层和下层是否“能分布”在不同的机器上,如:
② Tier:物理层
③ 按通用性分层
④ 技术堆叠
1.3.考虑非功能需求
非功能需求往往非常笼统,而场景是一种明确性很强的技术,目标-场景-决策表可以让架构师理性地应对非功能需求。
如下表
目标 |
场景 |
决策 |
可重用性 |
欲嵌入的HIS系统种类较多,如何避免开发多个完全独立的“医生工作站嵌入单元” |
研究可能嵌入的HIS,确定“医生工作站嵌入单元”的不变部分和可变部分。。。 |
。。。 |
。。。 |
。。 |
3. 细化架构(Refined-architecture)阶段(简称RA阶段)
Refined-architecture是相对Conceptual-architecture而言的,它们是架构设计的两个层次,分别对于“概念级”解决方案和“规约级”解决方案,Refined-architecture属于架构设计,不能与Detailed Design(详细设计)相混淆。
使用工具:多视图方法。
工具说明:
5视图方法
视图 |
思维立足点 |
技术关注点 |
逻辑视图 |
职责划分 |
职责划分 逻辑层 子系统、模块 关键类 职责间协作 接口 协作关系 |
开发视图 |
程序单元组织 |
程序单元 源文件、配置文件 程序库、框架 目标单元 程序单元组织 project划分 Project目录结构 编译依赖关系 |
运行视图 |
控制流组织 |
控制流 进程、线程 中断服务程序 控制流组织 系统启动与停机 控制流通信 加锁与同步 |
物理视图 |
物理节点组织 |
物理节点 PC、服务器 单片机、单板机、专用机 软件安装、部署、烧写 系统软件选型 物理节点拓扑 连接方式、拓朴结构 物理层 冗余考虑 |
数据视图 |
持久化设计 |
持久数据单元 文件 关系数据库 实时数据库 数据存储格式 文件格式 数据库Schema |
3.1. 逻辑架构
1. 先从划分子系统的3种必用手段讲起
分层的细化
展现层 |
控制层 |
业务接口层 |
业务实现层 |
业务实体层 |
数据访问层 |
分区的引入
开发应该“深度优先”,而不是“广度优先”,分区是一种单元,它位于某个层的内部,其粒度比层小。
机制的提取
基于接口(和抽象)的协作是机制,基于具体类的协作则算不上机制。机制是一种特殊的子系统,
3个手段是相辅相成的关系。
划分子系统的4个重要原则
² 职责不同的单元划分归不同的子系统
² 通用性不同的单元划归不同的子系统
² 需要不同开发技能的单元划归不同子系统
² 兼顾工作量的相对均衡,进一步切分太大的子系统。
接口设计的事实与谬误
“分”是手段,“合”是目的,不能“合”在一起支持更高层功能的模板,又有何用?
协作决定接口,“我的接口我做主”的观点是错误的,
逻辑架构设计的整体思维套路
² 质疑驱动(功能方面(特殊功能支持吗?),质量方面(耦合性、重用性、性能。。。))
² 结构设计和行为设计相分离
示例:
增量建模技巧——不要急于“一口吃成个胖子”
2. 逻辑架构设计的10条经验要点
1) 划分子系统:分层的细化
2) 划分子系统:分区的引入
3) 划分子系统:机制的提取
4) 接口的定义:协作决定接口
5) 选用序列图:杜绝协作图
6) 包-接口图:从结构到待办的桥
7) 灰盒包图:描述关键子系统
8) 循序渐进的螺旋思维
9) 设计模式:包内结构
10) 设计模式:包间协作
3. 逻辑架构设计中设计模式应用
明确子系统内的结构
明确包间的协作关系
4. 贯穿案例
PASS系统的架构设计
首先应该注意二点,第一,细化架构设计的重要“输入”之一是概念架构设计,不应忽视。下图列出了“基于鲁棒图的初步设计”和进行高层分割考虑后的图
第二,5视图方法的应用,总体而言是5个视图的设计穿插进行的。
从结构设计到行动设计,常用手段是画序列图,如下图所示
有了不同职责单元之间具体的协作关系,就可以展开细致的“质疑”了——别忘了,架构设计是质疑驱动的
3.2. 物理架构、运行架构、开发架构
1. 物理架构视图
着重考虑运行软件的计算机、网络、硬件设施等情况,关注如何配置硬件和网络来满足系统的可靠性、可伸缩性、持续可用性、性能、完全性等方面的要求。3项任务:
硬件选择与物理拓扑
软件到硬件的映射关系
方案的优化
物理架构的设计内容。
物理架构节点
PC 、服务器
单片机、单板机、专用机
软件安装、部署、烧写
系统软件造型
物理节点拓扑
连接方式、拓扑结构
物理层
冗余考虑
2. 运行架构视图
工作内容:
确定引入哪些控制流
确定每条控制流的任务
处理相关问题:控制流的创建、销毁、通信机制等
进一步考虑:控制流之间的同步关系,若有资源争用还要引入加锁机制
运行架构的设计内容
控制流
进程、线程
中断服务
控制流组织
系统启动与停机
控制流通信
加锁与同步
在实践中最常用于实现控制流的手段有3种
进程
线程
中断服务程序
3. 开发架构视图
完成下列工作
将“逻辑职责”映射为“程序单元”
要自主编写的源程序
可重用的库、框架
其他方式(如Shell脚本、平台支持下的配置文件)
开发技术选型
开发语言
开发工具
“程序单元”间关系
project划分(可选)
Project目录结构
编译依赖关系