第3章-需求分析

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第三章 需求分析,制作人：李尤丰,cnlyf,金陵科技学院 软件工程学院,内容要点：,3.1 需求分析,介绍需求分析到底做什么，建模的目标和要点，选择建模工具的要点。,3.2 常见需求分析方法,介绍结构化分析方法，面向对象分析方法，面向问题域分析方法，以及三种方法的比较。,3.3 第一阶段：理清框架与脉络,介绍业务流程分析，业务实体分析，角色与使用场景分析，第一阶段的产物。,3.4 第二阶段：确定需求细节,介绍确定行为需求的细节，确定结构需求的细节，第二阶段的产物,3.5 其他需求分析,介绍接口需求，非功能需求的追踪，设计约束，其他需求示例。,3.1 需求分析概述,1,准确地回答“系统必须做什么？”,2,需求分析时，要遵循两个基本原则：,原则一是分析结果需要能够表达和理解问题的信息域和功能域。,原则二是以层次化的方式对问题进行分解和不断细化，可以进行横向分解，也可以进行纵向分解。,3.1.1 需求分析到底做什么,需求分析是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作，概括为分解、提炼、消除矛盾三个方面。,3.1.1 需求分析到底做什么,1分解采用自顶向下的方法：采用业务导向的分解,3.1.1 需求分析到底做什么,1分解采用自顶向下的方法：,采用业务导向的分解,(1)业务流程为主线索的分解结构，该分解策略是目前比较流行的方法，主要按照“业务”的角度考虑分解方法。此方法特别适合联机事务处理系统、管理信息系统（MIS）。,3.1.1 需求分析到底做什么,(2)程序结构为主线索的分解结构：最常用的分解方法,适用于问题域不复杂或者系统与问题域关联性不强的情况。,当然，由于其过早进入程序结构，割裂了与问题域之间的联系，从而容易导致对问题域研究的不足，降低了需求的质量。,目前认为此种方法仅适合于问题域比较清晰，问题不算复杂的情况，例如工具软件、嵌入式系统等。,3.1.1 需求分析到底做什么,(3)基于场景的分解结构,适用于决策支持系统、面向用户的嵌入式系统。,对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、使用场景是主要的线索。向上可以总结成一类相似的集合，再总结成一系列的关注点或者功能域，向下可以分解成具体的步骤或者操作任务。,3.1.1 需求分析到底做什么,(4)基于数据的分解结构,适用于诸如数据仓库之类的数据类项目。,上述分解策略都是从“业务”角度来组织。但对于类似数据仓库之类的数据类项目，业务线索并不是十分明显，或者并不重要，这时就需要以数据为主的分解策略。其中主题域仍然与“业务流程为主的分解策略”类似。而主题类是企业中的高层实体，主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在实现时又会对应于多个物理数据类。,3.1.1 需求分析到底做什么,2提炼采用自底向上的方法,分解是一种自顶向下的方法，当按任何一种线索进行分解时，就会破坏其他线索的完整性。例如，如果以“事”为线索，那么会发现数据需求分解后就会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。,当出现这样的现象时就会阻碍需求分析人员建立全面理解，因此还需要采用自底向上的方法进行提炼。 提炼出系统的总体功能结构，更全面的描述系统。,3.1.1 需求分析到底做什么,3及时发现分析中的矛盾并消除矛盾。,在分析过程中，显然会发现有些需求是相互矛盾、相互冲突的，由于分析是把收集的信息放在一个预先定义的结构中来发现这些矛盾的，因此对矛盾的影响范围会有直观的了解，也知道它影响到哪些层面，这样，就可以很快地找到相应的人员，通过进一步的捕获来消除矛盾。,3.1.2 建模的目标与要点,建模的目标是帮助需求分析员按照实际情况或按需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对需求分析所做出的决策进行文档化。,建模的要点是设计要考虑到计划之外的变化；设计要文档化；用可视化的模型表达架构，有助于理解变化所代表的含义。,3.1.2 建模的目标与要点,在实际的建模过程中要遵循以下建模原则：,1.模型是用来沟通的；,2.选择创建什么模型对如何解决问题和如何形成解决方案具有深远的影响；,3.每种模型可以在不同的精度级别上表示；,4.最好的模型是与现实相联系的模型；,单个模型往往不够充分，对每个重要的系统最好用一组几乎独立的模型去处理。,3.1.3 选择建模工具的要点,1正确认识建模方法论,方法论,时代背景,建模要点,程序,=,数据结构,+,算法,出现于,20,世纪,50,60,年代,软件开发主要解决的是科学计算问题，,Fortran,语言是代表,选择适合的数据结构和算法显然是解决此类问题的关键,结构化分析与设计,出现于,20,世纪,60,70,年代，将解决一些与数据处理相关的问题，例如计费等。,COBOL,、,C,语言是代表,关键点有两个方法：一是确定有那些数据，格式是什么，如何存储，因此提供,E/R,模型；而是确定数据的加工、处理过程，因此提供了,DFD(,数据流图,),面向对象分析与设计,出现于,20,世纪,80,90,年代，信息系统覆盖了更多业务过程,数据并不再是唯一的视角，事（业务流程）、人的视角越来越重要，因此加入更多这方面的建模工具,3.1.3 选择建模工具的要点,2正确认识UML,UML是一种语言（Language），实际上UML就是一种表示方法，它不是方法论。UML是一种建模语言（Modeling Language），它不是编程语言，而是建模语言。它不仅包含软件建模，而且可用于业务建模、流程建模等多种领域。UML是统一建模语言（Unified Modeling Language ），它是一种标准化的、统一的建模语言，OMG认可的工业标准，也是如IBM、SUN等大型公司认可的事实标准。它为参与软件设计和开发的各类人员提供统一的语言，使开发人员能够基于共同的模型来理解业务、需求，理解软件及其架构如何构造的。,3.1.3 选择建模工具的要点,2正确认识UML,表3.2 需求阶段常用的图,使用频率,图名,功能,关注要点,主体,用例图,说明角色和使用场景之间的关系,人,活动图,说明业务流程，以及业务活动的步骤,事,顺序图,描述对象之间的交互,物,类图,说明业务实体之间的关系，体现结构规则,物,辅助,构件图,说明主题域划分以及他们之间的服务接口,接口,部署图,描述系统的部署环境，体现设计约束,设计约束,3.2 常见需求分析方法,方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面，包括问题域的结构、问题域数据、问题域中的重要事件及现象、解系统在问题域中应产生的效果。,目前常见的需求分析方法有结构化分析（SA）、面向对象分析（OOA）和面向问题域分析（PDOA）三种方法。,3.2.1 结构化分析（Structured Analysis）,结构化分析（SA）是面向数据流的需求分析方法，是70 年代末由Yourdon，Constantine 及DE Marco 等人提出和发展，并得到广泛的应用。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模，建模主要包括数据流模型（DFD）、数据字典（DD）、实体关系图（ERD）。,结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模，是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面，利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。,3.2.1 结构化分析（Structured Analysis）,常见的结构化分析技术包括数据建模、过程建模、行为建模、过程/数据关系建模和信息工程方法六类，下面我们主要介绍数据建模和过程建模。,3.2.1 结构化分析（Structured Analysis）,1数据建模：实体关系图Entity Relationship Diagram,简单情况下ERD建模分四步完成，首先从描述信息中辨识实体，可以重点关注描述信息中的名词，看系统是否需要收集其相关的特征；然后确定实体的标识符；进而建立实体间关系，判断各关系的建立是否会产生新的关联实体或者影响已有的实体特性；最后添加详细的描述信息，实体的详细属性和关系的基数。,3.2.1 结构化分析（Structured Analysis）,1数据建模：实体关系图Entity Relationship Diagram,ERD建模的案例：,1)研讨班在每个学年开始的时候开设，然后持续一个学年；,2)每个研讨班针对一个或几个研究方向；,3)每个研讨班由一位或几位教师主持；,4)在研讨班开设之后，学生可以根据主持教师（的姓名）和研讨班的方向来选择和参加某个研讨班；,5)所有的学生必须且只能参加一个研讨班的学习；,6)研讨班时常会开展活动，由教师来决定活动的时间、地点、主题和做报告的学生（的姓名）；,7)每次活动时，由一位或多位同学围绕活动主题做学习报告，交流自己对新技术的学习心得；,8)每个学生一次活动最多只能作一个报告，但每个学生至少会在一次活动中做一个报告；,9)教师对每份活动中的学生报告进行一次点评和指导，提出建议和意见。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图（DFD）就是组织中信息运动的抽象，是信息逻辑系统模型的主要形式。这个模型不涉及硬件、软件、数据结构与文件组织，它与对系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统在信息处理方面要做什么。,由于图形描述简明、清晰，不涉及到技术细节，所描述的内容是面向用户的，所以即使完全不懂信息技术的用户单位的人员也容易理解。因此数据流图是系统分析人员与用户之间进行交流的有效手段，也是系统设计（即建立所开发的系统的物理模型）的主要依据之一。数据流图脱离系统中的物理因素(如计算机等)，表达出系统对信息的加工情况，DFD可以描述原系统/新系统/子系统。DFD是SA的主要工具，它简单、直观，用图形、文字描述系统，它便于使用、便于交流、便于讨论、便于形成共识，是计算机专业人员和用户单位业务人员的共同语言。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,DFD由四种基本符号组成，如图3.5所示。,外部项（S） 数据加工（P） 数据存储（D） 数据流（F）,图3.5 DFD四种基本符号,外部实体,过程,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图的构成及基本元素如下：,1）外部项（外部实体）,源点和终点(又称端点)是系统外的实体，称作外部项。它们存在于环境之中，与系统有信息交流，从源点到系统的信息是系统的输入；从系统到终点的信息称系统的输出。同一个端点可以是人或其它系统。在DFD中引入源点和终点是为了便于理解系统，所以不需要详细描述它们。它们可有编号，以“S”开头。,外部实体是指处于待构建系统之外的人、组织、设备或者其他软件系统，它们不受系统的控制，开发者不能以任何方式操纵它们。需要进行建模的外部实体是那些和待构建的软件系统之间存在着数据交互的外部实体，它们是待构建系统的数据源或者数据目的地，所有的外部实体联合起来构成了软件系统的外部上下文环境。,引入外部项是为了划定系统的边界，不需严格定义，但也要统一编号，而且要与数据字典中的编号相一致。源点和终点可以在多处出现，用特定符号表示重复的外部项。,为了使DFD清楚易懂，我们对加工、数据流、文件的命名都力求简单。至于加工的加工逻辑、数据流的数据结构等，将在数据字典中定义。数据字典和DFD一起来描述系统。,常见的外部项（外部实体）有从待构建系统中获取数据或者为其提供数据的组织，如：供货方，销售方等；需要和待构建系统交互的个人，如：顾客，办事员；需要和待构建系统交换数据的其他软件系统。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图的构成及基本元素如下：,2）加工,加工又称处理或变换，它表示对数据流的操作。加工的符号分成上、下两部分，从上到下分别是标识部分和功能描述部分。标识部分用于标注加工编号，加工编号应具有唯一性，以标识加工，以“P”开头。功能描述部分用来写加工名。为使DFD清晰易读，加工名应简单，能概括地说明对数据的加工行为，其详细描述在数据词典中定义。加工要逐层分解，以求得分解后的加工功能简单、易于理解。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图的构成及基本元素如下：,3）数据流,数据流由一个或一组确定的数据项组成。数据流名应能直观地反映数据流的含义，如产量日报表、汇款单、录取通知书、课程表等，也可以用一组数据中的主要数据为数据流命名，例如“考生成绩单由考生姓名、成绩、通讯地址等数据组成，但成绩是主要的，所以可用“考生成绩”作为数据流的名字。,数据流应统一编号，编号要与数据字典一致。数据流经过一个加工后其数据结构/数据含义/数据的顺序一定要有所变化，否则这个加工就没有意义了。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图的构成及基本元素如下：,4）数据存储（文件）,数据存储是用来存贮数据的。在分层DFD中，数据存储一般仅属于某一层或某几层，因此又称数据存储为局部文件。现对数据存储符号说明如下：,数据存储名写在开口的长方框内，应概要地说明文件中的主要数据。,数据存储上一定要有数据流。,为便于说明和管理，数据存储亦应编号，编号写在文件符号左端小方格中，以“D”开头。,为避免DFD中出现交叉线，同一数据存储可在多处画出。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图的绘制步骤包括七步，如下：,1)确定所开发的系统的外部项（外部实体），即系统的数据来源和去处；,2)确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图；,3)确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）确定每个加工的输出与输入数据流以及与这些加工有关的数据存储；,4)根据自顶向下，逐层分解的原则，对上层图中全部或部分加工环节进行分解；,5)重复步骤（4），直到逐层分解结束；,6)对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有遗漏、重复、冲突之处，各层DFD及同层DFD之间关系是否合理，及命名、编号是否确切、合理等，对错误与不当之处进行修改；,7),和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图绘制规则有三条，如下：,1)过程是对数据的处理，必须有输入，也必须有输出，而且输入数据集和输出数据集应该存在差异；,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图绘制规则有三条，如下：,2)数据流是必须和过程产生关联的，它要么是过程的数据输入，要么是过程的数据输出；,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图绘制规则有三条，如下：,3) DFD当中所有的对象都应该有一个可以唯一标识自己的名称，过程使用动词，外部实体、数据流和数据存储使用名词。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图绘制过程如图3.8所示。,绘制数据流图的主要原则包含明确系统边界；自顶向下逐层扩展；合理布局；数据流图绘制过程，就是系统的逻辑模型的形成过程，必须始终与用户密切接触，详细讨论，不断修改，也要和其他系统建设者共同商讨以达到意见一致。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图建模,示例1,:,银行取款系统,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,银行取款系统,简单银行取款应用描述：,储户将填好的取款单、存折交银行，银行做如下处理：,审核并查对帐目，将不合格的存折、取款单退回储户，合格的存折、取款单送取款处理。,处理取款修改帐目，将存折、利息单、结算清单及现金交储户，同时将取款单存档。,画出银行取款处理数据流图。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,银行取款系统,第一步，画出关联数据流图。注意，现金是实物，不能作为数据流。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,银行取款系统,第二步，逐层分解加工，画出下层DFD。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图建模,示例2,：,图书预定系统,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,图书预定系统,图书预订系统描述：,书店向顾客发放订单，顾客将所填订单交由系统处理，系统首先依据图书目录对订单进行检查并对合格订单进行处理，处理过程中根据顾客情况和订单数目将订单分为优先订单与正常订单两种，随时处理优先订单，定期处理正常订单。最后系统根据所处理的订单汇总，并按出版社要求发给出版社。,画出图书预定系统的各层数据流图。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,图书预定系统,第一步，画出关联数据流图。,图,3.11,图书预定系统关联图,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,图书预定系统,第二步，逐层分解加工，画出下层DFD。注意到根据题意，当绘出系统顶层图后并不能将所有加工分解成基本加工，还要进行二层图分解，并在分解加工过程中逐步充实数据存储，如图3.12和3.13。图3.12 图书预定系统0层图,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,图3.13 图书预定系统1层图,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据流图建模,示例,3,：层次结构的建立,使用DFD描述常见的,电梯控制系统,。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,电梯控制系统,一个控制系统控制多个电梯。,每个电梯被置于一个相应甬道之中，在卷扬电机的作用下在甬道内做上下运动。,甬道内安装有多个传感器，通常每个电梯停靠点一个，用来感应电梯的实时位置。,电梯内部和建筑的每个电梯停靠层都设置有指示器，用来告知用户的电梯实时位置和运动状况。,电梯内和建筑的每个电梯停靠层都设有按钮，用户可以通过这些按钮提出服务申请并进出电梯。,控制系统调度用户的申请，让电梯以最有效的方式满足用户的服务要求。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,电梯控制系统表,-,表,3.3 业务描述表,业务需求,实现业务需求需要的系统特性,局部解决方案的对外交互,BR1,：让电梯运转起来,SF1.1,：能够获知电梯位置感应，并转交给指示器,外部输入：感应器感应信号外部输出：指示器要求信号,SF1.2,：能够控制卷扬电机，实现服务请求的电梯运动,外部输入：调度要求外部输出：卷扬电机控制信号,SF1.3,：用户可以利用按钮发出服务请求,外部输入：按钮信号外部输出：服务请求,BR2,：实现电梯的有效调度，最大限度的服务用户,SF2.1:,系统从服务请求队列中建立高效率的调度,外部输入：服务请求外部输出：调度要求,BR3,：保证安全，尤其是用户出入电梯的安全,SF3.1,：系统要根据电梯的运动状况和服务申请控制电梯门的开关,外部输入：服务请求、电梯状况外部输出：门控命令,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,电梯控制系统,图3.14 电梯控制系统的上下文图,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,电梯控制系统,层次结构的建立-建立DFD片断,表3.4 电梯控制系统的外部事件及其响应对照表,事件,系统的响应,用户利用按钮发出服务请求,系统首先要记录请求，以备调度，如果请求时电梯处于运动状态，则系统需要重新执行请求调度，并在需要的情况下更改运动目标。,用户利用按钮发出开关门请求,系统察看电梯状态，如果处于静止状态并且处于目前楼层，则发出门控命令，否则不予处理。,感应器信号发生变化,系统要根据新的信号更新电梯状态，并通知指示器改变显示。,电梯开始运动，即门已关闭，开始运动,系统要改变电梯状态为运动状态，然后根据等待的服务请求调度确定电梯的运动目标，结合电梯目前位置，控制卷扬电梯开始工作。,电梯停止，即电梯已经到达目标位置,系统更新电梯状态为静止状态以停止对新增请求的处理，去除已完成的请求，然后控制卷扬电机停止运动，并在停止后，开启电梯门。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,电梯控制系统,层次结构的建立-建立DFD片断,图3.15 电梯控制系统的关联图,3.2.1 结构化分析（Structured Analysis）,电梯控制系统,图3.15 电梯控制系统的关联图,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,电梯控制系统,层次结构的建立-建立0层图,电梯控制系统,层次结构的建立,-建立0层图,图3.16,电梯控制系,统,的初始0层图,电梯控制系统,层次结构的建立,-建立0层图,图3.17,电梯控制系统,的最终0层图,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,虽然数据流图能够形象、清晰地描述数据在系统中流动、加工、存储的情况，但数据流图中的许多构成元素，如数据流、数据存储、加工，仅依靠名称并不能反映其本质含义，因此必须对这些构成元素进行严格的定义。,作为对数据流图的补充，,数据字典(DD，Data Dictionary)能够准确地定义数据流图中各组成成分的具体含义，二者共同构成了系统的逻辑模型。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典是一个储存库，包含软件使用和产生的所有数据对象的描述，其中也包括DFD当中数据流和数据存储的定义。,有组织地列出DFD中的涉及的所有数据元素（数据流、数据存储），并定义每个数据元素的名称（数据元素的原始名称）、别名（数据元素的其他名称）、使用地点（会使用该数据元素的过程）、使用方法（该数据元素扮演的角色（输入流、输出流或数据存储等）、使用范围(该数据元素存在的范围)、描述(对数据元素内容的描述)、单位/格式(数据元素的数据类型，可能事先设置的取值)。,数据字典中的基本元素和含义见表3.5。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,表3.5数据字典基本元素及其含义表。,符号,含义,说明,=,表示定义为,用于对于,=,左边的条目进行确切的含义,+,表示与关系,X=a+b,表示,X,由,a,和,b,共同构成,表示或关系,X=a,b,与,X=a,b,等价，表示,X,由,a,或,b,组成,(),表示可选项,X=(a),表示,a,可以在,X,中出现，也可以不出现,表示重复,大括号中的内容重复,0,到多次,Mn,表示规定次数的重复,重复的次数最少,m,次，最多,n,次,“”,表示基本数据元素,“”,中的内容是基本数据元素，不可再分,.,连接符,Month=1.12,表示,month,可取,1,12,中的任意值,*,表示注释,内容为注释信息,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典是关于数据流图中各种成分详细定义的信息集合，可将其按照说明对象的类型划分为四类条目，分别为数据流条目、数据项条目、数据文件条目和数据加工条目。,数据字典的任务是对于数据流图中出现的所有被命名的图形元素在字典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,1)数据流条目,数据流在数据流图中主要用于说明数据结构在系统中的作用和流动方向，因此数据流也被称作“流动的数据结构”。数据字典中数据流条目应包括以下几项主要内容：数据流名称、数据流别名、说明、数据流来源、数据流流向、数据流组成和数据流量等。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,1)数据流目,数据流词条的描述示例1:,数据流名：发票,说明：用作学生已付书款的依据,数据流来源：来自加工“审查并开发票”,数据流去向：流向加工“开领书单”。,数据流组成：,学号+姓名+书号+单价总价+书费合计,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,1)数据流目,数据流词条的描述示例,2,:,工资系统中的出勤表数据流在数据字典中的条目描述为:,数据流名称：出勤表,数据流别名：无,说明：由人事部门每月月底上报的职工考勤统计数字,数据流来源：人事部门,数据流流向：加工1.1.1(统计出勤、请假及旷工时数),数据流组成：,出勤表 = 年份+月份+职工号+出勤时数+病假时数+事假时数+旷工时数,数据流量：1份/月,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,2)数据项条目,数据流图中每个数据结构都是由若干个数据项构成的，数据项是加工中的最小单位，不可再分。数据字典的数据项条目中应包含的主要内容有：数据项名称、数据项别名、说明、类型、长度、取值范围及含义等。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,2)数据项条目,例如：出勤表中的职工号数据项在数据字典中的条目描述为,数据项名称：职工号,数据项别名：,employee_no,说明：本单位职工的惟一标识,类型：字符串,长度：,6,取值范围及含义：,1,2,位,(00.99),为部门编号：,3,6,位,(XX0001.XX9999),为人员编号,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,3)数据文件条目,数据文件是数据流图中数据结构的载体。数据字典的数据文件条目中应包含的主要内容有：数据文件名称、说明、数据文件组成、组织方式、存取方式、存取频率等。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,3)数据文件条目,例如：工资系统中的职工工资档案文件在数据字典中的条目描述为,数据文件名称：工资档案,说明：单位职工的基本工资、各项津贴及补贴信息,数据文件组成：职工号,+,国家工资,+,国家津贴,+,职务津贴,+,职龄津贴,+,交通补贴,+,部门补贴,+,其他补贴,组织方式：按职工号从小到大排列,存取方式：顺序,存取频率：,1,次,/,月,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,4)数据加工条目,在数据流图中只简单给出了每个加工的名称，在数据字典中通过数据加工条目主要是要说明每个加工是用来“做什么”的。数据字典的数据加工条目中应包含的主要内容有：,数据加工名称、加工编号、说明、输入数据流、输出数据流、加工逻辑等。,3.2.1 结构化分析（Structured Analysis）,2过程建模：数据流图Data Flow Diagram,数据字典,4)数据加工条目,例如：工资系统中的计算应发工资这个加工在数据字典中的条目描述为,数据加工名称：计算应发工资,加工编号：,1.2,3.2.1 结构化分析（Structured Analysis）,3行为建模：状态(转换)图/矩阵State (Transition) Diagram/Matrix,行为建模技术是在设计产品时，综合考虑产品所要求的功能行为、设计背景和几何图形，采用知识捕捉和迭代求解的一种智能化设计方法。通过这种方法，设计者可以面对不断变化的要求，追求高度创新的、能满足行为和完善性要求的设计。行为模型常用状态转换图（简称状态图）来描述，它又称为状态机模型。行为模型通过描述系统的状态以及引起系统状态转换的事件来表示系统的行为。状态图中的基本元素有事件、状态和行为等。,3.2.1 结构化分析（Structured Analysis）,4过程/数据关系建模：功能实体矩阵Function/Entity Matrix,通过功能实体矩阵描述过程与数据关系，这里不再赘述。,3.2.1 结构化分析（Structured Analysis）,5信息工程方法：功能分解图Function Decomposition Diagram和过程依赖图Process Dependency Diagram,信息工程法是James Martin在对信息系统成功和失败多年研究的基础之上，进行了一系列实际考察和理论分析，并综合了多种信息系统规划方法，1982年提出的一套IT规划理论和方法，是一种面向技术的方法，建立企业模型、主题数据模型，确定主题数据库的内容和结构，制定数据库的开发策略。,信息工程法提供了建立企业模型、数据模型和流程模型的技术手段，其基础和核心是战略数据规划（strategic Data Planning，SDP），这种方法首先进行业务分析来建立企业模型；其次是进行实体分析来建立主题数据模型；最后进行的是数据的分布分析，并结合数据的存储地点，确定主题数据库的内容和结构，制定数据库的开发策略。总之，信息工程法在很大程度上是一种面向技术的方法。,3.2.2 面向对象分析（Object Oriented Analysis）,面向对象分析基本思想是如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。,面向对象分析（OOA）算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计。,OOA的大致方法是标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类之间的关系建模。,通常使用统一建模语言（Unified Modeling Language）来表示面向对象分析的结果。UML是用来对软件密集系统进行可视化建模的一种语言，是为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。,在面向对象分析过程中主要使用用例图、类图、交互图、活动图、对象约束语言、状态图六类图,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,在面向对象分析与设计中有两种风格的用例模型，即基本用例模型和系统用例模型。基本用例模型反映行为需求，用于对行为需求建立独立于技术的模型，一般在需求获取阶段建立，也被称为业务用例模型或者抽象用例模型；系统用例模型反映的是分析结果，用于为行为分析建模，描述用户与系统协同工作的细节，包括对用户界面特点的描述，一般在需求分析阶段建立，也称为具体用例模型或者详细用例模型。,基本用例和系统用例的区别由两个方面体现，从阶段上来说，基本用例在需求获取阶段构建，系统用例在需求分析阶段构建；从内容上来说，基本用例（也称业务用例）使用应用领域的语言和用户的语言进行表达，包括对一项任务和交互的简化的、通用的、抽象的、与技术无关并且独立于实现的描述，系统用例分析和描述所要解决的问题所提出的需求，同时和对用户界面将来外观的初步构思结合，系统用例一般将会引用屏幕显示和报表。,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,一般来说，基本用例和系统用例的区别很难说清楚，也和开发团队使用的方法有关，常见的情况是有的团队认为基本用例包含参与者、系统边界、用例实例，系统用例除此之外还包括业务规则、屏幕显示和报表等，有的团队没有对此进行区分。,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,示例：CMS系统需求非常简单，系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。,图,3.18,业务用例图,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,这里要注意三点：,1）业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的 操作，而用户所关注的业务是不包含“登录”的。,2）业务用例仅包含客户“感兴趣”的内容。,3）业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。,图,3.18,业务用例图,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,从业务用例图看到，一个“新闻管理”这个业务用例，分解出N多系统操作，这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是），例如，系统中至少要包含登录、注销登录、查看新闻列表、修改新闻、删除新闻等备选系统用例。这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。,找出所有的备选系统用例后，要对他们进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。最终可以得出的系统用例见图3.19。,图,3.18,业务用例图,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,最终可以得出的系统用例见图3.19。,图3.19 系统用例图,3.2.2 面向对象分析（Object Oriented Analysis）,1用例图Use-Case Diagram,得出系统用例图后，应该对每一个系统用例给出用例规约，对用例规约的要求是“清晰易懂”。下面给出“登录”这个系统用例的一个规约，见表3.6。,用例名称,登录系统,用例简述,用户登录,CMS,系统,用例图,主要流程,1,）用户输入用户名和密码,2,）选择用户类型,3,）点击登录按钮,替代流程,3a,）“用户名或密码错误”，系统出现用户名或密码错误的提示信息，回到主要流程,1,，由用户重新输入,3b,）“输入的用户名与类型不符”，系统出现提示信息，回到主要流程,1,，由用户重新输入,3c,）当用户点击取消按钮时，取消登录,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,类是对一组具有相同属性、操作、关系和语义的对象的描述。关系是类之间的，语义是蕴涵的，对一个类而言，其关键的特性是属性（成员变量）和操作（成员方法），UML对类的表示方法见图3.20。,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,图,3.20,类的表示方法,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,在概念建模阶段，类之间最常见的关系有三种：关联、泛化、聚合/组合。,数量关系在类图中是以多重性的形式表示的，有时也被称为重数。表示方式为“n.m”，其中，n表示定义所连接的最少对象的数目，m表示最多对象数，当不能确定最大数时，用“*”表示。,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,一个学生可以参加一个以上的讨论班；一个讨论班可以由零个或多个学生参加，类的数量关系见图3.21。,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,一个队员是一个或者多个团队的一部分；一个团队由一个或者多个队员组成；任何团队都可以是更大的团队的一部分；一个团队可以由多个小的子团队构成，类的数量关系见图3.22。,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,一个发动机是一架且仅是一架飞机的一部分；一架飞机有一个或多个发动机，类的数量关系见图3.23。,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,在阅读类图时，应分清类、考察类之间的关系、通过多重性理解类的结构特点。例如在图3.24中，可以读出7个类，分别是客户、订单、订单项、收货人、送货单、供应商、产品。,3.2.2 面向对象分析（Object Oriented Analysis）,2类图Class Diagram,表3.7 类之间的关系表,源类及多重性,目标类及多重性,描述,客户（,1,）,订单（,0.n,）,订单是属于某个客户的，客户可以有,1,个或者多个订单。,订单（,1,）,收货人（,1,）,每个订单只能有一个收货人,订单（,1,）,订单项（,1.n,）,订单由,1,个或多个订单项组成，,订单（,1,）,送货单（,1.n,）,一个订单有一个或者多个送货单,送货单（,1,）,订单项（,1.n,）,一个送货单对应订单中的多个订单项,送货单（,1,）,收货人（,1,）,每个送货单都对应一个收货人,供应商（,1,）,送货单（,0.n,）,每个供应商有相关的一个或者多个送货单,订单项（,1,）,产品（,1,）,每个订单项包含唯一的一类产品,供应商（,1,）,产品（,0.n,）,每个供应商有多种产品,3.2.2 面向对象分析（Object Oriented Analysis）,3交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram,交互图是描述对象之间的关系以及对象之间的信息传递的图，包括序列图和协作图（通信图）。,序列图是用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件；序列图是一种强调时间顺序的交互图，其中对象沿横轴排列，消息沿纵轴按时间顺序排列；序列图中的对象生命线是一条垂直的虚线，它表示一个对象在一段时间内存在，示例见图3.25。,3.2.2 面向对象分析（Object Oriented Analysis）,3交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram,3.2.2 面向对象分析（Object Oriented Analysis）,3交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram,图3.25是用户登录的序列图，注册会员为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行，UserServices为业务组件，调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定用户名、密码是否匹配，从而完成业务功能。,3.2.2 面向对象分析（Object Oriented Analysis）,3交互图（顺序图/通信图）Interaction（Sequence / Communication）Diagram,协作图（通信图）也是一种交互图，它强调收发消息的对象的组织结构，协作图和序列图是可以相互转换的。在很多情况下，协作图主要用来对单一的、顺序的控制流建模，同时它也可以用来对包括迭代和分支在内的复杂控制流进行建模。协作图包含一组对象和链(link)，用于描述系统的行为是如何由系统的组成成员协作实现的。,3.2.2 面向对象分析（Object Oriented Analysis）,4活动图Activity Diagram,活动图（activity diagram，动态图）是用来描述业务用例实现的工作流程。业务工作流程说明业务为向其所服务的业务主角提供其所需的功能而必须完成的工作。业务流通常包括一个基本工作流和一个或多个备选工作流，工作流的结构可以使用活动图来清晰的说明。业务流活动图用于整理实现业务目标时所要执行的各项任务或活动的顺序安排，活动既可以是手动执行的任务，也可以是自动执行的任务，它可以完成一个工作单元。,活动图是状态图的一种特殊形式。其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。,3.2.2 面向对象分析（Object Oriented Analysis）,4活动图Activity Diagram,示例：管理员添加菜品信息，管理员添加菜品的活动图见图3.26。,3.2.2 面向对象分析（Object Oriented Analysis）,4活动图Activity Diagram,示例：管理员添加菜品信息，管理员添加菜品的活动图见图3.26。,图3.26中的主要活动包括：,1）管理员进入菜品信息管理界面，用例开始；,2）管理员在菜品信息管理界面选择添加菜品功能；,3）系统显示菜品添加页面；,4）管理员填写菜品相关信息；,5）管理员保存添加的菜品信息；,6）系统提示菜品添加成功；,7）系统返回菜品信息管理界面，等待处理下一业务。,3.2.2 面向对象分析（Object Oriented Analysis）,5对象约束语言Object Constraint Language,对象约束语言简称OCL（Object Constraint Language），它是一种用于施加在指定的模型元素上约束的语言。OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在操作和方法上的前置条件和后置条件等。,3.2.2 面向对象分析（Object Oriented Analysis）,5对象约束语言Object Constraint Language,对象约束语言是一种形式化语言，它主要用于表示UML模型中施加于模型上的约束。OCL具有如下特点：,1）是一种精确的，无二义性的语言；,2）是一种规范说明性语言，所有有关实现的问题都不能用OCL来表达；,3）是一种纯表达式语言，它是具有没有任何副作用的申明性语言；,4）是一种类型化语言，即OCL中的每一个表达式都是具有类型的；,5）不是一种程序设计语言，不能用OCL编写程序逻辑和控制流程。,3.2.2 面向对象分析（Object Oriented Analysis）,5对象约束语言Object Constraint Language,OCL预定义的标准类型包含了一组基本类型和集合类型，其基本类型有“Boolean”、“Integer”、“Real”、“String”等，集合类型包括“Collection”、“Set”、“Bag”、“Sequence”等，这些标准型是OCL表达式的组成部分。,OCL表达式对于一个OCL类型求值，其具有以下特点：,1）表达式可以附加在模型元素上，模型元素的所有实例都应该满足表达式的条件；,2）表达式可以附加在操作上；,3）表达式可以指定附加在模型元素上的监护条件；,4）表达式的计算顺序是从左到右,5）表达式既可以使用基本类型又可以使用集合类型。,OCL表达式可以附加在模型元素或模型元素的属性和操作上表达一个约束条件。,3.2.2 面向对象分析（Object Oriented Analysis）,6状态图State Chart Diagram,状态图(State Chart Diagram)是描述一个实体基于事件发生状态转变的动态行为，展示了该实体如何根据当前状态对不同的事件做出相应反应，通常我们创建一个UML状态图是为了研究类、角色、子系统、或组件的复杂行为。,3.2.2 面向对象分析（Object Oriented Analysis）,6状态图State Chart Diagram,要建立对象生命期的模型：,首先要将状态机的环境设置为类、用例或整个系统。如果环境是类或用例，则要收集相邻的类，其中包括父类或通过关联关系或依赖关系可以接触到的类。这些相邻类是操作的候选目标，并且是可以包括在警戒条件中的候选目标。如果环境是整个系统，则要将重点集中到系统的一个行为上，然后考虑在该方面涉及到的对象的生命期