需求分析与解决方案设计ch11PPT推荐.ppt
《需求分析与解决方案设计ch11PPT推荐.ppt》由会员分享，可在线阅读，更多相关《需求分析与解决方案设计ch11PPT推荐.ppt（23页珍藏版）》请在冰点文库上搜索。
,3,11.2从客户需求到分析模型,分析模型的建立，是根据认真听取客户陈述他们的需求之后，分析人员就可以挑选出关键字，将这些关键字转换成特定的模型元素。
表11.1列出了一些可能的映射，把客户提供的重要名词和动词关联到分析模型组件。
表11.1把客户需求关联到分析模型组件,4,11.3数据流图,数据流图（dataflowdiagram，DFD）：
是一种分析模型，它描绘了过程、数据集合、端点以及他们之间的流，这种流表现了业务过程或软件系统的行为特点。
一个数据流图可以标识系统的转换过程、系统所操纵的数据或物质集合（存储），以及过程、存储和外部世界之间的数据流或物质流。
数据流模型把功能分解方法运用到系统分析上，把复杂的问题进一步分解到更详细的层次。
这种方法适用于事务处理系统和其他功能密集型应用程序。
图5.1所示的关联图是数据流图最高层的抽象。
5,图5.3化学品跟踪管理系统的关联图,6,11.3数据流图,我们可以把关联图详述成0层数据流图，它将系统划分为若干主要过程。
如图11.1所示“化学品跟踪管理系统”的第0层数据流图，将系统细分为7个主要过程（用圆圈表示）。
数据流图中的表示符号：
圆圈：
主要过程矩形框：
端点箭头：
数据流双箭头：
代表是一个更新的操作一对平行水平线：
数据存储区,7,8,11.3数据流图,在0层数据流图中每个圆圈代表的过程可以进一步扩展成一个独立的数据流图，以便更详细的展示其功能。
分析人员可以将它进行逐步细化，直到最底层的图只包含基本的过程为止。
如：
图2-4应付账款的0层数据流图。
将应付账款处理过程细化为应付账款处理的第一层次的数据流图,图2-4应付账款的0层数据流图,9,10,11.3数据流图,以下是绘制数据流图的一些约定规则：
将数据存储区放在第0层数据流图和更低层的子图上，而不要放在关联图中。
过程通过数据存储区进行通信，而不是从一个过程直接流到另一个过程。
使用数据流图时，不要试图让数据流图反映处理顺序。
用简明的动词短语命名每一个过程：
动词加对象（例如生成存货报表）。
过程的编号要惟一且具有层次性。
在单个图中绘制的过程不要超过810个，否则就很难绘制、更改和理解它。
与圆圈相连的数据流不允许只有输入或只有输出。
11,11.4实体关系图,数据模型用于描绘数据关系。
最常使用的数据模型是实体关系图（Entity-RelationshipDiagram，ERD）。
实体关系图：
是一种分析模型，它确认了一对实体之间的逻辑关系。
表示符号矩形框：
实体。
（实体用单名词来命名）菱形框：
关系。
（它确定了一对实体之间在逻辑上和数量上的连接。
关系的命名要能描述关系的本质）椭圆框：
属性实体和关系之间的连线上的数字或者字母表示每个关系的基数。
“1”代表一个，“m”代表多个。
实体之间的关系有：
一对一；
一对多；
多对多。
如图11.2所示,12,13,11.5状态转换图,所有软件系统都包括功能行为、数据操作和状态改变。
实时系统和过程控制应用程序可以在任何给定的时间内以有限状态中的某一种状态存在。
系统元素包括一个状态集和状态之间的变化，它们可以被视作有限状态机。
状态转换图可以很好的表现这种有限状态机。
状态转换图（StateTransitionDiagram，STD）：
是一种分析模型，它展示了系统可能的各种状态或系统中对象可能具有的状态，展示了状态之间允许的状态转换。
状态转换图包括如下3种元素：
可能的系统状态，用矩形框来表示。
允许的状态改变或迁移，用箭头连接一对矩形框表示。
引起每个状态转换的事件或条件，在每个迁移箭头上用文本标签来表示。
如图11.4,14,15,11.6对话图,用户界面可以视作一个有限的状态机，可以用一种称为对话图（dialogmap）的状态转换图来对许多用户界面进行建模。
对话图：
是一种分析模型，它描绘了用户界面架构，展示了屏幕元素以及在这些元素之间允许的导航。
对话图在较高的抽象层次上表示用户界面的设计，它展示了系统的对话元素及这些元素之间的导航连接，但没有展示详细的屏幕设计。
对话图展示的是用户-系统交互和任务流的本质，不会使团队陷入屏幕布局细节中。
通过跟踪对话图，用户可以发现遗漏的错误的或不必要的转换，进而发现遗漏的错误的或多余的需求。
16,11.6对话图,与普通的状态转换图一样，在对话图中将每一个对话元素展示为一个状态（用矩形框表示），将每一个允许的导航选项展示为一个转换（用箭头表示），触发用户界面导航的条件用转换箭头上的文本标签表示。
触发条件有以下几种类型：
用户动作。
数据值。
系统条件。
这些情况的某些组合。
17,18,11.7用例图,用例图：
是一种分析模型，它确认了与系统交互的执行者和每一个执行者将执行的用例。
图8.1化学品跟踪管理系统用例图,19,11.8流程图,流程图：
是一种分析模型，它按照过程或程序的逻辑，显示了过程步骤和判断点。
流程图与活动图相似。
20,11.9判定表和判定树,当逻辑和判定过程很复杂时，我们可以选用判定表和判定树这两种技术来表示系统应该做什么。
判定表（decisiontable）可列出影响系统行为的所有因素的各种取值，并表明对这些因素的每一种组合所期望的系统响应动作。
判定表和判定树是编写需求文档（或业务规则）的两种很有用的方法，采用这两种方法可以避免遗漏任何条件组合。
如下示例：
21,22,11.10最后的提醒,本章所述的每一种建模技术都有其优点和局限性。
我们绘制分析模型是为了提供一个层次来理解需求并交流需求，而这是用文本描述的软件需求规格说明和任何其他单一的视图所不能提供的。
应该避免陷入在软件开发方法和模型中发生的教条的思维模式和派系斗争。
23,课后小结,主要介绍需求分析的图形工具，包括数据流图（DFD）、实体关系图（ERD）、状态转换图（STD）或状态图、对话图、用例图。
重点掌握各种需求模型的概念模型中的表示符号,
升级会员 