南京师范大学软件需求分析与建模PPT课件

1、1,第二部分 软件需求分析与建模,窦万峰 计算机科学与技术学院 南京师范大学,.,2,回答问题,什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 什么是面向数据的建模？ 什么是面向数据流的建模？ 什么是非形式化建模、半形式化建模和形式化建模？ 什么是统一建模语言（UML）？ 什么是用例建模？ 什么是领域模型？,.,3,第5章 软件需求分析过程,什么是软件需求？ 软件需求分析有哪些过程？ 如何启动分析过程？ 需求规格文档有哪些内容？ 需求分析有哪些技术？,.,4,软件需求,功能需求：描述系统预期提供的功能或服务 对系统应提供的服务 如何对输入做出反应 系统在特定条件下的行为 非功能

2、需求：指那些不直接与系统具体功能相关的一类需求 产品需求 机构需求 外部需求 领域需求：源于系统的应用领域需求,.,5,功能需求,软件系统的功能需求描述可以有许多方式： 文字描述 图表表示 功能需求可以以不同的详细程度反复编写和细化 功能需求描述应该完整而且一致和准确 完整性意味着用户所需的所有的服务应该全部给出描述 一致性意味着需求描述不能前后矛盾 准确性是指需求不能出现模糊和二义性的地方,.,6,功能需求描述：出卷系统,教师能够根据自己的要求手动或自动出一份试卷； 教师可以修改试卷中不合适的题目，并能自动生成各种样式的试卷； 教师可以对试题中的题目进行更新。,.,7,非功能需求,非功能需求

3、主要与系统的总体特征相关，是一些限制性要求，是对实际使用环境所做的要求 性能要求 可靠性要求 安全性要求 可用性要求 移植性要求 非功能需求关心的是系统整体特征而不是个别的系统的特征，比功能需求对系统更关键。 非功能需求却很难检验 非功能需求与功能需求有时会发生冲突，它们之间存在着相互作用关系,.,8,非功能需求举例,一个POS系统所需的存储因为成本原因有所限制，而商品的描述和价目表的信息量很大。 如果采用远程服务器，提供商品描述和价目表信息，那必然需要网络通信，而这需要网络技术。 当POS机数量多时必然引起服务器处理瓶颈问题。,.,9,领域需求,领域需求反映应用领域的基本问题，直接影响到系统

4、的可用性。 例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络打印机上，但因为版权限制，这些文档打印之后应立即删除。,.,10,领域需求示例：短信系统,如果短信经过终端无线模块发送之前必须经过短消息协议标准编码才能发送出去。 要对短信编码，必须要对由ESTI制订的SMS规范有所了解。 技术实现(含编码方式)GSM 03.38、GSM 03.40 SMS的DTE-DCE接口标准(AT命令集)：GSM 07.05 三种方式来发送和接收SMS信息： Block Mode Text Mode：纯文本方式，可使用不同的字符集，也可用于发送中文短消息，主要用于欧美地区。 PDU M

5、ode：PDU Mode被所有手机支持，可以使用任何字符集，这也是手机默认的编码方式,.,11,PDU串（选讲）,PDU串表面上是一串ASCII码，由0-9、A-F这些数字和字母组成。它们是8位字节的十六进制数，或者BCD码十进制数。 PDU串不仅包含可显示的消息本身，还包含很多其它信息，如SMS服务中心号码、目标号码、回复号码、编码方式和服务时间等。 发送和接收的PDU串，结构是不完全相同的。,.,12,编码举例,例如： 发送SMSC号码是+8613800220500，对方号码消息内容是“Hello!”。 从手机发出的PDU串可以是： 08 91 68 31 08

6、20 02 05 F0 11 00 0D 91 68 31 58 81 27 25 F8 00 00 00 06 C8 32 9B FD 0E 01,.,13,发送短信每个编码段的解释,.,14,需求分析过程,需求分析主要是理解客户需要什么、分析要求、评价可行性、协商合理的方案、无歧义地详细说明方案、确认规格说明、管理需求以至将这些需求转化为可行系统 过程包括： 初步沟通 导出需求 分析和精化 可行性研究 协商与沟通 规格说明 需求验证 变更管理,.,15,初步沟通,业务领域的共利益者（如业务管理人员，市场营销人员，产品管理人员）定义业务用例 确定市场的范围 初略地可行性分析 确定项目范围的工

7、作说明,.,16,导出需求,导出需求应理解问题 范围问题：系统的边界，是客户和开发者共同关心的部分 理解问题：确定业务需求、需求冲突、说明有歧义和不可测试的需求 易变问题：分清需求稳定部分和易变部分 收集活动： 识别真正的客户/用户 正确理解客户的需求 耐心听取客户意见和思考 尽量使用符合客户语言习惯的表达,.,17,分析和精化,开发一个精确的技术模型，用以说明软件的功能、特征和约束。 精化是一个分析建模动作，由一系列建模和求精任务构成 定义了问题的信息域，功能域和行为域,.,18,可行性研究,可行性研究的目的是确定用最小的代价，在尽可能短的时间内确定问题是否能够解决 可行性研究的输入是系统的

