软件建模经验（4）

夏日

17. 应用已知的模式

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

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

18. 研究每个模型的长处和弱点

    用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。

    你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。

    同样，数据模型对描述软件需求来说是无用的。

   每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。

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

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

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

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

20. 教育你的听众

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

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

    另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。

    当每个人都能使用一个通用的设计语言的时候（比如UML），你的团队才能实现真正的合作。

21. 带工具的傻瓜还是傻瓜

    你给我CAD/CAM工具，请我设计一座桥。

    但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。

    使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。

    成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。

    一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。