java建模的误区在哪里

1、java建模的误区在哪里java建模的误区在哪里误区一：建模就等于是写文档这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。另外，甚至于许多尽责的开发人员现在也认为建模是一件讨厌的事，而不愿去学习相应的建模技术。事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在餐巾纸的背面，或写在一块白板上，或在Class Responsibility Collaboration(C

2、RC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身;价值体现在建模的活动中，而非模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。误区二：从开始阶段你可以考虑到所有的一切这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确，试图在编码开始前就

3、“冻结”所有的需求 - 因为它能规划数据库。这两个工具真正地帮助我实现了软件开发的目的 制造满足用户要求的软件。但我绝大多数得建模工作仍然使用的是简单的工具，而不是CASE工具。误区三：建模是在浪费时间许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进

4、行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该项目中的每个成员也可得到对该项目有一个从分的了解。误区四：数据模型(Data Model)就是一切许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规定，控制着你的.开发项目;或者你以前的数据库是一团糟，别无选择。事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。(参见“Extreme Modeling”，Thinking Objectively，Nov.2000)。

5、这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的(在数据模型中没有表示出来)，这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 使用案例(use cases)，业务规则(business rules)，activity diagrams，类图(class diagrams)，component diagrams，用户界面流程图(user interface flow diagrams)和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。误区五：所有的开发人员都知道如何建模我们现在面临照这样一个严重的问题：许多不是开发人员的人，包括高级经理和用户，不知道软件是如何建成的。其结果，他们不能够区分开熟练的开发者和一般的程序员(当然也分不清高级程序员和一般程序员)，他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，