第3章 软件需求分析.ppt

《第3章 软件需求分析.ppt》由会员分享，可在线阅读，更多相关《第3章 软件需求分析.ppt（111页珍藏版）》请在沃文网上搜索。

1、 第第3 3章章 软件需求分析软件需求分析3.1关于软件需求关于软件需求3.2需求分析过程需求分析过程3.3非形式化分析技术非形式化分析技术3.4结构化分析建模结构化分析建模3.5面向对象分析建模面向对象分析建模3.13.1关于软件需求关于软件需求软件需求的三个层次软件需求的三个层次业务需求：反映组织机构或客户对系统、产品高层次的目标要求。这些目标将在项目视图与范围文档中予以说明。用户需求：描述用户使用产品必须要完成的任务，在示例文档或方案脚本中说明。功能需求：定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。非功能需求：不直接与系统具体功能相关的一类需求。3.13.

2、1关于软件需求关于软件需求3.1.1功能需求功能需求功能需求描述系统预期提供的功能或服务，包括对系统应提供的服务、如何对输入做出反应，以及对系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需明确声明系统不应该做什么。功能需求取决于开发的软件类型、软件未来的用户及开发的系统类型。系统功能需求描述应该具有：完整性、一致性和准确性。要做到需求描述满足以上3点几乎是不可能的。3.1.23.1.2非功能需求非功能需求非功能需求是指那些不直接与系统具体功能相关的一类需求，主要与系统的总体特征相关，是一些限制性要求。也是对实际使用环境所做的要求，如性能要求、可靠性要求和安全性要求等。非功能需求关心

3、的是系统整体特征，而不是系统的个别特征，因此比功能需求对系统更关键。一个功能需求没有满足时可能会降低系统的功能，而一个非功能系统需求没有满足可能使整个系统无法使用。非功能需求源于用户的限制。非功能需求很难检验。非功能需求与功能需求有时会发生冲突。例：例：POS系统。系统。POS系统即销售时点信息系统，是指通过自动读取设备（如收银机）在销售商品时直接读取商品销售信息（如商品名、单价、销售数量、销售时间、销售店铺、购买顾客等），并通过通讯网络和计算机系统传送至有关部门进行分析加工以提高经营效率的系统。POS系统最早应用于零售业，以后逐渐扩展至其他如金融、旅馆等服务行业，利用POS系统的范围也从企业

4、内部扩展到整个供应链。POS(Pointofsale)“销售点”是一种多功能终端，把它安装在信用卡的特约商户和受理网点中与计算机联成网络，就能实现电子资金自动转帐，它具有支持消费、预授权、余额查询和转帐等功能，使用起来安全、快捷、可靠。8383页的问答题页的问答题4 4请分析POS机系统中共利益者共利益者之间的功能有哪些冲突的地方？共利益者：付款方、收款方、银行、网络服务商。功能需求：付款方：转账、消费等。收款方：购买pos机设备，缴纳手续费。银行：利用服务器实现转账、销售等，收取交易费。网络服务商：保障交易顺利进行。冲突点：付款方刷卡与收款方缴纳手续费冲突、pos机存储容量与价格冲突、pos

5、机存储容量与网络流量冲突、pos机数量与银行服务器处理速度和银行收益冲突47页描述。共利益者：CMMI中术语，Stakeholder。指的是受到某种负责产生输入的方式影响的群体或个人。共利益者可能包括项目经理、供方、顾客以及其他人。“相关的共利益者”：用于指某个计划中要求执行某类活动或接受某类信息的群体或个人。3.1.33.1.3业务需求业务需求业务需求：对已存在的功能预期的约束或者是需要实现的一个特别的计算，统称反映应用领域的基本问题。3.1.33.1.3业务需求业务需求【案例3.1】基于终端的短信系统在短信系统中，短信必须经过短消息协议标准编码才能经过终端无线模块发送出去。如果要对短信编码

6、，必须要对ESTI制订的SMS规范有所了解。与本书讨论的短消息收发有关的规范主要包括GSM03.38、GSM03.40和GSM07.05，前两项着重描述SMS的技术实现（含编码方式）；最后一项则规定了SMS的DTE-DCE接口标准（AT命令集）。发送和接收SMS信息共有3种方式，包括BlockMode、TextMode和PDUMode。BlockMode目前很少用；TextMode是纯文本方式，可使用不同的字符集，也可用于发送中文短消息。但国内手机基本不支持，主要用于欧美地区；PDUMode被所有手机支持，可以使用任何字符集，这也是手机默认的编码方式。PDU串表面上是一串ASCII码，由数字和

