需求工程-软件建模与分析

1、1 问题分析的主要步骤（五步）？ (1) 在问题定义上达成共识； (2) 理解根本原因，分析问题背后的问题； (3) 确定相关人员和用户； (4) 定义解决方案的界限； (5) 确定加在解决方案上的约束。2 鱼骨图主要用于定性分析，帕累托图主要用于定量分析。3 鱼骨图、帕累托图构建的主要步骤？ 鱼骨图 A 选择问题 首先选择一个具体的问题或者结果。在选择问题时，要保证问题是专门的、定义严谨的、范围相对较小的（对于大范围的问题往往需要考虑将其分解成相对较小的问题），并且保证参与人员切实理解要分析的内容。对问题定义产生出来的问题一般都应该进行一次独立的鱼骨图分析。 B 头脑风暴 就导致问题的可能原

2、因进行头脑风暴。将大家提出的意见记录下来，确认后贴到鱼骨图上。 需要注意的是不要将原因和解决方案混为一谈。在确定原因的分类前先进行头脑风暴（一个人提，大家批），不然思考问题的范围就会受到限制。支持者需要引导和鼓励参与者参与其中。 C 确定问题类型 对头脑风暴的结果进行整理，确定出主要的原因类型。一般来说，划分出来的问题不要少于2类，不要超过6类（经验数值，仅供参考）。经常使用的类型有：人、设备、材料、环境、方法、过程等。将这些类型补充到鱼骨图上。 D 分配原因 将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每一项原因都归于适当的类别中。如果原因看起来可以放在多个类别中，就表示是多重原因造成的

3、问题。但如果多次出现多重原因，可能就以为着分类存在问题。该阶段将形成最终的鱼骨图E 分析根本原因 对鱼骨图中罗列出来的所有潜在原因进行分析。分析出造成某一结果的最根本原因是什么？找出核心所在。 方法如下： 通过参与者之间的公开讨论来分享看法和经验； 寻找重复的原因，或者与特定类有关的原因的数量； 使用检查表收集资料、制造流程图或者进行用户调查， 通过帕累托分析法测试各种原因的相对强度； 投票（真理多数情况下掌握在多数人手里） 帕累托图 在通过使用鱼骨图完成问题原因的定性描述后。仍然存在一个问题，就是根本原因的辨识需要有经验的决策者确定，或者根据人类固有经验（少数服从多数）确定。更好地方法是能够

4、开展定量分析。帕累托分析可以帮助我们做出这样的定量分析。帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计资料，通过直方图的方式显示问题的相对频度或者大小高低等定量结果。A 确定问题和相关原因 利用鱼骨图的结果。B 收集数据 有针对性第收集数据。例如上例中，我们可以抽取一些废品，分析这些废品产生的原因C 绘制直方图4 上下文图画法步骤？ 在绘制上下文关系图时应该采用以下步骤：1、首先用一个矩形表示系统，写上系统的名称，将整个系统看做一个黑盒子；2、然后找到该系统的所有Customer(客户)，考虑这些Customer会发起什么事件，这些事件会引发Worker(内部工作人员)的什么工作，将

5、这些序列逐一表示出来；3、最后在看看系统的每个Worker还有没有一些主动发起的事件。（Customer：也就是该主题域的客户，它处于该主题域的外部。如，对于体检业务子系统而言，体检者显然就是一类客户，除此之外，客服中心、物资部门、财务部门的工作人员也是这个主题域的Customer。Worker：也就是该主题域的工作人员，它处于该主题域的内部。如，服务中心，体检科室，综合科的工作人员都是其Worker。关键要点在于“针对本主题域”而言。）5需求获取的主要活动研究应用背景，建立初始的知识框架；根据获取的需要，采用必要的获取方法和技巧；先行确定获取的内容和主题，设定场景；分析用户的高（深）层目标，

6、理解用户的意图；进行涉众分析，针对涉众的特点开展工作。6需求协商的几条法则的应用？差异问题协调法则：不同的业务层面（有时即使是相同业务层面）的用户对同样的概念或者流程有不同的认识和理解，会出现一些差异，在需求整理时应该将这些差异明确标识出来，并展示给用户高层管理人员，由他们来确定如何消除这些差异，并将这些情况记录。消除变更问题协调法则：上面法则提到的问题，从消除变更的角度考虑仍然存在问题。仅仅将差异标识并展示给高层并不能消除变更的可能，应该考虑这些差异形成背后的问题，应该从开发角度考虑如何消除这些差异，并提供给高层管理人员。要有主动性需求协商时机法则：不要在需求冻结前开展需求协商工作。需求协商

