原文
http://www.cnblogs.com/yxonline/archive/2007/07/09/811434.html
我们期待自己成ؓ一个优U的Y件模型设计者，但是Q要怎样做，又从哪里开始呢Q?
下列原则应用到你的软g工程中，你会获得立杆见媄的成果?/p>
1. 比技术重?
你开发Y件是Z供别Z用，没有Z用的软g只是没有意义的数据的集合而已。许多在软g斚w很有成就的行家在他们事业的初期却表现q_^Q因Z? 那时侯将主要_֊都集中在技术上。显Ӟ构gQcomponentsQ，EJBQEnterprise Java BeansQ和代理QagentQ是很有的东西。但是对于用h_如果你设计的软g很难使用或者不能满他们的需求，后台用再好的技术也于事无补。多 q旉到Y仉求和设计一个用户能很Ҏ理解的界面上?/p>
2. 理解你要实现的东?
好的软g设计人员把大多数旉p在徏立系l模型上Q偶写一些源代码Q但那只不过是ؓ了验证设计过E中所遇到的问题。这他们的设计方案更加可行?br />
3. 谦虚是必ȝ品格
你不可能知道一切，你甚臌很努力才能获得够用的知识。Y件开发是一复杂而艰巨的工作Q因Y件开发所用到的工具和技术是在不断更新的。而且Q? 一个h也不可能了解软g开发的所有过E。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事Y件开发的人来_每天可以学习很多C西（如果 愿意的话Q?/p>
4. 需求就是需?
如果你没有Q何需求，你就不要动手开发Q何Y件。成功的软g取决于时_在用戯求的旉内完成）、预和是否满用户的需求。如果你不能切知道用户需要的是什么，或者Y件的需求定义，那么你的工程注定会失败?/p>
5. 需求其实很改变，改变的是你对需求的理解
Object ToolSmiths公司Qwww.objecttoolsmiths.comQ的Doug Smith常喜Ƣ说Q?#8220;分析是一门科学，设计是一门艺?#8221;。他的意思是说在众多?#8220;正确”分析模型中只存在一个最“正确”分析模型可以完全满解决某个? 体问题的需要（我理解的意思是需求分析需要一丝不苟、精的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注Q?/p>
如果需求经常改动，很可能是你没有作好需求分析，q不是需求真的改变了?/p>
你可以抱怨用户不能告诉你他们惛_C么，但是不要忘记Q收集需求信息是你工作?/p>
你可以说是新来的开发h员把事情搞得一团糟Q但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样d?/p>
如果你觉得公怸让你与用户充分接触，那只能说明公司的理层ƈ不是真正支持你的目?/p>
你可以抱怨公司有兌Y件工E的理制度不合理，但你必须了解大多同行公司是怎么做的?/p>
你可以借口说你们的竞争Ҏ的成功是因ؓ他们有了一个新的理念，但是Z么你没先惛_呢？
需求真正改变的情况很少Q但是没有做好需求分析工作的理由却很多?/p>
6. l常阅读
在这个每日都在发生变化的产业中，你不可能在已取得的成׃陉太久?/p>
每个月至读2?本专业杂志或?本专业书c。保持不落伍需要付出很多的旉和金钱，但会使你成ؓ一个很有实力的竞争者?/p>
7. 降低软g模块间的耦合?
高耦合度的pȝ是很隄护的。一处的修改引v另一处甚x多处的变动?/p>
你可以通过以下Ҏ降低E序的耦合度：隐藏实现l节Q强制构件接口定义，不用公用数据结构，不让应用E序直接操作数据库（我的l验法则是：当应用程序员在写SQL代码的时候，你的E序的耦合度就已经很高了）?/p>
耦合度低的Y件可以很Ҏ被重用、维护和扩充?/p>
8. 提高软g的内聚?
如果一个Y件的模块只实C个功能，那么该模块具有高内聚性。高内聚性的软g更容易维护和改进?/p>
判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能p了。如果你用了一D话或者你需要用类?#8220;?#8221;?#8220;?#8221;{连词，则说明你需要将该模块细化?/p>
只有高内聚性的模块才可能被重用?/p>
9. 考虑软g的移植?
UL是Y件开发中一具体而又实际的工作，不要怿某些软g工具的广告宣传（比如java 的宣传口号write once run many ? 译者注Q?/p>
即仅仅对Y件进行常规升U，也要把这看得和向另一个操作系l或数据库移植一样重要?/p>
记得?6位WindowsUL?2位windows?#8220;乐趣”?Q当你用了某个操作pȝ的特性，如它的进E间通信(IPC){略Q或用某数据库专有语a写了存储q程。你的Y件和那个特定的品结合度已l很高了?/p>
好的软g设计者把那些Ҏ的实现细节打包隐藏v来，所以，当那些特性该变的时候，你的仅仅需要更新那个包可以了?/p>
10. 接受变化
q是一句老话了：唯一不变的只有变化?/p>
你应该将所有系l将可能发生的变化以及潜在需求记录下?以便来能够实现Q参?#8220;Architecting for Change”QThinking Objectively, May 1999Q?/p>
通过在徏模期间考虑q些假设的情况，你就有可能开发出_强壮且容易维护的软g。设计强壮的软g是你最基本的目标?/p>
11. 不要低估对Y件规模的需?
Internet 带给我们的最大的教训是你必须在Y件开发的最初阶D就考虑软g规模的可扩充性?/p>
今天只有100人的部门使用的应用程序，明天可能会被有好几万人的l织使用Q下月，通过因特|可能会有几百万Z用它?/p>
在Y件设计的初期Q根据在用例模型中定义的必须支持的基本事务处理，定软g的基本功能。然后，在徏造系l的时候再逐步加入比较常用的功能?/p>
在设计的开始考虑软g的规模需求，避免在用LH然增大的情况下Q重写Y件?/p>
12. 性能仅仅是很多设计因素之一
x软g设计中的一个重要因?-性能Q这好象也是用户最兛_的事情。一个性能不佳的Y件将不可避免被重写?/p>
但是你的设计q必d有可靠性，可用性，便携性和可扩展性。你应该在工E开始就应该定义q区分好q些因素Q以便在工作中恰当用。性能可以是，也可以不是优先最高的因素Q我的观ҎQ给每个设计因素应有的考虑?/p>
13. 理接口
“UML User Guide”QGrady BoochQIvar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999Q中指出Q你应该在开发阶D늚早期定义Y件模块之间的接口?/p>
q有助于你的开发h员全面理解Y件的设计l构q取得一致意见，让各模块开发小l相对独立的工作。一旦模块的接口定之后Q模块怎样实现׃是很重要了?/p>
从根本上_如果你不能够定义你的模块“从外部看上去会是什么样?#8221;Q你肯定也不清楚模块内要实现什么?/p>
14. 走近路需要更长的旉
在Y件开发中没有捷径可以走?/p>
~短你的在需求分析上q旉Q结果只能是开发出来的软g不能满用户的需求，必须被重写?/p>
在Y件徏模上每节省一周，在将来的~码阶段可能会多花几周时_因ؓ你在全面思考之前就动手写程序?/p>
你ؓ了节省一天的试旉而漏掉了一个bugQ在来的维护阶D，可能需要花几周甚至几个月的旉M复。与其如此，q不如重新安排一下项目计划?/p>
避免走捷径，只做一ơ但要做对（do it once by doing it rightQ?/p>
15. 别信赖Q何h
产品和服务销售公怸是你的朋友，你的大部分员工和高层理人员也不是?/p>
大部分品供应商希望把你牢牢l在他们的品上Q可能是操作pȝQ数据库或者某个开发工兗?/p>
大部分的N和承包商只关心你的钱q不是你的工E（停止向他们付ƾ，看一看他们会在周围呆多长旉Q?/p>
大部分程序员认ؓ他们自己比其他h更优UQ他们可能抛弃你设计的模型而用自己认ؓ更好的?/p>
只有良好的沟通才能解册些问题?/p>
要明的是，不要只依靠一家品或服务提供商，即你的公司Q或l织Q已l在建模、文档和q程{方面向那个公司投入了很多钱?/p>
16. 证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型， 或者称?#8220;端到?#8221;原型。以证明你的设计是能够工作的?/p>
你应该在开发工作的早期做这些事情，因ؓQ如果Y件的设计Ҏ是不可行的，在编码实现阶D|论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计更Ҏ获得支持?/p>
17. 应用已知的模?
目前Q我们有大量现成的分析和设计模式以及问题的解x案可以用?/p>
一般来_好的模型设计和开发h员，都会避免重新设计已经成熟的ƈ被广泛应用的东西。http://www.ambysoft.com/processPatternsPage.html收藏了许多开发模式的信息?/p>
18. 研究每个模型的长处和q
目前有很多种cȝ模型可以使用,如下图所C。用例捕L是系l行为需求，数据模型则描q支持一个系l运行所需要的数据构成。你可能会试囑֜用例中加
入实际数据描qͼ但是Q这对开发者不是非常有用。同P数据模型ҎqY仉求来说是无用的。每个模型在你徏模过E中有其相应的位|，但是Q你需要明白在
什么地方，什么时候用它们?br />
19. 在现有Q务中应用多个模型
当你攉需求的时候，考虑使用用例模型Q用L面模型和领域U的cL型?/p>
当你设计软g的时候，应该考虑制作cL型，序图、状态图、协作图和最l的软g实际物理模型?/p>
E序设计人员应该慢慢意识刎ͼ仅仅使用一个模型而实现的软g要么不能够很好地满用户的需求，要么很难扩展?/p>
20. 教育你的听众
你花了很大力气徏立一个很成熟的系l模型，而你的听众却不能理解它们Q甚xp－qؓ什么要先徏立模型都不知道。那么你的工作是毫无意义的?/p>
教给你开发h员基本的建模知识Q否则，他们会只看看你画的漂亮图表，然后l箋~写不规范的E序?/p>
另外Q?你还需要告诉你的用户一些需求徏模的基础知识。给他们解释你的用例(uses case)和用L面模型，以他们能够明白你要表达Cѝ当每个人都能用一个通用的设计语a的时候（比如UML-译者注Q，你的团队才能实现真正的合作?/p>
21. 带工Lȝq是ȝ
你给我CAD/CAM工具Q请我设计一座桥。但是，如果那桥徏成的话，我肯定不惛_W一个从桥上q的人，因ؓ我对建筑一H不通?/p>
使用一个很优秀的CASE工具q不能你成Z个徏模专Ӟ只能使你成ؓ一个优UCASE工具的用者。成Z个优U的徏模专安要多q的U篏Q不 会是一周针Ҏ个h值几千美元工L培训。一个优U的CASE工具是很重要Q但你必d习用它Qƈ能够使用它设计它支持的模型?/p>
22. 理解完整的过E?
好的设计人员应该理解整个软gq程Q尽他们可能不是精通全部实现细节?/p>
软g开发是一个很复杂的过E，q记得《object-oriented software process》第36늚内容吗？除了~程、徏模、测试等你擅长工作外Q还有很多工作要做?/p>
好的设计者需要考虑全局。必M长远考虑如何使Y件满用户需要，如何提供l护和技术支持等?/p>
23. 常做试Q早做测?
如果试对你的Y件来说是无所谓的Q那么你的Y件多半也没什么必要被开发出来?/p>
建立一个技术原型供技术评审用，以检验你的Y件模型?/p>
在Y件生命周期中Q越晚发现的错误难修改Q修Ҏ本越昂贵。尽可能早的做测试是很值得的?/p>
24. 把你的工作归?
不值得归档的工作往往也不值得做。归档你的设惻I以及Ҏ设想做出的决定；归档软g模型中很重要但不很明昄部分?l每个模型一些概要描qC使别人很快明白模型所表达的内宏V?/p>
25. 技术会变，基本原理不会
如果有h?#8220;使用某种开发语a、某个工h某某技术，我们׃需要再做需求分析，建模Q编码或试”。不要相信，q只说明他还~Zl验。抛开技术和 人的因素Q实际上软g开发的基本原理?0世纪70q代以来没有改变过。你必须q定义需求，建模Q编码，试Q配|，面对风险Q发布品，理工作人员 {等?/p>
软g建模技术是需要多q的实际工作才能完全掌握的。好在你可以从我的徏议开始，完善你们自己的Y件开发经验?/p>
以鸡汤开始，加入自己的蔬菜。然后，开始n受你自己的丰盛晚吧?/p>