软件工程2章需求法分析33l.ppt

《软件工程2章需求法分析33l.ppt》由会员分享，可在线阅读，更多相关《软件工程2章需求法分析33l.ppt（113页珍藏版）》请在三一办公上搜索。

1、第三章 需求分析,软件需求分析 需求分析是软件定义时期的最后一个阶段，它的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。并在在需求分析阶段结束之前，由系统分析员写出软件需求规格说明书，以书面形式准确地描述软件需求。即：-准确地回答“系统必须做什么?”。意义：软件需求的深入理解是软件开发工作获得成功的前提条件，不论我们把设计和编码做得如何出色，不能真正满足用户需求的程序只会令用户失望，给开发带来烦恼。,软件需求工程的活动（内容）,软件需求工程,需求开发,需求管理,需求建模,需求获取,需求规格说明,需求验证,建立基线,变更控制

2、,需求跟踪,综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：（1）需求获取：深入实际，确定待开发的软件系统的用户类，通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；（2）需求分析及建模：主要对收集到的需求进行提炼、分析和认真审查，确保所有参加人员取得一致共识。找出错误、遗漏和不足，为最终用户所看到的系统建立模型，根据软件需求信息建立软件系统的逻辑模型或需求模型。需求模型作为对需求的抽象描述，尽可能多的捕获现实世界的语义，并确定非功能性需求和约束条件和限制。（3）形成需求规格：根据收集的需求信息和逻辑模型生成需求模型构件的精确的形式化的描述，作为

3、用户和开发者之间的一个协约编写需求规格说明及其文档。（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。当需求发生变更时，对需求规格说明及需求变更实施进行管理。需求工程也是一个项目工程，因此也包括了项目的管理。,软件需求工程的活动（内容）,3.1需求获取,需求获取是需求工程的主体内容之一。获取需求是一个确定和理解不同涉众的需要和约束的过程。涉众团体(所有能够影响软件系统的实现,或者被实现后的软件系统所影响的个人和团体)之间的相互沟通，识别需要的过程。涉众团体通过这个过程提取、定义需

4、求。需求获取既涉及技术问题，也涉及社会交往问题。难点：缺乏领域知识,应用领域的问题常常是模糊的、不精确的；存在默认的知识,如难以描述的常识问题；存在多个知识源,且多知识源之间可能有冲突；客户可能的偏见，如不能提供或不想告知你所需要了解的事情。,在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。只有用户才真正知道自己需要什么，但是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须与用户沟通获取用户对软件的需求,3.1需求获取,业

5、务需求,项目范围文档,用户需求,文档,功能需求,质量属性,其他非功能需求,设计约束,需求规约(specification),非功能需求,系统需求,需求组成的全景图,软件需求的层次,业务需求：反映组织机构和客户对系统、产品高层次的目标要求。用户需求：从用户使用的角度给出需求的描述。如一个小型超市需要一个商品的查询系统。业务需求：进货人员需要查询商品库存以便保证及时进货；收款员需要查询商品的销售价格以便结账；经理需要查询商品的销售及盈利情况。用户需求:这三类用户怎样去查询系统，查询哪些信息，还需要哪些操作。,软件需求的层次,系统需求：从系统的角度描述要提供的服务以及所受到的约束。功能性需求：描述系

6、统应该做什么，即为用户和其它系统完成的功能、提供的服务。非功能性需求：产品必须具备的属性或品质。设计约束：设计与实现必须遵循的标准、约束条件。如运行平台、协议、选择的技术、编程语言和工具等。,软件需求的组成,需求获取的过程：,确定需求开发计划,建立项目前景与范围,确定调查对象,实地收集用户需求信息,确定非功能需求和约束条件,1.确定需求开发计划,确定需求开发计划的基本任务是确定需求开发的实施步骤，给出收集需求活动的人员、具体安排和进度。需要重点注意的是：针对不同层次的调查对象，安排的调查人员在阅历和经验上的对等原则。调查人员的沟通和业务理解能力必须适当。用户的时间延误、文档确认的时间要在计划进