7、应该在需求获取过程中不断开展，出现就考虑消除。如果都等到冻结前，将所有矛盾集中体现对工作是非常不利的。实例：W公司开发的信息系统到了需求冻结前夕，A建立拿出厚厚一本需求协商底稿，分为重点差异协调部分，一般差异协调部分，已协调差异列表。结果用户高层非常不满，认为这些工作需要大量时间难以短期完成。7需求获取的主要方法用户访谈用户调查文档分析原型法（情节串联板）模型驱动的方法8开放式话题与封闭式话题运用开放式话题优点：让被会见者感到自在；会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；提供丰富的细节；对没采用的进一步的提问有启迪作用；让被会见者更感兴趣；容许更多的自发性；会

8、见者可以在没有太多准备的情况下进行面谈。缺点：提此类问题可能会产生太多不相干的细节；面谈可能失控；开放式的回答会花费大量的时间才能获得有用的信息量；可能会使会见者看上去没有准备封闭式话题优点：节省时间；切中要点；保持对面谈的控制；快速探讨大范围问题；得到贴切的数据缺点：使得被会见者厌烦；得不到丰富的细节；出于上述原因，失去主要思想；不能建立和面谈者的友好关系。 9用户访谈时问题组织的三种方式及特点？金字塔结构如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构，通过逐步的引导来使得被会见者打开话匣子。如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这个话题，也

9、可以采用金字塔结构。当想结束讨论这个话题的时候，使用金字塔结构的提问顺序也是有用的。 漏斗结构漏斗结构为开始一场面谈提供了一种容易而轻松的途径。当被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提问顺序。或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。用这种方式组织面谈能得出很多的详细信息，以至于没有必要使用长序列的受限制问题和调查问题。 菱形结构使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。 10市场调查和需求获取在访谈与调查顺序上有何不同?原因何在？一般来

10、说，在开展市场调查时，由于很难深入接触到潜在的用户。所以总是先调查，后访谈。而在需求获取时，通常采用的策略是先访谈，后调查。 其实原因在于市场调查与需求获取有不同的应用背景。一般市场调查通常用于验证潜在客户对产品的接受程度。而需求获取的目标是要理解客户需要解决的问题。 也就是说需求获取时你往往还没有产品，信息不够充分，所以很难设计出有效的调查问卷。11采用原型方法的三个目的？明确并完善需求 原型作为一种需求工具，它是对部分系统的初步实现，因为我们尚没有很好地了解该系统。研究设计选择方案 原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统易用性，并评估可能的技术方案。发展为最终产

11、品 原型作为一种构造工具，是产品一个最初子集的完整功能实现。12用例描述方法13需求关系的根本任务是什么？ 需求分析是软件需求中最核心的工作，需求建模是需求分析的主要手段。需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。需求分析根本任务：建立分析模型，创建解决方案。14需求分析任务中分解策略主要包含那几种？每种策略分别适合应用于那些系统的开发 1）业务流程为主线的分解策略；业务流程为主线的分解策略是目前比较流行的方法，主要

12、按照“业务”的角度考虑分解方法。此方法特别适合联机事务处理系统、管理信息系统（MIS）。目标系统-主题域的分解依据是“目标决定范围”；主题域-业务事件所做的是理清业务脉络；业务事件-业务活动所做的是填充细节；业务活动-业务步骤所做的是细化和确认工作。2）程序结构为主线的分解策略； 方法是需求分析最常用的分解方法。当由于其过早进入程序结构，割裂了与问题域之间的联系，从而容易导致对问题域研究的不足，降低了需求的质量。目前认为此种方法仅适合于问题域比较清晰，问题不算复杂的情况，例如工具软件、嵌入式系统等。3）基于场景的分解策略； 对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、使用场景是主要

13、的线索。向上可以总结成一类相似的集合，再总结成一系列的关注点或者功能域，向下可以分解成具体的步骤或者操作任务。4）基于数据的分解策略等。 上述分解策略都是从“业务”角度来组织。但对于类似数据仓库之类的数据类项目，业务线索并不是十分明显，或者并不重要这是就需要以数据为主的分解策略。其中主题域仍然与“业务流程为主的分解策略”类似。而主题类是企业中的高层实体，主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在实现时又会对应于多个物理数据类。15 需求分析中分解与提炼的比较？ 分解是一种自顶向下的方法，当按照任何一种线索进行分解时。就会破坏其它线索的完整性。例如，如果以“业务”为线索，就会发现数据

14、需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。 此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行提炼。例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。16构建分析模型的目的？ 1将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征2和用户达成对信息内容的共同理解3分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息17分析模型的建模方法？模型 “模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解” 集中关注问题的计算特性（数据、功能、规则等等） “

