我们希望成功地塑造一个软件模型。但如何成为一个伟大的建模者，怎样开始？请在软件项目应用下列一些关键原则，以获得立竿见影的效果。
1、 以人为本
软件是为人制作的――没有用户，软件只是一个没有任何意义的比特集合。许多软件专家在他们的职业早期显得很高深，因为他们紧紧将注意力集中在技术上。的确，组件、企业级Java Beans(EJB)和代理很令人感兴趣，但是如果你的软件很难使用或不满足用户需求的话，这些技术无关紧要。必须花一定的时间去研究能够让用户理解的软件需求和用户界面。
2、 明白为什么而设计
最好的设计师用大部分的时间建模，偶尔编写源代码。这样增加了他们设计的合理性。
3、 谦虚出质量
你不可能什么都知道，甚至知道足够多的东西都需要去奋斗。软件开发是一件复杂的劳动，因为开发工具和开发技术总是在不断地变化，这个过程仅仅一个人是不可能完全理解的。你每天都可以学到一些新的知识――在软件开发中，可能会更多一些――当然，你必须选择谦虚。
4、 需求是一项要求
如果你没有任何需求，就根本没有必要编写软件。成功的软件是在预定的时间、预定的成本内，满足其用户的需求。如果你不知道有些什么需求，你的项目保证会失败。
5、 需求很少变化，但你对他们的理解常常变化
object toolsmith公司的道格*史密斯喜欢说：”分析是一门科学，设计是一门艺术”。他所指的仅仅是”正确”的模型――完全展示了所有问题――许多”正确”的模型—他们提供了很好的解决问题的方案。
需求看上去常常变化，这是因为你的收集工作做的不够好，而不是他们实际有了变化。你可能会说用户不能明确告诉你他们需要什么，但收集需求是你的工作；你可能会说一群新人的到来否定了你以往的工作，但你应该从第一天就与他们交流；你可能会抱怨你所在的组织并没有提供与客户交流的良好途径，但这意味着高层管理人员并没有真正支持你的项目。；你也许会抱怨新的法律，但你应该注意公司外的环境发生了什么变化；你也可能抱怨你的竞争对手提出了一个新观念，但为什么不是你的组织先提出来呢？
鲜有需求变动的实例，只是你没有很好的收集需求。
6、 不断的阅读
在一个日新月异的行业中，你不可能永远活在过去的荣誉上。建议你每个月至少读两三本杂志和一本书。在此方面花费时间和金钱是值得的，常此以往，你将成为组织内部新的令人兴奋的项目的有吸引力的竞争者。
7、 减少软件内部的耦合
有很多耦合的系统；很难维护；一处的变化往往会造成另一处的变化，进而至另一处――这让你很头痛。你可以通过隐藏执行细节，给组件制定已定义的接口，不共享数据结构，不允许应用程序直接访问数据存储（我的原则是如果程序员要写sql语句，就已经失败了）。松耦合的软件更易重用、易维护、易改进。
8、 增加软件的内聚性
如果一个软件部件只完成一项功能，那么它是内聚的，这意味着高内聚的软件易于维护和改进。判断构件是否内聚，就看是否能用一句简单的话来描述。如果需要一个段落，或者需要使用”和”、”或”这样的连词，那你就可能需要把它重新分解成几个部分。高内聚的软件更易于重用。
9、 期待出售你的软件
升级是软件开发的实现，不管采用怎样的软件工具市场宣传。你能够指望将你的软件用于另一个操作系统或数据库上，甚至它只是一个升级版本。要知道从win16升级到win32是多么大的快乐呀？每次你吸取一个操作系统独特的优点时，如进程通信策略；获数据库底某一特征，如用相应的语言编写存储进程，你的设计与这一独特产品冲突。成功的建模者隐藏了这些实现细节，如果要改变的话，只需改变其外壳。
10、接受变化
可能这是陈词滥调，但变化确实是恒在的。你可以文档化”变化案例”来规划它――你的系统将来能够完成的需求（参阅”变化规划”，客观地思考，1999年5月）。通过建模时思考这些问题，你就可以开发一个足够健壮的设计来轻松的支持这些变化――设计健壮的软件应该是你的主要目标。
11、不要低估可扩展性
互联网最重要的一点就是在开发初期就必须考虑可扩展性。今天一个有100人的部门使用的软件明天就可能被上万人的组织使用，下个月又可能在互联网上被百万人使用。你可以通过分析你的软件必须支持的基本商务流（常在用户案例模型获得）来设计可扩展的软件，然后编译你的系统，你能够扩展它至高负荷环境下完成这些事务。在设计初期考虑扩展性，那么当你发现系统突然有了一个大很多的用户群时，可以避免大量的重复工作。
12、稳定性只是设计因素之一
集中在一个设计因素上――－稳定性，这看上去很迷人――将不可避免地导致蹩脚的设计，从而导致队伍的返工。你的设计必须考虑到可扩展性，可用性，可移植性，可延伸性。必须在工程的初期着重考虑这些设计因素，恰当地处理他们。稳定性可能是、也可能不是你第一位考虑地因素，不过你应给其他设计因素应有的考虑。
13、处理好构件接口
一颗智慧之珠是《统一建模语言用户指南》，著者为格兰蒂*博斯，爱华*杰克布森，吉姆*拉姆博（爱迪生*维尔斯利），其中指出在设计初期定义用户界面。这会帮助你的团队同意软件棏整体设计，让独立的子小组分别工作。只要构件接口是稳定的，那么它是怎样做成的无关紧要。基本原则是，如果不能定义外面的东西看上去象什么，就不可能理解足够的东西来开始内部的工作。
14、”捷径”常常花费更多的时间
软件开发没有捷径可走。缩短用户需求时间的努力将会导致软件不能满足用户需要，从而返工；不建模就开始的工作会导致数周毫无意义的开发，因为开发者常常先做后想；如果每天减少测试工作，会导致花费数周乃至上月的时间去修正你所遗忘的错误所造成的相互冲突的数据，那就需要从新调试数据和软件。避免捷径――通过正确的途径一次做好。
15、不要轻信别人
产品销售商和服务商并不是你的朋友，大部分你的合作者和高级经理也不是。大部分的公司希望将你锁定在他们的产品上，要么是操作系统，要么是数据库或开发工具。大部分的顾问和合同商只在乎你的钞票，而不是你的项目（试试不给他们付钱，看他们能支持多久）。大多数程序员认为他们比任何人都懂得的多，因此会抛弃你的模型而首选他们自己的模型。通过意见沟通改进通常是解决这些问题的好方法。销售商的独立对你来说很重要。你的组织将投资在建立模型、文档化和已证明正确的过程来进行软件开发。
16、说明你的开发是基于实践的
你应该建立一个技术模型，即终端到终端的模型，来证明你的方法确实有效。在开发阶段尽可能早地做此项工作，因为如果你的设计从开始就不起作用的话，以后的软件开发过程中无论有多少代码也无济于事。你的技术概念将证明你的设计确实有效，从而更容易获得支持。
17、应用已成熟的模式
现在已经存在大量的可获得的分析和设计的模型，以及在模型中解决问题的可重用的方法。好的建模者，通常来说是好的开发者，能够避免从新制造组件。
18、熟悉各种模型的优缺点
你可能要与很多不同的模式接触。使用案例模型去捕捉行为需求，通过数据模型捕捉所需要的不变的数据来支持该系统。你可以尝试在用户案例内对你的恒定的数据建模，但这对开发者并不十分有用。与此类似，数据模型对描述软件需求是用处不大的。在你的建模工具中每种模型都应该有其相应的位置，你应该知道何时何地使用他们。
19、对一个任务使用多种模型
收集需求时，要考虑开发用户案例模型、用户界面模型、域模型。设计软件时，要考虑创建一个类模型，一系列序列图，一些陈述图，一些合作图，最终是不变的物理模型。建模者如果仅仅只采用一种模型，那就可能开发出一个健壮性不强的软件，要么无法满足用户需要，要么不易改进。
20、教育你的客户
如果你的用户不理解，那么建立一个复杂的模型就没有意义――或者更糟糕，他们压根就不理解你为什么要使用这些模型。告诉你的合作者建模的必要性；否则，他们很可能会看着那些漂亮的图片然后去裁减源代码。你也需要告诉你的用户需求模型的重要性。在用户案例和用户界面模型上也这样做，那么他们就会理解你在努力沟通。当每个人都说一种通用的语言时，你的团队将得到良好的沟通。
21、一个拥有良好工具的蠢人仍然是蠢材
你可以给我一个cad/cam的工具，然后要我设计一座桥，然而我可能是最后完成此项工作的人，因为我对土木工程一无所知。拥有一个好的建模工具并不能使你成为一个好的建模者，这只是使你拥有接触好的建模工具的途径。要成为一个好的建模者需要多年的工作经验积累，而不仅仅是在一个数千美元的工具的一周的培训。一个好的计算机辅助建模工具很重要，但你首先必须学会如何使用这个工具，从而开发出它所支持的模型。
22、理解整个过程
好的开发者理解整个软件过程，尽管他们不是在所有方面都很精通。36页展示的软件过程――相当复杂，是吗？这显示对整个软件来说，面向对象编程、建模、测试比怎样去具体化他们更重要。优秀的建模者考虑整个蓝图，考虑长期的发展和用户的需求，同时考虑怎样维护和支持他们开发的软件。
23、尽早的、经常的测试
如果一个工程不需要测试，那么他可能就不值得创建。你可以通过建立技术模型来检测你的模型，或对他们执行技术回顾。在软件开发期中测试的越晚，去修正所发现的错误就越难、花费也更多。尽可能早的进行测试是值得的。
24、文档化你的工作
如果不需要文档，那工程也可能不需要创建。你必须文档化你的决议以及他们所基于的假定，模型的每个部分（尤其是那些不明显的部分），创建每个视图的回顾，因而其他人能清楚的知道你要表达什么。
25、技术在变，但其基础不变
当开发者说一些毫无意义的话：”通过特定的语言、工具或x技术，我们不需要做需求分析、建模、编码和测试的工作”的时候，就可能是他需要更多经验的标志。不管如今项目上的技术和人员怎么变化，今天软件开发的基础跟20世纪70年代的仍旧差不多。你必须定义需求、建模、编程、测试、发布、管理风险、管理运输、管理职员等等。软件建模是需要花费数年时间去掌握的技术。不过你可以根据我所说的和你实际开发中获得的经验来开始。使用这份鸡汤，再加上你的蔬菜，将得到一份建模的盛餐。