8、一个框架描述和高层逻辑模型 输出是一份需求开发评价报告，对需求工程和系统开发是否值得做的具体建议和意见 三个问题： 系统是否符合机构的总体要求？ 系统是否可以在现有的技术条件、预算和时间限制内完成？ 系统能否把已存在的其他系统集成？,.,19,协商与沟通,调节冲突和问题 需求排序 识别和分析与每项需求相关的风险、开发工作量、成本和交付时间,.,20,软件需求规格,一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型、一组使用场景、一个原型或以上各项的任意组合。 软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“

9、产品”，它是客户、管理者、分析工程师、测试工程师、维护工程师交流的标准和依据。 软件需求规格描述了系统的数据、功能、行为、性能需求、设计约束、验收标准、以及其他与需求相关的信息。 分为：用户需求和系统需求,.,21,用户需求描述示例,2.1 处理销售：完成一次销售过程。 2.1.1 基本流程：（1）顾客携带所购商品或服务到收银台通过POS机付款；（2）收银员开始一次新的销售交易；（3）收银员输入商品条码；（4）系统逐条记录销售的商品，并显示该商品的描述、价格和累计额；重复（3）（4），直到输入结束；（5）系统显示总额；（6）收银员告知顾客总额，并请求付款；（7）顾客付款，系统处理支付；（8）系

10、统记录完整的销售信息，并将销售金和支持信息发送到外部的帐务系统和库存系统；（9）系统打印票据；（10）顾客携带商品和票据离开。 2.1.2 扩展流程：.,.,22,系统需求,系统需求是比用户需求更详细的需求描述，是系统实现的基本依据 系统需求描述可能包括许多不同的模型，如对象模型和数据流模型,.,23,需求规格文档标准,1 引言 1.1 编写目的 1.2 项目背景（单位和与其他系统的关系） 1.3 定义（专门术语和缩写词） 2 任务概述 2.1 目标 2.2 运行环境 2.3 条件限制 3 数据描述 3.1 静态数据 3.2 动态数据 3.3 数据库描述 3.4 数据字典 3.5 数据采集 4

11、 功能需求 4.1 功能划分 4.2 功能描述 5 性能需求 5.1 数据精确度 5.2 时间特性 5.3 适应性 6 运行需求 5.1 用户界面 5.2 硬件接口 5.3 软件接口 5.4 故障处理 7 其他需求 （检测或验收标准、可用性、可维护性 可移植性、安全保密性）,.,24,需求验证,需求验证对需求文档和制品进行质量评估，确保需求说明准确、完整 包括以下内容： 正确性 一致性 完整性 可行性 必要性 可检验性 需求的可跟踪性 最后签字,.,25,需求变更管理,需求变更管理是组织、控制和文档化需求的系统方法 建立基线以便在客户和开发人员之间建筑一个约定 需求管理从标识开始，建立跟踪表

12、需求跟踪表可以跟踪需求的特征、来源、依赖、子系统和接口等关系,.,26,通用跟踪表,.,27,启动分析过程,确定共利益者：直接或间接从正在开发的系统中获益的人。 例如，POS机系统中的共利益者有：收银员，售货员，顾客，公司，经理，支付授权服务，帐务系统和库存系统等 识别视点：从不同的视角看待该系统。 比如，收银员关心准确、快速生成一次销售，且没有支付错误；售货员关注销售提成 协同工作：共利益者之间的协作 首次提问：集中于客户和其他共利益、整体目标、收益等,.,28,非形式化需求分析技术,会谈： 正式会谈：提出一些可自由回答的问题 非正式会谈：提出一些事先准备好的议题 情景分析：需求分析从对场景

13、的评论中得到信息，然后再将其以形式化方式表示出来。 使用调查表 制定调查表 分析 建立原型 界面 执行过程,.,29,场景分析,分析员与项目相关人员共同识别出情景，并捕获这些情景的细节。 把细节加入到一个纲要的需求描述中时，情景特别有用 情景是对交互实例片断的描述，每个情景可能包含一个或多个交互，它们能在不同的细节层次上提供不同类型的情景信息 情景开始于一个框架，在导出过程中，细节被逐渐增加，直到产生交互的一个完整的描述,.,30,情景,一个情景可能包括如下内容： 在情景开始部分有一个系统状态描述； 一个关于标准事件流的描述； 一个关于哪儿会出错，以及如何处理错误的描述； 有关其他可能在同一时

14、间进行的活动的信息； 在情景完成后系统状态的描述,.,31,实例分析：出卷系统,用户： 教师：关注如何出一份合理的试卷，并能根据样式打印与输出。 学生：关注如何通过生成一些模拟试题，并在线学习和检查学习结果。 题库维护人员：关注试题的添加、更新和删除等工作。 视点： 教师关注自动出卷、手工出卷、试卷编辑和试卷输出。 学生关注随时抽卷、联系试卷和评价分析。 题库维护人员关注试题管理。,.,32,出卷系统的功能需求,自动出卷：系统根据教师的要求自动生成一份合理的试卷。 手动出卷：教师手动从候选的试题中挑选题目。 随机抽卷：系统随机抽取试题生产一份试卷。 在线练习：学生可以在线做练习和查看答案。 在

