javaee企业级项目开发蒋卫祥)电子资源javaee-单元1 任务2 软件需求分析

《javaee企业级项目开发蒋卫祥)电子资源javaee-单元1 任务2 软件需求分析》由会员分享，可在线阅读，更多相关《javaee企业级项目开发蒋卫祥)电子资源javaee-单元1 任务2 软件需求分析（38页珍藏版）》请在金锄头文库上搜索。

1、Struts2+Hibernate+Spring,JavaEE 企业级项目开发,单元一 项目分析与设计,任务2 软件需求分析,目录页,第1页,任务2 软件需求分析,过渡页,第2页,过渡页,任务简介,任务2 软件需求分析,任务简介,本任务主要： 学习软件需求分析的基本概念、操作步骤及常用工具； 分析了高校办公自动化管理系统的功能需求、非功能需求。,第3页,过渡页,第4页,过渡页,任务分析,任务2 软件需求分析,任务分析,需求分析是软件开发的关键过程，主要目的是解决“做什么”。 主要任务是确定系统功能需求、性能需求、可靠性与可用性需求等。 需求分析方法主要包括：结构化分析方法、面向对象分析方法。

2、结构化分析方法是面向数据流的方法，主要根据软件内部的数据传递、变换关系，自顶向下逐层分解。 面向对象分析方法按照面向对象的思想来分析问题。,第5页,任务2 软件需求分析,任务分析,UML是软件建模的一种工具，用例图是分析系统功能需求的重要工具。 业务流程图用一些规定的符号及连线来表示具体业务处理过程。 本任务通过UML用例图、业务流程图分析高校办公自动化管理系统的功能、性能等需求。,第6页,过渡页,第7页,过渡页,相关支撑知识,任务2 软件需求分析,相关支撑知识,“需求分析”，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。 主要工作：

3、深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。 具体包括： 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划,第8页,需求分析是做系统之前必做的,一需求分析简介,任务2 软件需求分析,相关支撑知识,第9页,一需求分析简介,任务2 软件需求分析,相关支撑知识,第10页,一需求分析简介,分析系统的数据要求，是软件分析的一个重要任务，通常采用建立数据模型的方法。 复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。 利用数据字典可以全面地定义数据，但是数据字典不够直观。为了提高可理解性，常常利用

4、图形化工具辅助描述数据结构。,任务2 软件需求分析,相关支撑知识,第11页,一需求分析简介,通常使用以下几种方式描述系统的逻辑模型： 数据流图 E-R图 状态转换图 数据字典 主要的处理算法,任务2 软件需求分析,相关支撑知识,第12页,一需求分析简介,在需求分析过程中，可以准确估计系统成本和进度，修正以前定制的开发计划,任务2 软件需求分析,相关支撑知识,结构化分析(简称SA )方法是面向数据流的需求分析方法，适合于分析大型的数据处理系统，特别是企事业管理系统。 SA 法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。,第13页,二

5、需求分析方法,分解 抽象,SA基本思想,任务2 软件需求分析,相关支撑知识,第14页,二需求分析方法,分解 指复杂的系统分解成若干小问题，然后分别解决。 自顶向下、逐层分解。顶层抽象地描述了整个系统，底层具体地画出了系统的每一个细节，而中间层是从抽象到具体的逐层过渡。,SA基本思想,缺点,抽象 分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容。,任务2 软件需求分析,相关支撑知识,第15页,二需求分析方法,建立当前系统的“具体模型”：即将当前系统用DFD 图描述出来 抽象出当前系统的逻辑模型：分析系统 “具体模型”，抽象出其本质的因素，排除次

6、要因素，获得用DFD 图描述的当前系统的“逻辑模型”。 建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，从而进一步明确目标系统“做什么”，建立目标系统的“逻辑模型”(修改后的DFD 图)。 为了对目标系统作完整的描述，还需要考虑人机界面和其他一些问题。,SA步骤,任务2 软件需求分析,相关支撑知识,第16页,二需求分析方法,分层的数据流图 数据词典 描述加工逻辑的结构化语言、判定表或判定树,SA描述工具,任务2 软件需求分析,相关支撑知识,数据流图(简称DFD)是描述系统中数据流程的图形工具，标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。,第17页,

7、二需求分析方法,SA基本思想,SA描述工具,箭头表示数据流，圆或椭圆表示加工。双杠或者单杠表示数据存储，矩形框表示数据的源点或终点，即外部实体。,任务2 软件需求分析,相关支撑知识,数据流是数据在系统内传播的路径，由一组固定的数据项组成。可从加工流向加工，也可从加工流向文件或从文件流向加工，也可从源点流向加工或从加工流向终点。 加工也称为数据处理，它对数据流进行某些操作或变换。每个加工要有名字，简明地描述完成什么加工。在分层的数据流图中，加工还应有编号。 数据存储指暂时保存的数据，可以是数据库文件或任何形式的数据组织。流向数据存储的数据流可理解为写入文件，或查询文件，从数据存储流出的数据可理解

8、为从文件读数据或得到查询结果。 数据源点和终点是软件系统外部环境中的实体(包括人员、组织或其他软件系统) 。一般只出现在数据流图的顶层图中。,第18页,二需求分析方法,SA描述工具,任务2 软件需求分析,相关支撑知识,面向对象分析方法（OOA），是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。 OOA与结构化分析区别： OOA强调在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。,第19页,二需求分析方法,OOA模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题