7、字母组成。它们是8位字节的十六进制数，或者BCD码十进制数。PDU串不仅包含可显示的消息本身，还包含很多其他信息，如SMS服务中心号码、目标号码、回复号码、编码方式和服务时间等。发送和接收的PDU串的结构是不完全相同的。例如，发送SMSC号码是+8613800220500，对方号码是13851872528，消息内容是“Hello!”。3.1.33.1.3业务需求业务需求从手机发出的PDU串可以是：0891683108200205F011000D91683158812725F800000006C8329BFD0E01对照规范，发送短信每个编码段的解释如表3-1所示。分段含义说明08SMSC地址信

8、息的长度共8个八位字节（包括91）91SMSC地址格式（TON/NPI）用国际格式号码（在前面加“+”）683108200205F0SMSC地址8613800220500，补“F”凑成偶数11基本参数（TP-MTI/VFP）发送，TP-VP用相对格式00消息基准值（TP-MR）00D目标地址数字个数共13个十进制数（不包括91和“F”）91目标地址格式（TON/NPI）用国际格式号码（在前面加“+”）683158812725F8目标地址（TP-DA）8613851872528，补“F”凑成偶数个字节00协议标志（TP-PID）是普通GSM类型，点到点方式00用户信息编码方式（TP-DCS）7b

9、it编码00有效期（TP-VP）5分钟06用户信息长度（TP-UDL）实际长度6字节C8329BFD0E01用户信息（TP-UD）“Hello!”3.1.33.1.3业务需求业务需求例如，接收SMSC号码是+8613800220500，对方号码是13851872528，消息内容是“你好!”，手机接收到的PDU串可以是：0891683108200505F0840D91683158812764F8000830302180635480064F60597D0021对照规范，接收短信每个编码段的解释如表3-2所示。分段含义说明08地址信息的长度共8个八位字节（包括91）91SMSC地址格式（TON/NP

10、I）用国际格式号码（在前面加“+”）683108200205F0SMSC地址8613800220500，补“F”凑成偶数个字节84基本参数（TP-MTI/MMS/RP）接收，无更多消息，有回复地址0D回复地址数字个数共13个十进制数（不包括91和“F”）91回复地址格式（TON/NPI）用国际格式号码（在前面加“+”）683158812725F8回复地址（TP-RA）8613851872528，补“F”凑成偶数00协议标志（TP-PID）普通GSM类型，点到点方式08用户信息编码方式（TP-DCS）UCS2编码30302180635480时间戳（TP-SCTS）2003-3-1208:36:4

11、5+8时区06用户信息长度（TP-UDL）实际长度为6字节4F60597D0021用户信息（TP-UD）“你好!”3.1.33.1.3业务需求业务需求若基本参数的最高位（TP-RP）为0，则不包含用做回复地址的3个段，从互联网上发出的短消息常常是这种情形。注意号码和时间的表示方法不是按正常顺序排序的，而且将奇数个字节补“F”凑成偶数个字节。在PDUMode中，可以采用3种编码方式对发送的内容进行编码，它们是7bit、8bit和UCS2编码。7bit编码用于发送普通的ASCII字符，它将一串7bit的字符（最高位为0）编码成8bit的数据，每8个字符可“压缩”成7个；8bit编码通常用于发送数据

12、消息，如图片和铃声等；而UCS2编码用于发送Unicode字符。PDU串的用户信息（TP-UD）段最大容量是140字节。3.1.33.1.3业务需求业务需求下面以一个具体的例子说明7bit编码的过程，本例对短信“Hello!”进行编码，解释如表3-3所示。3.23.2需求分析过程需求分析过程1沟通沟通为进一步的交流和合作建立基本的协商准备。2导出需求导出需求确定业务需求和需求冲突，分清稳定需求和易变需求。（1）识别真正的客户。（2）正确理解客户的需求。（3）耐心听取客户意见和思考。（4）尽量使用符合客户语言习惯的表达。3分析和精化分析和精化形成一个分析模型，定义问题的信息域、功能域和行为域。4

13、可行性研究可行性研究目的是用最小的代价，在尽可能短的时间内确定问题是否能够解决。主要回答三个问题：系统是否符合机构的总体要求；系统是否可以在现有的技术条件、预算和时间限制内完成；系统能否把已存在的其他系统集成。3.23.2需求分析过程需求分析过程5协商协商调节需求的冲突。6.编写需求规格说明编写需求规格说明我国GB856D1988国家标准给出了需求规格文档SRS的内容框架，如表3-4所示。该文档包括系统的用户需求和详细的系统需求描述。7需求验证需求验证对需求文档和模型进行质量评估。8需求管理需求管理利用需求跟踪表管理需求的变更。3.33.3非形式化分析技术非形式化分析技术3.3.1会谈会谈在需