15、线评价：系统在线评价学生练习的情况。 试题管理：管理人员维护题库中的试题。 试卷编辑：更新试题。 试卷输出：根据某个样式输出试卷。,.,33,实例分析： POS机系统,收银员：能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水众扣除。 售货员：自动更新销售提成。 顾客：希望以最小代价完成购买活动并得到快速服务。便捷、清晰地看到所输入的商品项目和价格。得到购买凭证，以便退货。 公司：希望准确地记录交易，满足顾客要求。确保记录了支付授权服务的支付票据。有一定的容错性。能够自动、快速地更新记帐和库存信息。 经理：能够快速执行超控操作，并易于更正收银员的不当操作。 支持授权服务：依据

16、正确的通信格式进行授权服务。 库存系统：正确的方式更新库存信息。 记账系统：能够准确地记录每次销售支付信息。,.,34,POS机系统主要功能需求,处理销售：收银员完成一次销售记录，并出具票据和更新库存系统和帐务系统。 处理支付：完成一次销售对应的支付，包括现金支付，信用卡支付和支票支付。 处理退货：根据顾客请求完成商品退货处理。 办理会员卡：注册、注销和更新会员记录。,.,35,实例分析：图书馆系统,图书馆系统的共利益者与视点有： 图书流通管理：负责图书借还工作。 用户：希望快速得到借书，还书服务，能够续借、预约图书，以及查询个人和图书信息。 编目管理员：负责图书的管理、用户管理和处理罚金等。

17、,.,36,图书馆系统的主要功能需求,图书借出：管理员完成一次借书过程。 图书归还：管理员完成一次还书过程。 图书预约：用户查询要借的图书，若不能借，可预约该图书。 图书续借：用户可以将图书的归还日期延长一段时间。 图书管理：添加新书。更新图书馆信息，销毁图书。 用户管理：注册新用户，更新用户信息，注销用户。 处理罚金：用户缴纳罚金吼，系统将罚金数额清零。,.,37,实例分析：短信系统,本系统共利益者和视点有： 收发人员：负责发送短信给用户或接受用户的短信。 用户管理：添加用户，更新用户信息，删除用户。 本系统主要功能需求有： 短信发送：填写发送内容，选择发送用户，并指明是否要回执，然后发送短

18、信。（通过无线终端或短信网关） 短信接收：从无线终端或短信网关读取短信内容，并显示查看。 用户管理：添加新用户，更新用户信息，删除用户。,.,38,实例分析： ATM系统,银行客户:接受系统服务； 银行的代表:银行间自动柜员机有互惠协议； 支行管理者:从该系统中获得管理信息； 支行柜台职员:负责系统日常运转和处理客户意见； 数据库管理者:负责系统和客户数据库集成； 银行信息安全管理者:负责保证系统信息安全； 银行市场开发部:将该系统视为银行市场开拓手段； 硬件和软件工程师:负责硬件和软件维护及升级。,.,39,ATM系统主要功能需求,存款：从ATM机上存钱到指定账户上。 取款：从指定账户上取一

19、定数量的货币。 转账：从一个账户取出一定数量的货币，然后转存到另一个账号上。 查询余额：察看指定账户的余额。 修改密码：修改账户密码。,.,40,小结,需求分析也称为需求工程，是一个非常重要而有很复杂的，需要交替进行，反复迭代的过程。 软件需求分为功能需求和非功能需求。功能需求描述系统所预期提供的服务，而非功能需求描述与系统不直接相关的一些需求。 领域需求是一种特有的功能需求，反应应用领域的基本问题。 软件需求规格说明文档描述了系统的数据、功能、行为、性能需求、设计约束、验收标准以及其他于需求相关的信息，它有可能成为客户与开发商之间的合同。 需求分析过程通过执行初步沟通、需求导出、分析与精化、

20、可行性研究、协商和沟通、规格说明、验证和变更管理八个不同的活动来完成。 非形式技术主要包括会谈、调查表和场景技术，用于获取用户需求和系统需求。,.,41,第6章 结构化分析建模,分析模型元素 结构化需求分析 面向数据的建模方法 案例分析,.,42,结构化分析建模,需求分析的任务就是准确地指出“软件目标产品必须做什么？” 需求分析的一个重要过程就是需求建模的过程 结构化分析方法是一种传统的系统建模技术,.,43,分析模型,分析模型的目的是为基于计算机系统提供必须的信息、功能和行为域的说明 模型是对系统某个方面的抽象，抛弃了具体细节，对系统中最突出的特征作简化 分析模型元素： 基于场景的元素 基于

21、过程的活动序列的元素 基于类的元素 行为元素 面向信息流的元素 基于数据的元素,.,44,分析模式,分析模式：在软件开发领域，在特定的应用领域内某些事物在所有的项目中重复发生。 分析模式可以使用标准的模板来表现，模板采用模式名、目的、动机、外因和环境、解决方案、结论、设计、已知应用和相关模式的格式描述分析模式信息。 例如，ERP（Enterprise Resource Plan）软件就是一个高层分析模式，形成一套开发ERP软件的分析模式。,.,45,分析模型的目标与原则,分析模型必须实现三个主要目标： 描述客户需要什么； 为软件设计奠定基础； 定义在软件完成后可以被确认的一组需求。 分析模型的

