画uml图、流程图、软件结构图、类图、顺序图的方法
2008-10-07 10:01
471 查看
作者:cuichaox@gmail.com
软件开发中,分析和设计时,文档的编写和思想的交流,经常要绘制各种各样的图。相对于人类的自然语言,描绘复杂结构,图具有直观和整体的特征,有着不可替代的表现力。
软件开发是创造性的劳动,开发人员几乎在每一分钟都要做出某些选择,每一个选择都好像决定着最后的结果。绘图的时候也是如此,脑中有完整或不完整的想法,要清晰的表现出来时相当不容易。事实上,我发现许多老手不会画图。
在实践的过程中,我总结了一些经验,得出了一些结论。
1. 不画没有必要的图。如果简单的文字就能说得很清楚,还画图干什么?对代码级别的细节,不要画图来表现;不要借助图来让你的文档得变大;画蛇莫要添足。
2. 忽略底层的细节。软件是一个多层的东西,一个图只展现恰当抽象层次之上的细节。一个过细的图,大量的信息会掩盖真正重要的东西。比如:在一个流程图上,不需要把“文件打开的错误判断”也作为一个分支画在图上,除非你“无聊到”要强调这个显而易见的异常处理;
3. 图不要太大。如果一个图上包含上百个对象,看起来不舒服,应该化整为零,使用多个图,每个图描述不同的部分。
4. 画纯种的图。图传递的信息应该明确,无歧义。一定要明确图中的各个组成元素都是什么东西,整个图要表现什么。尽量使用规范的图。比如:流程图中,应关注控制的传递,不要有从文件中读取数据的数据流;软件结构图中,描述模块之间的父子关系的同时,不要有模块之间的数据流。我常见到这样的图:在图中既有“控制流”,也有“数据流”,不伦不类,名之曰“示意图”。个人认为,交流时,这种示意图在白板上随手画画还可以,决不应该出现在正式的文档上。这些图中的控制流,实是一个模糊概念,A->B可以表示:1)A调用B,把控制传递给B;2)A启动B,把控制传递给B;3)A向B传递一个控制信号;4)有一个第三者调用A完成后,马上调用B。
5. 图的布局要简洁,美观。我听说:书写大幅的毛笔字,特别讲究布局。同样道理,画软件图,尽量密度分布均匀,减少连线的交叉。 为了减少连线的交叉, 同样的单元可以在图中出现多次。
6. 其实并不需要完备的图。使用UML有三种方式:UML as sketch(草图),使用不完备的图进行系统某一部分或某一方面的内容进行交流;UML as blueprint(篮图),通过完备的UML图表现详细设计的所有决定;UML as programming language,自动精确的UML图,直接编译成可执行的代码(现在好像还没有实现)。Martin Fowler说:使用UML绘制草图的人,真正关注UML的精髓(大师就是大师,说话就是不一样)。所谓“不足胜有余”,不管什么图,图应该集中表现其关注的方面,恰当的忽略一些细节时必要的。类图中,往往没有必要包含类的所有函数合成员说明;在表现对象之间协作的顺序图中,大多时候也没有必要表现存在的分支和循环。
7. 所有的规则都是用来遵守和打破的。上面的所有道理,也并非是不变的真理。但是,道理被打破以前,你应该了解它,熟悉它,批评它,忘记它(追求类似张三丰太极剑的境界)。古人云:事有反道而适权,伪经而和道者。笑傲江湖说:独孤九剑,无招胜有招。萧大侠:删繁就简,取精用宏。 规劝朋友也规劝自己:连有招的境界尚未达到,应该知道自己该做什么。
软件开发中,分析和设计时,文档的编写和思想的交流,经常要绘制各种各样的图。相对于人类的自然语言,描绘复杂结构,图具有直观和整体的特征,有着不可替代的表现力。
软件开发是创造性的劳动,开发人员几乎在每一分钟都要做出某些选择,每一个选择都好像决定着最后的结果。绘图的时候也是如此,脑中有完整或不完整的想法,要清晰的表现出来时相当不容易。事实上,我发现许多老手不会画图。
在实践的过程中,我总结了一些经验,得出了一些结论。
1. 不画没有必要的图。如果简单的文字就能说得很清楚,还画图干什么?对代码级别的细节,不要画图来表现;不要借助图来让你的文档得变大;画蛇莫要添足。
2. 忽略底层的细节。软件是一个多层的东西,一个图只展现恰当抽象层次之上的细节。一个过细的图,大量的信息会掩盖真正重要的东西。比如:在一个流程图上,不需要把“文件打开的错误判断”也作为一个分支画在图上,除非你“无聊到”要强调这个显而易见的异常处理;
3. 图不要太大。如果一个图上包含上百个对象,看起来不舒服,应该化整为零,使用多个图,每个图描述不同的部分。
4. 画纯种的图。图传递的信息应该明确,无歧义。一定要明确图中的各个组成元素都是什么东西,整个图要表现什么。尽量使用规范的图。比如:流程图中,应关注控制的传递,不要有从文件中读取数据的数据流;软件结构图中,描述模块之间的父子关系的同时,不要有模块之间的数据流。我常见到这样的图:在图中既有“控制流”,也有“数据流”,不伦不类,名之曰“示意图”。个人认为,交流时,这种示意图在白板上随手画画还可以,决不应该出现在正式的文档上。这些图中的控制流,实是一个模糊概念,A->B可以表示:1)A调用B,把控制传递给B;2)A启动B,把控制传递给B;3)A向B传递一个控制信号;4)有一个第三者调用A完成后,马上调用B。
5. 图的布局要简洁,美观。我听说:书写大幅的毛笔字,特别讲究布局。同样道理,画软件图,尽量密度分布均匀,减少连线的交叉。 为了减少连线的交叉, 同样的单元可以在图中出现多次。
6. 其实并不需要完备的图。使用UML有三种方式:UML as sketch(草图),使用不完备的图进行系统某一部分或某一方面的内容进行交流;UML as blueprint(篮图),通过完备的UML图表现详细设计的所有决定;UML as programming language,自动精确的UML图,直接编译成可执行的代码(现在好像还没有实现)。Martin Fowler说:使用UML绘制草图的人,真正关注UML的精髓(大师就是大师,说话就是不一样)。所谓“不足胜有余”,不管什么图,图应该集中表现其关注的方面,恰当的忽略一些细节时必要的。类图中,往往没有必要包含类的所有函数合成员说明;在表现对象之间协作的顺序图中,大多时候也没有必要表现存在的分支和循环。
7. 所有的规则都是用来遵守和打破的。上面的所有道理,也并非是不变的真理。但是,道理被打破以前,你应该了解它,熟悉它,批评它,忘记它(追求类似张三丰太极剑的境界)。古人云:事有反道而适权,伪经而和道者。笑傲江湖说:独孤九剑,无招胜有招。萧大侠:删繁就简,取精用宏。 规劝朋友也规劝自己:连有招的境界尚未达到,应该知道自己该做什么。
相关文章推荐
- 画uml图、流程图、软件结构图、类图、顺序图的方法
- 基于体系结构、面向构件的软件开发方法(梅宏)听后感
- 应用三菱GX Developer编程软件编写SFC顺序功能图的方法
- 软件方法:业务建模和需求札记-建模和UML
- UML 基础:类图,组件图,部署图,对象图,包图,用例图,活动图 ,顺序图,协作图,状态图,交互概览图,时间图
- UML用例图,类图,顺序图
- 按图索骥---软件的设计图纸(用例图,类图,状态图,活动图,顺序图)
- 识别UML图---类图结构
- PowerDesigner(八)-面向对象模型(用例图,序列图,类图,生成Java源代码及Java源代码生成类图)面向对象模型 面向对象模型是利用UML(统一建模语言)的图形来描述系统结构的模型,
- 怎样画流程图攻略:流程图绘制软件使用方法
- UML实践----用例图、类图、对象图、顺序图、协作图、状态图、活动图、组件图、配置图
- (2013-4-21)数据结构实验三:狐狸逮兔问题(方法一:顺序表实现)
- ASP.NET中HttpApplication中ProcessRequest方法中执行的事件顺序;ASP.NET WebForm和MVC整体请求流程图
- 软件概要设计说明书(类图,顺序图)
- 【UML入门教程】——静态结构(下):类图
- 第一章 简单工厂模式 及 UML中类图的表示方法
- 软件体系结构 UML设计
- 产品需求文档写作方法(三)用例文档(UML用例图、流程图)
- 软件体系结构原理、方法与实践总结
- 软件流程图绘制方法