7、度中预留。,2.确定产品前景与项目范围,本阶段的任务是帮助投资管理人、产品经理弄清楚“为什么要作这个项目？”，组织的业务目标以及系统最终版本具备哪些功能的长远规划。产品前景（product vision）描述了产品用来干什么，它最终会是什么样子。项目范围（project scope）确定当前的项目要解决产品长远规划中的哪一部分。项目范围的细节体现于项目定义的需求基线。产生文档：前景与范围文档。,前景与范围的关系,前景关系到整个产品。当产品的战略定位或业务目标随时间发生改变时，前景也会变化。范围则只与一个特定项目，或实现产品功能下一增量的某次迭代相关。产品前景包括了每一个计划产品版本的范围,前景

8、和范围文档的模板,1.业务需求1.1 背景1.2 业务机遇1.3 业务目标与成功标准1.4 客户和市场需要1.5 业务风险2.解决方案的前景2.1 前景陈述2.2 主要的系统特征2.3 假设和依赖条件,3.项目范围与限制 3.1 第一个版本的范围 3.2 各后续版本的范围 3.3 限制和排除条件4.业务背景 4.1 涉众档案 4.2 项目优先级 4.3 运行环境,3.确定调查对象,本阶段的基本任务是明确地确定来自不同层次的需求来源和用户，并将其分类。(前景与范围文档可以帮助区分用户分类)由于软件需求分为三个层次，业务需求、用户需求、功能需求，故应根据需求的层次来区分不同的用户。用户分类：可分为

9、三种不同类别 用户方的领导者、项目规划者、项目出资人(目标)软件的直接使用、操作人员（功能,易用性）未来软件系统的技术管理、运行维护人员（性能,安装,维护）,4.实地收集用户需求信息,实地收集需求信息面临的困难1）能提出软件需求的用户没有时间2）有时用户希望通过简单的说明和问答3）用户和开发人员只考虑自己的利益4）用户本身不能提出明确的需求5）开发人员缺乏用户的业务知识，而用户缺乏计算机方面的知识，引起交流困难。,实地调查的步骤,1）向掌握“全局”的负责人调查：概貌,规划,目标,范围2）向部门负责人调查：业务和业务流程,部门间相互关系。功能需求和非功能需求,与其他部门间的接口。3）向业务人员调

10、查：自身工作处理细节、具体数据或表格的作用来源和去向、类型、精度、处理要求和输入/输出格式。具体的功能和性能需求。,2023/10/5,17,实地收集需求信息的方式,需求获取可能是软件开发中最需要交流的一项工作。获取涉众的需求是需求工作的重要环节。需求获取只有通过客户与开发者的有效合作才能成功。分析者必须为客户建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的产品有关。另外要让用户明确了解，对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，消除不必要的需求，以避免项目范围无意义地膨胀。目前主要有以下的需求获取方法。,面谈法 重要而直接，简单的需求获取

11、技术。面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；2）面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。提问题：a.你所在部门的业务流程是怎样的？b.你所在部门与其它部门的关系是怎样的？c.本部门产生哪些表格及其输入/输出形式？d.在业务中使用什么计算方法？关于如何解决问题的提问：a.当某问题发生时，应该如何解决？b.你现在工作中存在什么问题？如何解决？c.除了正常情况，还会发生什么异常情况？该如何应对？,实地收集需求信息的方式,交谈形式举例,正向模拟：选择典型业务情景（初始情况），请用户说明工作过程；陈述过程中不断提炼并提问新情况案例分析：请用户选择有代表性的业务情景（初始