22、所有元素都可以直接映射到设计模型 创建分析模型时应遵循的原则： 模型应关注在问题或业务域内可见的需求，抽象的级别相对高； 分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解； 基于基础机构和其他非功能的模型应推延到设计阶段再考虑； 最小化整个系统内的关联； 确认分析模型为所有共利益者都带来价值； 尽可能保持模型简洁,.,46,结构化需求分析,用户需求一般用自然语言描述 系统需求必须用较专业的方式来描述 模型是软件设计的基础，也是创建规约的基础 需求分析原则： 必须表示和理解问题的信息域； 必须定义软件将完成的功能； 必须表示软件的行为（作为外部事件的结果

23、）； 必须划分描述信息、功能和行为的模型，从而使得可以以层次的方式揭示细节； 分析过程应该从要素信息移向细节实现。,.,47,结构化分析方法,结构化分析（SA，Structured Analysis）方法是20世纪70年代，由E.Yourdon等人倡导的一种适用于大型数据处理系统的、面向数据流的需求分析方法。 结构化需求分析方法指导性原则： 在开始建立分析模型之前先理解问题。 开发模型，使用户能够了解将如何进行人机交互（使用原型技术）。 记录每个需求的起源和原因，保证需求的可追踪性和可回溯性。 使用多个需求分析视图，建立数据、功能和行为模型。 给需求赋予优先级，优先开发重要的功能，提高开发生产

24、效率。 删除含糊性。,.,48,结构化分析模型,系统模型从以下不同的角度表述系统： 从外部来看，它是对系统分析上下文或系统环境建模； 从行为上看，它是对系统行为建模； 从结构上看，它是对系统的体系结构和系统处理的数据结构建模。 结构化的需求分析模型有： 系统行为模型： 数据流模型，用来描述系统中的数据处理过程 状态转换模型，用来描述系统如何对事件做出响应 实体关系模型：关心的是寻找系统中的数据及其之间的关系，却不关心系统中包含的功能。,.,49,结构化分析模型结构,.,50,结构化分析模型结构,分析模型结构的核心是数据字典（DD，Data Dictionary），包含了软件使用或生产的所有数据

25、对象描述的中心库。 分析模型结构的中间层有三种视图： 数据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。 实体关系图（E-RD，Entity-Relationship Diagram）描述数据对象间的关系，用来进行数据建模活动的记号。 状态转换图（STD，State Transition Diagram）指明作为外部事件的结果，系统将如何动作。 分析模型结构的外层是规约描述： 在实体关系图中每个数据对象的属性可以使用数据对象来描述。 在数据流图中出现的每个加工/处理的功能描述包含在加工规约中。 软

26、件控制方面的附加信息包含在控制规约中,.,51,面向数据的建模方法,系统建模的一个重要方面就是要定义系统处理的逻辑结构。 最广泛采用的数据建模技术是实体-关系模型，它描述数据实体、关联及实体属性。 实体关系模型可用ERD（Entity-Relationships Diagram实体关系图）来表示： 实体 关联 实体属性 基数,.,52,实例分析：出卷系统,.,53,实例分析：出卷系统,试卷由一组题目组成，而题目来自试卷库中被挑选的题目。试卷根据出卷要求选择项目。这些实体的属性给出如下： 试题：编号、科目、题干、题干图、答案、答案图、题型、知识点、难度、抽取时间 试卷：编号、科目、出卷人、年级、

27、性质、总分、难度、题目* 出卷要求、总分、总难度、总题型、总知识点 题目：编号、题干、题干图、答案、答案图、题型、知识点、难度,.,54,实例分析：图书馆系统,.,55,实例分析：图书馆系统,实体：图书、借书者、管理员、借书目录、预约记录、书目 属性给出如下： 借书者：借书者编号、姓名、性别、借书数、最大借书数、罚金金额、有限期 图书：图书号、书目号 书目：书目号、书名、作者、出版社、丛书名、收藏数、在馆数、预约数 借书记录：图书号、借书者编号、借出日期、应还日期、续借次数 预约记录：书目号、借书者编号、预约日期,.,56,实例分析：POS机系统,.,57,实例分析：POS机系统,实体有销售、

28、支付、商品、商品描述 关联： 销售包含一组商品； 每个商品都有相应的描述信息； 每个支付对应一个销售。 实体的属性： 销售：编号、总价、1商品*，日期 支付：编号、支付客户、找零、销售编号 商品：编号、数量 商品描述：名称、产地、厂家、单价,.,58,面向数据流的建模,面向数据流的建模是结构化需求分析方法之一 采用自顶向下逐层分解，描绘满足用户要求的软件模型 表示： 数据流图：描述系统处理过程 数据字典：模型中的数据信息集合 状态转换图：描述系统对内部或外部事件响应的行为模型,.,59,数据流图符号,.,60,数据流图举例,设一个工厂采购部每天需要一张定货报表。定货的零件数据有：零件编号、名称

29、、数量、价格、供应者等。零件的入库、出库事务通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。 数据流分析： 数据源点：仓管员（负责入库或出库事务给定货系统）； 数据终点：采购员（接收每天的定货报表）； 数据流：事务，定货； 数据存储：定货信息，库存清单； 处理：处理事务，产生报表。,.,61,数据流图举例,画基本系统模型,.,62,数据流图举例,第一步求精,.,63,数据流图举例,第二步求精,.,64,数据字典,数据字典是分析模型中出现的所有名字的一个集合，并包括有关命名实体的描述 数据字典有以下两个作用： 它是所有名字信息管理的有效机制 作为连接软件分

