介绍一种好的设计方法——在软件设计前先画界面图

时　间:2009-06-24 16:12:14
作　者:   ID：6284  城市：西安
摘　要:介绍一种好的设计方法——在软件设计前先画界面图
正　文:

在软件设计前先画界面图

开始做自己的软件了，可是写说明书的时候，原先的很多思路却整理不出来了。无奈在网上寻觅，最后看到了java视线论坛，被一些文字吸引了，我看到了dlee写的文章，真的很高兴，我结合大家的讨论总结如下。

在做软件设计之前，画好系统的界面图是一种非常有效的建模和交流方式。不要急于从需求转到软件设计，而是根据需求文档（可以是传统的需求说明书也可以是用例）先画出系统的界面图来。

你要把界面的布局画的详细些，起码界面上所有的功能点（比如所有的按钮和超链接）应该全部画出来。不仅要画出第一级页面，那些第二级页面、弹出页面、子页面也都要画出来。他们之间的逻辑关系和导航关系都要明确地标记出来。你最好尽量考虑的细致一些以便页面制作人员，可以参照这些界面图不需要费什么脑子就能顺利把页面做出来，如果你能把这些界面图全部想象出来并且能细致地画在纸面上（当然这个工作并不象这里说的那么容易），那么系统该做成什么样子你就胸有成竹了。使用这些界面图来进行讨论也会比较具体和深入。

好处：

1，需求文档总是给人以不够具体的感觉，界面图画出来后，需求就非常具体了（一目了然，程序员因为直接参与这项工作，因此对于需求非常清楚，做开发的时候可以大量减少由于理解上的问题而产生的 bug）。
2，而且还可以根据界面图的数量和复杂度估算工作量，和客户讨价还价的时候心里比较也有底，客户对我们估计的工作量也比较信服。

stonecat说
1、更好的和客户交流，如果让你给客户描述一个工作流程可能比较麻烦，但如果有界面就很直观。
2、客户很容易发现需求存在的问题，在usecase中需求人员考虑的各方的操作习惯涉众利益可能和实际用户的需求不一样，有了界面用户很容易发现问题，可以在此基础上做一次需求的迭代。
3、客户会感觉到你们的效率很高，对于客户来说后面的处理他并不太关心，起码业务人员不关心，界面才是他们关心的重点。如果你能很快给他一个界面，他就仿佛看到了一个真正的产品。
4、界面开发人员和需求分析人员之间的交流会大大减少。
5、我们一般只对新业务做这一个工作，感觉很有效

下一步工作是根据界面图制作出页面，这里我指的是正式的页面（而不仅仅是一个由超链接形成的界面原型），包括全部的 JavaScript 脚本。我们现在创造了一种新的开发方式，可以完全不做后台的开发把全部页面制作好。然后再写后台的代码和配置。因为我们目前工作量的大约 2/3 集中于前台的页面和 JS 上，所以页面全部做好后可以说 2/3 的工作量就已经完成了。

补充一下，不是需要画完所有的界面图才可以做软件设计的（那样又堕入了“瀑布模型”的老路上），而只是需要完成主要的场景就可以了，只要这些功能场景相互独立，并且确实可以独立完成而彼此没有影响。在一个增量开发的团队中，需求搜集、画界面图、软件设计、开发是经常进行的工作。

经过我们长期的思考加实践，我们现在完全有能力定制出一种真正适合于我们的开发过程了，根本就不需要去照搬 RUP、XP、FDD、ASD、Crystal，那只是没有经验的开发团队所热衷的事情。

shiningzhao说
1、系统边界图
作为整个系统的业务情况的top0层的图，能够使大家一眼就对要做的系统有所认识。一般用visio。
2、UseCase图visio或者rose
3、界面图，我们用word画，便于修改和保存，因为是web系统，所以我们定义了一些常用的元素：txt框、下拉列表、多选、单选等，画起来很快，改起来也很快。
4、界面流程图，这是从《敏捷建模》中第一次学到并应用，感觉很清楚。界面流程图忽略了界面的细节，可以很清楚地看到几十个界面间的调用、流转情况。

这些做法对于B/S结构的设计很有用。