14、求分析的最初阶段，需求分析员要与客户组成员碰头协商，决定目标产品中需要什么信息。通常由客户决定最初的会谈，随后的会谈可在前次会谈过程中决定、会谈工作要持续到需求分析员确信所有来自客户和产品未来使用者的信息都已完全明确了为止。会谈有两种形式，即正式会谈和非正式会谈。3.3.23.3.2场景分析场景分析场景开始于一个框架，在导出过程中细节被逐渐增加，直到产生交互的完整的描述。在绝大多数情况下，一个场景可能包括如下几个内容。（1）在场景开始部分有一个系统状态描述。（2）一个关于标准事件流的描述。（3）一个关于哪里会出错，以及如何处理错误的描述。（4）有关其他可能在同一时间进行的活动的信息。（5）在场

15、景完成后系统状态的描述。3.3.33.3.3调查表调查表获取需求的一种有效地方法是向客户组织的大量相关人员发放调查表。调查表可以通过与客户会谈的方式制定。【案例3.2】ATM机“取款”场景描述参与者：银行客户场景如下。（1）插卡。（2）验卡。（3）输入密码。（4）验证密码。（5）选择业务（取款）。（6）输入取款金额（1000元）。（7）处理取款。（8）取走现金。（9）打印凭条。（10）退卡。问答题问答题6.试描述图书馆系统中还书的一个常规场景。7.试描述银行客户从ATM上存一笔钱的场景。3.43.4结构化分析建模结构化分析建模3.4.1结构化需求分析结构化需求分析结构化分析（Structure

16、dAnalysis，SA）方法是20世纪70年代由E.Yourdon等人倡导的一种适用于大型数据处理系统并面向数据流的需求分析方法，结构化需求分析方法一般采用以下一些指导性原则。（1）理解问题：人们通常急于求成，甚至在问题未被很好地理解前，就产生了一个解决错误问题的软件。（2）开发模型，使用户能够了解将如何进行人机交互（推荐使用原型技术）。（3）记录每个需求的起源和原因，从而能有效地保证需求的可追踪性和可回溯性。（4）使用多个需求分析视图，建立数据、功能和行为模型。为软件工程师提供不同的视图，将减小忽略某些东西的可能性，并增加识别不一致性的可能性。（5）为需求赋予优先级，优先开发重要的功能，提

17、高开发生产效率。（6）删除含糊性：需求常使用自然语言描述，存在含糊的可能，可以通过复审发现这些问题。3.4.23.4.2结构化分析模型结构化分析模型结构化分析模型必须分别达到以下几个主要目标：描述客户需要、建立软件设计基础、定义在软件完成后可以确认的一组需求。结构化分析模型的三个层次：内层：数据字典（DD），所有数据对象的描述。中间层：DFD、ERD、STD。外出：描述。对中间层模型内容的描述。3.4.23.4.2结构化分析模型结构化分析模型分析模型结构的中间层有如下3种视图。（1）数据流图（DataFlowDiagram，DFD）服务于两个目的，一是指明数据在系统中移动时如何被变换；二是描述

18、对数据流进行变换的功能和子功能。数据流图提供了附加信息，它们可以用于信息域的分析，并作为功能建模的基础。集中了数据的流动和数据转换功能，而不关心数据结构的细节。（2）实体-关系图（Entity-RelationshipDiagram，E-RD）描述数据对象间的关系，是用于进行数据建模活动的记号。它关心的是寻找系统中的数据及其之间的关系，不关心系统的细节。（3）状态转换图（StateTransitionDiagram，STD）指明了作为外部事件结果的系统行为，用于表示系统的各种行为模式，以及在状态间转换的方式，是行为建模的基础。分析建模通常开始于数据建模，定义系统内处理的所有数据实体、实体间关系