30、析、设计、实现和进化阶段的开发机构的信息存储 数据字典应该由四类元素的定义组成： 数据流 数据流分量 数据存储 处理 对于处理，可用输入处理输出（IPO，Input-Process-Output）视图描述更方便,.,65,数据字典,应对组成的数据元素定义进行自顶向下的分解。 分解的原则是：当包含的元素不需要进一步定义，且每个和工程有关的人都清楚时为止 数据字典中应该包括关于数据的信息： 一般信息（名字、别名、描述等） 定义（数据类型、长度、结构等） 使用特点（值的范围、使用频率、使用条件、使用方式、条件值等） 控制信息（用户、使用特点、改变数、使用权等） 分组信息（文档结构、从属结构、物理位置

31、等） 三种类型的任意组合定义数据字典中的任何条目。 顺序：顺序连接两个或多个分量元素。一般用加号表示顺序连接关系。 选择：从两个或多个可选的分量元素中选取一个。选择运算符用方括号表示，对于多个可供选择的元素，用“|”符号分隔。例如，A-1 | A-2 | A-3 表示三个可选数据元素。 重复：描述的分量元素重复零次或多次。例如， 都表示数据元素A的下限为1，上限为5。,.,66,数据字典卡片方式示例,.,67,状态转换图,状态模型是一种描述系统对内部或者外部事件响应的行为模型。 它描述系统状态和事件，以及事件引发系统在状态间的转换。 这种模型适用于描述实时系统 状态模型一般采用状态转换图（简称

32、状态图）的标记方法 状态图描述了系统中某些复杂对象的状态变化 状态是可观察的行为模式，用圆角矩形表示； 变迁表示状态的转换，用箭头表示； 事件是引发变迁的消息，用箭头上的标记表示。 状态图还可以用事件后的方括号表示先决条件，只有当这个条件为真时，才会发生状态变化；用状态自身的弧线箭头表示先决条件不为真时，状态不会改变。,.,68,复印机控制软件状态图,.,69,加工逻辑的描述,加工逻辑也称为过程说明，用于描述数据流图中加工逻辑的处理算法或过程 用以下三种工具： 过程描述语言（PDLProcedural Description Language） 判定表 判定树,.,70,过程描述语言,介于自然

33、语言和形式语言之间的一种半形式语言，使用有限的词汇和有限的语句来描述加工逻辑。 它的结构可分成两层： 外层：用来描述控制结构，采用顺序、选择、重复三种基本结构。 内层：一般采用祈使语句的自然语言短语，使用数据字典中的名词和有限的自定义词,.,71,举例,统计空格 seq 打开文件 读入字符串 Totalsum = 0 程序体 iter until文件结束 程序体end 印总数seq 印出空格总数 印总数end 关闭文件 停止 统计空格end,.,72,判定表,例如：某数据流图中有一个“确定保险类别”的加工，指的是申请汽车驾驶保险时，要根据申请者的情况确定不同的保险类别。 加工逻辑为： 如果申请

34、者的年龄在21岁以下，要额外收费； 如果申请者是21岁以上并是26岁以上的女性，适用于A类保险； 如果申请者是26岁以下的已婚男性，或者26岁以上的男性，适用于B类保险； 如果申请者是21岁以下的女性或26岁以下的单身男性适用于C类保险； 除此之外的其他申请者都适用于A类保险。,.,73,判定表,提取问题中的条件：年龄、性别、婚姻。 标出条件的取值,.,74,判定表,计算所有条件的组合数N。N= =322 提取可能争取的动作或措施。适用于A类保险、B类保险、C类保险，额外收费共四种。 制作判定表 完善判定表 缺少判定采取的动作 有冗余的列,.,75,制作判定表,.,76,合并后的判定表,.,7

35、7,判定树,判定树是判定表的变形，一般情况下它比判定表更直观，且易于理解和使用,.,78,出卷系统：总体数据流图,.,79,出卷系统：自动出卷数据流图,.,80,出卷系统：手动出卷数据流图,.,81,出卷系统的实体-关系图,.,82,数据字典举例,名称：试卷 别名：无 描述：试卷信息 定义：试卷=试卷编号+课程名+出卷人+时间+总分+难度+试题 试卷编号=1字符串10 课程名=1字符30 出卷人=1字符8 时间=日期 总分=整数,.,83,数据字典举例,名称：出卷要求 别名：要求 描述：出卷的卷面要求 定义：出卷要求=总分+总难度+总题型+总知识点 总分=整数 总难度=难分数比例+中分数比例+

36、易分数比例 总题型=1题型分数比例* 总知识点=1知识点分数比例* 位置：自动出卷，手动出卷，设置出卷要求,.,84,数据字典举例,名称：试题 别名：题目 描述：题库中的题目 定义：试题=试题编号+题干+题干图+答案+答案图+题型+难度+知识点+抽取时间 试题编号=1字符10 题干=1字符200 题干图文件名=30字符40 答案=1字符200 答案图文件名=30字符40 题型=【|选择|填空|简答|改错|应用|】 难度=【|难|中|易|】 知识点=【|】 抽取时间=日期 位置：自动出卷，手动出卷，题库系统,.,85,图书馆系统,.,86,图书馆系统,.,87,图书馆系统实体关系图,.,88,图

