模型定义

如果你现在是一个程序员，准备在软件开发这条路上走下去，并且希望能够在这条路上越走越顺的话，你应该在模型上下更多的功夫。典型的技术人员在软件开发职业上的路有两条：1. 程序员（编码）->高级程序员（详细设计）->系统分析员（系统分析）->架构师（架构设计）；2. 程序员->高级程序员->Team Leader->Project Manager。不管你准备走哪一条路，模型都是你必不可少的、有力的工具。

    模型是什么？

    模型是系统知识的抽象表示。我们不能仅仅通过语言来描述一个系统，也不能仅仅通过记忆来记录关于系统的知识。知识是通过某种媒介来表达的，这种媒介所表达的内容就是模型。而知识形成媒介的过程就是建模，或者称为模型化。通常模型可以使用多种不同的媒介来表达，比如纸质或电子文档、缩微模型/原型、音像制品等等。而表达模型的体现方式也是多种多样的，常见的有图表、公式、原型、文字描述等等。

    模型三要素

    模型是通过建模语言、表示法和文字描述来表示的。语法（syntax）、语义（semantics）和语用（pragmatics）是模型的三个要素。

    语法是使用建模语言所提供的元素的方法，以及如何组织、关联这些元素。

    语义是指一个具体模型所表达的含义。

    语用则表示模型在特定环境下的应用，以及应用此模型的环境对模型本身的影响。

    模型的作用

    模型首先是参与构造软件的人之间的主要沟通手段和基础；其次，模型指导系统的实现；模型还帮助设计者做出决策；最后，模型对未来的开发很重要，也是软件维护的基础。

    软件模型存在的问题

    国内的软件开发，从来都不缺乏模型——缺乏的是模型的完整性和准确性。产生这个问题的原因有很多，其中主要的、影响较大的有：不切实际的进度要求迫使开发商极力压缩建模时间；分析设计人员水平不够；分析设计人员没有掌握建模方法或对模型的表达不科学；建模完成后缺乏维护。

    进度问题是一个非常棘手的问题，一般还是要依靠商务人员解决。分析设计人员水平问题，我是没有办法解决。——这些都不在本文讨论范围内。下面主要讲后面两个问题。

    建模问题及对策

    首先就是对建模语言的语法掌握不准确，甚至存在对语法的误用。这就导致了模型表达不精确，或者使用错误的方式来表达正确的概念。这在小型的开发组织中是比较常见的。解决这个问题的对策如下：

• 开展针对建模语言、建模方法的培训。培训才是王道啊！

• 使用尽量小的建模语言元素集合。这样可以减小犯错误的机会，只是治标不治本。

• 局部范围内统一对建模语言元素的使用。这是Work around的方法，初始成本低，但这要求后期水平提高后批量修改原存在错误的模型。

    模型维护问题及对策

    相比建模问题，模型维护在问题更加严重和普遍。本来，模型和实际的事物之间就存在着一定的差异，这叫做语义间隙（semantic gap）。这类似于思维和客观对象之间的关系——思维只能无限逼近客观对象的实际原理。由于人（客户）本身的思维不确定性及其不断发展，用户需求总是在不断改进或变化。相应的，我们开发的软件也要不断的修改。但是，在国内，这种变化基本从未反应到模型中。这就造成语义间隙越来越大，最后模型也就成了聋子的耳朵——摆设。解决这个问题的对策：

• 加强软件配置管理和变更控制。通过严格的变更控制来确保模型的一致性。

• 逆向工程在某些情况下可以发挥作用。可惜不是总能够发挥作用，而且它不能减小语义间隙。

• 期待MDA（Model Driven Architecture）。问题是MDA什么时候才能完善呢？保持关注吧。
  

    关于语用

    关于语用的研究不多。语用，即使在语言学范畴也是比较偏的领域。基本上我们没有一个可用的指导理论，只能依赖于经验。对于越大的系统，模型越重要，也能够发挥其作用。对于简单的系统，可以建设较小的模型，其发展可能会较快，这就需要更多的维护工作。简单系统通常至少需要一个精致的核心模型，虽然用到的语法元素不多，比较紧凑，但也不能在这方面忽视它。