怎样成为一个优秀的软件模型设计者

我们期待自己成为一个优秀软件模型设计者，但是，要怎样做，又从哪里开始呢？ 字串3

　　将下列原则应用到你软件工程中，你会获得立杆见影成果。 字串2

　　1. 人远比技术重要 字串4

　　你开发软件是为了供别人使用，没有人使用软件只是没有意义数据集合而已。许多在软件方面很有成就行家在他们事业初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣东西。但是对于用户来说，如果你设计软件很难使用或者不能满足他们需求，后台用再技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解界面上。

字串8

　　2. 理解你要实现东西

字串9

　　软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到问题。这将使他们设计方案更加可行。

字串4

　　3. 谦虚是必须品格 字串4

　　你不可能知道一切，你甚至要很努力才能获得足够用知识。软件开发是一项复杂而艰巨工作，因为软件开发所用到工具和技术是在不断更新。而且，一个人也不可能了解软件开发所有过程。在日常生活中你每天接触到新鲜事物可能不会太多。但是对于从事软件开发人来说，每天可以学习很多新东西（如果愿意话）。 字串5

　　4. 需求就是需求

字串3

　　如果你没有任何需求，你就不要动手开发任何软件。成功软件取决于时间（在用户要求时间内完成）、预算和是否满足用户需求。如果你不能确切知道用户需要是什么，或者软件需求定义，那么你工程注定会失败。

字串4

　　5. 需求其实很少改变，改变是你对需求理解

字串8

　　Object ToolSmiths公司（www.objecttoolsmiths.com）Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他意思是说在众多“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题需要（我理解意思是需求分析需要一丝不苟、精确完成,而设计时候反而可以发挥创造力和想象力 - 译者注）。

字串8

　　如果需求经常改动，很可能是你没有作需求分析，并不是需求真改变了。

字串8

　　你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。 字串8

　　你可以说是新来开发人员把事情搞得一团糟，但是，你应该确定在工程第一天就告诉他们应该做什么和怎样去做。

字串3

　　如果你觉得公司不让你与用户充分接触，那只能说明公司管理层并不是真正支持你项目。 字串7

 

字串9

　　你可以抱怨公司有关软件工程管理制度不合理，但你必须了解大多同行公司是怎么做。

字串2

　　你可以借口?img alt="" src="http://51dev.com/ads/de.gif" />忝?img alt="" src="http://51dev.com/ads/de.gif" />竞争对手成功是因为他们有了一个新理念，但是为什么你没先想到呢？

字串4

　　需求真正改变情况很少，但是没有做需求分析工作理由却很多。 字串4

　　6. 经常阅读 字串9

　　在这个每日都在发生变化产业中，你不可能在已取得成就上陶醉太久。 字串8

　　每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多时间和金钱，但会使你成为一个很有实力竞争者。 字串3

　　7. 降低软件模块间耦合度 字串5

　　高耦合度系统是很难维护。一处修改引起另一处甚至更多处变动。

字串7

　　你可以通过以下方法降低程序耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我经验法则是：当应用程序员在写SQL代码时候，你程序耦合度就已经很高了）。 字串8

　　耦合度低软件可以很容易被重用、维护和扩充。

字串4

　　8. 提高软件内聚性 字串2

　　如果一个软件模块只实现一个功能，那么该模块具有高内聚性。高内聚性软件更容易维护和改进。

字串9

　　判断一个模块是否有高内聚性，看一看你是否能够用一个简单句子描述它功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

字串7

　　只有高内聚性模块才可能被重用。

字串5

　　9. 考虑软件移植性

字串3

　　移植是软件开发中一项具体而又实际工作，不要相信某些软件工具广告宣传（比如java 宣传口号write once run many ? 译者注）。 字串2

　　即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。 字串5

　　记得从16位Windows移植到32位windows“乐趣”吗 ？当你使用了某个操作系统特性，如它进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你软件和那个特定产品结合度就已经很高了。

字串2

　　软件设计者把那些特有实现细节打包隐藏起来，所以，当那些特性该变时候，你仅仅需要更新那个包就可以了。 字串6

　　10. 接受变化 字串1

　　这是一句老话了：唯一不变只有变化。 字串6

　　你应该将所有系统将可能发生变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999） 字串7

　　通过在建模期间考虑这些假设情况，你就有可能开发出足够强壮且容易维护软件。设计强壮软件是你最基本目标。 字串2

 

字串2

　　11. 不要低估对软件规模需求 字串8

　　Internet 带给我们最大教训是你必须在软件开发最初阶段就考虑软件规模可扩充性。

字串3

　　今天只有100人部门使用应用程序，明天可能会被有几万人组织使用，下月，通过因特网可能会有几百万人使用它。

字串4

　　在软件设计初期，根据在用例模型中定义必须支持基本事务处理，确定软件基本功能。然后，在建造系统时候再逐步加入比较常用功能。

字串4

　　在设计开始考虑软件规模需求，避免在用户群突然增大情况下，重写软件。 字串1

　　12. 性能仅仅是很多设计因素之一 字串9

　　关注软件设计中一个重要因素--性能，这象也是用户最关心事情。一个性能不佳软件将不可避免被重写。

字串4

