框架设计总结

框架设计总结

 

温昱老师的《一线架构师实现指南》读完好几天了，本书很多大牛都有推荐，自己从头到底一字不漏的看了，很多关键的方法，做了标记，看了多次，是一本介绍构架设计方面很好的书，准备把它做为工具书，在开始中用好其中的方法。

大学学的软件工程，软件设计要从需求分析、可行性分析、概要设计、软件设计、软件开发和测试，说的是一个大的过程，具体到针对一个项目时还是会感觉无从下手；本书提供的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目录结构

编译依赖关系

 

 

 

4.     贯穿案例