谈谈我理解的SA——Systems Architecture
2019-12-02

 

什么是SA?

SA即Systems Architecture,是系统体系结构。

系统体系结构是定义系统的结构、行为和系统视图的概念模型。架构师将其系统的形式化描述或表示出来,以支持结构和行为的推理的方式组织。

谈起SA,我第一印象总觉得他是一个概念,一个混淆的概念,因为他被提出时就是模糊的。然而随时不断的接触,它其实是会越来越清晰的出现在我们眼前,他是那么的有条理,那么的明确,甚至连动态变化都可以被用文字语言描述。

我看过一些架构相关的书籍,然而大部分书中描述的内容都是一种作者最熟悉,或者自己创新的结构。当然,它们很有用,但某一种结构或几种组合都不能代表SA,它们只是SA繁衍出来的具体行为的指导思想或结构模板。

 

ABSD

ABSD(architecture-based softwar design)基于体系结构的软件设计。ABSD方法是一个【自顶向下】,【递归细化】的方法。ABSD把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化6个子过程。

什么意思呢?就是在做架构时,有一个正常的顺序:

【需求=>设计=>文档化=>复审=>实现=>演化】

这是一个自顶向下的顺序,但节点之间和节点内部还存在递归,并且每个节点都有自己独特的细化方案。

有兴趣的同学可以百度了解一下ABSD。或者买些相关书籍。

为什么推荐ABSD呢,因为我觉得大多数系统结构,都是基于ABSD扩展的。学会ABSD以后,在阅读其他相关书籍时,会事半功倍。

 

我心中的SA

SA并不是只有思想,在实践的过程中,我们还要设计或者选择框架,在ABSD中,SA被被分为三个基础元素,分解、风格、模板。然而我觉得风格和模板可以合并,改称为框架,相信很多架构师都有自己的框架,而且可能有很多个框架。

SA实践时,有很多种方法,步骤也可以不同,书上的概念总是希望将很多内容归纳或归类为一;然而现实中,我们在实现SA时,往往是设计与框架同时进行。所以我觉得实战中,大部分架构师的设计顺序应该是这样的。

一,分解子系统和功能模块;

二,设计框架模型;

三,分析功能模块;

四,设计框架详细。

然而现实中不会有这么清晰的边界,真实的情况可能是,这四步也相互穿插,同步进行。

 

为什么SA的解释那么多?

这是个很有趣的问题,因为很多人都在用学习,创新SA,他们在尝试为它定义的同时,还尝试将软件设计模式,软件开发方法,软件管理方法,软件风格,软件模板等等概念与SA进行分离,并逐一明确其概念和实现。

虽然细节很重要,没有细节的SA都是空谈,但如此多的书籍和定义,导致的结果就是,很多人在学习时,需要面对茫茫多的概念,找不到总纲,然后混乱的一沓糊涂。

我突然想起了王阳明先生的“知行合一”;知行本是一,却被拆分为二,圣贤教人知行,却被后人传为知与行。

我觉得软件概念目前也存在着这样的情况。例如XP极限编程,如此详细的构建了开发细节,明明是SA的一种,可却被定义为软件开发方法,看起来好像XP和ABSD和ADMEMS是不同的东西了。

为什么呢,因为很多SA的书籍在编写时,有些书想重点突出设计思想,因为他觉得那是他的亮点,而人员分配,设计模式,并未提及。但依据其思想其实是可以推理出开发测试分工的。再比如,XP重点突出其特殊的人员配置和分工模式,但其分布式模块,独立设计的设计思想也是跃然纸上。

【PS:但如果你都能依据他的书中的部分内容,推理出整个SA细节,那我觉得你也不需要看他的书了。】

回到现实中,在茫茫的网络世界里,我们只是因为其突出的侧重点不同,而强行将其分类定义,只是增加后学的学习难度和成本,而已。

 

后记

架构重点关注问题

理解系统要解决的问题

认识系统特性与要解决的问题间的关系

识别系统的核心行为

整理系统的非功能性需求

确定架构需求

管理需求

规划系统的高层组织

确定架构机制

分析用例场景

演进系统的高层组织并形成组件模型

规划系统的运行时架构和部署模型

规划系统的实现模型

编写核心代码

验证架构设计

整理架构文档