Refined Architecture阶段——细化架构

Refined Architecture阶段就是相对于Conceptual Architecture而言，分别对应于“概念级”解决方案和“规约级”解决方案。

Refined Architecture（细化架构）属于架构设计，不能与Detailed Design（详细设计）相混淆。架构领域最喜欢将建筑设计的多视图方法与软件架构设计的多视图方法作类比。

《方案书》意味着架构师在一个项目中须要进行对已经“明确”的架构进行更进一步的细节架构，即RA阶段。前边说明的“明确”的架构就是《方案书》中所说的方案，这里引用书中原文的几句话“方案=项目+需求+架构的总览，而方案≠架构的所有”，小张没有将“架构”进行细化，因此他的任务不算完成。

那么什么是软件架构呢？架构对应英文单词“Architecture”，在英文里Architecture是个名词，表示结构。但实际上结构只是架构的产物，如何获得这个结构呢？是经过架构师的一个个决策获得的。因此，架构包含了过程和结果，其过程就是项目全部人员共同完成的一部分，而后架构师根据全部的成员完成的任务，以及项目、需求综合起来造成的一个结果。这就是我所理解的软件架构。它是一个有机的结合，靠着一个项目的全部人员共同完成的一项结果。

从那本书中，我截下了这个图

这是RA阶段中的细化架构与概念架构的分层及比例，明显的能够看出细化架构处于概念架构和开发实现之间，因此项目的实现以前必须进行细化架构，细化架构就是项目的实现阶段，让项目的全部人员将概念转换成实现的一个重要的步骤。

逻辑架构在书中解释为划分子系统，定义接口等等属于逻辑架构的工做。

划分子系统的方法有三个：①分层的细化；②分区的引入；③机制的提取；

这三点老师都在课堂上讲到过，详细的示例在网络上均可以找到，这里我找到了一篇关于划分子系统的博客，贴在了帖子内

https://www.cnblogs.com/riasky/p/3476592.html

 

在使用这种方法后，很想找到一种新的名词来代替“子系统”，由于不少人提到子系统的时候极可能想的都是前台界面和后台逻辑的划分，而最大尺度上的非功能分割。

关于物理架构、运行架构以及开发架构（转载于原文连接：https://blog.csdn.net/cui841923894/article/details/84677805）

物理架构
为何须要物理结构设计
有时候增长硬件未必能解决问题；
软件实际服务能力不只受到“硬件资源”的制约，也受到“数据短缺”和“数据争用”的制约。
增长硬件 = 增长计算能力 不等于 软件的实际服务能力加强
物理结构关注如何能够知足软件系统的可靠性、可伸缩性、持续可用性、性能、安全性等方面的要求。

物理架构设计的工做内容
物理架构设计主要的3项任务：
硬件选择和物理拓扑。
软件到硬件的映射关系。
方案的优化。

物理架构的设计思惟
从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。

运行架构
为何须要运行架构设计
当系统并不引入任何并行或并发处理，而且也没有给予SDK、API等基础软件进行定制开发，那就不须要设计运行架构设计。
若是系统为了应对复杂的业务逻辑或者复杂的互操做逻辑（含硬件交互），或者为了优化关键资源使用效率，而必须借助多条控制流并行或者并发执行时，就须要设计运行架构。

运行架构设计工做内容
运行架构设计可能根据具体状况不一样包括下列工做内容:
肯定引入哪些控制流。
肯定每条控制流的任务。
处理相关问题：控制流的建立、销毁、通讯机制等。
进一步考虑：控制流之间的同步关系，如有资源争用还要引入加锁机制。

控制流图是关键。运行架构设计的工做看似多而杂，单其实只要把握“控制流图”，就可以提纲挈领地开展其余相关设计。

实现控制流的3种常见手段
最经常使用于实现控制流的3种手段：
进程、线程、中断服务程序。

开发架构
为何开发架构是必须的
并行开发所需的“程序单元”、“源码目录结构”等概念，是不一样程序团队开展具体工做的基础。
能支持并行的详细设计。
让程序经理参与到架构实践的工做，免去大量的“单纯架构交流”的工做量，更让程序人员有“成就感”。

开发架构设计的工做内容
通常完成：
1.将“逻辑职责”映射为“程序单元”：
要自主编写的源程序
可重用的库、框架
其余方式（如shell脚本、平台支持下的配置文件）

2.开发技术选型
开发语言
开发工具

3.“程序单元”间的关系
Project划分
Project目录结构
编译依赖关系

重用测试是关键
解决年复一年修复相似问题的问题
从根本上下降维护成本