我们希望成功地塑造一个软件模型。但如何成为一个伟大的建模者，怎样开始？请在软件项目应用下列一些关键原则，以获得立竿见影的效果。

软件是为人制作的――没有用户，软件只是一个没有任何意义的比特集合。许多软件专家在他们的职业早期显得很高深，因为他们紧紧将注意力集中在技术上。的确，组件、企业级Java Beans(EJB)和代理很令人感兴趣，但是如果你的软件很难使用或不满足用户需求的话，这些技术无关紧要。必须花一定的时间去研究能够让用户理解的软件需求和用户界面。

最好的设计师用大部分的时间建模，偶尔编写源代码。这样增加了他们设计的合理性。

你不可能什么都知道，甚至知道足够多的东西都需要去奋斗。软件开发是一件复杂的劳动，因为开发工具和开发技术总是在不断地变化，这个过程仅仅一个人是不可能完全理解的。你每天都可以学到一些新的知识――在软件开发中，可能会更多一些――当然，你必须选择谦虚。

如果你没有任何需求，就根本没有必要编写软件。成功的软件是在预定的时间、预定的成本内，满足其用户的需求。如果你不知道有些什么需求，你的项目保证会失败。

object toolsmith公司的道格*史密斯喜欢说：“分析是一门科学，设计是一门艺术”。他所指的仅仅是“正确”的模型――完全展示了所有问题――许多“正确”的模型—他们提供了很好的解决问题的方案。

需求看上去常常变化，这是因为你的收集工作做的不够好，而不是他们实际有了变化。你可能会说用户不能明确告诉你他们需要什么，但收集需求是你的工作；你可能会说一群新人的到来否定了你以往的工作，但你应该从第一天就与他们交流；你可能会抱怨你所在的组织并没有提供与客户交流的良好途径，但这意味着高层管理人员并没有真正支持你的项目。；你也许会抱怨新的法律，但你应该注意公司外的环境发生了什么变化；你也可能抱怨你的竞争对手提出了一个新观念，但为什么不是你的组织先提出来呢？

鲜有需求变动的实例，只是你没有很好的收集需求。

在一个日新月异的行业中，你不可能永远活在过去的荣誉上。建议你每个月至少读两三本杂志和一本书。在此方面花费时间和金钱是值得的，常此以往，你将成为组织内部新的令人兴奋的项目的有吸引力的竞争者。

有很多耦合的系统；很难维护；一处的变化往往会造成另一处的变化，进而至另一处――这让你很头痛。你可以通过隐藏执行细节，给组件制定已定义的接口，不共享数据结构，不允许应用程序直接访问数据存储（我的原则是如果程序员要写sql语句，就已经失败了）。松耦合的软件更易重用、易维护、易改进。

如果一个软件部件只完成一项功能，那么它是内聚的，这意味着高内聚的软件易于维护和改进。判断构件是否内聚，就看是否能用一句简单的话来描述。如果需要一个段落，或者需要使用“和”、“或”这样的连词，那你就可能需要把它重新分解成几个部分。高内聚的软件更易于重用。

升级是软件开发的实现，不管采用怎样的软件工具市场宣传。你能够指望将你的软件用于另一个操作系统或数据库上，甚至它只是一个升级版本。要知道从win16升级到win32是多么大的快乐呀？每次你吸取一个操作系统独特的优点时，如进程通信策略；获数据库底某一特征，如用相应的语言编写存储进程，你的设计与这一独特产品冲突。成功的建模者隐藏了这些实现细节，如果要改变的话，只需改变其外壳。

可能这是陈词滥调，但变化确实是恒在的。你可以文档化“变化案例”来规划它――你的系统将来能够完成的需求（参阅“变化规划”，客观地思考，1999年5月）。通过建模时思考这些问题，你就可以开发一个足够健壮的设计来轻松的支持这些变化――设计健壮的软件应该是你的主要目标。

互联网最重要的一点就是在开发初期就必须考虑可扩展性。今天一个有100人的部门使用的软件明天就可能被上万人的组织使用，下个月又可能在互联网上被百万人使用。你可以通过分析你的软件必须支持的基本商务流（常在用户案例模型获得）来设计可扩展的软件，然后编译你的系统，你能够扩展它至高负荷环境下完成这些事务。在设计初期考虑扩展性，那么当你发现系统突然有了一个大很多的用户群时，可以避免大量的重复工作。

集中在一个设计因素上――－稳定性，这看上去很迷人――将不可避免地导致蹩脚的设计，从而导致队伍的返工。你的设计必须考虑到可扩展性，可用性，可移植性，可延伸性。必须在工程的初期着重考虑这些设计因素，恰当地处理他们。稳定性可能是、也可能不是你第一位考虑地因素，不过你应给其他设计因素应有的考虑。

[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>