15、它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易” 建模方法抽象分解投影抽象（Abstraction）一方面要求人们只关注重要的信息，忽略次要的内容通过强调本质的特征，就减少了问题的复杂性（例如学生模型）另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节在问题的各元素之间推断出更广泛和更普遍的关系，帮助人们寻找解决方案分解（Decomposition / Partitioning）“分而治之” 将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系分解的方案往往还能提供问题的解决思路

16、投影（Projection）多视点方法 18实际的建模过程中要遵循的建模原则？ 在建模时，要注意考虑到计划之外的变化：设计要文档化，只有这样，才能使不熟悉的新手也可以有效地利用设计的方案。用可视化的模型表达现实世界，有助于理解变化所代表的含义。 在实际的建模过程中要遵循以下建模原则：模型是用来沟通的；选择创建什么模型对如何解决问题和如何形成解决方案具有深远的影响。每种模型可以在不同的精度级别上表示；最好的模型是与现实相联系的模型；单个模型往往不够充分，对每个重要的系统最好用一组几乎独立的模型去处理。19需求建模的流程？ 先依据获取的问题域信息建立初步的模型。然后分析用户需求，对模型进行调整，得

17、到一个中间形式的模型形式。最后，对调整后的模型进行逻辑推理和验证，如果符合预期的期望，那么它就是最终的解决方案模型。 20 常见的需求分析技术？ 结构化技术数据建模实体关系图Entity Relationship Diagram过程建模数据流图Data Flow Diagram上下文图Context Diagram微规格说明Mini-Specification数据字典Data Dictionary行为建模状态(转换)图/矩阵State (Transition) Diagram/Matrix过程/数据关系建模功能实体矩阵Function/Entity Matrix信息工程方法功能分解图Funct

18、ion Decomposition Diagram过程依赖图Process Dependency Diagram面向对象技术UML用例图Use-Case Diagram类图Class Diagram交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram活动图Activity Diagram对象约束语言Object Constraint Language状态图State Chart Diagram正确认识UML（2）（3）（4）() UML的准确理解UML是一种语言（Language）实际上UML就是一种表示方法，它不是方法论。UML是一

19、种建模语言（Modeling Language）它不是编程语言，而是建模语言。它不仅包含软件建模，而且可用于业务建模、流程建模等多种领域。UML是统一建模语言（Unified Modeling Language ）它是一种标准化的、统一的建模语言，OMG认可的工业标准，也是如IBM、SUN等大型公司认可的事实标准。(3) 为什么要使用UMLUML是一种统一的、标准化的建模语言，它为参与软件设计和开发的各类人员提供统一的语言，使开发人员能够基于共的模型来理解业务、需求，理解软件及其架构如何构造的。(4) 如何使用UMLUML2.0标准中，共定义了13种不同的图，这些图的功能以及与UML1.0之间

20、的关系如下表图名功能备注类图描述类、类特性及类间关系UML1.0原有对象图描述一个时间点上系统各个对象的一个快照UML1.0非正式图复合结构图描述类的运行时刻的分解UML2.0新增构件图描述构件的结构和连接UML1.0原有部署图描述在各个节点上的部署UML1.0原有包图描述编译时的层次结构UML1.0非正式图用例图描述用户与系统如何交互UML1.0原有活动图描述过程行为与并行行为UML1.0原有状态图描述事件如何改变对象生命周期UML1.0原有顺序图描述对象之间的交互、重点在于强调顺序UML1.0原有通信图描述对象之间的交互、重点在于连接UML1.0中的协作图定时图描述对象之间的交互、重点在于

21、定时UML2.0新增交互概观图是一种顺序图与活动图的混合UML2.0新增如何使用UML-需求阶段一般常采用的图使用频率图名功能关注要点主体用例图说明角色和使用场景之间的关系人活动图说明业务流程，以及业务活动的步骤事顺序图描述对象之间的交互物类图说明业务实体之间的关系，体现结构规则物辅助构件图说明主题域划分以及他们之间的服务接口接口部署图描述系统的部署环境，体现设计约束设计约束22 结构化分析遵循的三条原则？结构化分析遵循的三条基本原则： 分解 抽象 映射23结构化分析模型的构成元素？ 数据字典(DD) 模型核心，包含了所有数据对象的描述的中心库。E-R图(ERD)表示数据对象以及相互的关系，用