37、书馆系统数据字典,.,89,小结,分析模型帮助用户逐层深入理解问题，为软件设计提供基础。 分析建模的元素有基于场景的用例建模、基于过程的活动序列建模、基于类的建模、行为建模、基于信息流的建模和基于数据的建模。 结构化分析方法是一种自顶向下，逐步分解的面向数据和数据流的建模方法。 面向数据的建模以实体、关系和属性三个基本元素描述系统，涉及数据及其它们之间的关系，用ERD表示。 基于数据流的方法用于描述数据如何在系统中流动或被变换，用数据流图、数据字典、加工规程等形式表示。,.,90,第7章 面向对象分析,面向对象建模 用例模型 领域模型 行为模型 案例分析,.,91,面向对象分析,面向对象分析（

38、OOA，Object-Oriented Analysis）是一种半形式化的规格说明技术。 目前，最流行的技术是OMT和Booch开发技术 面向对象的最大特点是面向用例 在用例的描述中引入了外部角色的概念,.,92,面向对象建模,面向对象模型 对象模型：定义了“做什么”的实体 动态模型：规定在何种状态下，接受什么事件的触发而“做什么” 功能模型：指明了系统应该“做什么”,.,93,对象模型,对象模型可以看成是数据流和语义数据模型的结合 对象模型表示静态的、结构化系统的“数据”性质。 它是对模拟客观世界实体的对象，以及对象彼此间的关系的映射，描述了系统的静态结构。 对象模型是一个类（包括其属性和行

39、为）、对象（类的实例）、类和（或）对象之间关系的定义集。 类名是一类对象的抽象命名，其命名是否恰当对系统的可理解性影响相当大。 对象模型还必须表示类/对象之间的结构关系。类/对象之间的关系一般可概括为关联、归纳（泛化）、组合（聚集）三类。,.,94,动态模型,动态模型表示瞬间的、行为化的系统“控制”性质，它规定了对象模型中对象的合法变化序列。 对象运行周期中的阶段就是对象的状态。 对象状态是对对象属性的一种抽象。 对象之间相互触发/作用的行为（称为事件），引起了一系列的状态变化。 事件是某个特定时刻所发生的一个系统行为，它是对引起对象从一种状态转换到另一个状态的现实世界事件的抽象。 对象对事件

40、的响应，取决于接受该触发的对象当时所处的状态，其响应包括改变自己的状态，或者是形成一个新的触发行为（事件）。 动态模型描绘了对象的状态，触发状态转换的事件，以及对象行为（对事件的响应）。,.,95,功能模型,功能模型表示变化的系统的“功能”性质，指明了系统应该“做什么”。 它更直接地反映了用户对目标系统的需求。 面向对象是以用例驱动的。用例站在用户的角度描述用户的交互过程，有助于软件开发人员更深入地理解问题域，改进和完善自己的分析和设计。 对象模型、动态模型和功能模型相辅相承，使得对系统的需求分析和设计描述更加直观、全面。 对象模型是最基本、最重要的，它为其他两种模型奠定了基础。,.,96,统

41、一建模语言UML,统一建模语言（UML，Unified Modeling Language）是一种基于面向对象的可视化建模语言。 UML用丰富的图形符号隐含表示了模型元素的语法，而用这些图形符号组成元模型表达语义，组成模型描述系统结构（或称为静态特征）以及行为（或称为动态特征）。 UML的模型元素： 一类模型元素用于表示模型中的某个概念，如类、对象、用例、结点、构件、包、接口等； 另一类模型元素用于表示模型元素之间相互连接的关系，主要有关联、泛化（表示一般与特殊的关系）、依赖、聚集（表示整体与部分的关系）等。,.,97,UML模型元素,.,98,UML模型结构,四个抽象层次： 元元模型：定义了

42、描述元模型的语言 元模型：定义了元类、元属性、元操作等一些概念 模型：定义了描述信息领域的语言 用户模型：模型的实例，用于表达一个模型的特定情况,.,99,UML模型视图,UML主要是用来描述模型的。它可以从不同视角为系统建模，形成不同的视图（View）。每个视图是系统完整描述中的一个抽象，代表该系统一个特定的方面；每个视图又由一组图（Diagram）构成，图包含了强调系统某一方面的信息。 两类图： 静态图：包括用例图、类图、对象图、构件图和部署图 动态图：包括状态图、时序图、协作图和活动图 五种视图： 用例视图从用户角度表达系统功能； 结构视图主要使用类图和对象图描述系统静态结构； 行为视图

43、展示系统动态行为及其并发性； 实现视图展示系统实现的结构和行为特征； 部署视图展示系统的实现环境和构件是如何在物理结构中部署的,.,100,用例建模,需求捕获的目标： 发现真正的需求 以适用于用户、客户和开发人员的方式加以表示 系统用户表示为一个参与者 参与者在与用例进行交互时使用系统 用例向参与者提供某些有价值结果而执行一些动作序列,.,101,编写用例,用例着眼于为用户增加价值，提供了一种捕获功能需求的系统且直观的方法，可驱动整个开发过程。 用例从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景。 要开始开发用例，应列出特定参与者执行的功能或者活动。 用例模型帮助客户、用户和开发