12、情况），并说明工作过程；陈述过程中不断提炼并提问新情况局外评论：存在现有系统，请用户对正在进行的过程进行评论知识反教：在获取一些信息后，按照自己的理解表述给用户，请用户判断正确与否,问卷法调查法 是对面谈法的补充。是从多个用户中收集需求信息的有效方式，一般问卷设 计形式：1）多项选择问题；2）评分问题；3）排序问题。,实地收集需求信息的方式,需求专题讨论会 最有力的需求获取技术。有利于培养高效团队。由开发方和用户方共同召开,操作步骤：开发方根据双方制定的需求调研计划召开相关需求主题沟通会；会后开发方整理出需求调研记录提交给用户方确认；如果此主题还有未明确的问题则再次沟通,否则开始下一主题；所有

13、需求都沟通清楚后，开发方根据历次需求调研记录整理出用户需求说明书，提交给用户方确认签字。会前发议题，控制参会人员规模、时间、讨论范围，会中有记录，会后整理。掌握方向不跑题。,实地收集需求信息的方式,需求信息的分类,如图列出9种需求类别：,业务规则（领域需求）,当客户说只有特定的人在特定的条件下才能执行某一动作时，他也许是在描述一条业务规则。业务规则举例：产品必须符合某项国际（或国家）标准。必须根据（某个公式）计算。如果（满足某一条件），则（进行某事）。功能性需求 功能性需求描述了系统在特定条件下表现的可观察的行为，以及系统允许用户执行的操作。如：所有的用户界面操作都属于功能性需求。功能性需求占

14、据了软件需求规格说明的大部分篇幅。,质量属性,产品的易用性、可靠性、运行速度、出错频率、异常处理能力等等特性合称为质量属性，它是系统非功能性需求的一部分。非功能需求是衡量软件能否良好运行的定性指标。举例：可靠性：规定条件下系统完成所要求功能的概率。定量指标如平均无故障时间和平均修复时间。可扩充性：系统能方便和容易地增加新功能，可用增加新功能所需工作量大小来衡量。安全性：如防止非法访问,防止数据丢失，防止病毒入侵等。例如：身份验证、用户权限、访问控制等。,互操作性：指系统与其他系统交换数据和服务的难易程度。健壮性：指系统或组成部分遇到非法输入数据以及在异常情况和非法操作下能继续运行的程度。易用性

15、：指用户学习和使用软件系统功能的简易程度,也包括对系统输出结果的易于理解的程度。可维护性：指系统中发现并纠正一个故障或进行一次更改的简易程度。可移植性：指把一个软件系统从一种运行环境移植到另一个运行环境所花费的工作量的度量。可重用性：指组成软件系统中的某个部件还可以在其他应用系统中使用的程度。,质量属性,外部接口需求描述了系统与外部世界的联系。软件需求规格说明中专门有一章描述系统与用户、硬件、其它软件系统之间接口的说明。,约束,对设计和实现的约束合理地限制了开发人员可用的选择。如：通过电子邮件传送的文件大小不能超过10MB。进行安全交易时，必须使用128位的加密算法。产品数据库必须支持Orac

16、le 11g,期末大作业之一：假设让你开发一个在线交易平台网站，分别从功能需求，质量特性，约束3种需求类别进行描述。,3.2 需求分析,需求分析和需求获取是密切相关的两个过程。需求分析的任务就是分析和综合通过需求获取阶段收集到的需求信息，提炼出真正的需求，确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立系统完整的逻辑模型。需求分析是一种提炼与整合活动：需将用户的原始需求合并到业务活动中去。需求分析是一种规格化活动：要找到冲突、矛盾，并通过访谈手段解决问题。,划分需求优先级的用处：可帮助判断系统的核心需求，可用于风险分析。优先级之间的关联可以帮助决定软件体系结构、解决设计冲突。帮助权衡项

17、目范围、进度安排、预算、人力资源及质量目标要求。使用方法：接受一个高优先级的需求时，删除低优先级的需求，或将其推迟到下一版去实现。,3.2 需求分析,3.3 需求建模,目的：需求建模的工作就是导出目标系统的逻辑模型，以明确目标系统“做什么”的问题。定义：所谓模型就是为了理解事务而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。组成：通常模型可由图形符号或数字符号以及组织这些符号的规则组成。注意：建立需求模型的目的是为了增强对用自然语言描述的需求规格说明的理解，而不是替换它。,软件工程中常用模型分类开发过程模型：瀑布、增量、螺旋模型等(规约性)信息流模型：DFD、SADT等(描述性)设计模