　　但是你设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高因素，我观点是，给每个设计因素应有考虑。 字串8

　　13. 管理接口 字串9

　　“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段早期就定义软件模块之间接口。 字串3

　　这有助于你开发人员全面理解软件设计结构并取得一致意见，让各模块开发小组相对独立工作。一旦模块接口确定之后，模块怎样实现就不是很重要了。 字串5

　　从根本上说，如果你不能够定义你模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

字串9

　　14. 走近路需要更长时间

字串6

　　在软件开发中没有捷径可以走。 字串2

　　缩短你在需求分析上花时间，结果只能是开发出来软件不能满足用户需求，必须被重写。 字串9

　　在软件建模上每节省一周，在将来编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。 字串4

　　你为了节省一天测试时间而漏掉了一个bug，在将来维护阶段，可能需要花几周甚至几个月时间去修复。与其如此，还不如重新安排一下项目计划。

字串3

　　避免走捷径，只做一次但要做对（do it once by doing it right）。 字串2

　　15. 别信赖任何人

字串6

　　产品和服务销售公司不是你朋友，你大部分员工和高层管理人员也不是。

字串7

　　大部分产品供应商希望把你牢牢绑在他们产品上，可能是操作系统，数据库或者某个开发工具。 字串7

　　大部分顾问和承包商只关心你钱并不是你工程（停止向他们付款，看一看他们会在周围呆多长时间）。

字串8

 

字串2

　　大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计模型而用自己认为更。 字串6

　　只有良沟通才能解决这些问题。

字串5

　　要明确是，不要只依靠一家产品或服务提供商，即使你公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。

字串6

　　16. 证明你设计在实践中可行 字串6

　　在设计时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你设计是能够工作。 字串3

　　你应该在开发工作早期做这些事情，因为，如果软件设计方案是不可行，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你设计可行性，从而，你设计将更容易获得支持。

字串9

　　17. 应用已知模式

字串1

　　目前，我们有大量现成分析和设计模式以及问题解决方案可以使用。 字串2

　　一般来说，模型设计和开发人员，都会避免重新设计已经成熟并被广泛应用东西。

字串3

　　http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式信息。 字串2

　　18. 研究每个模型长处和弱点 字串9

　　目前有很多种类模型可以使用,如下图所示。用例捕获是系统行为需求，数据模型则描述支持一个系统运行所需要数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用。每个模型在你建模过程中有其相应位置，但是，你需要明白在什么地方，什么时候使用它们。

字串6

　　19. 在现有任务中应用多个模型

字串7

　　当你收集需求时候，考虑使用用例模型，用户界面模型和领域级类模型。

字串1

　　当你设计软件时候，应该考虑制作类模型，顺序图、状态图、协作图和最终软件实际物理模型。

字串2

　　程序设计人员应该慢慢意识到，仅仅使用一个模型而实现软件要么不能够很地满足用户需求，要么很难扩展。

字串1

　　20. 教育你听众

字串5

　　你花了很大力气建立一个很成熟系统模型，而你听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你工作是毫无意义。 字串2

　　教给你开发人员基本建模知识；否则，他们会只看看你画漂亮图表，然后继续编写不规范程序。 字串2

　　另外， 你还需要告诉你用户一些需求建模基础知识。给他们解释你用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用设计语言时候（比如UML-译者注），你团队才能实现真正合作。 字串9

　　21. 带工具傻瓜还是傻瓜

字串7

 

字串6

　　你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成话，我肯定不想当第一个从桥上过人，因为我对建筑一窍不通。

字串2

　　使用一个很优秀CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具使用者。成为一个优秀建模专家需要多年积累，不会是一周针对某个价值几千美元工具培训。一个优秀CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持模型。 字串7

　　22. 理解完整过程 字串8

　　设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。 字串6

　　软件开发是一个很复杂过程，还记得《object-oriented software process》第36页内容吗？除了编程、建模、测试等你擅长工作外，还有很多工作要做。 字串1

　　设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。 字串2

　　23. 常做测试，早做测试 字串2

　　如果测试对你软件来说是无所谓，那么你软件多半也没什么必要被开发出来。 字串3

　　建立一个技术原型供技术评审使用，以检验你软件模型。 字串8

　　在软件生命周期中，越晚发现错误越难修改，修改成本越昂贵。尽可能早做测试是很值得。 字串9

　　24. 把你工作归档

字串7

　　不值得归档工作往往也不值得做。归?img alt="" src="http://51dev.com/ads/de.gif" />?img alt="" src="http://51dev.com/ads/de.gif" />设想，以及根据设想做出决定；归档软件模型中很重要但不很明显部分。 给每个模型一些概要描述以使别人很快明白模型所表达内容。

字串5

　　25. 技术会变，基本原理不会 字串5

　　如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人因素，实际上软件开发基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。 字串9

　　软件建模技术是需要多年实际工作才能完全掌握。在你可以从我建议开始，完善你们自己软件开发经验。 字串4

　　以鸡汤开始，加入自己蔬菜。然后，开始享受你自己丰盛晚餐吧。

本文来自: 我要研发网(http://www.51dev.com) 详细出处参考：http://51dev.com/plus/view.php?aid=9689