22、于数据建模。数据流图(DFD) 指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能; DFD中每个功能的描述包含在加工规约(小说明)。用于功能建模。状态变迁图(STD) 指明作为外部事件的结果,系统将如何动作。用于行为建模。24结构化建模示例-建立计算机售书系统的逻辑模型 通过对现实环境的调查，获得当前系统的物理模型。 （2 ） 去掉具体模型中的非本质因素：抽取现实系统的实质，抽象出当前系统的逻辑模型。 （3）分析当前系统与目标系统的差别，建立目标系 统的逻辑模型 。（4）对目标系统的逻辑模型进行细化、改进与优化（5）需求分析的验证25 数据流图（DFD）第9章PPT 第20-69页

23、数据流图（DFD：Data Flow Diagram）就是组织中信息运动的抽象，是信息逻辑系统模型的主要形式。这个模型不涉及硬件、软件、数据结构与文件组织，它与对系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统在信息处理方面要做什么。由于图形描述简明、清晰，不涉及到技术细节，所描述的内容是面向用户的，所以即使完全不懂信息技术的用户单位的人员也容易理解。因此数据流图是系统分析人员与用户之间进行交流的有效手段，也是系统设计（即建立所开发的系统的物理模型）的主要依据之一。数据流图脱离系统中的物理因素(如计算机等)，表达出系统对信息的加工情况。DFD可以描述原系统

24、/新系统/子系统。DFD是SA的主要工具，它简单、直观，用图形、文字描述系统。它便于使用、便于交流、便于讨论、便于形成共识，是计算机专业人员和用户单位业务人员的共同语言。DFD由四种基本符号组成。如下图所示。数据流图的构成及基本元素外部项（外部实体）源点和终点(又称端点)是系统外的实体，称作外部项。它们存在于环境之中，与系统有信息交流，从源点到系统的信息叫系统的输入；从系统到终点的信息称系统的输出。同一个端点可以是人或其它系统。在DFD中引入源点和终点是为了便于理解系统，所以不需要详细描述它们。它们可有编号，以“S”开头。外部实体外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，

25、它们不受系统的控制，开发者不能以任何方式操纵它们。需要进行建模的外部实体是那些和待构建的软件系统之间存在着数据交互的外部实体，它们是待构建系统的数据源或者数据目的地所有的外部实体联合起来构成了软件系统的外部上下文环境 引入外部项是为了划定系统的边界，不需严格定义。但也要统一编号，而且要与数据字典中的编号相一致。源点和终点可以在多处出现，用特定符号表示重复的外部项。为了使DFD清楚易懂，我们对加工、数据流、文件的命名都力求简单。至于加工的加工逻辑、数据流的数据结构等，将在数据字典中定义。数据字典和DFD一起来描述系统。 常见的外部项（外部实体）有：a)从待构建系统中获取数据或者为其提供数据的组织

26、，如：供货方，销售方等。b)需要和待构建系统交互的个人，如：顾客，办事员。c)需要和待构建系统交换数据的其他软件系统。加工加工又称处理亦称变换，它表示对数据流的操作。加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分。标识部分用于标注加工编号，加工编号应具有唯一性，以标识加工，以“P”开头。功能描述部分用来写加工名。为使DFD清晰易读，加工名应简单，能概括地说明对数据的加工行为，其详细描述在数据词典中定义。加工要逐层分解，以求得分解后的加工功能简单、易于理解。数据流数据流由一个或一组确定的数据项组成。 数据流名应能直观地反映数据流的含义。如产量日报表、汇款单、录取通知书、课程表等

27、。也可以用一组数据中的主要数据为数据流命名。例如“考生成绩单由考生姓名、成绩、通讯地址等数据组成，但成绩是主要的，所以可用“考生成绩”作为数据流的名字。 数据流应统一编号，编号要与数据字典一致。 数据流经过一个加工后其数据结构/数据含义/数据的顺序一定要有所变化，否则这个加工就没有意义了。数据存储（文件） 数据存储是用来存贮数据的。在分层DFD中，数据存储一般仅属于某一层或某几层，因此又称数据存储为局部文件。现对数据存储符号说明如下：数据存储名写在开口的长方框内，应概要地说明文件中的主要数据。数据存储上一定要有数据流。为便于说明和管理，数据存储亦应编号，编号写在文件符号左端小方格中，以“D”开

28、头。为避免DFD中出现交叉线，同一数据存储可在多处画出。数据流图的绘制步骤（1）确定所开发的系统的外部项（外部实体），即系统的数据来源和去处。（2）确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图。（3）确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）确定每个加工的输出与输入数据流以及与这些加工有关的数据存储。 （4）根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解。（5）重复步骤（4），直到逐层分解结束。（6）对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有遗漏、重复、冲突之处，各层DFD及同层DFD之间关