18、型：类图、功能层次图等交互作用模型：实例图、交互作用图、时序图等状态迁移模型：状态图、Statecharts、Petri网等用于构造细节的原理模型：设计模式、实体关联图等,3.3 需求建模,3.4 需求文档,规格说明(SRS)通常用自然语言+模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。软件需求规格说明书，是需求分析阶段得出的最主要的文档。需求规格说明书的作用在于：提供一个用户和开发者对开发软件的共同的理解；相当于用户和开发单位之间的一份技术合同；是今后各阶段设计的基本依据，起到控制系统演进的作

19、用；是今后验收测试阶段对软件进行确认和验收的基准。,3.4需求文档,需求规格说明书主要内容：概述。从系统的角度描述软件的目标和任务。数据描述 数据流图 数据字典 系统接口说明 内部接口说明 功能描述 功能 处理 设计的限制,3.4 需求文档,性能描述 性能指标 测试种类 预期的软件响应性能 其它 参考文献目录 附录,1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料,2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束,软件需求说明书的编写提示（GB856T88）,软件需求说明书的编写提示（GB856T88）,3 需求规定 3.1 对功能的规定 3.2 对性

20、能的规定 3.2.1 精度 3.2.2 时间特性要求 3.2.3 灵活性 3.3 输人输出要求 3.4 数据管理能力要求 3.5 故障处理要求 3.6 其他专门要求,4 运行环境规定 4.1 设备 4.2 支持软件 4.3 接口 4.4 控制,(一)需求验证的重要性需求审查和管理复审是需求开发的最后一个环节，通过了这一环节，就等于暂时为需求分析阶段画上了一个“句号”。尽管后期可能还会有些对需求分析的反复，但有了这个“句号”，就可以进入设计阶段了。经过审批之后的文档，在整个项目范围内，相当于用户与开发人员双方对需求达成共识后作出承诺形成了一份合约，后期的系统设计和系统测试，都将以这份“规约”为准

21、。任何对合约的修改，都将影响到整个项目的工期和开发成本，都需要经过严格的审批和签约。,3.5 需求的有效性验证,(二)需求验证的内容1.有效性检查指功能需求是否符合用户所提出的需求2.一致性检查需求文档中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。3.完备性检查是指需求规约中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其他一些不起眼的但却是必需的功能。不完备的文档将导致产生功能不完整的产品，用户在使用该软件时可能无法完成预期的任务。4.可检验性检查文档中的各项需求对用户方而言都应当是可验证的。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷

22、。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。,3.5 需求的有效性验证,(二)需求验证的内容5.必要性检查需求规格说明书中的各项需求对用户而言应当都是必要的。可以把必要比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期

23、望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在需求规约中将那些“锦上添花”的需求设置为较底的优先级。,3.5 需求的有效性验证,用户的需求分类,基本的需求：用户明确提出的系统应达到的目标，如果产品实现了这些需求，用户会感到满意。例如，用户所要求的图形界面的类型，特定的系统功能，以及指定的性能。期望的需求：这些需求隐含于产品或系统中，用户没有明确的陈述。但如果没有实现这些需求，用户会感到失望。例如产品的易于安装，超负载时的正确性和可靠性等。感兴趣的需求：这些需求在用户的期望之外，但如果被实现了，用户会感

24、到非常满意。例如字处理软件除了标准的特性之外，提供了许多页面的排列功能。,3.6需求管理,需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI 1995)。这种契约都包含在编写的需求规格说明与模型中，需求管理贯穿需求分析全过程 通常的需求管理活动包括：定义需求基线（迅速制定需求文档的主体）。所谓的基线是配置演化过程中的状态标识，是配置在某一时刻的快照，反映了它所描述的系统或者其组成部分在某一时刻的状态；可以将配置的基线理解为配置的版本，是配置演化的里程碑，即软件生命周期内的阶段里程碑。所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需