19、及其相关信息。定义系统处理的逻辑模型采用实体关系模型ERD。实体：是现实世界中存在且可相互区分的事物。只封装数据，没有操作。圆角矩形表示。属性：定义实体的性能。可以用来描述实例，引用实体。用矩形表示。关系：实体间的联系。菱形表示，关系的基数有3类：一对一、一对多和多对多。3.4.33.4.3面向数据的建模方法面向数据的建模方法【案例3.3】图书馆管理系统实体关系模型根据图书馆系统的问题描述，可得到的实体包括图书、借书者、管理员、借书目录、预约记录和书目。图书馆系统部分ERD如图3-1所示。3.4.33.4.3面向数据的建模方法面向数据的建模方法【案例3.4】POS机系统根据POS机系统的问题描

20、述，给出的实体有销售、支付、商品、商品描述等，它们的ERD如图3-2所示。练习：1.请使用visio软件绘制案例3.3和3.4中的ERD模型。2.某学校考务系统中，一个考场在期末考试中可以安排多场考试，考场实体有属性：考场编号，容纳考生数，考区实体有属性：考区号、考区名（如本部、南区、西区），某一时间某一考场只能安排一门课程的考试，考试期间有监考老师监考和正处级领导巡考，一个考场至少要有2名监考老师，一个考区至少要有两名正处级领导巡考，某一时间内一个监考老师只能监一个考次的考试，某一时间内一名正处级领导只能在一个考区进行巡考，监考老师实体的属性为：教师号、姓名、年龄、性别、所在部门。请画出该考

21、务系统的ER图。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法1数据流图（数据流图（DFD）数据流图中的处理或转换在最终生成的程序中将是若干程序功能模型。数据流图有4种基本符号，如图3-3所示。矩形（或立方体）表示数据源点或终点，圆角矩形（或圆形）代表变换数据的处理，开口矩形（或两条平行线）代表数据存储，箭头表示数据流。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法1数据流图数据流图数据处理的形式：3.4.43.4.4面向数据流的建模方法面向数据流的建模方法1数据流图数据流图数据存储是处于静止状态的数据，数据流是处于活动中的数据。数据源点有时会和终点相同，若只用一个

22、符合代表数据的源点和终点，则至少将有两个箭头与这个符号相连。通常数据流图中忽略出错处理、打开或关闭文件之类的内务处理。数据流图的基本要点是描绘“做什么”，而不考虑“怎么做”，通常要忽略出错处理，也不包括内部处理。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法1数据流图数据流图数据流图的层次结构数据流图的层次结构对于大型系统，往往采用自顶向下逐层分解的方法，用分层数据流图表示所有数据流和加工。对任何一个数据流图来说，它的上层图为父图，在它的下一层的图为子图。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法1数据流图数据流图数据流图的层次结构3.4.43.4.4面向数据流

23、的建模方法面向数据流的建模方法1数据流图数据流图画数据流图的基本原则画数据流图的基本原则自顶向下逐层细化完善求精 具体步骤具体步骤:（1）绘顶层数据流图。找出对整个系统而言的输入、输出数据，确定外部实体，它们决定了系统与外界的接口。（2）为数据流命名，为加工命名。（3）检查核对。（4）核对无误后，进行分解，画处理的内部。在（在（2）至（）至（4）步之间反复迭代，直到处理无法进一步分解为止。）步之间反复迭代，直到处理无法进一步分解为止。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法【案例3.5】订货系统数据流图设一个工厂采购部每天需要一张订货报表，订货的零件数据有零件编号、名称、数

24、量、价格和供应者等。零件的入库、出库事务通过计算机终端输入给订货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次订货。（1）数据流分析。数据源点：仓管员（负责入库或出库事务给订货系统）。数据终点：采购员（接收每天的订货报表）。数据流：事务，订货。数据存储：订货信息，库存清单。处理：处理事务，产生报表。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法（2）绘制基本系统模型。一个系统的本质就是将输入转换成输出，任何系统的基本模型都由若干数据源点/终点和一个代表系统对数据加工变换基本功能的处理组成。图3-4所示为订货系统基本模型的数据流图。3.4.43.4.4面向数据流的建模方

25、法面向数据流的建模方法（3）第1步求精。基本系统模型的数据流图非常抽象，因此需要把基本功能细化，描绘出系统的主要功能。订货系统细化后的数据流图如图3-5所示，可分为“处理事务”和“产生报表”两个主要功能；同时增加了“库存清单”和“订货信息”两个数据存储，并对应出现了“事务”、“库存信息”、“订货信息”和“订货报表”4个数据流。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法（4）第2步求精。对描绘系统主要功能的数据流图进一步细化，订货系统第2步求精的数据流图如图3-6所示。数据流图示例数据流图示例借书系统的顶层数据流图数据流图示例数据流图示例书店借书系统的第一次分解后的数据流图数据

