北京大学研究生课程《软件工程》.ppt

北京大学研究生课程 软件工程,教材： 软件工程 第二版 王立福，麻志毅，张世琨编著 北京大学出版社出版 辅助教材： Agile Software Development: Principle,Patterns,and Practices 2003年版 Robert C. Martin 期末成绩： 平时 30% 笔试 70%,课程内容： 1、软件工程概念 2、软件开发模型 3、系统建模技术-结构化方法 4、系统建模技术-面向对象方法 5、软件测试 6、软件过程与CMM简介 7、敏捷软件开发,为屏蔽计算机硬件的异构性，发展了操作系统,C/C+ 语言,Java 语言,支撑软件中间件,为屏蔽操作系统和编程语言的异构性，发展了支撑软件和中间件,Fortran 语言,为了祢补应用软件与现实计算环境之间的距离,应用系统,网 络 层,综观 软件技术 的发展,软件开发的本质,应用系统,概念不同，逻辑不同。 解决问题的思维逻辑 不同。 -“距离”,语 言,网络 异构,VB、VC -程序设计环境,中间件技术与产品,面向领域的软件体系结构,应用框架,领域软件生产线,系统建模,运行平台,开发平台,软件工程学科所要解决的问题,软件开发的本质 可概括为： 第一点： 问题空间的概念 与 解空间的模型化概念 之间的映射 例如：对象 = F（张山） （模型化概念） （问题空间的概念） 其中， 对应的过程：需求分析 使用的技术：面向对象 使用的原理：数据抽象 目的：作为计算的客体。,第二点：问题空间的处理逻辑 与 解空间处理逻辑 之间的映射 例如1： 加工1（及相关的数据流）=F（计算学生成绩） 其中：使用的方法：结构化方法； 对应的过程：需求分析 使用的原理：过程抽象,加工1 计算学生平均成绩,科目+年级/班,学生成绩文件,学生平均成绩,规约后的处理逻辑,例如2： 交互图1=H（计算学生成绩） 其中：对应的过程：需求分析 使用的方法：面向对象 使用的原理：行为结构抽象（简称行为抽象） 作用：实现计算,：教务员,：教员,递交A科学生成绩表,A科学生成绩表,：教学主任,求A科平均,A科平均,由于以上两个映射是由“人”完成的，因此 就软件开发而言，需要解决两个方面的问题： 1：管理 2：技术 进一步说，技术问题主要是指软件开发过程通常需 要遵循的途径和方向 其中，过程方向 确定用于创建问题模型和设计解的 特定的抽象层次 例如，需求、设计、实现、部署等,第一章、软件工程及软件工程框架 软件计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述；文档是为了便于了解程序所需的阐明性资料。 工程将理论和所学的知识应用于实践的科学。 软件工程应用计算机科学、数学及管理科学等原理，开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。其中，计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。 软件工程是一门交叉性学科。,软件工程框架,软件工程目标 生产具有正确性、可用性和开销合宜的产品。正确性是指软件产品达到预期功能的程度。可用性是指软件基本结构、实现以及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。 软件开发活动 生产一个最终满足需求且达到工程目标的软件产品所需要的活动。软件开发的基本活动包括：需求分析（requirement analysis），设计（design），实现（implementation），验证/确认（verification/validation）和维护（maintenance）。,（1）需求分析 是在一个抽象层上建立系统模型的活动。产生需求规约，作为开发人员和客户间契约的基础，并作为以后开发阶段的输入。 （2）设计 定义了实现需求规约所需的结构。包括软件体系结构（数据和程序结构），以及详细的处理算法，即所谓设计规约，给出了实现软件需求的软件解决方案。 （3）实现 是由设计规约到代码的转换。 （4）验证/确认是一评估活动，其中主要包括需求规约、设计规约以及实现代码的评估。验证/确认这一评估可以是动态的，或是静态的。在动态分析中，以选定的输入来执行程序或程序段，并与预期结果进行比较。静态分析是不执行程序的分析，例如模型评审、代码“走查”以及程序的形式化验证等。 （5）维护是在软件发布之后所进行的开发或修改（modification），包括对发现错误的修正以及对环境的变化所进行的必要调整等。,软件工程原则 围绕软件开发，提出了以下基本原则。 第一：选取适宜的开发范型 在系统设计中，经常需要权衡软件需求、硬件需求以及其它因素之间的相互制约和影响，适应需求的易变性。选用适宜的开发范型，以保证软件开发的可持续性，并使最终的软件产品满足客户的要求。 第二：采用好的设计方法 在软件设计中，通常需要考虑软件的模块化、信息隐蔽、局部化、一致性以及适应性等问题。采用合适的设计方法，支持这些问题的解决和实现。 第三条：提供高质量的工程支持 如其它工程一样，需要提供高质量的工程支持，例如配置管理、质量保证等，才能按期交付高质量的软件产品。 第四条原则：有效的软件工程管理 软件工程的管理，直接影响可用资源的有效利用，提高软件组织的生产能力。仅当对软件过程实施有效管理时，才能实现有效的软件工程。,小结： 1）软件工程框架：目标，原则，活动 给出了软件所涉及软件工程的工程要素 给出了各要素之间的关系 给出了软件工程学科所研究的主要内容 2）研究内容主要包括： 软件开发过程 软件开发方法 软件工程管理与支持 软件质量特征 软件过程度量以及CASE工具、环境等。,第二章、软件开发模型 1、软件开发模型 软件过程、活动、任务的结构框架。 瀑布模型 演化模型 增量模型 螺旋模型 喷泉模型 外征：软件开发活动的组织 内涵：求解软件的计算逻辑,分 析,编 码,（1）瀑布模型 50年代末：二级模型 “做什么” “编程-实现”,需求分析,设 计,编 码,测 试,运 行,瀑布模型雏型,系统需求,软件需求,需求分析,设 计,编 码,测 试,运 行,1970年，W.Royce 将雏型进一步精化 其中：每一阶段具有以下特征： 从上一阶段接受工作对象，即输入； 对这一输入实施本阶段的工作 给出本阶段的结果作为输出。,系统需求,软件需求,需求分析,设 计,编 码,测 试,运 行,瀑布模型 活动如瀑布流水式的组织 规定每一活动的工作对象和输出 评审、确认和反馈,问题：无法通过开发活动澄清 本来不确切的软件需求 维护、甚至返工的代价,需求,设计,编码,测试,集成,需求,设计,编码,测试,集成,开 发,反 馈,开 发,反 馈,.,核 心 系 统 开 发,第 二 次 迭 代,（2）演化模型 针对事先不能完整地定义需求 针对用户的核心需求,开发核心系统 根据用户的反馈,实施活动的迭代,1,3,2,5,9,10,11,6,7,12,13,8,4,增量1 1,2,5,9 增量2 3,6,7,4,10,11 增量3 8,12,13 ,管理,增量规约,增量设计,纠错性分析,增量实现,增量1,增量2,增量3,（3）增量模型,微软“同步-稳定的产品开发模型” 将项目分为若干个里程碑阶段 定义稳定、灵活的体系结构，并为构件 和子系统的开发提供统一的接口 开发构件，维持一个可发布的系统版本 可以准确把握项目进展情况 增强开发人员的信心和成就感 可以随时根据市场情况及时作出调整,演化,维护,确认,实现,设计,分析,喷泉模型 特征：迭代 无缝 与面向对象技术 的关系,第三章 系统建模技术-结构化方法 （一）结构化分析方法 要回答：如何定义问题？ 就如何定义问题而言，如何获得需求 如何规约需求 如何验证需求 1、关于需求获取 需求面临的挑战 问题空间理解 人与人之间的通信 需求的不断变化,1）需求目标 在任何一个设计中，精确地陈述问题总是第一步的。需求的目标是要简洁而精确地说明所要解决的问题。 为此： 软件人员的注意力应在做什么和为什么做，而不是如何做。 与用户和该领域的专家进行交流，导引出他们对软件产品的要求。 基于对用户要求的理解，结合计算机软件的特有能力，创造出对用户有价值的，能提高产品的质量与可用性的新的产品要求。 分析所定出的产品要求，判断其正确性，一致性，完整性及可行性； 决定解决方案，完成高层次的设计，确定出功能子系统及子系统之间的接口界面。 把产品要求以用户手册及工程设计技术要求的形式表达出来。（可能还包括测试的标准）。用于在开发的全过程中，验证核实所开发的产品确能满足用户的要求，支持技术文档的管理，更重要的是支持需求变化的管理。 可见，为了实现这一目标：需求(工程)包括需求的引出、创造、分析、表述、验核和管理。,2）需求工程的重要性 Standish-Group对350家公司的8000个软件项目作过一次调查 其中，31%的项目的结局是被取消。 引致这些项目失败的原因是： 13.1% 不完整的产品要求； 12.4% 缺乏用户的参与； 10.6% 缺少资源（人力、财力）； 9.9% 不现实的期望； 9.3% 高层领导支持不足； 8.7% 产品要求与指标的改变； 8.1% 没有订计划； 7.5% 不再需耍该开发中的系统。 其中，与产品需求有关的（1,2,4,和6项）占了44.1%。这些数据突出地显示了软件产品需求在软件开发中的重要性。,重要性之一 软件需求工程直接关系到“成本、质量和按时交付” 等问题-它们是项目成败的关键因素。 项目的五维：进度，特性，质量，成本，人员。 重要性之二 软件需求工程-这种发生在软件生命周期的初始阶段 的错误是非常难于改正，并且是代价极高的。 最新的研究兴趣聚焦于“需求引出”， 因为它涉及到 软件开发人员与非软件专业人员合作的问题。,3）需求工程的原则 （1） 抽象：抓住事物的本质（要素）。其中，一个重 要方面是：捕获问题空间的“一般/特殊”关系 是认识 、构造问题的一般途径。 （2） 划分：分离问题。其中，一个重要方面是：捕获问题空间的“整体/部分”关系 是降低问题复杂性的基本途径之一 （3）投影：捕获并建立问题空间的多维“视图” 是描述问题的基本手段之一 是解决“A是B，B是A”的基本方法 ,分析问题和需求的能力取决于分析人员的思维和经验。 思维来源于： 严谨、逻辑和“活跃”的思考习惯。 （1）严谨要求思考的对象应该是不放过任何一个“小” 问题 （2）逻辑要求思考的过程应该是一种符合规则的 推导过程 （3）活跃思维要求思考的方式应该是并行的，即 不是仅一个角度，而是多个角度来思考问题 经验来源于： （1）开发了一些软件并善于总结-创新与教训 （2）跟踪最新技术。,具体地说 （1）基础 软件人员必须先在一定程度上熟悉并学习软件所涉及的专业领域。程度的深浅，以满足工作的要求为目标。 软件人员要懂得如何帮助用户去表达出他们对产品的耍求。因为需求获取是一个交互的过程。 软件人员面对的用户是：他们不是计算机或软件的专业人员，他们不能完全清楚软件能带来一些什么新的功能可以帮助提高工作效率和提供新的服务，因此 必须在需求规约中包括用户对产品工作性能，可靠性，可维护性，可扩展性等的需求。 （2）表达 使用清楚而良构的语言完成需求规约。 必须完全用问题领域方面的词汇来表达,不应该出现软件领域内的词汇。通过浏览文档，能够完全理解所要解决的具体问题和该问题的一般性解决方案。,（3）做法 开始问题定义时，通常是建立一个词汇表。对于具有模糊含义的术语，或者在目前的问题中用于有限范围内的术语，要给出专门的定义。 另外，在词汇表中加入精化细节也是很有帮助的-那些通常归入功能性需求规范的“东西”，常体现在精化细节中。 集中在公司的关键任务的目标上。一个新项目的 开始，可能是执行一个已有的长期系统计划的结果，或来自于一系列高层战略信息系统计划编制的建议。因此，由此产生的建造，应该尽量基于长期的方向和目标，而不是针对商业危机或技术潮流而做出的反应。应该直接集中在公司的业务需要上，而不是技术员的理想软件列表上。 应该通过考察现在的应 用情况，并根据其业务性能和任何预计的未来的市场影响，对每个系统进行分类。,需求分类 根据软件产品的性能指标和实现难度，对问题和需求进行分类： 核心需求 基本功能需求 高级功能需求 组合功能需求,恰当地选取问题和需求的切入点。所有问题和需求都有发生的根源，其表面现象往往是开发者思路的切入点。其中，如果切入点是狭隘的，那么围绕着问题和需求的分析往往局限于自身的思路范围，问题和需求产生的原因就很难发现。所以当不能理解分析的问题和需求时，不妨先跳出思维惯例，寻求存在这样的问题和需求的原因，然后再分析理解之。 交替反复分析多个问题和需求，寻找问题间的共性和特性。 问题复杂化，是一个抽象问题或需求的逆过程。提出问题需求的许多可能的假设，丰富问题需求的形式。问题复杂化的意图是许多问题应该从更多的方面去验证不同环境下问题是否同样存在。 问题抽象化，继而简化问题。众多的问题和需求变成程序式过程，就是公式化问题和需求。类模板就是一个抽象问题很好的例子。,4）需求获取技术特征 由上可见，需求获取技术特征： 方便通讯（使用易于理解的语言） 提供定义系统边界的方法 提供划分、抽象、投影等方法 允许采用多种可供选择的设计方法 适应需求的变化 支持使用问题空间的术语，思考问题和编制文档 ,需求获取技术- Use Case (Ivar Jacobson,1994) 1）引言 Use Case主要用于促进和用户的交流、沟通。为此使用了一种用户和开发人员都能理解方式描述系统功能和行为。 Use Case可以划分系统与外部实体的界限，是系统开发的起点，而最终应该落实到类和实现代码上。 Use Case既然是对系统行为的动态描述，因此它是类、对象、操作的来源，是系统分析和设计阶段的输入之一，是分析和设计，制定开发计划，测试计划，设计测试用例的依据之一。 Use Case Model是系统需求分析阶段的成果之一。 Use Case不但有助于帮助分析员理清思路；验证用户需求。而且，也是开发人员之间进行交流的重要手段。,2）语义与表示 一般地说，USE CASE是用户为了达到某一目标和系统进行的典型交互。例如： “做一次拼写检查” “对一个文档建立索引” 对一个用况而言，关键要素是：表示一种用户可以理解并对该用户有价值的功能。 用况提供了客户和开发人员在制订项目计划中进行交流的主要成分。,（1） USE CASE语义 一个USE CASE是系统或其它语义实体（例如子系统或一个类）所提供的一块(unit)高内聚的功能，显露该系统和一个或多个外部的交互者（称为操作者）交替出现的消息序列，以及该系统所执行的动作。 可见，一个USE CASE捕获了参与交互的各方关于其行为的一个约定。通过这一约定，描述了该语义实体在不同条件下的行为对参与者一个要求的响应，以实现某一目的。不同的行为序列，依赖于所给出的特定要求以及与这些要求相关的条件。,（2）表示与描述 USE CASE通常被表示为： USE CASE包含一组操作和属性，这些操作和属性 规约了该USE CASE的实例所执行的那个动作序列。动作 包含状态的改变以及该USE CASE与其环境的通讯。 为了表明USE CASE所包含的具体内容，还应给出它 的正文描述。即：,USE CASE 中包含的信息 名称(Name) 标识(Identifier) 描述(Description) 角色(Actor) 状态(Status) 活动及时序 频度(Frequency) 注：具体例子请参见P16-17。,3）操作者语义与表示 一个操作者定义了一组高内聚的角色，当用户与该 实体交互时，用户可以扮演这一角色。 对于每一USE CASE，一个操作者有一种角色，即每 一USE CASE与具有一种角色的操作者进行通讯。 通常，一个操作者被表示为：,4）USE CASE获取 仿真法（Simulation） 掌握用户的所有输入与输出的数据种类，通过仿真的方法，找出它们之间的对应关系，与及相应的数据处理过程。包括任何计划中将要新增加的数据类型与处理过程。 原型法（Prototyping） 从用户处取得一组基本的USE CASE产品要求之后， 立即建造USE CASE产品的原型（这个原型可以是实际可运行的软件（外壳），或是一个用描述来表达的产品），然后让用户去模拟使用这个原型，提出修改的意见。其中，值得注意的是，不要忽略将要新增加的数据类型与处理过程。 场景法（Scenario Generation） 让用户穷举他们现有的所有的数据处理实践以及任何计划中将要新增加的数据类型与处理过程。 从以上三种方法中可以看出，Use Case 的功能划分均要以角色为主体，行为是角色触发的。,5）关系 在USE CASE之间，或在操作者与USE CASE之间，存在一些标准的关系： 关联：参与关系，即操作者参与一个USE CASE。例如，操作者的实例与USE CASE实例相互通讯。关联是操作者和USE CASE之间的唯一关系。 扩展：USE CASE A到USE CASE B的一个扩展关系，指出了USE CASE B的一个实例可以由A说明的行为予以扩展（根据该扩展所说明的特定条件），并依据该扩展点定义的位置，A说明的行为被插入到B中。 包含：USE CASE A到USE CASE B的一个包含，指出A的一个实例将包含B说明的行为，即这一行为将包含在A定义的那部分中。 泛化：USE CASE A到USE CASE B的泛化，指出A是B的特殊情况。,1 *, the salesperson asks for the catalog,Place Order extension points additional requests: after creation of the order,Supply Customer Data,Order Produck,Arrange Payment,Request Catalog,salesperson,例：USE CASE 关系 Actor 关系,Supervisor,Establish Credit,1 *,6）、USE CASE图 USE CASE图给出了操作者和USE CASE以及它们之间的关系。即图中给出了一些操作者、一组关系、一些接口和这些元素之间的关系。 (关系是操作者和USE CASE之间的关联 是操作者之间的泛化 是USE CASE之间的泛化、扩展和包含) 可以将一些USE CASE用一矩形括起，以表示所包括的那个系统或其它语义实体的边界。,Check status,Place order,Fill order,Establish credit,Telephone Catalog,Salesperson,Shipping Clerck,Supervisor,Customer,例：USE CASE图,7）、使用USE CASE图的建模类型 使用USE CASE图所建造的模型类型，可以从两个层面上进行分类，它们是“整体/部分”关系 系统建模（system modeling ） 系统建模用于描述软件系统的结构和行为 业务建模（business modeling） 业务建模用于企业或组织过程的优化和再工程（process re-engineering） 业务建模的图形元素不仅包括普通的Actor和Use Case，还包括Worker、Artifact，Business 过程描述时还应结合时序图(sequence diagram)和活动图(activity diagram),2、关于需求规约 需求规约的主要目标： 依据需求陈述（作为输入），解决其中的歧义、不一致等问题，以系统化的形式表达用户的需求，即给出问题的形式化或半形式化的描述（建立模型），形成需求规格说明书。为了实现这一目标， （一）结构化分析方法 1提出的概念有： 数据流： 加工： 数据存储： 数据源： 数据潭： 概念是完备的。,2建模过程 (1)建立系统的功能模型 -使用的工具为数据流图DFD 首先：建立系统环境图，确定系统边界 继之：自顶向下，逐层分解 (2)建立数据字典 定义数据流 定义数据存储 定义数据项 (3)给出加工小说明 -使用的工具可以为判定表 判定树,(1)建立系统的功能模型 -使用的工具为数据流图DFD 数据流图：是一种描述数据变换的图形工具。例如：,旅行社,订票单,预定 机票,准备 机票,记帐,费用,航班,帐单,机票,记帐文件,航班目录,旅行社,数据流图由四个基本成分组成： 数据流 加工 数据存储 数据源和数据潭,其中：1 各成分的定义 2 数据流、数据存储-支持数据抽象 加工-支持过程/功能的抽象 3 关于命名问题,简化的商业自动化系统,营业员,收款员,经 理,销售的商品,现金额,现金余额,销售情况,日销售额,查询要求,首先：建立系统环境图，确定系统边界 -顶层DFD,其中：1 数据流为：销售的商品，日销售额等 3个输入流，3个输出流 数据源为：营业员，经理，收款员 数据潭为：经理，收款员 2 加工名为：要建立的系统名字,录入、修改或 删除商品信息,录入、修改 现金额, 并计算余额,查询商品销售情况 计算日销售额,1,2,3,继之：自顶向下，逐层分解 A、按人或部门的功能要求，将加工“打碎”，形成：,注：需给每一加工编号；,B、”分派”数据流，形成：,录入、修改或 删除商品信息,2 录入、修改 现金额, 并计算余额,查询商品销售情况 计算日销售额,销售的商品,现金额,现金余额,查询要求,销售情况,日销售额,1,3,其中：要根据特定的加工要求进行分派； 保持与顶层数据流的一致； 可以不引入数据源和数据潭。,录入、修改或 删除商品信息,录入、修改 现金额, 并计算余额,查询商品销售情况 计算日销售额,销售的商品,现金额,现金余额,查询要求,销售情况,日销售额,销售文件,1,2,3,C、引入文件，使之形成一个有机整体系统：,注：到一个文件，既有输入流，又有输出流，则可简化为 ，并可不给出标识。 至此，体现精化，形成0层数据流图。,查询商品销售情况 计算日销售额,查询要求,销售情况,日销售额,销售文件,3,继续A、B、C：自顶向下，逐层分解。例如：加工3,可分解为：,判定要求,查询要求,3。1 统计销售情况,3。2 计算日销售额,销售文件,查询要求2,查询要求1,销售情况,日销售额,加工3:,*其中为什么要引入 加工“判定要求”？,(2)建立数据字典 定义数据流 定义数据存储 定义数据项 引入：结构符 | 用于定义数据结构,A,A,A,B,C,B0,C0,B*,数据字典: 1、数据流: 销售的商品=商品名+商品编号+单价+数量+日期 现金额 = 余额 =日销售额=非负实数 查询要求=商品编号|日期 查询要求1=商品编号 查询要求2=日期 销售情况=商品名+商品编号+金额 2、数据存贮: 销售文件=销售的商品 3、数据项,(3)给出加工小说明 -使用的工具可以为判定表 判定树 判断表 条件类别 条件组合 操作 操作执行 例如： 考试总分 =620 =620 620 单科成绩 有满分 有不及格 有满分 发升级通知书 y y n 发留级通知书 n n y 发重修通知书 n y n,3建模中注意的问题 （1）模型平衡规则 父图和子图必须平衡 每个数据流和数据存储必须在数据字典中予以定义 “叶”加工（最低层）必须给出加工小说明 小说明和数据流图的图形表示必须一致，例如： 在小说明中，必须说明“输入数据流”如何使用，必须 说明如何产生“输出数据流”，必须说明如何选取、使用、 修改“数据存储”,（2）控制复杂性规则 上层数据可以“打包” 上、下数据流对应关系在数据字典中给出，但包内 数据流的性质（输入、输出）必须一致。 一幅图中的图元个数应控制在7+/-2以内 与每一加工相关的数据流的数目应适中 （与层次有关） 分析数据内容，确定是否所有的输入信息都用于 产生输出信息； 分析加工，确定一个加工所产生的输出，是否都 能由该加工的输入信息导出,实例讲解：图书管理系统问题陈述见P35。 根据问题陈述，在一定的层次上，可以把该系统分为两“大块”，即：借还书等事务的处理，以及咨询事务处理。 -进行功能抽象。 （注：不同的功能抽象将导致不同的结果！但应该是等价的。） 于是，可以根据这一抽象，可以识别： 1）顶层数据流：借还书等事务处理要求 咨询事务要求 以及相关的数据流 2）数据源和数据潭为：图书管理人员，读者以及时钟。,基于以上分析，可形成该系统的环境图：,图书管理系统,图书管理员,图书管理要求,查询要求,图书统计表,图书情况,读者情况,读者,系统时钟,当前日期,罚款单,其中：3个输入流：图书管理要求，查询要求，系统时钟 图书管理要求=入库单 借书单 还书单 注销单 查询要求=读者情况 图书情况 图书统计表 4个输出流：图书统计表，图书情况，读者情况、罚款单,通过“打碎”、“分派”，可形成如下0层DFD：,1 处理借还 书等事务,2 处理咨询 事务,图书管理要求,查询要求,当前日期,目录文件,借书文件,读者文件,罚款单,读者情况,图书情况,图书统计表,其中：保持输入与输出的一致； 引入三个文件，对顶层DFD进行细化。 （注：存在数据库设计问题）,以同样方式，对加工1进行分解，形成：,1。1 入库新书,1。2 借书,1。3 还 书,1。4 注销图书,图书管理要求,处理图书管理要求,目录文件,罚款单,当前日期,借书文件,读者文件,入库单,借书单,注销单,还书单,其中：注意平衡问题；平面化问题。当然，还可以继续细化,1。2 借书,目录文件,借书文件,例如：借书,读者文件,借书单,1。2。1 检查读者的有效性,读者文件,1。2。2 检查读者的资格,1。2。3 办理借书,1。2。4 检查图书库存,借书单,无效读者,有效读者借书单,借书超限,核准后的借书单,该书已借完,借书记录,借书文件,目录文件,注意：其中粗线数据流！,图书管理系统的USE CASE模型（基本思路）：,借书,还书,新书入库,注销图书,图书管理员,读 者,请：1、在这一思路的基础上，建立该系统的USE CASE模型；并给出每一USE CASE的描述。 2、对该系统的两种模型进行比较。（在哪些方法进行？）,3、关于需求验证 有关SRS内容方面： （1）正确性：指的是SRS中陈述的每个需求是否都表达了 系统的某个要求。 （2）无二义性：指的是SRS中陈述的每个需求是否都只有 一种解释。 （3）完整性： 未来系统所做的任何事情都包含在SRS的陈述中； 未来系统响应所有可能的输入（包括有效和无效）； SRS中没有被标识为“待定”的内容。,（4）可验证性：SRS中陈述的每个需求都是可验证的- 即当且仅当存在一个有限代价的过程（人工或机器） 可以检查构造的软件产品是否符合用户的需求。 （5）一致性： SRS中陈述的需求没有与以前的文档发生冲突； SRS中陈述的各个需求之间没有发生冲突。 （6）可理解性：,有关SRS格式与风格方面 （7）可修改性：指的是SRS的结构和风格使任何对需求的 必要修改都易于完整、一致的进行。 （8）可被跟踪性：指的是SRS中的每个需求的出处都是清 楚的，这意味着SRS中包含对前期支持文档的引用表。 （9）可跟踪性：指的是SRS的书写方式有助于对其中陈述 的每个需求进行引用。 （10）设计无关性：指的是SRS不暗示特定的软件结构和 算法。,要回答如何解决问题 即给出软件解决方案 1总体设计的任务：如何将DFD转化为MSD 分二步实现： 第一步：如何将DFD转化为初始的MSD 分类：变换型数据流图 事务型数据流图 变换设计 事务设计,第四章 结构化设计,数据流图分类 变换型: 事务型,1,2,3,4,5,6,7,8,a,b,c,d,e,f,h,g,y,x,z,1,2,3,5,4,6,a,b,c,d,e,f,g,y,变换设计,XX系统,变换模块,get e,put h,put g,get c,get d,c,d-e,e-f,f-g,h,h-y,put y,g-x,put x,x-z,put z,get a,get b,b-d,a-c,e,e,g,h,h,g,z,z,x,x,g,y,y,h,d,b,c,a,c,d,e,e,f,g,h,f,x,a,b,事务设计,事务中心,输入模块,路径1,路径2,输出模块,a,y,c,g,b,f,c-e,c,e,e-g,e,g,b-d,b,d,d-f,d,f,3,4,6,8,2,5,7,9,A2,c,b,d,e,f,g,i,h,m,k,n,1,10,A1,x,一个系统的DFD，通常是变换型数据流图和事务型数据流 图的组合。如下所示：,第二步：如何将初始的MSD转化为最终可供详 细设计使用的MSD 概念：模块 模块化 模块化度量：内聚 耦合 设计规则经验规则 精化初始的MSD 体现设计人员的创造,1）耦合：不同模块之间相互依赖程度的度量。 耦合类型： （1）内容耦合： （2）公共耦合：两个以上的模块共同引用一个全局数据项。 （3）控制耦合：一个模块向另一模块传递一个控制信号， 接受信号的模块将依据该信号值进行必要的活动。 （4）标记耦合：两个模块至少有一个通过界面传递的公共 有结构的参数。 （5）数据耦合：模块间通过参数传递基本类型的数据。,2）内聚：一个模块之内各成分之间相互依赖程度的度量。 内聚类型： （1）偶然内聚：一个模块之内各成分之间没有任何关系。 （2）逻辑内聚：几个逻辑上相关的功能放在同一模块中。 （3）时间内聚：一个模块完成的功能必须在同一时间内完成，而 这些功能只是因为时间因素关联在一起。 （4）过程内聚：处理成分必须以特定的次序执行。 （5）通信内聚：各成分都操作在同一数据集或生成同一数据集。 （6）顺序内聚：各成分与一个功能相关，且一个成分的输出作为 另一成分的输入。 （7）功能内聚：模块的所有成分对完成单一功能是最基本的，且 该模块对完成这一功能而言是充分必要的。,启发性规则-经验的总结 （1）改进软件结构，提高模块独立性； （2）模块规模适中-每页60行语句； （3）深度、宽度、扇入和扇出适中； （4）模块的作用域力争在控制域之内； （5）降低模块接口的复杂性； （6）模块功能应该可以预测。,示例：数字仪表板系统的精化,读旋转信号,收集并 求平均,转换成 转/分,计算 gph,读并 校核,确定 加速/减速,计算里程,计算mph 和超速值,计算 燃料消耗,产生 加速/减速显示,产生 里程显示,发出 铃声,产生 mph显示,产生 mpg显示,旋转信号,信号/秒,(sps),sps,燃烧流 传感器信号,燃烧流,gph,sps,rpm,rpm,箭头指示,上箭头,下箭头,水平线,英里,超速值,mph,mpg,mpg显示,mph显示,铃声,里程显示,输入部分,Get gph,Get rpm,Get sps,Get 燃料流,变换燃料流为 ghp,Get 燃转信号,变换燃转信 号为燃料流,变换sps为 rpm,Get sps,Get sps,转换为 sps,Get 转速信号,变换为sps,变换为 sps,1、 数字仪表板系统输入部分的精化 输入部分的初始模块结构图,转速信号,燃料流,燃料流,燃料流,gph,sps,sps,rpm,sps,rpm,gph,sps,sps,sps,sps,sps,sps,sps,转速信号,转速信号,输入部分,计算gph,计算rpm,计算 sps,读燃转信号,采集sps,读转速信号,使用启发式规则1，并考虑其它规则， 可以将输入部分的模块结构图精化为：,其中：sps为转速的每秒信号量；sps 为sps的平均值； sps为sps的瞬时 变化值；rpm为每分钟转速；mph为每小时英里数；gph为每小时燃烧 的燃料加仑数；rpm为行进里程。,输出部分,PUT mpg,PUT mph,PUT里程,PUT 加/减速,PUT 超速量,显示,显示,显示,2、 数字仪表板系统输出部分的精化 输出部分的初始模块结构图,显示,显示,变换,变换,变换,变换,变换,对于这一初始的模块结构图，一般情况下应： 把相同或类似的物理输出合并为一个模块，以减少模块之间的关联。就本例而言： 左边前三个“显示”，基本上属于相似的物理输出，因此可以把它们合并为一个显示模块。而将“PUT mpg”模块和相关的“生成显示的模块合并为一个模块；同样地，应把“PUT mph”模块、“PUT里程”各自与相关的生成显示的模块合并为一个模块，参见下图。 其它求精的规则，与输入部分类同。例如，可以将“PUT 加/减速”模块与其下属的两个模块合并为一个模块，将“PUT 超速量”模块与其下属的两个模块合并为一个模块 。,输出模块,生成mpg 显示,生成mph 显示,生成里程 显示,生成加/减速显示,生成蜂鸣,显示,通过以上求精之后,可得如下的模块结构图,变换模块,计算mpg,计算mph,计算里程,计算加/减速,3、变换部分的精化 1）首先，应该了解：对于变换部分的求精，是一项具有挑战性的工作。其中主要是根据设计准则，并要通过实践，不断地总结经验，才能设计出合理的模块结构。 2）就给定的数字仪表板系统而言，如果把“确定加/减速”的模块放在“计算速度mph”模块下面，则可以减少模块之间的关联，提高模块的独立性。 通过这一求精，可以得到如下的模块结构图：,通过以上讨论，可以看出：在总体设计中 （1）将一个给定的DFD转换为初始的模块结构图基本 上是一个 “机械”的过程，一般体现不了设计人员的创 造力； （2）优化设计-将一个初始的模块结构图转换为最终 的模块结构图，对设计人员将是一种挑战，其结果将 直接影响软件系统开发的质量。,总体设计小结： 1、总体设计的目标和任务； 2、总体设计的表示：层次图，HIPO图，模块结构图； 3、基本概念：模块，以及由此产生的“鸿沟”； 4、总体设计的基本思想与步骤： 通过：变换设计和事务设计 DFD-初始的MSD （几乎可“机械”地进行） 使用：启发式规则 初始的MSD-MSD （体现设计人员的创造）,2详细设计的任务：定义每一模块 结构化程序设计 三种控制结构:顺序 begin s1;s2;sn end; 选择 if 条件表达式 then s1 else s2; 循环 while 条件表达式 do s ;,几种表示工具 流程图、PAD、NS图、伪码等 1)框图,s1,s2,s1,s2,. . .,s,2)伪码 伪码是一种混合语言。外部采用形式语言的 控制结构，内部使用自然语言。 Begin 输入一元二次方程的系数a,b,c; if b2-4aco then 计算两实根 else 输出无实根； end.,3)PAD图,S1,S2,S3,S1,S2,X5 X5,S,顺序: 选择 : 循环:,注:支持逐步求精设计,3)N-S图,支持逐步求精设计举例,顺序: 选择 : 循环:,条件,F,T,S1,S2,循环条件,循环体,N:=110,X5,T,F,F,T,S1,S2,S3,S4,S5,S6,S8,S7,S9,S10,X10&Y3,1、结构化方法是一种比较系统的软件开发方法学。 包括：结构化分析和结构化设计 2、紧紧围绕“过程抽象”和“数据抽象”， 给出了 完备的符号体系 -概念与表示 可操作的过程 -步骤与准则 易理解的表示工具 提供了 控制信息组织复杂性的机制，例如 逐层分解，数据打包等,结构化方法小结,3、问题：捕获的“过程”和“数据” 恰恰是客观事物的易变性质， 解的结构也不保持原系统的结构， 从而：造成 维护，验证上的困难。,A,B1,B2,B3,B4,C2,C3,C4,C5,C1,Dn,Dm,数据结构1,数据结构2,概念 软件方法学以软件方法为研究对象的学科。主要涉及指导软件设计的原理和原则，以及基于这些原理、原则的方法和技术。狭义的也指某种特定的软件设计指导原则和方法体系。 从构造的角度，软件开发方法学主要由三部分组成 NOTATION PROCESS TOOLS,从能力的角度，软件开发方法学应能表达： 系统的说明性信息 系统的行为信息 系统的功能信息，并要给出以下机制： 控制信息组织复杂性 控制文档组织复杂性,5、学习、掌握、运用系统建模技术的基本“技巧”： 1）知识 知识=概念+关系+条件/过程 2）建模 建模=（实际事物概念）+表示(形式化或半形式化符号) 抽象：关注一个事物的重要的或主要方面，而忽略或去掉不重 要的或没意义的细节。 其中，就软件开发而言， 根据当前情况和需要，应以细节的不同层次来观察问题； 控制复杂性，并考虑正确性、可维护性、可复用性和可理解性等。 模型：any abstraction that includes all essential capabilities, properties,or aspects of what is being modeled without any extraneous details.Firesmith,Henderson-Sellers 3） 实践,一、引言 1、构造模块的四种基本观点 1）以“过程”或“函数”为基点，使每一模块实现一项功能； 2）以一个“数据结构”为基点，使每一模块实现该数据结构 上的操作功能； 3）以“事件驱动”为基点，使每一模块识别一个事件并对该 事件作出响应； 4）以“问题域中的一个成分”为基点，使每一模块对应现实 世界中的一个事物。,第五章 面向对象方法-概念与表示,2、OO方法基于的“世界观”： 世界是由对象构成的； 对象有其自己的属性和内部运动规律； 对象之间的相互作用，构成了大千世界的 各式各样的不同系统。,3、OO方法的两种学派: 一种：以“方法（method ）”驱动的方法学。 基本思想：在给出符号体系的基础上，明确规定 进行的“步骤”，并在每一步中给出 “实现策略”。 代表：P.Coad的“OOA（1990）”， “ OOD（91）” 优缺点分析： 优点：容易学习和掌握。 缺点：不够灵活，可能对出现的新问题就没有 办法处理。,3、OO方法的两种学派: 第二种：以“模型（model ）”驱动的方法学。 基本思想：给出模型化概念，即符号体系以及目标 模型；而不明确规定实现目标的“步骤” 但给出一些必要的指导。 代表：Rumbaugh 的“OMT（1991）”等 优缺点分析： 优点：比较灵活； 缺点：与OOA相比，不易学习和掌握。,如以前所述,建模方法主要包括:建模语言和过程. 建模语言(Modeling Language)是用以表述设计方法的表示法(主要是图形的); 过程(Process)是对设计中所应采取的步骤的意见. 在建模语言方面,“UML已成为一种绘制面向对象设计图的标准工具,并已传播到非面向对象领域.面向对象以前的主要方法已经消逝.UML登场了,并且稳居宝座.” 摘自序,徐家福译,面向对象建模技术,UML的创建历程 （1）95年，Grade Booch 、Jim Rumbaugh在OOPSA会议上公布了他们的统一方法（0.8版）； （2）96年， G.Booch 、J.Rumbaugh以及Ivar Jacobson “三友”，将他们的统一建模语言命名为UML； （3）97年，Rational公司发布了UML文档1.0版，作为OMG的建议方案； （4）98年，在合并不同建议的基础上，OMG以其结果1.1版作为一个正式的标准。从此以后，Gris Kobryn领导一个修订工作组（Revision Task Force RTF）进行渐进的修订； （5）1999年，RTF发布了1.3版，作为OMG的下一个正式版本。,1、类图 1）类 根据OO的世界观，对象有其自己的属性和内部运动规律，并与其他对象相互作用。因此，可以在结构上把对象抽象为两个主要部分： 数据和操作 其中，数据用于表达对象的状态，而操作表达在特定状态对外提供的服务（功能）。,于是，现在可以从二个层面来理解“对象”： 概念层：对象是可标识的、可触摸的和可感知 的一切事物。 结构层：对象是数据和操作(或谓属性和行为) 的封装通信单位.数据表示对象的属性 状态，操作(或称方法)决定了对象的 行为和与其它对象进行通