咱们期待本身成为一个优秀的软件模型设计者，可是，要怎样作，又从哪里开始呢？html
将下列原则应用到你的软件工程中，你会得到立杆见影的成果。java
你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据集合而已。程序员
许多在软件方面颇有成就的行家在他们事业的初期却表现平平，由于他们那时侯将主要精力都集中在技术上。数据库
显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是颇有趣的东西。可是对于用户来讲，若是你设计的软件很难使用或者不能知足他们的需求，后台用再好的技术也于事无补。编程
多花点时间到软件需求和设计一个使用户能很容易理解的界面上。windows
好的软件设计人员把大多数时间花费在创建系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程当中所遇到的问题。设计模式
这将使他们的设计方案更加可行。数据结构
你不可能知道一切，你甚至要很努力才能得到足够用的知识。ide
软件开发是一项复杂而艰巨的工做，由于软件开发所用到的工具和技术是在不断更新的。工具
并且，一我的也不可能了解软件开发的全部过程。
在平常生活中你天天接触到的新鲜事物可能不会太多。可是对于从事软件开发的人来讲，天天能够学习不少新东西（若是愿意的话）。
若是你没有任何需求，你就不要动手开发任何软件。
成功的软件取决于时间（在用户要求的时间内完成）、预算和是否知足用户的需求。
若是你不能确切知道用户须要的是什么，或者软件的需求定义，那么你的工程注定会失败。
Object ToolSmiths公司的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。
他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型能够彻底知足解决某个具体问题的须要（我理解的意思是需求分析须要一丝不苟、精确的完成,而设计的时候反而能够发挥创造力和想象力）。
若是需求常常改动，极可能是你没有做好需求分析，并非需求真的改变了。
能够抱怨用户不能告诉你他们想获得什么，可是不要忘记，收集需求信息是你的工做。
能够说是新来的开发人员把事情搞得一团糟，可是，你应该肯定在工程的第一天就告诉他们应该作什么和怎样去作。
若是以为公司不让你与用户充分接触，那只能说明公司的管理层并非真正支持你的项目。
能够抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么作的。
能够借口说大家的竞争对手的成功是由于他们有了一个新的理念，可是为何你没先想到呢？
需求真正改变的状况不多，可是没有作好需求分析工做的理由却不少。
在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉过久。
每月至少读二、3本专业杂志或者1本专业书籍。保持不落伍须要付出不少的时间和金钱，但会使你成为一个颇有实力的竞争者。
高耦合度的系统是很难维护的。一处的修改引发另外一处甚至更多处的变更。
你能够经过如下方法下降程序的耦合度：
耦合度低的软件能够很容易被重用、维护和扩充。
若是一个软件的模块只实现一个功能，那么该模块具备高内聚性。
高内聚性的软件更容易维护和改进。
判断一个模块是否有高的内聚性，看一看你是否可以用一个简单的句子描述它的功能就好了。若是你用了一段话或者你须要使用相似“和”、“或”等连词，则说明你须要将该模块细化。
只有高内聚性的模块才可能被重用。
移植是软件开发中一项具体而又实际的工做，不要相信某些软件工具的广告宣传（好比java 的宣传口号write once run many ）。
即便仅仅对软件进行常规升级，也要把这看得和向另外一个操做系统或数据库移植同样重要。
记得从16位Windows移植到32位windows的“乐趣”吗 ？
当你使用了某个操做系统的特性，如它的进程间通讯(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。
好的软件设计者把那些特有的实现细节打包隐藏起来，因此，当那些特性改变的时候，你的仅仅须要更新那个包就能够了。
这是一句老话了：惟一不变的只有变化。
你应该将全部系统将可能发生的变化以及潜在需求记录下来,以便未来可以实现（参见“Architecting for Change”，Thinking Objectively, May 1999）
经过在建模期间考虑这些假设的状况，你就有可能开发出足够强壮且容易维护的软件。
设计强壮的软件是你最基本的目标。
Internet 带给咱们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。
今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，经过因特网可能会有几百万人使用它。
在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，肯定软件的基本功能。而后，在建造系统的时候再逐步加入比较经常使用的功能。
在设计的开始考虑软件的规模需求，避免在用户群忽然增大的状况下，重写软件。
关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。
一个性能不佳的软件将不可避免被重写。
可是你的设计还必须具备可靠性，可用性，便携性和可扩展性。
你应该在工程开始就应该定义并区分好这些因素，以便在工做中恰当使用。
性能能够是，也能够不是优先级最高的因素，个人观点是，给每一个设计因素应有的考虑。
“UML User Guide”中指出，你应该在开发阶段的早期就定义软件模块之间的接口。
这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工做。
一旦模块的接口肯定以后，模块怎样实现就不是很重要了。
从根本上说，若是你不可以定义你的模块“从外部看上去会是什么样子”，你确定也不清楚模块内要实现什么。
在软件开发中没有捷径能够走。
缩短在需求分析上花的时间，结果只能是开发出来的软件不能知足用户的需求，必须被重写。
在软件建模上每节省一周，在未来的编码阶段可能会多花几周时间，由于在全面思考以前就动手写程序。
为了节省一天的测试时间而漏掉了一个bug，在未来的维护阶段，可能须要花几周甚至几个月的时间去修复。与其如此，还不如从新安排一下项目计划。
避免走捷径，只作一次但要作对（do it once by doing it right）。
产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。
大部分产品供应商但愿把你紧紧绑在他们的产品上，多是操做系统，数据库或者某个开发工具。
大部分的顾问和承包商只关心你的钱并非你的工程（中止向他们付款，看一看他们会在周围呆多长时间）。
大部分程序员认为他们本身比其余人更优秀，他们可能抛弃你设计的模型而用本身认为更好的。
只有良好的沟通才能解决这些问题。
要明确的是，不要只依靠一家产品或服务提供商，即便你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了不少钱。
在设计的时候应当先创建一个技术原型， 或者称为“端到端”原型。以证实你的设计是可以工做的。
你应该在开发工做的早期作这些事情，由于，若是软件的设计方案是不可行的，在编码实现阶段不管采起什么措施都于事无补。
技术原型将证实你的设计的可行性，从而，你的设计将更容易得到支持。
目前，咱们有大量现成的分析和设计模式以及问题的解决方案可使用。
通常来讲，好的模型设计和开发人员，都会避免从新设计已经成熟的并被普遍应用的东西。
用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所须要的数据构成。
你可能会试图在用例中加入实际数据描述，可是，这对开发者不是很是有用。
一样，数据模型对描述软件需求来讲是无用的。
每一个模型在你建模过程当中有其相应的位置，可是，你须要明白在什么地方，何时使用它们。
当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。
当你设计软件的时候，应该考虑制做类模型，顺序图、状态图、协做图和最终的软件实际物理模型。
程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不可以很好地知足用户的需求，要么很难扩展。
你花了很大力气创建一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为何要先创建模型都不知道。那么你的工做是毫无心义的。
教给你开发人员基本的建模知识；不然，他们会只看看你画的漂亮图表，而后继续编写不规范的程序。
另外， 你还须要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们可以明白你要表达地东西。
当每一个人都能使用一个通用的设计语言的时候（好比UML），你的团队才能实现真正的合做。
你给我CAD/CAM工具，请我设计一座桥。
可是，若是那座桥建成的话，我确定不想当第一个从桥上过的人，由于我对建筑一窍不通。
使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。
成为一个优秀的建模专家须要多年的积累，不会是一周针对某个价值几千美圆工具的培训。
一个优秀的CASE工具是很重要，但你必须学习使用它，并可以使用它设计它支持的模型。
好的设计人员应该理解整个软件过程，尽管他们可能不是精通所有实现细节。
软件开发是一个很复杂的过程，《object-oriented software process》说过：除了编程、建模、测试等你擅长工做外，还有不少工做要作。
好的设计者须要考虑全局。必须从长远考虑如何使软件知足用户须要，如何提供维护和技术支持等。
若是测试对你的软件来讲是无所谓的，那么你的软件多半也没什么必要被开发出来。
创建一个技术原型供技术评审使用，以检验你的软件模型。
在软件生命周期中，越晚发现的错误越难修改，修改为本越昂贵。尽量早的作测试是很值得的。
不值得归档的工做每每也不值得作。
归档你的设想，以及根据设想作出的决定；
归档软件模型中很重要但不很明显的部分。
给每一个模型一些概要描述以使别人很快明白模型所表达的内容。
若是有人说“使用某种开发语言、某个工具或某某技术，咱们就不须要再作需求分析，建模，编码或测试”。
不要相信，这只说明他还缺少经验。
抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。
你必须定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工做人员等等。
软件建模技术是须要多年的实际工做才能彻底掌握的。好在你能够今后建议开始，完善本身的软件开发经验。
以鸡汤开始，加入本身的蔬菜。而后，开始享受你本身的丰盛晚餐吧。
http://www.cnblogs.com/allanbolt/archive/2009/06/26/1511438.html