26、流图示例数据流图示例“借书”处理分解后的数据流图数据流图示例数据流图示例第二个例子：第二个例子：考务处理系统的分层考务处理系统的分层DFDDFD顶层数据流图顶层数据流图考考生生考务考务处理系统处理系统考考试试中中心心阅卷站阅卷站不合格报名单不合格报名单报名单报名单准考证准考证考生通知单考生通知单成成绩绩清清单单合格标准合格标准错误成错误成绩绩清单清单考考生生名名单单统计分析表统计分析表0 0层数据流图层数据流图登记登记报名单报名单报名单报名单准考证准考证1 1统计统计成绩成绩2 2不合格不合格报名单报名单考生通知单考生通知单成成统计分析表统计分析表考生名册考生名册绩绩清清单单合合格格标标准准考

27、考生生名名单单成成绩绩清清单单错错误误一层数据流图一层数据流图 (a)(a)检查检查报名单报名单报名单报名单准考证准考证1.11.1编准考编准考证号证号1.21.2不合格不合格报名单报名单考生名册考生名册考生名单考生名单合格合格报名单报名单登记登记考生考生1.31.3一层数据流图一层数据流图 (b)(b)检查检查成绩清单成绩清单2.12.1审定审定合格者合格者2.22.2考生名册考生名册正确正确成绩清单成绩清单制作制作通知单通知单2.32.3分析分析统计成绩统计成绩2.42.4分析分析试题难度试题难度2.52.5试题得分清单试题得分清单考生考生通知单通知单难度难度分析表分析表合格合格标准标准分

28、类分类统计表统计表成绩清单成绩清单错误错误成绩清单成绩清单经审定的经审定的成绩清单成绩清单多层数据流图的注意事项：在多层数据流图中，顶层流图仅包含一个数据处理，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据底层流图是指其数据处理不需再做分解的数据流图，它处在最底层中间层流图则表示对其上层父图的细化。它的每一数据处理可能继续细化，形成子图。数据流图上所有图形符号只限于前述四种基本图形元素；数据流图的主图必须包括前述四种基本元素，缺一不可；数据流图的主图上的数据流必须封闭在外部实体之间；每个数据处理至少有一个输入数据流和一个输出数据流；在数据流图中，需按层给数据处理框编号。

29、编号表明该处理所处层次及上下层的亲子关系；规定任何一个数据流子图必须与它上一层的一个数据加工对应，两者的输入数据流和输出数据流必须一致。此即父 图 与子图的平衡；可以在数据流图中加入物质流，帮助用户理解数据流图；图上每个元素都必须有名字；数据流图中不可夹带控制流；初画时可以忽略琐碎的细节，以集中精力于主要数据流数据流图练习数据流图练习1 1某公司加班申报及核对流程描述如下：班组长每天在加班前填写本组人员加班申报表，由部门主管签字批准后提交给行政助理修改加班记录；班组长填报前日加班异常表，由部门主管签字批准后提交给行政助理调整前日加班记录。行政助理在每周三上报上周加班情况，并填写加班汇总表提交给

30、人力资源部，人力资源部根据汇总表核对员工考勤记录情况，导出异常加班情况表交行政助理核对，并修改加班记录。数据流图练习数据流图练习2 2采购员从库房收到缺货通知单以后，查阅订货合同单，若已订货，向供货单位发出催货请求，否则，填写订货单交供货单位。供货单位发出货物后，立即向采购员发出取货通知单。采购员取货后，发出入库单给库房。库房进行验货入库处理，如发现有不合格货品，发出验收不合格通知单给采购员，采购员据此填写退货单给供货单位。数据流图练习数据流图练习3 3“进书”主要指新书的验收、分类编号、填写、审核、入库。主要过程：书商将采购单和新书送采购员；采购员验收，如果不合格就退回，合格就送编目员；编目

31、员按照国家标准进行的分类编号，填写包括书名，书号，作者、出版社等基本信息的入库单；库管员验收入库单和新书，如果合格就入库，并更新入库台帐；如果不合格就退回。“售书”的流程：顾客选定书籍后，收银员进行收费和开收费单，并更新销售台帐。顾客凭收费单可以将图书带离书店，书店保安审核合格后，放行，否则将让顾客到收银员处缴费。画出“进书”和“售书”的数据流程图。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法2数据字典数据字典数据字典是分析模型中出现的所有名字的一个集合，并包括有关命名实体的描述。使用数据字典有以下两个作用。（1）数据字典是所有名字信息管理的有效机制。在一个大型系统中，需要为模