25、求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。,3.6需求管理,评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。1)随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。2)市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。,(3)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。需求跟踪的目的是建立与维护“需求设计编程测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方

26、式:正向跟踪：检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。,3.6 需求管理,3.6 需求管理,需求变更控制,案例王先生刚出任项目经理，并承接了一个中型软件项目。上任时公司高层再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。王先生动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向王先生申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很

27、多相关文档也忘记修改。很快王先生就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误,公司高层对项目的质量也疑虑重重。随后

28、发生的事情让王先生更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。王先生知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，王先生只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问王先生：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”王先生委屈极了，疑惑自己到底错在哪里了。,需求活动之间关系,需求获取和分析,需求描述,需求有效性验证,系统模型,用户需求和系统需求,需求规约,软件需求过程,需求管理,3.7 结构化分析方法,结构化分析（Structured

29、 Analysis，SA）由美国YOURDON公司提出。采用自顶向下、逐层进行功能分解的系统分析方法来定义系统的需求。适用于分析大型的数据处理系统。方法的特点：利用数据流图（Data Flow Diagram，DFD）来帮助理解问题，对问题进行分析。一般工具：DFD、数据字典、判定表、判定树等。功能分析工具：DFD、DD、判定表和判定树。数据分析工具：ER图或者EER（扩展ER）图。行为分析工具：状态迁移图、Petri网等。SA主要针对数据处理领域，因此，系统分析的侧重点在于功能分析和数据分析，而行为分析使用得较少。,结构化分析方法的一些弊病：基于功能分析和数据分析，将功能和数据分离，与人类现

30、实世界环境不一样，和人的自然思维也就不一致了。以功能为主，数据只是被动的信息载体。当系统行为发生变化时，系统维护非常困难。DFD中不涉及系统的控制信息，因此，SA不适合于分析以控制信息为主的系统需求。,3.7 结构化需求分析,分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决（如右图）。,一、SA法的基本思想“分解”和“抽象”,抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去,以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。,3.7 结构化需求分析,三、SA法的描述方法1、分层的数据

31、流图（DFD图）2、数据词典3、描述加工逻辑的结构化语言、判定表及判定树,二、SA法的步骤,深入调查研究,分析用户需求,用DFD图描述,分析系统需求,用DFD图描述,修改完善DFD图,增添功能,3.7 结构化需求分析,3.7 结构化需求分析,四、SA总结软件系统开发中的结构化分析方法就是面向数据流自顶向下逐步求精的需求分析方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。要达到此目的，一般从数据流图的输出端入手，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。,3.8分析建模,3.8.1 建立模型模型

32、-就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。-模型将作为软件设计的基础和编写软件规格说明的依据。一般的说明，在需求分析阶段要写出详细的规格说明是不可能的。因为，用户对什么是正确的需求没有把握，开发人员对怎样正确的完成所要取得功能和性能也没把握，所以需求分析选择模型开发方法。需求分析过程应该建立3种模型：数据模型：实体联系图，描绘数据及数据对象之间的关系。功能模型：数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程。行为模型：状态转换图，描绘系统各种行为模式和在不同状态间的转换。,概念模型和规范化,软件系统的整个开发

33、过程都必须考虑两方面的问题：“数据”及对数据的“处理”。为了把用户的数据要求清晰明确的表达出来，系统分析员要建立概念性的数据模型（也称信息模型），它也是一种面向问题的数据模型，是按用户的观点来对数据和信息建模。采用的方法是：实体联系方法（EntityRelationship Approach）即ER模型。,表示概念模型最常用的是实体联系方法（entity-relationship approach）。该方法用ER图(ER模型或实体联系模型)来描述。它是描述概念世界、建立概念模型的实用工具。E-R模型独立于具体的计算机系统。E-R模型的主要成分是实体、联系和属性。它用简单的图形反映了现实世界中存

