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

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

                                      

在做软件设计之前，画好系统的界面图是一种非常有效的建模和交流方式。

总 是有人抱怨在需求和软件设计之间仍然有很大的鸿沟需要填补，这是至今仍然未能有效解决的软件工程难题。多年以来，有很多人一直在寻找从需求到设计的直接的 形式化映射方法，但是收获很少。实际上软件工程对于软件生命周期前面的那些阶段并没有多大的帮助。为了响应 o6z 说的努力在在现有技术基础上杀死人狼的号召，我来推荐一种有效的设计方法。

这种方法其实非常简单，就是不要急于从需求转到软件设计， 而是根据需求文档（可以是传统的需求说明书也可以是用例）先画出系统的界面图来。用什么画图呢？你可能立即会想到 Word、Visio、ROSE 一类的工具，我现在告诉你这是错误的做法。你应该采用最快的方式把界面图画出来，因为界面图主要是用来交流的（是给人看的而不是给机器看的），所以你不需 要太拘泥于形式。你找些白纸和一支铅笔，马上就可以开展这项重要工作了。如果用白纸和铅笔，我一天最多可以画 20 张界面图，但是用 Word 我的速度可就慢多了，因为我还要考虑排版、美观等等无聊的细节。

你要把界面的布局画的详细些，起码界面上所有的功能点（比如所有的按钮和超链 接）应该全部画出来。不仅要画出第一级页面，那些第二级页面、弹出页面、子页面也都要画出来。他们之间的逻辑关系和导航关系都要明确地标记出来。你最好尽 量考虑的细致一些以便页面制作人员（实际上我们是由程序员自己来制作页面的，可能又会引起某些人的惊诧和愤慨了）可以参照这些界面图不需要费什么脑子就能 顺利把页面做出来，而不是他们做出来后你又要告诉他们这个地方不对那个地方不对。如果你能把这些界面图全部想象出来并且能细致地画在纸面上（当然这个工作 并不象这里说的那么容易），那么系统该做成什么样子你就胸有成竹了。 使用这些界面图来进行讨论也会比较具体和深入。需求文档总是给人以不够具体的感觉，界面图画出来后，需求就非常具体了（一目了然，程序员因为直接参与这项 工作，因此对于需求非常清楚，做开发的时候可以大量减少由于理解上的问题而产生的 bug）。而且还可以根据界面图的数量和复杂度估算工作量，和客户讨价还价的时候心里比较也有底，客户对我们估计的工作量也比较信服。当然你还要尽量把界 面设计的美观大方而且容易使用，这方面可以参考我上面介绍的那本书和 Alan Cooper 的《软件创新之路》。

这些界面图需要讨论上两到三次才能定稿，讨论的时候最好能有最终用户的参与，以便尽早获得他的反馈。在这时候发现需求理解上的错误，修改只需要在白纸上重新画几张界面图，成本可以说是最低的。定稿后这些界面图要作为重要的项目文档归档保存。

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

有很多的经验都是软件工程的经典教材中所没有的，难道我们就可以忽略这些经验了吗？有那些项目组是采用这种方式来做开发的？

 

源文档 <http://cache.baidu.com/c?word=%D4%DA%3B%C8%ED%BC%FE%3B%C9%E8%BC%C6%3B%C7%B0%3B%CF%C8%3B%BB%AD%3B%BD%E7%C3%E6%3B%CD%BC&url=http%3A//www%2Eblogdriver%2Ecom/hopeshared/578456%2Ehtml&p=c974d31885cc42aa03a2c4710914cb&user=baidu>