32、型中的许多实体和联系命名。而这些名字在系统中必须保持一致且不能发生冲突，数据字典可以检查名字的唯一性。（2）作为连接软件分析、设计、实现和进化阶段的开发机构的信息存储。随着系统的改进，字典中的信息也会发生相应变化，新的信息会随时加入进来。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法2数据字典数据字典数据字典由4类元素的定义组成：数据流数据流分量数据存储处理数据字典中的数据元素定义应自顶向下分解，直至包含的元素不需进一步定义，且让人看懂。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法由数据元素组成数据的方式有以下3种基本类型，可以使用这3种类型的任意组合定义数据字典

33、中的任何条目。（1）顺序：顺序连接两个或多个分量元素。一般用加号表示顺序连接关系。（2）选择：从两个或多个可选的分量元素中选取一个。选择运算符用方括号表示，多个可供选择的元素用“|”符号分隔。例如，A-1|A-2|A-3表示3个可选数据元素。（3）重复：描述的分量元素重复零次或多次。重复运算符用大括号表示，并与重复的上下限同时使用。如果上下限相同，表示重复次数固定；如果上下限分别为0和1，表示分量可有可无。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法数据字典通常采用卡片形式描述。一张卡片上应包含名字、别名、描述、定义和位置等信息。例如，订货系统中部分卡片形式的数据定义如图3-7

34、所示。数据字典中定义数据的方法数据字典中定义数据的方法1 1、定义数据流、定义数据流数据流名：说明：简要介绍作用即它产生的原因和结果。数据流来源：来自何方。数据流去向：去向何处。数据流组成：数据结构。数据量流通量：数据量，流通量举例：举例：数据流定义：数据流定义：2 2、定义数据元素、定义数据元素数据元素（数据项）指数据处理中最小的，不可再分的单位。描述包括：数据元素名：类型：数字（离散值，连续值），文字（编码类型）长度：取值范围：相关的数据元素及数据结构：数据元素定义举例（数据元素定义举例（1 1）数据元素定义举例（数据元素定义举例（2 2）数据元素定义举例（数据元素定义举例（3 3）数据元

35、素定义举例（数据元素定义举例（4 4）3 3、定义数据存储、定义数据存储数据文件名：简述：存放的是什么数据 输入数据：输出数据:数据文件组成：数据结构存储方式：顺序，直接，关键码存取频率：数据存储定义举例（数据存储定义举例（1 1）4 4、定义数据处理、定义数据处理数据处理定义举例（1)数据处理定义举例（数据处理定义举例（2 2）加工逻辑词条说明举例（加工逻辑词条说明举例（3 3）5 5、源点及汇（终）点词条描述、源点及汇（终）点词条描述名称：外部实体名简要描述：什么外部实体有关数据流：数目：3.4.43.4.4面向数据流的建模方法面向数据流的建模方法3状态机模型状态机模型适合于描述有外界环境

36、的激励而驱动的实时系统。主要使用状态、变迁和事件3种符号。状态：可观察的行为模式，用圆角矩形表示。变迁：表示状态的转换，用箭头表示。事件：是引发变迁的消息，用箭头上的标记表示。【案例3.6】电子表系统的状态图电子表具有3种状态，分别为显示时间、设置小时和设置分钟。模式按钮是外部事件，它可以导致电子表发生状态变化。图3-8所示为电子表系统的状态图。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法【案例3.7】图书馆管理系统的分析模型第1步，分析图书馆系统的以下几个外部用户。浏览者：仅能浏览图书馆提供的图书介绍和查询信息等，无须登录便可进入系统。借书者：经登录才能进入系统，可以完成借书

37、、还书、续借和预约的功能，还可以查询自己的信息，包括借书情况、有无超期图书和有无罚金等。普通管理员：协助借书者完成借书、还书和续借等功能。系统管理员：负责旧书销毁、新书录入和图书更新，以及用户注册（借书前）、注销和信息更新和罚金处理等。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法第2步，绘制数据流图。图3-9所示是图书馆系统逻辑模型中图书流通子系统的数据流图。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法由于篇幅关系，这里仅就借书功能进一步讨论，其余的功能请读者自己分析给出。图3-10给出了借书功能进一步细化的数据流图。3.4.43.4.4面向数据流的建模方法面向