44、人员在如何使用系统方面达成共识。 用例图描述部分用例模型，显示带有联系的用例和参与者的集合,.,102,POS机系统部分用例图,.,103,用例图,用例图包括：参与者、用例、关联和边界四个要素。 参与者：用小人形表示 用例：用椭圆表示 关联：用直线表示说明参与者驱动某个用例 边界：用矩形框表示，说明系统关注点。,.,104,开发用例,用例使用非正式的描述性风格编写，也可以使用某个结构化的格式编写，有些格式更强调描述的直观性。,.,105,POS机系统中处理销售的场景,用例名称：处理销售 范围：POS机应用 级别：用户目标 主要参与者：收银员 涉众及其关注点： 收银员：希望能够准确、快速地输入，

45、而且没有支付错误，因为如果少收货款，将从其薪水众扣除。 售货员：希望自动更新销售提成 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。 公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即便在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。希望能够自动、快速地更新帐户和库存信息。 经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。 前置条件：收银员必须经过确认和认证。 成功保证（或后置条件）：存储销售信息，更新帐户和库存信息，记录提成，生成票据，记录支付

46、授权的批准。,.,106,主成功场景,1.顾客携带所购商品或服务到收银台通过POS机付款。 2.收银员开始一次新的销售交易。 3.收银员输入商品条码。 4.系统逐步记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。 5.系统显示总额和计算折扣。 6.收银员告知顾客总额，并请顾客付款。 7.顾客付款，系统处理支付。 8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。 9.系统打印票据。 10.顾客携带商品和票据离开。,.,107,开发活动图,UML活动图通过提供特定的场景内交

47、流的图形化表示来补充用例。 活动图符号： 两端为半圆形的矩形表示一个特定的系统功能 箭头表示通过系统的流 判定菱形表示判定分支 水平线、分叉点和连接表示并发活动 对象节点表示活动对象 活动图通常能够既表示控制流又表示数据流。 UML活动图代替传统的数据流图（Data Flow Diagram）表示法,.,108,处理销售用例中的UML活动图,.,109,泳道图,UML泳道图（swimlane）是活动图的一种有用的变形 可以让建模人员表示用例所描述的活动图，同时看哪个参与者或分析类对活动矩形所描述的活动负责。 泳道用纵向分割图的并列条形部分表示，就像游泳池中的泳道，也称特定分区。 UML泳道图通

48、常对于涉及众多参与者的非常复杂的业务过程建模具有价值。,.,110,泳道图举例,.,111,建立领域模型,领域模型能捕获语境中最重要的对象模型，领域对象代表系统工作的环境中存在的事情或发生的事件。 领域有三种典型的形式： 业务对象，表示业务中可操作的东西，例如订单、帐户和合同等。 系统需要处理的现实世界中的对象和概念，如导弹、轮船等。 将要发生或已经发生的事件，例如飞机起飞或午餐休息等。 领域建模的目的是理解和描述在领域语境中最重要的类,.,112,识别分析类,领域模型实际上是更为完整的业务模型的一个特例 有两种类型的UML模型支持业务建模： 用例模型 对象模型 对系统开发的用例或处理叙述进行

49、“语法分析”，可以开始分析类的识别。,.,113,分析类识别方式,外部实体：使用基于计算机的系统的信息。 事物：问题信息域的一部分。 发生或事件：在系统操作环境内发生。 角色：由和系统交互的人员扮演。 组织单元：和某个应用相关。 场地：建立问题的环境和系统的整体功能。 结构：定义了对象的类或与对象相关的类。,.,114,分析类,分析类侧重于处理功能性需求 通过较高的、非形式化层次的职责类定义某行为 分析类三种基本构造型： 边界类：边界类用于建立系统与其参与者之间交互的模型，经常代表对窗口、窗体、窗幕、通信接口、打印机接口、传感器、终端以及API等的抽象。每个边界类至少应该与一个参与者有关，反之

50、亦然。 控制类：控制类代表协调、排序、事务处理以及其他对象的控制，经常用于封装与某个具体用例有关的控制。控制类还可以用来表示复杂的派生与演算，如业务逻辑。 实体类：实体类用于对长效持久的信息建模。大多数情况下，实体类是直接从业务对象模型中相应的业务实体类得到的。,.,115,分析类举例,.,116,控制类,控制类类似于设计模型中的控制器类，其目的是UI层之上的第一个对象，主要负责接收和处理系统操作消息。把职务分配给能代表以下选择之一的类： 代表整个“系统”、“根对象”、运行软件的设备或主要子系统，这些是外观控制器的所有变体。 代表用例场景，在该场景中发生系统事件，通常命名为UsecaseNam

51、e+Handler、UsecaseName+Coordinator或UsecaseName+Session。,.,117,控制类举例,.,118,用例实现分析,用例实现分析是分析模型内部的一种协作，主要描述了如何根据分析类及其交互的分析对象来实现和执行一个具体的用例。 用例实现包括事件流的文本描述、反映参与者用例实现的分析的类图以及按照分析对象的交互作用描述特定流实现或用例脚本的交互图。 用例实现侧重于功能性需求。,.,119,处理销售类图,.,120,交互图,当参与者向系统发送某种形式的消息而激活用例时，开始执行该用例中的动作序列。 边界类对象将接收来自参与者的消息。 边界对象向其他对象发送