34、在的事物或数据及它们之间的关系。E-R模型独立于具体的计算机系统。E-R模型的主要成分是实体、联系和属性。它用简单的图形反映了现实世界中存在的事物或数据及它们之间的关系。,实体联系模型,1.实体：客观存在并且相互区别的事物称为实体,2.实体属性：实体所具有的某一特性称为属性。一个实体可以由若干个属性来刻画。,3.实体集和实体型：属性值的集合表示一个实体，实体名和各个属性名的集合来抽象和描述同类实体称为实体型(Entity type)。同类型的实体的集合称为实体集(有时也把它直接称为实体)。,实体联系模型,实体集之间的对应关系称为联系，反映现实世界各种事物之间的相互关联，一般有以下三种联系。（1

35、）一对一联系（1:1）如果对于实体集A中的每一个实体，实体集B中至多有一个实体与之对应；反之亦然，则称A与B具有一对一联系。（2）一对多联系（1:n）如果对于实体集A中的每一个实体，实体集B中有n个实体（n0）与之对应；反之，对于实体集B中的每一个实体,实体集A中至多只有一个实体与之对应，则称A与B具有一对多联系。（3）多对多联系（m:n）如果对于实体集A中的每一个实体，实体集B中有n个实体（n0）与之对应；反之，对于实体集B中的每一个实体,实体集A中也有m个实体（m0）与之对应，则称A与B具有多对多联系。,实体联系模型,一对一联系是一对多联系的特例，一对多联系又是多对多联系的特例。概念模型和

36、各种数据模型(层次模型除外)均不支持多对多联系，只支持一对一联系或一对多联系。在复杂问题中，两个以上的实体集之间也往往存在一对一、一对多或多对多联系。多对多联系直接处理起来很困难，通常是将多对多联系转化为两个一对多联系来处理。联系本身也是一种实体型（如老师-学生的联系就是上课，而上课又具有上课时间，地点，课程名等属性），也可以有属性。,实体联系模型,在ER图中，实体、属性和联系的表示方法如下：(1)实体型：用矩形表示，矩形框内写实体名；(2)属性：用椭圆表示，并用无向线段与相应的实体连接；(3)联系：用菱形表示，菱形框内写明联系名，并用无向线段与有关的实体连接。同时在无向线段旁标上联系的类型（

37、1：1，1：n或m：n）。联系本身也是一种实体型，也可以有属性。如果一个联系有属性，也用无向线段将属性与该联系连接。,实体联系模型,软件教研室,信息学院,(a)1:1联系(b)1:n联系(c)m:n联系两个实体之间的三类联系,软件教研室,实体联系模型,学生实体、课程实体及其属性 将多对多联系转化为一对多联系的一般方法是：增加一个新的实体集，并且这个新的实体集和原来的两个实体集之间都是一对多联系。,实体联系模型,教学信息管理概念模型,成绩,考分,实体联系模型,考,选,数据流图DFD-Data Flow Diagram（功能模型）,一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的

38、变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程，是系统逻辑功能的图形表示。设计数据流图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能，所以它也是今后进行软件设计的很好的出发点。,数据流图四种基本符号,数据加工/处理/变换,数据源点或终点(外部实体),数据流(data flow),数据存储文件,或,或,或,源或宿,软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称为外部实体。表示软件系统输入数据的来源和输出数据的去向，一般只出现在数据流图的顶层图中。因此也称为源点和终点源或宿用相同的图形符号表示当数据流从该符号流出时

