软件（架构）设计培训心得总结

今 天培训的是软件设计过程，但我会把今天的内容理解为架构设计。

不管了，我在本文中都统一为架构设计，不恰当的地方请见谅。

 

关键名字解释：

迭代： 就是 反复求精 的过程，是提升质量的过程，是 从模糊到清晰 的过程；

增量： 则是 数量渐增 地过程。

 

 

说在最前面的话，我认为软件架构是【 ****** 】 ：

1、  架构设计不是一些图和文档，架构设计是一个过程，是一个不断深入分析的过程，深入思考的过程。所以所有产物不一定是必须的，但是一定要先想，有分析、思考、决策的过程。 【至于为什么要深入分析，深入思考，后面会说明。】

2、  好的架构是持续完善的。所有好的架构都是在发展中演化出来的。

3、  架构是一种权衡与取舍，没有完美的架构。软件的要求肯定很多，必须抓住关键因素。

4、  架构是对复杂系统的一种共性的抽象，是针对特定目标系统、问题而提出的通用解决方案。即架构是蓝图，是整体到部分的最高层次的划分。

5、  架构是关注点分离。

【 for example:

  错误理解：高楼大厦是由钢筋、水泥和砖块构成

  正确理解：高楼大厦是由支撑系统、管道系统、强弱电系统、给排水系统。。等构成

 

  错误理解：信息系统是由一个个模块、一个个对象和组件构成

  正确理解：信息系统是由组织结构、业务流程、业务功能、业务信息。。等构成

】

 

软件（架构）设计的作用或意义【一定要记住】：

1、 深入理解业务与系统。【这条最重要。因为你不够理解业务与系统，所以才需要分析和设计】

2、 提供高层次的解决方案，还有为开发提供指导原则、实现思路、关键决策。

3、  团队理解、沟通的桥梁

 

项目管理的主要对象是人和项目，

而，架构设计主要的对象是【也要记住】 ：

1、 业务

2、 系统

所以相对来说，架构设计跟人的关系不大。

 

 

一些事情不要太纠结，关注和理解你的目标、目的、意义 ：

设计即分析，分析即设计。分析与设计的界线很模糊，没必要纠结自己到底是在做分析，还是在设计。

 

 

软件（架构）设计过程【这个大家都知道，请跳过】：

需求采集、捕获【需求采集卡，用户故事】 ------- 》

需求分析【需求规格说明书 : 背景、目标、功能性、非功能性需求、约束等】 -------- 》

概念模型【 用例简述、用例图、用例规约 边界、业务环境图、系统环境图】 --- 》

业务用例分析、实现【鲁棒图、时序图、活动图】 ----》

得到领域模型、 系统用例-----》

系统用例分析、实现【交互图、状态图、分析图】 ---- 》

概念类、数据字典 --- 》

再进行分析------》

架构设计【 4+1 视图】

 

简单解释什么是概念模型？

概念模型就是从用户看重的角度，来分析这个产品或者这个项目，抽象得到的一些模型。

相对的， 从开发人员脑子里想的、从开发实现角度分析设计 的就是实现模型。

 

重点说明下这个设计过程：

1、上面这个设计过程的意思，不是说你从下往下做了一遍，软件架构设计就出来了，就完成了。

其实在实际工作中，这些过程经常是反复进行的，交替进行的，不断进行迭代和增量的，不断的进行验证的。【进化式架构概念】

上面的过程的一个重要作用是，前面一个步骤的结果就是后面一个步骤的输入和验证条件，最终判断是否正确，是看是否满足了所有需求。

2、也并不是说，你上一个步骤没有完成，下一个步骤就不能开始。否则稍微复杂的项目，将是一个漫长的过程，还会因为长时间看不到有价值的东西，而打击团队的信心。在实际工作中，并非严格按照上述步骤，很多工作可以并行的。比方说，你在前期分析、设计到一定程度的时候，就可以考虑开发视图、关键功能原型设计、技术调研等。

 

 

软件设计规范过程、步骤【 Rational 】其实是很多的，产物也很多。但其实针对具体的软件产品或项目，并非全部是必须的，这已经是公认的。

但具体项目中，哪些是必需的，哪些可以省略？有没有什么标准呢？【大家很关心吧】

 

根据上面架构设计的目的，我觉得必需的依据标准如下：

1、  业务需求、目标、范围、约束、成功标准、关键驱动因素、关键功能和要求

2、  业务边界、业务环境、系统环境

3、  业务特点、业务规模大小（小型、中型、大型）

4、 你和你的团队，不了解的、不清楚的、模糊的，或者复杂的，都需要分析、设计【这个很重要】

 

架构设计中最关键的两样东西：

1、  领域模型（或者说概念类）

2、 系统中各个角色与系统之间、还有各个实体之间的关系与交互。（ 这个是最关键的。系统其实就是一堆关系和行为。 ）

 

由于这两个关键的东西，所以我认为架构分析、设计中最重要的图是：

1、  领域模型、概念类、数据字典；

2、  鲁棒图、协作图、状态图

其他什么用例图、时序图、活动图都是为了辅助分析、理解的。

 

架构设计其实就是不断的通过分析，不断的深入理解业务和系统，然后得到较高层次的解决方案。

架构设计其实就是从多维度、多角度进行抽象

架构设计中难把握的两样东西：

1、 粒度

2、 抽象层次

 

我觉得架构设计中抽象的最低层次应该是：组件、一个小功能、一个处理流程、一个线程，不要再往下细分设计咯。

 

架构设计需要注意事项：

软件需求一般包括：功能性需求、非功能性需求【包括约束和质量性需求】，

1 、功能性需求是最容易变化的，架构设计中，从一开始用例场景到最后，都应该思考很容易改变。

2 、约束会影响架构和功能，所以从一开始就要尽量弄清楚所有约束

 

附 4+1 视图：

 

4 ：

过程视图：其实就是组件图，组件之间的交互

开发视图：其实就是技术选型、分层，关注点分离、复用、公用。【常见的：内核层、 Framework 层（业务无关）、业务公用 API 层、业务中各种应用（管理系统、 WebService 、客户端 .. ）】

 

逻辑视图【这个没什么好说的】

部署视图【这个没什么好说的】

 

1 ：用例视图【这个没什么好说的】