29、系是否合理，及命名、编号是否确切、合理等，对错误与不当之处进行修改。（7）和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。 数据流图绘制规则(1)过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应该存在差异。 (2)数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数据输出。(3) DFD当中所有的对象都应该有一个可以唯一标识自己的名称。过程使用动词外部实体、数据流和数据存储使用名词数据流图绘制过程绘制数据流图的主要原则 （1）明确系统边界。 （2）自顶向下逐层扩展。（3）合理布局。（4）数据流图绘制过程，就是系统的逻辑模型的形成过程，

30、必须始终与用户密切接触，详细讨论，不断修改，也要和其他系统建设者共同商讨一求一致意见。数据流图应用示例-银行取款系统 简单银行取款应用描述(1）储户将填好的取款单、存折交银行，银行做如下处理： 审核并查对帐目，将不合格的存折、取款单退回储户，合格的存折、取款单送取款处理。 处理取款修改帐目，将存折、利息单、结算清单及现金交储户，同时将取款单存档。画出银行取款处理数据流图。第一步，画出关联数据流图。注意，现金是实物，不能作为数据流。第二步，逐层分解加工，画出下层DFD。数据流图应用示例-图书预定系统图书预订系统：书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对订单进行检查并

31、对合格订单进行处理，处理过程中根据顾客情况和订单数目将订单分为优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最后系统根据所处理的订单汇总，并按出版社要求发给出版社。 画出图书预定系统的各层数据流图。第一步，画出关联数据流图。 第二步，逐层分解加工，画出下层DFD。注意到根据题意，当绘出系统顶层图后并不能将所有加工分解成基本加工，还要进行二层图分解。并在分解加工过程中逐步充实进数据存储。见图。 数据流图的作用前面说过，系统分析的主要任务是建立新系统的逻辑模型。具体地讲主要是画出新系统的DFD，编写定义DFD的数据词典。 建立新系统的DFD是一项十分重要的工作。因为建立的DFD是系统

32、开发乃至系统维护的依据，是系统的重要文档之一。系统分析员要在详细调查中，在与用户的反复交流中修改DFD，力求新建DFD是正确的、准确的。DFD的层级结构 依据所含过程的不同抽象程度，DFD可以在不同的抽象层次上进行系统的描述 一个比较抽象的过程可以被展开为一个子过程更加具体的DFD图DFD的层次结构上下文图0层图N层图（N0）关于上下文图将整个系统看做是一个过程，这个过程实现系统的所有功能 ，是系统功能的最高抽象 上下文图中存在且仅存在一个过程，表示整个系统。这个单一的过程通常编号为0 上下文图中需要表示出所有和系统交互的外部实体，并描述交互的数据流，包括系统输入和系统输出 上下文图中不会出现

33、数据存储实例 它非常适合于描述系统的应用环境、定义系统的边界 关于0层图位于上下文图下面一层，是上下文图中单一过程的细节描述，是对该单一过程的第一次功能分解 是整个系统的功能概图 0层图应该被描述的简洁、清晰，需求工程师要根据系统的复杂度掌握0层图中过程的抽象程度关于N层图对0层图的过程分解产生的子图称为1层图，对N层图的过程分解后产生的子图称为N+1层图（N0） ，过程分解是可以持续进行的，直至最终产生的子图都是原始DFD图原始DFD图可以进一步展开为微规格说明数据字典在低于0层图的子图上通常不显示外部实体 层次结构的构建建立步骤创建上下文图 发现并建立DFD片断 根据DFD片断组合产生0层

34、图；对0层图的过程进行功能分解，产生N层图 创建上下文图 在需求获取阶段获得的业务需求以及业务需求所决定的项目前景与范围可以用来帮助建立系统的上下文图。发现并建立DFD片段DFD片断是系统对某个事件的响应过程的DFD描述，它是为系统中发生的重要事件创建的。它将系统对事件的处理看做是一个单一的过程，重点描述这个单一过程与事件外界（包括系统内其他部分和系统外的外部实体）的数据流交互。产生0层图往往需要多次调整DFD片段的整合结果才能得出对DFD图（尤其是0层图）质量的判定有下面几个准则：1、没有语法错误，遵守前述的各项规则。2、具有良好的语义，过程的功能设置要高内聚、低耦合。3、保持数据一致性，过

35、程的输入流要足以产生数据输出。同时过程的输出流是在充分利用输入数据的基础上产生的，不存在输入数据的浪费。4、控制复杂度，不要一次在图中显示太多的信息。一般情况下，一个图中的过程数量最好控制在59（人脑的最佳信息处理量）个。而且图中的数据流数量越少越好，越简洁越好（接口最小化）。功能分解产生N层图功能分解是一个拆分功能的描述，将单个复杂的过程变为多个更加具体、更加精确和更加细节的过程。 在功能分解过程当中，最重要的是要保证分解过程的平衡性（Balance） ，它要求DFD子图的输入流、输出流必须和父过程的输入流、输出流保持一致 。在分解产生的子图为下述情景之一时，可以判定其为原始DFD图，此时应

36、该停止持续的功能分解活动：所有过程都已经被简化为一个选择、计算或者数据库操作；所有数据存储都仅仅表示了一个单独的数据实体；用户已经不关心比子图更为细节的内容，或者子图的描述已经详细的足以支持后续的开发活动；每一个数据流都已经不需要进行更详细的切分，以展示对不同数据的不同处理方式；每一个业务表单、事务、计算机的屏幕显示（computer on-line display）和业务报表都已经被表示为一个单独的数据流；系统的每一个最低层菜单选项都能在子图中找到独立的过程。 层次结构的建立-示例使用DFD描述常见的电梯控制系统。一个控制系统控制多个电梯。每个电梯被置于一个相应甬道之中，在卷扬电机的作用下在

37、甬道内做上下运动。甬道内安装有多个传感器，通常每个电梯停靠点一个，用来感应电梯的实时位置。电梯内部和建筑的每个电梯停靠层都设置有指示器，用来告知用户的电梯实时位置和运动状况。电梯内和建筑的每个电梯停靠层都设有按钮，用户可以通过这些按钮提出服务申请并进出电梯。控制系统调度用户的申请，让电梯以最有效的方式满足用户的服务要求。层次结构的建立-建立DFD片断 层次结构的建立- 建立0层图DFD验证验证DFD的语法 确保DFD中不会发生语法错误 验证DFD的结构 验证DFD层次结构之间的一致性 验证DFD层次结构说明的完备性 验证DFD的语义 确保DFD所说明内容的正确性和准确性 26 数据字典 数据字

38、典的提出背景：虽然数据流图能够形象、清晰地描述数据在系统中流动、加工、存储的情况，但数据流图中的许多构成元素，如数据流、数据存储、加工，仅依靠名称并不能反映其本质含义，因此必须对这些构成元素进行严格的定义。作为对数据流图的补充，数据字典(DD，Data Dictionary)能够准确地定义数据流图中各组成成分的具体含义，二者共同构成了系统的逻辑模型。数据字典是一个储存库，包含软件使用和产生的所有数据对象的描述，其中也包括DFD当中数据流和数据存储的定义。有组织地列出DFD中的涉及的所有数据元素（数据流、数据存储），并定义每个数据元素的名称别名使用地点使用方法使用范围描述 单位/格式名称数据元素

39、的原始名称别名数据元素的其他名称使用地点会使用该数据元素的过程使用方法该数据元素扮演的角色（输入流、输出流或者数据存储等）使用范围该数据元素存在的范围描述对数据元素内容的描述单位/格式数据元素的数据类型，可能事先设置的取值数据字典中的基本元素和含义符号含义示例=包含，由构成Name=first_name+last_name+指明序列结构()内容可选Phone_No.=(Area_No.)+Local_No.内容多选一Number=0|1|2|3|4|5|6|7|8|9|分割内部的多个选项nm循环,最少n次,最多m次Area_No=3Number4数据存储的标识符(关键字)Student=ID+

40、Name+.*注释Area_No=3Number4*区号为3到4位数字数据字典中的条目及说明格式数据字典是关于数据流图中各种成分详细定义的信息集合，可将其按照说明对象的类型划分为四类条目，分别为数据流条目、数据项条目、数据文件条目和数据加工条目。数据字典的任务是: 对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。(1)数据流条目数据流在数据流图中主要用于说明数据结构在系统中的作用和流动方向，因此数据流也被称作“流动的数据结构”。数据字典中数据流条目应包括以下几项主要内容：数据流名称、数据流别名、说明、数据流来源、数据流流向、数据

41、流组成和数据流量等。数据流词条的描述示例:数据流名：发票说明：用作学生已付书款的依据数据流来源：来自加工“审查并开发票” 数据流去向：流向加工“开领书单”。数据流组成：学号+姓名+书号+单价总价+书费合计 数据流词条的描述示例2： 工资系统中的出勤表数据流在数据字典中的条目描述为:数据流名称：出勤表数据流别名：无说明：由人事部门每月月底上报的职工考勤统计数字数据流来源：人事部门数据流流向：加工1.1.1(统计出勤、请假及旷工时数)数据流组成：出勤表 = 年份+月份+职工号+出勤时数+病假时数+事假时数+旷工时数数据流量：1份/月 (2)数据项条目 数据流图中每个数据结构都是由若干个数据项构成的

42、，数据项是加工中的最小单位，不可再分。数据字典的数据项条目中应包含的主要内容有：数据项名称、数据项别名、说明、类型、长度、取值范围及含义等。 例如：出勤表中的职工号数据项在数据字典中的条目描述为 数据项名称：职工号 数据项别名：employee_no 说明：本单位职工的惟一标识 类型：字符串 长度：6 取值范围及含义：12位(00.99)为部门编号：36位(XX0001.XX9999)为人员编号 (3)数据文件条目 数据文件是数据流图中数据结构的载体。数据字典的数据文件条目中应包含的主要内容有：数据文件名称、说明、数据文件组成、组织方式、存取方式、存取频率等。 例如：工资系统中的职工工资档案文

43、件在数据字典中的条目描述为 数据文件名称：工资档案 说明：单位职工的基本工资、各项津贴及补贴信息 数据文件组成：职工号+国家工资+国家津贴+职务津贴+职龄津贴+交通补贴+部门补贴+ 其他补贴 组织方式：按职工号从小到大排列 存取方式：顺序存取频率：1次/月(4)数据加工条目 在数据流图中只简单给出了每个加工的名称，在数据字典中通过数据加工条目主要是要说明每个加工是用来“做什么”的。数据字典的数据加工条目中应包含的主要内容有： 数据加工名称、加工编号、说明、输入数据流、输出数据流、加工逻辑等。 例如：工资系统中的计算应发工资这个加工在数据字典中的条目描述为 数据加工名称：计算应发工资 加工编号：

44、1.2 27 ERD建模示例 简单情况下ERD建模（1）从描述信息中辨识实体 可以重点关注描述信息中的名词，看系统是否需要收集其相关的特征（2）确定实体的标识符 （3）建立实体间关系判断各个关系的建立是否会产生新的关联实体或者影响已有的实体特性 （4）添加详细的描述信息 实体的详细属性和关系的基数 简单情况下ERD建模-示例研讨班在每个学年开始的时候开设，然后持续一个学年。每个研讨班针对一个或几个研究方向。每个研讨班由一位或几位教师主持。在研讨班开设之后，学生可以根据主持教师（的姓名）和研讨班的方向来选择和参加某个研讨班。所有的学生必须且只能参加一个研讨班的学习。研讨班时常会开展活动，由教师来

45、决定活动的时间、地点、主题和做报告的学生（的姓名）。每次活动时，由一位或多位同学围绕活动主题做学习报告，交流自己对新技术的学习心得。每个学生一次活动最多只能作一个报告，但每个学生至少会在一次活动中做一个报告。教师对每份活动中的学生报告进行一次点评和指导，提出建议和意见。 复杂情况下ERD建模发现系统的概念域 指那些在系统业务中非常重要的概念，如果没有这个概念，组织就可能不会存在或者业务发生重大变化 不能遗漏那些对业务有重大影响的概念，同时概念域的发现也不要太细节 每一个概念域都会以星型发散的方式扩展为多个逻辑实体 建立对概念域的描述 展开概念域 简单情况下的ERD建模或者进一步细分子域合并概念

46、域的局部数据模型消除冗余和冲突 28 结构化范型与面向对象范型的区别？ 结构化范型（Structured Paradigm）基于如下的思想进行开发活动：一个系统应该被划分为两个部分：数据（使用数据/持久化模型建模）和功能（使用过程模型建模）。简言之，结构化方法，数据将和设计模型中以及系统实现中（也就是程序中）的行为分离。 范型（Paradigm）：做事情的整体策略或观点，是一套特定的思想集合。面向对象范型（Object-oriented Paradigm）不是将系统定义为两个分离的部分（数据和功能），而是需要把系统定义为一组正在交互的对象。对象可以完成一些事情（对象具有功能），对象也知道一些事

47、情（对象有数据）。29 抽象类与具体类在表示上有何区别？ 引入抽象类是为了实现类的公共行为。 抽象类与具体类的区别在于：可以从具体类中实例化（创建）对象，但不能从抽象类中实例化对象。意味着软件需要实例化教授或者研究员对象，但不需要创建教师对象。当创建一个类实现多个类的共同特征时，就可以建立抽象类。 30UML 多重指示器的含义？ 指示器含义0.1零或1个1仅1个0.*零或多个1.*1或多个n仅n个（n1）0.n零到n个（n1）1.n1到n个（n1）31 高内聚、低耦合含义？ 耦合 耦合表示两个项目，如类与方法之间如何相互关联的一种方法。当一个类依赖另外一个类时，则称其为耦合的。当一个类与另外一

48、个类交互，但不知道这个类的实现细节时，则称其为松散耦合的。当一个类依赖于实现（即它可以直接访问别的类的数据属性）是，则称其为高度耦合的。 当两个类高度耦合时，一个发生了变化往往需要另一个也跟着变化。高度耦合是巨大的维护负担存在的主要原因。 松散耦合用起来通常都很好，但高度耦合用起来通常问题较多。内聚 一般情况下，应该定义高度内聚的类和方法。 当且仅当只完成一件事情的方法是高内聚的。高内聚的类通常仅表示一种类型的对象。在大学系统中，我们一般不定义职员类，而是将教授，研究员，实验员分别加以定义。目的就是要增加内聚性。32 需求获取及分析阶段的成果及相互关系图？ 面向对象建模是面向对象方法学在需求分

49、析中的应用，也称为面向对象分析。所谓面向对象方法学的观点就是将系统看作是一系列相互作用的对象的集合。每个对象具有独立的职责，完成独立的任务，对象之间通过消息机制相互协作，共同实现系统的目标。 需求获取关注了解用户和他们的使用需求，分析关注理解要构建的内容。面向对象分析技术，如用例模型，类建模，顺序图，活动图以及用户界面原型等都被用来消除需求和系统设计之间的差异。33 需求获取与需求分析的主要区别？ 分析的目的在于理解将要构建的内容，这与需求获取相似。需求获取确定用户要构建的内容。区别在于需求获取将重点放在理解用户和他们使用系统的潜在要求，而分析的重点在于理解系统本身34 针对每个业务事件、报表

50、进行领域类图的构建时主要包括那三个步骤？ 针对每个业务事件、报表进行领域类图的构建时，主要包括三个步骤： （1）识别出业务实体； （2）确定业务实体之间的关系； （3）定义业务实体的关键属性。35 业务实体分析的产物？ 业务实体分析（构建）的产物一般采用两种模型：（1）类图：类图是面向对象分析和设计方法引入的，使UML规范的一部 分。它在语义上比传统的E/R模型强。更加适合于领域建模；（2）E/R图：E/R模型也称实体关系图，与数据库结合更紧密。但在领域建模方面，在语义上没有类图丰富。36 如何从用户给出的具体实例抽象出业务模型？ 假定哈尔滨的王一要给北京的张三买一件礼物。为此，王一登陆到电子

51、商务网站，通过电子商务网站将其送给张三。电子商务网站是通过其签约的北京某礼品店来完成该任务。在整个礼品传递的过程中，各个实体的关联关系如下图所示： 实际情况要比上述场景复杂得多。电子商务网站要能够接受很多人的订货，签约的礼品店有很多，以将礼物送给不同人地方的人。对上述场景进行抽象。可以得到以下的抽象场景。对象是类的一个实例或者出现。类描述了具有相同特性（属性）和行为（操作）、关系类别以及语义的一组对象。王一是一个对象，它是“订货人”类的一个对象。北京海淀礼品店是一个对象它是“礼品店”类的一个对象。北京张三是一个对象，它是“收货人”类的一个对象。电子商务网站不应该成为一个类，因为它除了送礼以外，

52、还要干别的事情，用一个类难以包含，不适应高内聚，低耦合的要求。业务模型的抽象过程37 CRC模型的概念？ CRC（类职责协作卡）模型CRC是Class、 Responsibility和 Collaborator三者的缩写。CRC卡是一种被划分为三个部分的标准索引卡，一部分指出卡片表示的类名，一部分列出类的职责，一部分列出与该类一起协作履行职责的其他类名基于CRC可以建立一种索引卡片，被称为CRC卡，每个卡片代表了一个被发现的候选对象 形式可能是多种多样的，卡片、纸张、黑板等等都可以作为CRC卡的介质载体 CRC卡简洁方便，可以随时被移动、修改或者丢弃，所以它特别适合于在复杂的系统当中进行对象的发现和设计思想的挖掘 ，即进行复杂情况下的面向对象分析与设计 。CRC模型是一组相关的CRC 卡的集合,用于对系统整体或部分建模。38 理解业务规则？ 业务规则实际上是（业务）系统必须满足的运行原则和策略。 业务规则获取的方式： 业务规则通常关注访问控制的问题例如允许教授输入和修改参加其讨 论班的学生的成绩，但不允许输入和修改别的讨论班的学生的成绩。 业务规则也常常与业务计算有关-例如，如何把学生在某个讨论班中得到 的百分制成绩，