39、表示是源当数据流流向该符号时表示是宿当两者皆有时表示既是源又是宿,加工,加工：也称为数据处理，它对数据流进行某些操作或变换。描述了输入数据流到输出数据流的变换，即将输入数据流加工成输出数据流。每个加工也要有名字，通常是动词短语，简明地描述完成什么加工。在分层的数据流图中，加工还应有编号。每个加工用一个定义明确的名字标识至少有一个输入数据流和一个输出流可以有多个输入数据流和多个输出数据流,文件,文件：保存数据信息的外部单元。使用文件、数据库等保存某些数据结果供以后使用。流向数据存储的数据流可理解为写入文件，或查询文件，从数据存储流出的数据可理解为从文件读数据或得到查询结果。每个文件用一个定义明确

40、的名字标识由加工进行读写DFD中称为文件，但在具体实现时可以用文件系统实现也可以用数据库系统等实现,注意:数据存储和数据流都是数据,仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运行中的数据。,数据流,每个数据流用由一组固定成分的数据组成并拥有一个定义明确的名字标识如：运动会管理系统中，报名单(数据流)由队名、姓名、性别、参赛项目等数据组成数据流的流向从一个加工流向另一个加工从加工流向文件(写文件)从文件流向加工(读文件)从源流向加工从加工流向宿,注意：数据流和程序流程图中用箭头表示的控制流有本质不同，在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。,

41、数据流图的扩充符号,描述一个加工的多个数据流之间的关系,数据流图的层次结构,为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。描述了软件系统与外界(源或宿)之间的数据流。中间层流图则表示对其上层父图的细化。中间层图中至少有一个加工(也可以有多个)可能继续细化，在下层图中分解成一张子图。底层流图是指其所有加工不需再做分解的数据流图，它处在最底层。,分层的数据流图,-系统逻

42、辑模型,数据流程图应用实例,某汽车配件公司设有销售、采购、仓库、会计等业务部门。公司每天都要处理大量的销售订单业务。当配件缺货或库存量低于保险贮备量时，就要进货。如果暂不考虑配件公司内部的仓库和会计业务细节，那么，配件公司的TOP图，如下图所示。,发货清单,系统,2,数据流程图应用实例,第0层,第1层,缺货数据,到货通知,发货清单,发货清单,系统,销售配件,采购配件,数据流程图应用实例,缺货记录,客户档案,第2层,补发清单,审核,客户档案,客户信息,开发货单,更新库存,配件库存,补发清单,销售报表,数据流程图应用实例,第3层,.便于实现,.便于使用,-采用逐步细化的扩展方法，可避免一 次引入过

43、多的细节，有利于控制问题 的复杂度；,-用一组图代替一张总图，方便用户及 软件开发人员阅读。,分层 DFD 图的优点,1）为数据流(或数据存储)命名(1)名字应代表整个数据流(或数据存储)的内容，而不是仅 仅反映它的某些成分。(2)不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。(3)如果在为某个数据流(或数据存储)起名字时遇到了困难 则很可能是因为对数据流图分解不恰当造成的，应该试 试重新分解，看是否能克服这个困难。,1.注意数据流图中成分的命名,画分层 DFD 的指导原则,2）为加工命名(1)通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且

44、体现了人类习惯的“由表及里”的思考过程。(2)名字应该反映整个加工的功能，而不是它的一部分功能。(3)名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。(4)通常名字中仅包括一个动词，如果必须用两个动词才能描述整个加工的功能，则把这个处理再分解成两个处理可能更恰当些。(5)如果在为某个加工命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。,1.注意数据流图中成分的命名,画分层 DFD 的指导原则,画分层 DFD 的指导原则,3.掌握分解的速度,一般来说，每一个加工每次可分为 2-4个子加工，最多 不得超过 7 个。,4.

