举一个简单的例子：一个银行的信贷系统有这样的问题描述：

　　“若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。”

　　在某种条件下应该做什么事情，这就是这个问题描述的表现形式，很简单是吧。

　　实际上，这里可以引申出两个概念：场景(context)和问题(problem)，场景指的是一种特定的情况，会导致某种问题的发生；而问题是在某个场景之中，但它也有可能产生出新的场景。

　　过程和对象

　　有必要说明一下以前基于过程的软件开发和目前基于对象的软件开发的不同。在没有OO的年代里，DFD(Data Flow Diagram 数据流程图)是一份软件设计中的非常重要的文档，注意力的关键也是集中在数据如何在各个系统之间传递。可是在现在的OO概念中，数据大有为消息(message)所替代的趋势。比如你到麦当劳快餐店，要花10块钱买一份汉堡。在DFD的时代，就是这样表示的：

　　如果你用消息表示法来表示话，就是另一种方式：

　　怎么样，你觉得那一种方式更自然呢。(如果你敢回答第一种的话我就...)。再比如上一段话中关于问题描述的例子，如果用传统的数据描述的方法的话，就会是这样子的：
 
　　“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”

　　请比较其中的两句话：

　　“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”

　　“若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。”

　　了解其中的不同之处了吗，用自然的语言去描述你的问题，这是写出好的软件的第一步。

　　系统分析员的语言

　　场景描述是一个很不错的方法，可是随着你对系统的分析的深入，参与开发的人员的增加，你渐渐的感觉这种方法不够用了。原因有很多：文字的描述不够直观，不可能到达一种很细致的程度。这时候就需要一种能够描述问题、描述解决方案、起沟通作用的语言。这就是UML。

　　UML(Unified Modeling Language 统一建模语言)是由Rational公司发明，目前由OMG(标准化对象管理机构)维护。作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分：

　　UML语义　

　　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。