需求分析第三课：需求分析常用模型概述
方法/步骤
1、大牛回顾了第二课的内容：“在需求分析中用到三种类蕞瞀洒疸型的模型，分别是数学模型、描述模型和图形模型。需求分析中诸如数据分析、统计、计算一般用数学模型建模，图形模型较多用于业务流程建模，描述模锸责氧铼型一般用于功能列表、输入列表、输出列表、事件等列表的建模”。小白：“在需求分析中，有没有标准化的、成熟的模型可以使用呢？”。大牛：“当然有，不过软件建模不是从来就有的，而是随着软件工程的发展不断成熟和完善起来。在需求分析阶段，系统分析员经常使用逻辑模型来建立需求模型”。小白：“什么是逻辑模型？”。大牛：“逻辑模型只是定义了系统需求，并没有局限于某一具体技术，逻辑模型的具体细节后面会讲到，本课主要是对需求分析阶段用到的逻辑模型做个简单介绍”。大牛在黑板上写下了本节课的学习内容。●需求分析阶段常用的逻辑模型大牛：“有很多种类的逻辑模型用来定义系统需求，这是一些经常使用的模型”。大牛边说边在黑板上写下了常用的逻辑模型。■事件列表■数据字典■数据流图（DFD）■实体关系图（ERD）■流程图■类图■用例图■时序图■协作图■状态图小白：“太多模型了，需求分析中都要用到吗？能不能简单介绍一下每个逻辑模型的用途？”大牛：“在需求分析中，上面所列的模型不一定都要用到，可以根据项目规模和项目要求选取合适的逻辑模型来建模，一般建模都是从事件列表开始建模的”。小白：“事件列表是不是记录系统发生的事件呢？”大牛：“对，所有系统的开发方法都是以事件概念开始建模的，事件发生在某一特定的事件和地点，可描述并且系统应该记录下来”。小白：“记录系统发生的事件对需求分析有什么作用呢？”。大牛：“例如，我们对Windows操作系统都很熟悉，Windows操作系统本身就是由事件驱动的。你点击一个程序图标、滑动鼠标、按下鼠标左键等操作都是在触发一个事件，操作系统接收到事件，并对事件进行相应的处理”。大牛：“Windows操作系统的所有处理过程都是由事件来驱动或触发的，当你定义系统需求时把所有事件罗列出来并加以分析是非常重要的”。小白：“哦，明白了，所有的系统需求分析都是先从事件分析开始的，事件模型就是记录事件分析的结果”。小白：“数据字典呢？这个概念有点抽象”。大牛：“数据字典是用来描述模型数据的，是对模型涉及到数据进行定义和描述。举个例子，电话在线订餐系统的事件模型中可能会记录用户拨进电话这个事件，这个事件需要记录拨进的电话号码、区号、时间等数据项，你可能需要描述这些数据项的长度、数据类型、用途或预先定义的默认值，给系统设计师提供参考数据，这些描述数据称为数据字典”。小白：“哦，数据字典就是模型中用到的一些数据，需要另外的数据来定义和描述”。大牛：“不错，理解很快。我们再来看数据流图”。随即大牛将一张图片投影到屏幕上。
2、大牛：“你看这张图，这就是数据流图，数据流图描述了数据从输入到输出的整个过程，数据流图以数据为中心，展示数据的流向和数据的处理节点，通过数据流图可以清晰地看出从接听电话开始到取餐结束，完整订餐信息流的处理及变换”。小白：“真是一张图胜过千言万语啊，电话的订餐过程一目了然。不过，怎么判定数据流？怎么区分数据流和数据的处理过程呢？”大牛笑了笑：“别急，现在只是让你了解一下需求建模的常用模型，后面的课会详细讲述如何建模”。小白：“哦，好”。大牛：“我们再来看实体关系图”随后大牛将一张图片投影到屏幕上。大牛：“你看这张图，这就是实体关系图。实体关系图反映了系统实体及实体间的关系。例如：在电话订餐系统中，涉及到的实体有客户、接电话人员（客服）、备餐人员、订餐单据。图给出了这些实体间的关系，图中N:N的意思是一个客服可以对应多个客户，一个客户也可以对应多个客服”。小白：“这么说，实体就是系统涉及到人和事”。大牛：“基本可以这么说，实体一般都有存储数据的需求，如果事物没有存储数据的需求，就不能当作实体看待”。小白：“明白….”。大牛：“接着是流程图，流程图很简单，基本都见过，这里就不说了，再看下面的几个模型”。大牛：“类图、用例图、时序图、协作图、状态图都是UML建模语言提供的模型，类图用于在需求分析中为识别的实体建模；用例图用于系统功能建模；时序图用于实体间交互行为发生的时间顺序建模；协作图也是描述实体间的交互行为，与时序图不同的是，协作图更强调实体之间的相互关系及协作而忽略时间的约束；状态图用于描述实体状态的变化及事件发生时实体的变化情况”。小白苦笑了一下：“脑子有点打浆糊了，刚才说的类图、用例图、时序图、协作图、状态图都没太听清楚”。大牛：“现在不清楚没关系，后面我们都要详细讲述”。小白：“哦，那太好了”。大牛：“这节课主要是讲述了需求建模常用的模型，对常用的模型先大概了解一下，后面会详细讲述。下节课的内容，我们会探讨事件的概念，因为任何系统需求分析都是从事件开始的”。