9、、定义属性和定义服务）组成。 定义了两种对象类之间的结构：分类结构是一般与特殊的关系；组装结构反映了对象之间的整体与部分的关系。,任务2 软件需求分析,相关支撑知识,第20页,二需求分析方法,OOA在定义属性的同时，要识别实例连接 实例连接是一个实例与另一个实例的映射关系。 OOA在定义服务的同时要识别消息连接 当一个对象需要向另一对象发送消息时，它们之间就存在消息连接。 OOA 中的5个层次和5个活动持续贯穿在OOD（面向对象的设计）过程中,任务2 软件需求分析,相关支撑知识,第21页,二需求分析方法,抽象：抽象原则包括过程抽象和数据抽象； 封装：把对象的属性和服务结合为一个不可分的系统单位

10、，并尽可能隐蔽对象的内部细节； 继承：特殊类和一般类； 分类：把具有相同属性和服务的对象划分为一类； 聚合：又称组装；,OOA主要原则,关联 ：通过一个事物联想到另外的事物； 消息通信：用消息连接表示出对象之间的动态联系； 粒度控制：考虑全局时，注意其大的组成部分，暂时不详察具体的细节；考虑某部分的细节时则暂时撇开其余的部分； 行为分析：行为复杂。,任务2 软件需求分析,相关支撑知识,第22页,二需求分析方法,三种分析模型,功能模型：即用例模型； 对象模型： 对用例模型进行分析，把系统分解成互相协作的分析类，通过类图/对象图描述对象/对象的属性/对象间的关系，是系统的静态模型。 动态模型 描述

11、系统的动态行为，通过时序图/协作图描述对象的交互，以揭示对象间如何协作来完成每个具体的用例； 单个对象的状态变化/动态行为可以通过状态图来表达。,任务2 软件需求分析,相关支撑知识,第23页,二需求分析方法,基本步骤,任务2 软件需求分析,相关支撑知识,用例图： 用来图示化系统的主事件流程，描述客户的需求； 用例就是软件的功能模块，是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系。,第24页,三UML 用 例 图,用例图包含： 用例 参与者 用例之间用关联来连接,任务2 软件需求分析,相关支撑知识,用例 是从系统外部可

12、见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。 用例之间关系： 都是独立、并列的，它们之间并不存在着包含从属关系； 但为体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出：包含(include)、扩展(extend)和泛(generalization)几种关系。,第25页,三UML 用 例 图,任务2 软件需求分析,相关支撑知识,第26页,三UML 用 例 图,使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基本用例复用。 基本用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基本用例的事件流中。 基

13、本用例可以依赖包含用例执行的结果，但双方不能访问对方的属性。,任务2 软件需求分析,相关支撑知识,第27页,三UML 用 例 图,将基本用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基本用例中声明的扩展点上进行扩展，从而使基本用例行为更简练和目标更集中。 扩展用例为基本用例添加新的行为 扩展用例可以访问基本用例的属性。,任务2 软件需求分析,相关支撑知识,第28页,三UML 用 例 图,子用例和父用例相似，但表现出更特别的行为； 子用例将继承父用例的所有结构、行为和关系。 子用例可以使用父用例的一段行为，也可以重载它，父用例通常是抽象的。,任务2 软件需求分析,相关支撑知识,用

14、例描述一般包括： 简要描述（说明） 前置（前提）条件 基本事件流 其他事件流 异常事件流 后置（事后）条件等等,第29页,三UML 用 例 图,任务2 软件需求分析,相关支撑知识,用例编号：例如：系统(QTP)+模块(JH)+顺序(001)= QTPJH001 用例名称 用例描述 执行者 过程描述 主过程描述 备选过程描述,第30页,三UML 用 例 图,业务规则 涉及的业务实体 前置条件：执行用例之前必须存在的系统状态。 后置条件：用例一执行完毕系统可能处于的一组状态。,任务2 软件需求分析,相关支撑知识,业务流程图（TFD）：用一些规定的符号及连线来表示某个具体业务处理过程。 是一种描述系

15、统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表，利用它可以帮助分析人员找出业务流程中的不合理流向，是物理模型。 业务流程图的绘制是按照业务的实际处理步骤和过程进行的。 业务流程图是一种系统分析人员都懂的共同语言, 用来描述系统组织结构、业务流程。,第31页,四业务流程图,任务2 软件需求分析,相关支撑知识,第32页,四业务流程图,任务2 软件需求分析,相关支撑知识,现行系统业务流程总结 在画业务流程图之前，要对现行系统进行详细调查，并写出现行系统业务流程总结。 业务流程图的绘制 根据系统业务流程的描述，绘制出系统处理业务流程图。,第33页,四业务流程图,任务2 软件需求分析,相关支撑知识,制作流程图的过程是全面了解业务处理的过程，是进行系统分析的依据； 是系统分析员、管理人员、业务操作人员相互交流思想的工具； 系统分析员可直接在业务流程图上拟出可实现计算机处理的部分； 可分析出业务流程的合理性。,第34页,四业务流程图,过渡页,第20页,过渡页,任务小结,任务2 软件需求分析,任务小结,能力目标,第21页,谢谢观看,