51,407
社区成员
发帖
与我相关
我的任务
分享craig larman 的建议：在开发过程中如何画UML图
工作的程度
作为一个指导原则，在迭代过程的编程之前，开发人员最好两人一组在下述时间构思画图。
2周迭代 在迭代开始前半天至一天进行构思（如星期一或星期二）。
4周迭代 在迭代开始前一到两天进行构思。
对上述两种情况，在最初集中设计之后不必停止画图。在迭代过程中，开发人员——最好两人一组——在编写更多代码前到白板前作简短讨论并概括出思路。若他们在迭代初始的任务中或下一个任务开始前遇到复杂问题，还可以在迭代中途开一个长达半天的讨论会。
两人一组而不要单独一人画图。首先，合作能得到更好的设计。其次，彼此能很快地从对方那里学到设计技巧，因而一起成为更好的设计者。孤立地工作很难让软件设计者成长。周期性地同其他画图和设计人员一起工作，可以相互获得更广泛的知识。
为了弄清楚多次没有明确定义的问题，在迭代过程中(如UP)，程序员也是设计者，并没有将设计结果转交给程序员的单独的设计小组。开发人员先以UML设计者的身份画些图,再以程序员的身份实现代码，并在编程过程中继续进行设计工作。
假设有十位开发人员，在一天里分成五组在不同的白板上画图。架构设计师轮流参与各组工作，就会看到他们设计的依赖关系、冲突和交叉引用。此时，架构设计师可以协调关系，明晰依赖关系，使设计更顺畅合理。
为项目雇佣技术秘书，并教授他们一些UML符号和基本OOA/D概念（使其能理解项目环境）。这样,他们就能用CASE工具做繁琐的工作，如从代码逆向转换出UML图，用绘图仪打印图例并展示出来等等。开发人员则可以把更宝贵的时间花在他们擅长的事情上：设计和编程。技术秘书除了编写最终用户文档等真正的文档工作外，还能在管理UML图方面支援开发人员。这称为Mercenary分析家模式[Coplien95a]。
在开发工作区分布许多毗邻的大白板。
总而言之，要最大限度利用工作环境以方便开发者在白板上作图。要创建“画图友好”和“挂图友好”的环境。如果开发人员不得不勉强在小小的2X3英尺的白板上、一般尺寸的计算机屏幕上或零碎的纸张上绘图，就不要指望建立成功的可视建模的文化环境。舒舒服服的画图需要非常大的、开放的物理或虚拟空间。
作为白板的补充，可以使用能粘在墙上的白色静电吸附塑膜薄片，可成包购买，一包有20多张，很多文具店里都有。这些塑膜片通过静电吸附粘在墙上，象白板一样使用可擦洗书写工具。可把他们贴满一面墙，创建巨大的临时白板。我曾培训过几个团队，我们用薄膜片将办公室从上到下贴满了每一面墙，发现这大大有助于我们的交流和沟通。
若在白板上画UML图，要用设备(市场上一定会至少有一款适合)获取手工的绘图并传送至计算机转换成图形文档。用这种设备设计时，有一个接收端接在白板一角，还有一个能插入转换器的书写笔。
另一种替代设备是摄取图像的数字摄像机，通常需要在两个或三个区域摄像，这是一种相当常用而有效的作图做法。
还有一种能打印的白板很有用，通常双面可用，并带有扫描仪和打印机。
打印摄像机或白板设备能获取手绘的UML图像，并可以将它们悬挂在非常接近编程工作台的地方。UML图的作用在于为编程提供灵感，程序员在编程时应该一眼就能看到它们。如果画完就束之高阁，画图就毫无意义。
若手工绘画UML图，要使用易于书写的简单符号。
即使在白板上作创造性的设计，也需要在开始下一个迭代过程前用CASE工具通过逆向工程把上一迭代的源代码转换成包图和类图，作为后续创造性设计的起点。
周期性地用绘图仪将逆向工程生成的有意义、不稳定或复杂的包图和类图在三、四英尺宽的连续的纸上打印出来。将这些图挂在开发人员能方便察看的地方。技术秘书可以做这项工作。在创造性的设计过程中要鼓励开发人员画图和在图上涂改。
关于逆向工程，有些UML工具不仅能从源代码逆向工程生成类图，还能产生顺序图。
如果可以，可以为架构上重要的场景生成顺序图，用绘图仪将它们全部打印出来，悬挂在易于察看的地方。
若使用UML CASE工具（建议对所有的编程工作都这么做），可采用双监视器工作站(两台普通尺寸的纯平显示器比一台大尺寸纯平显示器要便宜)。现在的操作系统至少支持两个视屏卡，也就是两台显示器。要在两台显示器的UML工具间组织视窗，因为小屏幕显示器空间狭小，在画图和使用可视语言方面对开发人员在心理上和创新上有抑制作用。开发人员会沮丧地认为：屏幕满了，看起来拥挤不堪，该结束设计了。
两人或几人一组使用CASE工具进行创新设计时，把两台投影仪分别插到两块视屏卡上，将投影图像排列在墙上，使所有开发人员都能在较大的画布空间中一边观察一边工作。小画布和不易辨认的图对小组协作进行可视设计在心理上和交流上都有所限制。
fangsoft,摘自《APPLYING UML AND PATTERN》2ND
2003年6月11日
作为一个指导原则，在迭代过程的编程之前，开发人员最好两人一组在下述时间构思画图。
2周迭代 在迭代开始前半天至一天进行构思（如星期一或星期二）。
4周迭代 在迭代开始前一到两天进行构思。
对上述两种情况，在最初集中设计之后不必停止画图。在迭代过程中，开发人员——最好两人一组——在编写更多代码前到白板前作简短讨论并概括出思路。若他们在迭代初始的任务中或下一个任务开始前遇到复杂问题，还可以在迭代中途开一个长达半天的讨论会。
两人一组而不要单独一人画图。首先，合作能得到更好的设计。其次，彼此能很快地从对方那里学到设计技巧，因而一起成为更好的设计者。孤立地工作很难让软件设计者成长。周期性地同其他画图和设计人员一起工作，可以相互获得更广泛的知识。
为了弄清楚多次没有明确定义的问题，在迭代过程中(如UP)，程序员也是设计者，并没有将设计结果转交给程序员的单独的设计小组。开发人员先以UML设计者的身份画些图,再以程序员的身份实现代码，并在编程过程中继续进行设计工作。
假设有十位开发人员，在一天里分成五组在不同的白板上画图。架构设计师轮流参与各组工作，就会看到他们设计的依赖关系、冲突和交叉引用。此时，架构设计师可以协调关系，明晰依赖关系，使设计更顺畅合理。
为项目雇佣技术秘书，并教授他们一些UML符号和基本OOA/D概念（使其能理解项目环境）。这样,他们就能用CASE工具做繁琐的工作，如从代码逆向转换出UML图，用绘图仪打印图例并展示出来等等。开发人员则可以把更宝贵的时间花在他们擅长的事情上：设计和编程。技术秘书除了编写最终用户文档等真正的文档工作外，还能在管理UML图方面支援开发人员。这称为Mercenary分析家模式[Coplien95a]。
在开发工作区分布许多毗邻的大白板。
总而言之，要最大限度利用工作环境以方便开发者在白板上作图。要创建“画图友好”和“挂图友好”的环境。如果开发人员不得不勉强在小小的2X3英尺的白板上、一般尺寸的计算机屏幕上或零碎的纸张上绘图，就不要指望建立成功的可视建模的文化环境。舒舒服服的画图需要非常大的、开放的物理或虚拟空间。
作为白板的补充，可以使用能粘在墙上的白色静电吸附塑膜薄片，可成包购买，一包有20多张，很多文具店里都有。这些塑膜片通过静电吸附粘在墙上，象白板一样使用可擦洗书写工具。可把他们贴满一面墙，创建巨大的临时白板。我曾培训过几个团队，我们用薄膜片将办公室从上到下贴满了每一面墙，发现这大大有助于我们的交流和沟通。
若在白板上画UML图，要用设备(市场上一定会至少有一款适合)获取手工的绘图并传送至计算机转换成图形文档。用这种设备设计时，有一个接收端接在白板一角，还有一个能插入转换器的书写笔。
另一种替代设备是摄取图像的数字摄像机，通常需要在两个或三个区域摄像，这是一种相当常用而有效的作图做法。
还有一种能打印的白板很有用，通常双面可用，并带有扫描仪和打印机。
打印摄像机或白板设备能获取手绘的UML图像，并可以将它们悬挂在非常接近编程工作台的地方。UML图的作用在于为编程提供灵感，程序员在编程时应该一眼就能看到它们。如果画完就束之高阁，画图就毫无意义。
若手工绘画UML图，要使用易于书写的简单符号。
即使在白板上作创造性的设计，也需要在开始下一个迭代过程前用CASE工具通过逆向工程把上一迭代的源代码转换成包图和类图，作为后续创造性设计的起点。
周期性地用绘图仪将逆向工程生成的有意义、不稳定或复杂的包图和类图在三、四英尺宽的连续的纸上打印出来。将这些图挂在开发人员能方便察看的地方。技术秘书可以做这项工作。在创造性的设计过程中要鼓励开发人员画图和在图上涂改。
关于逆向工程，有些UML工具不仅能从源代码逆向工程生成类图，还能产生顺序图。
如果可以，可以为架构上重要的场景生成顺序图，用绘图仪将它们全部打印出来，悬挂在易于察看的地方。
若使用UML CASE工具（建议对所有的编程工作都这么做），可采用双监视器工作站(两台普通尺寸的纯平显示器比一台大尺寸纯平显示器要便宜)。现在的操作系统至少支持两个视屏卡，也就是两台显示器。要在两台显示器的UML工具间组织视窗，因为小屏幕显示器空间狭小，在画图和使用可视语言方面对开发人员在心理上和创新上有抑制作用。开发人员会沮丧地认为：屏幕满了，看起来拥挤不堪，该结束设计了。
两人或几人一组使用CASE工具进行创新设计时，把两台投影仪分别插到两块视屏卡上，将投影图像排列在墙上，使所有开发人员都能在较大的画布空间中一边观察一边工作。小画布和不易辨认的图对小组协作进行可视设计在心理上和交流上都有所限制。
fangsoft,摘自《APPLYING UML AND PATTERN》2ND
2003年6月11日
...全文
请发表友善的回复…
发表回复
nettman 2003-06-12
- 打赏
- 举报
楼主的文章个个经典，十分感谢！