38、数据流的建模方法第3步，建立实体关系图。根据图书馆系统问题描述，分析出“图书”和“借书者”两个实体，图3-11所示为图书馆系统的实体-关系图。3.4.43.4.4面向数据流的建模方法面向数据流的建模方法第4步，建立数据字典。系统中所有的名字，无论是实体名、类型名、关系名、属性名还是服务名等都要建立到一个数据字典中。图书馆系统的图书信息分为“标题”和“书目”，“标题”描述抽象的图书信息；“书目”则是具体的每一本书的信息。图3-12所示为用卡片方式给出的图书馆系统部分数据信息的描述。名称：标题别名：抽象的图书描述：描述一个抽象的图书的信息定义：标题=ISBN+书名+作者+出版社+出版日期版次+价格

39、+目录+内容简介+馆藏数+可借数+预约数位置：图书查询、借书、还书、预约名称：书目别名：具体的书描述：对应标题的具体的一本书定义：书目=条码号+分类号+ISBN位置：借书、还书、更新3.53.5面向对象分析建模面向对象分析建模3.5.1面向对象概念面向对象概念1对象模型对象模型对象模型表示静态且结构化系统的“数据”性质，它是对模拟客观世界实体的对象，以及对象彼此间关系的映射，描述了系统的静态结构。2动态模型动态模型建立对象模型之后，就需要考察对象的动态行为。动态模型表示瞬间且行为化的系统“控制”性质，它规定了对象模型中对象的合法变化序列。3功能模型功能模型功能模型表示变化系统的“功能”性质，指

40、明了系统应该“做什么”，因此它更直接地反映了用户对目标系统的需求。3.5.2UML3.5.2UML统一建模语言统一建模语言1UML的组成的组成（1）UML的模型元素。UML定义了两类模型元素的图形表示，一类模型元素用于表示模型中的某个概念，如类、对象、用例、节点、构件、包和接口等；另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖和聚集（表示整体与部分的关系）等。图3-13给出了部分UML定义的模型元素的图形表示。3.5.2UML3.5.2UML统一建模语言统一建模语言（2）UML模型结构。根据UML语义，UML模型结构可分为4个抽象层次，即元元模

41、型、元模型、模型和用户模型。它们的层次结构如图3-14所示，下一层是上一层的基础，上一层是下一层的实例。元元模型层定义了描述元模型的语言，是任何模型的基础，它的模型定义了元类、元属性和元操作等一些概念。例如，图3-15所示是一个“元类”的元元模型描述，“事物”概念可代表任何定义的对象。3.5.2UML3.5.2UML统一建模语言统一建模语言元模型层定义了描述模型的语言，它组成了UML模型的基本元素，包括面向对象和构件的概念，如类、属性、操作和构件等。元模型是元元模型的一个实例，如图3-16所示是一个元模型示例，其中类、对象和关联等都是元元模型中事物概念的实例。3.5.2UML3.5.2UML统

42、一建模语言统一建模语言2UML模型模型UML主要是用于描述模型的，它可以从不同视角为系统建模，形成不同的视图（View）。每个视图都是系统完整描述中的一个抽象，代表该系统一个特定的方面。每个视图又由一组图（Diagram）构成，图中包含了强调系统某一方面的信息。3.5.33.5.3用例建模用例建模1编写用例编写用例【案例3.8】POS机系统用例描述POS机系统中，系统的参与者主要有收银员、经理、顾客和公司销售员等，本例主要考虑收银员和经理的用例图，如图3-17所示。3.5.33.5.3用例建模用例建模随着与用户更多的交谈，分析师为每个标记的功能开发用例。通常用例使用非正式的描述性风格编写，也可

43、以使用某个结构化的格式编写，而且有些格式更强调描述的直观性。用例场景详细描述的模板如表3-5（a）所示。POS机系统中的“处理销售”场景描述如表3-5（b）所示。用例不同部分说明用例名称以动词开始描述用例名称范围要设计的系统级别“用户目标”或者是“子功能”主要参与者调用系统，使之交付服务涉众及其关注点关注该用例的人及其需要前置条件开始前必须为真的条件成功保证成功完成必须满足的条件主成功场景典型、无条件和理想方式的成功场景扩展成功或失败的替代场景特殊需求相关的非功能性需求技术和数据变元素不同的I/O方法和数据格式发生频率影响对实现的调查、测试和时间安排杂项未决问题等表3-5（a）用例场景详细描述