52、一个消息，并使有关对象与之交互从而实现该用例。 在分析阶段，通常使用协作图类描述用例的实现。 协作图又称为通信图，是以图或网络格式描述对象交互，其中对象可以置于图中任何位置。,.,121,.,122,处理销售协作流的事件-分析流,收银员通过处理销售商品界面发起一次销售，控制类创建一个销售类，收银员逐个输入商品，销售类创建商品，并放入销售列表中。控制类要求计算商品总价，收银员请求顾客付款，控制类委派销售类创建一个支付。,.,123,分析包,分析包描述了对分析模型的制品进行组织的方式，它可以包括分析类、用例实现及其他分析。 分析包应是有强内聚性与低耦合性，具有以下特点： 分析包可以表示对分析内容的

53、分割。 在统一过程中，服务的概念是由服务包支持的。服务包在按照系统提供的服务而组织的分析包层次结构中处于较低层。服务包包含了一组活动相关的类，服务包不可分割。 在实现用例时，可能会有一个或多个服务包参与其实现。服务包相对独立，可以复用。 UML包图用于描述系统的逻辑架构层、子系统、包等。 UML包用一大一小两个矩形组合而成。如果内部显示了其成员，则包名称标在上面的小矩形内，否则，可以标在包内。,.,124,UML包图,.,125,逻辑架构,逻辑架构是类的宏观组织结构，它将类组织为包、子系统和层等。 层是对类、包或子系统的甚为粗粒度的分组，是有对系统主要方面加以内聚的职责。,.,126,分层逻辑

54、架构,.,127,关联与依赖,两个分析类以某种方式相互联系，这些联系被称作关联。 关联可进一步指出多样性，也称为基数。 两个分析类之间存在客户服务器联系，客户类在某些方面依赖于服务器类并且建立了依赖关系。,.,128,识别属性和操作,属性描述类的性质，可以通过分析该类存在的一些信息类构建。 操作定义了某个对象的行为。 操作可以分为四种类型： 以某种方式操纵数据，例如：添加、删除、选择、更新等。 执行计算的操纵，例如：销售中的计算总价。 请求某个对象状态的操作。 监视某个对象发生某个控制事件的操作。 操作的构造需要交互图和场景描述等手段多次反复分析才能获取。在研究语法分析并分离动词作为候选的操作

55、。推荐的一个方法是使用CRC技术。,.,129,CRC技术,CRC(Class-Responsibility-Collaborator,类-职责-协作者)建模提供识别和组织与产品相关的类。 一旦系统的基本使用场景（用例）确定后，则要标识侯选类，指明它们的责任和协作，即类-责任-协作者建模： 责任是与类相关的属性和操作，即责任是类知道要做的事情。 协作者是为某类提供完成责任所需要的信息的类，即协作类。 CRC建模方法提供了一种简单标识和组织与系统或产品需求相关的类的手段。 CRC模型是一组表示类标准的索引卡CRC卡的集合。 CRC卡的内容分成三个部分： 类的名字 类的责任 协作类,.,130,销

56、售类CRC卡,.,131,行为建模,行为模型显示了软件如何对外部事件或激励做出响应。要生成行为模型，分析师必须按如下步骤进行： 评估所有的用例，以使得完成理解系统内的交互序列。 识别驱动交互序列的事件，并理解这些事件如何和具体的类相互关联。 为每个用例生产序列。 创建系统状态图。 评估行为模型以验证准确性和一致性。,.,132,系统顺序图,系统顺序图（System Sequence Diagram,SSD）是为了阐述与讨论系统相关的输入和输出事件而快速、简单地创建的制品。 它们是操作契约和重要对象设计的输入。 用例文本及其所示的系统事件是创建SSD的输入。 SSD展示了直接与系统交互的外部参与

57、者，系统以及由参与者发起的系统事件。 SSD可以用UML顺序图的形式表示，用以阐述外部参与者到系统的事件。 系统事件就是将系统看作黑盒，参与者为完成功能而向系统发出的事件。,.,133,处理销售用例的系统SSD,.,134,操作契约,操作契约使用前置条件和后置条件的形式，详细和精确描述领域模型中的对象的变化，并作为系统操作的结果。 操作契约的主要输入是SSD中确定的系统操作、领域模型和领域专家的见解。 操作契约四部分： 操作是指操作的名称和参数 交叉引用是指会发生此操作的用例 前置条件是指执行操作之前对系统领域模型对象状态的假设 后置条件是指完成操作后，领域模型对象的状态,.,135,后置条件

58、,后置条件（Post Condition）描述了领域模型内对象状态的变化。 领域模型状态变化包括创建用例、形成或消除关联以及改变属性。 后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果。 后置条件可以分为三种类型： 创建或删除实例 属性值的变化 形成或消除关联,.,136,操作enterItem的契约,操作名称：enterItem(id,quantity) 交叉引用：处理销售用例 前置条件：正在进行的销售 后置条件： （1）创建了SaleLineItem的实例（创建关联） （2）SaleLineItem与当前Sale关联（形成关联） （3）SaleLineItem.quantity赋值为quantity(修改属性) （4）基于id匹配，将SaleLineItem关联到Product Descr