45、遵守加工编号规则,顶层加工不编号。第二层的加工编号为1,2,3,n号。第三层编号为1.1,1.2,1.3 n.1,n.2等号，依此类推。,父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同(相对应），分层数据流图的这种特点称为子图与父图“平衡”。,2.注意父图和子图的平衡,5.数据流”一定是和“加工”有关联的。一个数据流不是流入“加工”的就必然是从“加工”流出的。,数据流与加工的关系,6.一个加工的输出数据流不能与该加工的输入数据流同名,7.合理使用文件。顶层图通常没有文件,在其他层中当文件作为某些加工之间的交界面时，文件必须画出来，一旦文件作为数据流图中的一个独立成份画出来了，那么

46、他同其他成份之间的联系也应同时表达出来。,画分层 DFD 的指导原则,案例,某医院欲开发病人监控系统，该系统通过各种设备监控病人的生命体征，并在生命体征异常时向医生和护理人员报警。该系统的主要功能如下：1）本地监控：定期获取病人的生命体征，如体温、血压、心率等数据；2）格式化生命体征：对病人的各项重要生命体征数据进行格式化，然后存入日志文件并检查生命体征；3）检查生命体征：将格式化后的生命体征与生命体征范围文件中预设的正常范围进行比较，如果超出了预设范围，系统就发送一条警告信息给医生和护理人员；4）维护生命体征范围：医生在必要时（如新的研究成果出现时）添加或更新生命体征值的正常范围；5）提取报

47、告：在医生或护理人员请求病人生命体征报告时，从日志文件中获取病人生命体征生成体征报告，并返回给请求者；,6）生成病历：根据日志文件中的生命体征，医生对病人的病情进行描述，形成病历存入病历文件；7）查询病历：根据医生的病历查询请求，查询病历文件，给医生返回病历报告；8）生成治疗意见：根据日志文件中的生命体征和病历，医生给出治疗意见，如处方等，并存入治疗意见文件；9）查询治疗意见：医生和护理人员查询治疗意见，据此对病人进行治疗。现采用结构化方法对病人监控系统进行分析和设计，获得如图1-1所示的顶层数据流图和图1-2所示的0层数据流图。,案例,案例,在数据流图中对一个数据流、数据存贮或加工只能标明一

48、个名字，没有对这些元素的构成细节、内容、特性及加工过程详细说明。分析人员仅靠“图”来完整地理解一个系统的逻辑功能是不可能的。为了完整地描述这个系统，还需借助“数据词典”和“小说明”对图中的每个数据和加工给出解释。数据定典就是用来定义数据流图中的各个成分的具体含义的工具，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。它和数据流图共同构成了系统的逻辑模型，是“需求规格说明书”的主要组成部分。,数据词典(DD),A、数据流条目给出某个数据流的定义，通常是列出该 数据流的各组成数据项。例如：报名单姓名单位名年龄性别课程名 常用符号：、（）、,C、数据

49、项条目（数据流分量）数据项条目给出某个数据单项的定义，通常是数据项的值类型，允许的取值范围。,B、文件条目给出某个文件的定义，文件的定义通常是列出文件记录的组成数据流。例如：订单文件订单编号顾客名称产品名称订货数量交货日期,D、加工条目 加工类条目就是“加工小说明”。一般应该单独列出。,数据词典(DD),常用的描述数据结构的关系算符,1.数据流条目,数据流条目通常列出组成该数据流的数据项数。,名称：订单别名：无简述：顾客订货时填写的项目来源：顾客去向：加工1.1.1“编辑检查订单”数据流量：1000份/每周组成：编号+订货日期+顾客编号+地址+电话+银行 帐号+配件名称+数量其中：数据流量指单

50、位时间内（每小时或每天）传输 的次数,数据流条目,由数据元素组成数据的方式只有如下三种基本类型：顺序 以一定的顺序连接两个或多的元素；选择 从两个或多个可能的元素中选取一个；重复 把指定的元素重复零次或多次。可选 理论上，可以使用上述三种关系定义数据字典中的任何条目。因为，当重复次数为0次或一次时，就构成了一种可有可无的可选关系。但由于“可选”是由数据元素组成数据的一种常见方式，把它单独列为一种关系会使数据字典的描述更清晰。,2.数据项条目,名称：配件编号别名：配件号简述：本公司的所有配件编号类型：字符型长度：10位取值范围及含义：第1位：进口/国产 第2-4位：类别 第5-7位：规格 第8-