44、的模板3.5.33.5.3用例建模用例建模2开发活动图开发活动图活动图通常能够既表示控制流，又表示数据流。UML活动图能够满足数据流建模，从而代替传统的数据流图表示法。图3-18给出了处理销售用例中的UML活动图的例子，图中的黑色圆点表示起点，外带一个圆代表终点。3.5.33.5.3用例建模用例建模3泳道图泳道图UML泳道图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值。在为复杂业务过程建模时，可以利用耙子符号和活动图分层描述。图3-19所示为处理销售用例的UML泳道图。3.5.43.5.4业务建模业务建模1识别分析类识别分析类（1）边界类。边界类用于建立系统与其参与者之间交互的模型，

45、经常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端及API等的抽象。每个边界类至少应该与一个参与者有关，反之亦然，例如，收银员与“处理销售界面”的边界类交互用于支持输入商品和处理支付等交互，如图3-20所示。3.5.43.5.4业务建模业务建模（2）实体类。实体类用于为长效持久的信息建模，大多数情况下，它是直接从业务对象模型中相应的业务实体类得到的。实体对象不一定是被动的，有时可能具有与它所表示的信息有关的复杂行为，能够将变化与其所表示的信息隔开。（3）控制类。控制类代表协调、排序、事务处理及其他对象的控制，经常用于封装与某个具体用例有关的控制。控制类还可以用来表示复杂的派生与演算

46、，如业务逻辑。3.5.43.5.4业务建模业务建模2用例实现分析用例实现分析UML包图通常用于描述系统的逻辑架构层、子系统和包等，层可以建模为UML包，例如，UI（UserInterface）层可以建模为名为UI层的包。UML包图分层组织元素的方式，也可以用嵌套形式。UML包是比Java包或.Net命名空间更为通用的概念，可以表示更为广泛的事物。UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内；否则可以标在包内。UML包代表命名空间，假如Date定义在两个包中，可以用全限定的名称区分它们。如Java：Util：Date表示Java的包嵌套了名为Util的包，

47、后者包含Date类。图3-21所示为一台POS机的部分UML包图。3.5.43.5.4业务建模业务建模3识别属性和操作识别属性和操作操作可以分为以下4种类型。（1）以某种方式操纵数据，例如，添加、删除、选择、更新等。（2）执行计算的操纵，例如，销售中的计算总价。（3）请求某个对象状态的操作。（4）监视某个对象发生某个控制事件的操作。3.5.43.5.4业务建模业务建模【案例3.9】POS机系统业务分析图3-22所示为一个与处理销售相关类的类图。3.5.43.5.4业务建模业务建模POS机系统中使用若干个操作，首先经过控制类将系统请求和输入信息转发给下面的实体类进行处理。在POS领域内，Proc

48、essSaleHandler是运行软件的特定装置，如图3-23所示。3.5.43.5.4业务建模业务建模图3-24所示为POS机“处理销售”的协作图。3.5.43.5.4业务建模业务建模图3-25给出了UML包图所表示的层。3.5.43.5.4业务建模业务建模POS机系统中一些用CRC卡片表示的例子，如表3-6表3-9所示。3.5.53.5.5系统行为建模系统行为建模系统行为模型显示了软件如何对外部事件或激励做出响应，要生成行为模型，分析师必须按如下步骤进行。（1）评估所有的用例，以完成理解系统内的交互序列。（2）识别驱动交互序列的事件，并理解这些事件如何和具体的类相互关联。（3）为每个用例生

49、产序列。（4）创建系统状态图。（5）评估行为模型以验证准确性和一致性。3.5.53.5.5系统行为建模系统行为建模1系统顺序图系统顺序图如图3-26所示为处理销售用例系统顺序。3.5.53.5.5系统行为建模系统行为建模2操作契约操作契约操作契约包括4个部分，即操作、交叉引用、前置条件和后置条件（PostCondition），操作是指操作的名称和参数；交叉引用是指会发生此操作的用例；前置条件是指执行操作之前对系统领域模型对象状态的假设；后置条件是指完成操作后，领域模型对象的状态。例如，操作enterItem的契约如下。操作名称：enterItem（id,quantity）。交叉引用：处理销售用

50、例。前置条件：正在进行的销售。后置条件完成如下操作。（1）创建SaleLineItem的实例（创建关联）。（2）SaleLineItem与当前Sale关联（形成关联）。（3）SaleLineItem.quantity赋值为quantity（修改属性）。（4）基于id匹配，将SaleLineItem关联到ProductDescription（形成关联）。3.5.53.5.5系统行为建模系统行为建模例如，下面给出了处理销售用例中的系统操作，makeNewSale()操作如下。操作名称：makeNewSale()；交叉引用：处理销售；前置条件：无；后置条件完成如下操作。（1）创建了Sale的实例S（