软件(架构)设计培训心得总结

红雪中国 2012-04-24

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

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

 

关键名字解释:

迭代: 就是 反复求精 的过程,是提升质量的过程,是 从模糊到清晰 的过程;

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

软件(架构)设计培训心得总结

 

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

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 :用例视图【这个没什么好说的】

相关推荐