《软件工程 教学课件 ppt 作者 张海藩 第三章》由会员分享，可在线阅读，更多相关《软件工程 教学课件 ppt 作者 张海藩 第三章（50页珍藏版）》请在金锄头文库上搜索。
1、第二篇 传统方法学,第3章 结构化分析,为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提和关键，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会给用户带来失望，给开发者带来烦恼。 传统的软件工程方法学采用结构化分析(Structured Analysis ,SA)技术完成需求分析工作。,退出,3.1 概述 3.2 与用户通信的技术 3.3 分析建模与规格说明 3.4 实体关系图 3.5 数据流图 3.6 状态转换图 3.7 数据字典 3.8 小结,3.1 概述,需求分析是发现、求精、建模、规格说明和复审的过程。为
2、了发现用户的真正需求，首先应该从宏观角度调查、分析用户所面临的问题，也就是说，需求分析的第一步是尽可能准确地了解用户当前的情况和需要解决的问题。 分析员对用户提出的初步要求应该反复求精多次细化，才能充分理解用户的需求，得出对目标系统的完整、准确和具体的要求。,为了更好地理解问题，人们常常采用建立模型的方法。所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。结构化分析就是一种建立模型的活动，通常建立数据模型、功能模型和行为模型等三种模型。 除了用分析模型表示软件需求之外，还要写出准确的软件需求规格说明。模型既是软件
3、设计的基础，也是编写软件规格说明的基础。,在分析软件需求和编写软件规格说明的过程中，软件开发者和软件用户都起着关键的、必不可少的作用。 用户与开发者之间需要通信、沟通的内容非常多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。因此，不仅在整个需求分析过程中应该采用行之有效的通信技术，集中精力过细工作，而且对需求分析的结果(分析模型和规格说明)必须严格审查。,尽管目前存在许多不同的结构化分析方法，但是，所有这些分析方法都遵守下述准则。 必须理解和表示问题的信息域，根据这条准则应该建立数据模型。 必须定义软件应完成的功能，这条准则要求建立功能模型。 必须表示作为外部事件结果的软件行
4、为，这条准则要求建立行为模型。 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 分析过程应该从要素信息移向实现细节。,3.2 与用户通信的技术,软件需求分析总是从两方或多方之间的通信开始。用户面临的问题需要用基于计算机的方案来解决；开发者应该对用户的需求作出反应，给用户提供帮助。这样就产生了相互通信的需求。但是，正如前面已经讲过的，从开始通信到真正相互理解的道路通常是充满坎坷的。良好的通信技术有助于加快理解的过程。 3.2.1 访谈 访谈(或称为会谈)是最早开始运用的获取用户需求的技术，也是迄今为止仍然广泛使用的主要的需求分析技术。,访谈有两种基本形式，分别是正式的和非正式的
5、访谈。在正式的访谈中，系统分析员将提出一些事先准备好的具体问题，例如，询问客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等。在非正式的访谈中，将提出一些可以自由回答的开放性问题，以鼓励被访问的人员表达自己的想法，例如，询问用户为什么对目前正在使用的系统感到不满意。,当需要调查大量人员的意见时，向被调查的人员分发调查表是一个十分有效的做法。 在对用户进行访谈的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户运用目标系统解决某个具体问题的方法和结果进行分析。,3.2.2 简易的应用规格说明技术 这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案的要素，商讨不
6、同的方法并指定基本的需求。今天，简易的应用规格说明技术已经成为信息系统界使用的主流技术。 尽管存在许多不同的简易应用规格说明方法，但是它们遵循的基本准则是相同的。 在中立地点举行由开发者和用户双方出席的会议。 制定准备会议和参加会议的规则。, 提出一个议事日程，这个日程应该足够正式以便能够涵盖所有要点，同时这个日程又应该足够非正式，以便鼓励自由思维。 由一个“协调人”来主持会议，他既可以是用户也可以是开发者还可以是从外面请来的人。 使用一种“定义机制”(例如，工作表、图表等)。 目标是标识问题、提出解决方案要素、商讨不同的方法以及在有利于实现目标的氛围中指定初步的需求。,3.2.3 软件原型
7、构建原型的要点是，它应该实现用户看得见的功能(例如屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如修改文件)。 快速原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。,快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户的需求。在实际开发软件产品时，“修改试用反馈”的过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间。,3.3 分析建模与规格说明,3.3.1分析建
8、模 结构化分析实质上是一种创建模型的活动。通过需求分析而建立的模型必须达到下述的三个基本目标。 描述用户的需求。 为软件设计工作奠定基础。 定义一组需求，一旦开发出软件产品之后，就可以用这组需求为标准来验收该产品。 为了达到上述这些目标，在结构化分析过程中导出的分析模型的形式，如图3.1所示。,图3.1 分析模型的结构,3.3.2 软件需求规格说明 通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明，它是分析阶段的最终成果。下面给出的简略大纲可以作为软件需求规格说明的框架。 .引言 A .系统参考文献 B .整体描述 C .软件项目约束,.信息描述 A .信息内容 B .信息流 1
9、.数据流 2 .控制流 .功能描述 A .功能分解 B .功能描述 1 .处理说明 2 .限制 3 .性能需求 4 .设计约束 5 .支撑图,C .控制描述 1 .控制规格说明 2 .设计约束ZK) .行为描述 A .系统状态 B .事件和动作 .确认标准 A .性能范围 B .测试种类 C .预期的软件响应 D .特殊考虑 .参考书目 .附录,3.4 实体关系图,数据模型包含三种相互关联的信息：数据对象、描述数据对象的属性及数据对象彼此间相互连接的关系。 3.4.1数据对象 数据对象是对软件必须理解的复合信息的表示。所谓复合信息是指具有一系列不同性质或属性的事物，因此，仅有单个值的事物(例如
10、宽度)不是数据对象。,3.4.2 属性 属性定义了数据对象的性质。 应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。 3.4.3 关系 数据对象彼此之间相互连接的方式称为关系，也称为联系。 (1) 一对一联系(11) (2) 一对多联系(1N) (3) 多对多联系(MN) 联系也可能有属性。,3.4.4 实体关系图的符号 通常，使用实体关系图(EntityRelationship Diagram)来建立数据模型，从而可以满足31节中讲述的第一条分析准则。可以把实体关系图简称为ER图，相应地，用ER图描绘的数据模型也可以称为ER模型。 ER图中包含了实体(即数据对象)、关系和
11、属性等三种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用无向边把实体(或关系)与其属性连接起来。例如，图3.2是某学校教学管理的ER图。,图3.2 某校教学管理 ER 图,3.5 数据流图,当信息在软件中移动时，它将被一系列“变换”所修改。数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。 3.5.1 数据流图符号 如图3.3(a)所示，数据流图有四种基本符号：正方形(或立方体)表示数据的源点或终点；圆角矩形(或圆形)代表变换数据的处理；开口矩形(或两条平行横线)代表数据存储；箭头表示数
12、据流，即特定数据的流动方向。注意，数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。,图3.3 数据流图的符号,3.5.2 例子 下面通过一个简单例子具体说明怎样画数据流图。 假设一家工厂的采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据；零件编号、零件名称、定货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。 数据流图有四种成分：源点或终点、处理、数据存储和数据流。因此，画出上述定货系统的
13、数据流图可采用以下步骤。,从问题描述中提取数据流图的四种成分。 接下来考虑处理 最后，考虑数据流和数据存储 表3.1总结了上面分析的结果，其中加星号标记的是在问题描述中隐含的成分。,一旦把数据流图的四种成分都分离出来以后，就可以着手画数据流图了。任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。对于上述的定货系统可以画出如图3.4所示的基本系统模型。 从基本系统模型这样非常高的抽象层次开始画数据流图是一个好办法。在这个高层次的数据流图上是否列出了所有给定的数据源点/终点是一目了然的，因此它是很有价值的通信工具。,下一步应该把基本系统模型细
14、化，描绘系统的主要功能。 在图3.5中给处理和数据存储都加了编号，这样做的目的是便于引用和追踪。 接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。 当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入/输出数据流必须相同。,图3.4 定货系统的基本系统模型 (突出表明了数据的源点和终点),图3.5 定货系统的功能级数据流图,图3.6 把处理事务的功能进一步分解后的数据流图,3.5.3 命名 数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性，因此，给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题。 1为数据流(
15、或数据存储)命名 名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。 如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。,2为处理命名 通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。 名字应该反映整个处理的功能，而不是它的一部分功能。 名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。,3.6 状态转换图,状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。在状态图中用圆形框或椭圆框表示状态，通常在框内标上状态名。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态。
