软件工程概论

第一讲软件工程概论与需求分析9/21/20241内容软件危机软件工程传统开发模式面向对象模式UML需求分析基于用例的需求分析9/21/202421.软件危机1.1从千年虫问题谈起千年虫如同一个定时炸弹一样，十几年前就有人提出了预警，但是无人注意直到日期到来的前两年，才引起了恐慌9/21/202441.2软件危机的提出“软件危机”是1958年在NATO会议上作为一个正式的议题被提出来软件项目不成功的例子比比即是：1999年10月，耗资1.25亿美元的NASA的火星气象卫星失踪，据信这是由于简单的数据转换错误所导致的。人们发现卫星软件中，有些数据使用英制，它们应被转换成公制。这个卫星应当充当另一项任务中的火星极地着陆项目的通信转发器，那个任务也失败了，原因不明。9/21/20245美国IBM公司在1963年至1966年开发的IBM360机的操作系统。这一项目花了5000人一年的工作量，最多时有1000人投入开发工作，写出了近100万行源程序。......据统计，这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果。......

这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：“......正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难。......程序设计工作正像这样一个泥潭，......一批批程序员被迫在泥潭中拼命挣扎，......谁也没有料到问题竟会陷入这样的困境......”。IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取。9/21/202469/21/202479/21/20248一些数据：大约70％的软件开发项目超出了估算的时间，大型项目平均超出计划交付时间20％到50％，90％以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高美国政府审计局：只有不到2％的合同定购软件在发布时具有可用性——98％以上的项目都失败了9/21/202492.软件工程2.1定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料IEEE：软件工程是开发、运行、维护和修复软件的系统方法FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法9/21/2024112.2要素软件工程三要素：方法、工具和过程软件工程方法为软件开发提供了“如何做”的技术软件工具为软件工程方法提供了自动的或半自动的软件支撑环境软件工程过程定义了:

方法使用的顺序要求交付的文档资料为保证质量和适应变化所需要的管理软件开发各个阶段完成的里程碑9/21/2024122.3原理⑴用分阶段的生命周期计划严格管理

项目概要计划

里程碑计划

项目控制计划

产品控制计划

验证计划

运行维护计划⑵坚持进行阶段评审⑶实行严格的产品控制——基准配置管理(Baselineconfigurationmanagement)⑹开发小组的成员应该少而精1+1<2⑷采用现代程序设计技术⑸结果应能清楚地审查—setstandards⑺承认不断改进软件工程实践的必要性9/21/2024133.传统开发模式3.1瀑布模型瀑布模型(WaterfallModel)

维护开发定义DefinitionFeasibilityStudyRequirementsAnalysisProgramDesignCoding&ModuleTestingIntegration&SystemTestingDelivery&MaintenanceSystemDesign9/21/202415(1)问题定义和可行性研究确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度制定出完成开发任务的实施计划,连同可行性研究报告，提交管理部门审查9/21/202416(2)需求分析对待开发软件提出的需求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审9/21/202417(3)设计总体设计—“如何解决问题”可以列出多种解决方案进行比较把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审。9/21/202418(4)编码把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”写出的程序应当是结构良好、清晰易读的，且与设计相一致的9/21/202419(5)测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正组装测试，将已测试过的模块按一定顺序组装起来按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用9/21/202420(6)运行和维护改正性维护运行中发现了软件中的错误需要修正适应性维护为了适应变化了的软件工作环境，需做适当变更完善性维护为了增强软件的功能需做变更9/21/2024213.2瀑布模型的特点⑴顺序性、依赖性⑵推迟程序的物理实现⑶质量保证的观点——阶段文档与评审的要求，利于尽早发现错误。易于组织，易于管理缺点？需求变化后引起的代价将很高9/21/202422结构分析设计过程

阶段关键问题结束标准问题定义问题是什么？关于规模和目标的报告书可行性研究有可行的解吗？系统的高层逻辑模型数据流图成本/效益分析需求分析系统必须做什么？系统的逻辑模型数据流图数据字典算法描述

9/21/202423结构分析设计过程

阶段关键问题结束标准总体设计概括地说，应该如何解决这个问题？可能的解法：系统流程图成本/效益分析推荐的系统结构；层次图或结构图详细设计怎样具体地实现这个系统？编码规格说明：HIPO图或PDL编码和单元测试正确的程序模块源程序清单；单元测试方案和结果综合测试符合要求的软件综合测试方案和结果；完整一致的软件配置维护持久地满足用户需要的软件完整准确的维护记录9/21/202424本质上是功能分解，以实现功能的过程为中心，而用户的需求变化主要是针对功能的。这就使基于过程的设计不易被理解；且功能变化往往引起结构变化较大，稳定性不好。系统有明确的边界定义，且系统结构依赖于系统边界的定义，这样的系统不易扩充和修改。数据与操作分开处理，可能造成软构件对具体应用环境的依赖，可重用性(reusability)较差.结构化技术的缺点9/21/2024254.面向对象模式4.1面向对象分析、设计与编码面向对象的分析（OOA）分析问题论域，找出问题解决方案，发现对象，分析对象的内部构成和外部关系，建立软件系统的对象模型面向对象的设计（OOD）根据已确定的系统对象模型，运用面向对象技术，进行系统软件设计面向对象的编码9/21/202427(1)面向对象的分析问题论域分析业务范围，业务规则，业务处理过程，确定系统的责任，范围和边界，确定系统的需求发现和定义对象和类识别对象和类，确定它们的内部特征：属性和操作，这是一个抽象过程识别对象的外部联系对象与对象，类与类之间的各种外部联系，包括一般与特殊，整体与部分，实例连接（关联），消息连接等建立系统的静态结构模型对象类图和对象图，系统与子系统结构图等，绘制相应的图建立系统的动态行为模型对象之间的交互关系等9/21/202428(2)面向对象的设计设计对象和类具体设计对象和类的属性，操作，设计对象与类的各种外部联系的实现结构，设计消息与事件的内容、格式等设计系统结构设计组件与子系统，以及它们的相互的静态和动态关系设计问题论域子系统负责领域的业务服务设计人机交互系统设计数据管理子系统设计任务管理子系统进程管理设计优化，提高系统性能9/21/202429(3)比较结构化设计方法以功能分解为中心面向对象方法自然地以论域中的对象作为软件的基本分析和设计单元，改善了软件的可理解性，可重用性9/21/2024305.UML5.1UML历史面向对象的分析与设计(OOA＆D)方法的发展在80年代末至90年代中出现了一个高潮.UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。9/21/202432三个好朋友

9/21/2024335.2UML定义UML(统一建模语言)是为软件系统的制品进行描述（specifying）、可视化（visualizing）、构造（constructing）、文档化（documenting）的一种语言。它同样适用于商业模块和其他非软件系统。在大型和复杂系统的建模中，UML成功地描述一些优秀的工程实施。9/21/202434曹操孙权Environment

话说三国演义OOAD

适用于社会组织法分析(Domain)西蜀9/21/202435曹操孙权Environment

刘备关羽孔明张飞赤壁之战其它流程(Domain)西蜀曹操进兵引发西蜀的流程谁来执行流程呢?9/21/202436

OOAD最关心流程与元素

1.描述流程(剧情)----分析

赤壁之战其它流程2.安排主/配角(元素)演出----设计刘备关羽孔明张飞9/21/202437

OOAD最主要的工具

UML(Unified

Modeling

Language)

OMG

认可的世界标准

19979/21/202438

为什么需要

UML呢?

贝多芬作曲时使用五线谱您设计软件时使用UML9/21/202439

为什么需要

UML呢?

五线谱有多种音符UML也有多种符号刘备孔明关羽曹操赤壁之战其它流程空城計退敵

UseCase图

Sequence图9/21/202440

UseCase叙述

曹操举兵南下,西蜀就拟定策略,展开部署並联络孙权,鼎力对抗曹操大军.曹操赤壁之战孙权西蜀

把西蜀看成黑箱!!

准备打开西蜀黑箱9/21/202441

Scenario叙述

曹操赤壁之战孙权

把西蜀黑箱打开

!!

刘备关羽孔明张飞9/21/202442

Scenario叙述

曹操赤壁之战孙权刘备关羽孔明张飞

曹操举兵南下,刘备请孔明拟定策略.派遣关羽和张飞防守荆州,同时请孔明联络孙权,共同对抗曹操.孔明联合孙权,借东风,火烧曹军于赤壁.9/21/202443

Scenario叙述

使用UML

表示之9/21/202444

Scenario叙述

刘备孔明关羽求战请拟定策略张飞请防守荆州请防守荆州前线孙权曹操请联络孙权请孙权领兵相助借东风火攻火攻曹军9/21/202445刘备的責任?

刘备求战请拟定策略请防守荆州请联络孙权我必需迎战曹操!!9/21/202446使用UML表示-----类图

刘备求战刘备迎战曹操迎战曹操迎战曹操迎战曹操迎战曹操迎战曹操9/21/202447使用UML表示

孔明请拟定策略请联络孙权请孙权领兵相助借东风火攻火攻曹军孔明拟定策略联合孙权借东风火攻9/21/202448使用UML表示

关羽张飞请防守荆州请防守荆州前线关羽防守荆州张飞防守荆州前线9/21/202449

关羽防守荆州张飞防守荆州前线刘备迎战曹操孔明拟定策略联合孙权借东风火攻UML的Class图

您已熟悉UseCaseSequence图Class图现在准备进入OOP阶段9/21/2024503.

认识

OOP

OOP阶段的任务

----衔接OOAD的工作----从UML到Java----从Java

到组件9/21/202451

使用Java

刘备迎战曹操写Java程序‘Class刘备Method

迎战曹操()……EndMethod9/21/202452

孔明拟定策略联合孙权借东风火攻使用Java

写Java程序‘Class孔明Method

拟定策略()……EndMethodMethod

联合孙权()……EndMethodMethod

借东风火攻()……EndMethod9/21/202453‘Class刘备Method

迎战曹操()……EndMethod使用VisualBasic‘Class孔明Method

拟定策略()……EndMethodMethod

联合孙权()……EndMethodMethod

借东风火攻()……EndMethod‘Class关羽Method

防守荆州()……EndSub‘Class张飞Method

防守前线()……EndMethod依样画葫芦准备填写Method內容9/21/202454

写Java程序內容

刘备求战请拟定策略请防守荆州请联络孙权写Java程序‘Class刘备孔明

k;关羽

g;Public刘备（孔明k1,关羽g1）Public

迎战曹操(){

k.拟定策略

g.防守荆州

k.联合孙权}9/21/202455写Java程序內容

孔明请拟定策略请联络孙权请孙权领兵相助借东风火攻借东风火攻写Java程序‘Class孔明DimsAs孙权Function

拟定策略()……EndFunctionSub

联合孙权()

s.请领兵相助

s.借东风火攻EndSubSub

借东风火攻()……EndSub9/21/202456写VB代码

‘Class刘备DimkAsNew孔明DimgasNew关羽Sub

迎战曹操()

k.拟定策略

g.防守荆州

k.联合孙权EndSub‘Class孔明DimsAs孙权Function

拟定策略()……EndFunctionSub

联合孙权()

s.请领兵相助

s.借东风火攻EndSubSub

借东风火攻()……EndSub9/21/202457写Java代码

把Java类编译为Class组件JVM9/21/2024586.需求分析6.1概述软件产品建造的第一步：需求分析根据用户对产品的功能的期望,提取出产品外部功能的描述。9/21/2024606.2需求分析的困难性9/21/2024617.需求分析与UML7.1需求分析的途径：用例视图用例视图——支持产品外部功能描述的视图用例视图从软件产品的使用者的角度而不是开发者的角度，描述用户对待开发的产品的需求，分析产品所需的功能、动态行为因此需要容易理解9/21/2024637.2软件的外部特征当软件的使用者考查一个软件产品的功能时，其考虑的内容通常包括：软件的功能的设置的合理性软件的运行效率软件功能使用的方便程度这些内容是软件产品的外部特性，是软件系统通过其边界呈现给用户的特性

外部特性通常是动态的，通过外部特性，软件系统的使用价值得到了体现呈现在软件系统的边界上的外部特征，是由软件系统的内部实现决定的，但是，对于软件系统的使用者而言，软件功能的内部实现不是他们关心的问题，他们所关心的只是其所需要的功能是否以令其满意的方式得到了实现9/21/2024647.3需求分析原则分析软件系统的功能设置时，应该把重点放在描述软件系统的外部边界上，即重点考虑用户对软件系统的功能设置的合理性、方便性和运行效率的要求，而不应该在需求分析阶段就过多地考虑软件系统的结构和内部实现机制。这是在对软件系统进行需求分析时，应该遵循的一个重要原则

9/21/2024657.4需求分析内容/1软件系统不是孤立存在的，不但需要分析共有哪些用户将要使用软件系统，而且还需要分析软件系统的运行结果将要对哪些对象产生影响，这包括：指定运行结果的输出和存储的媒介指定被软件系统运行结果控制的硬件设备如显示器、打印机、工业机器人、数控机床等9/21/202466当提取出了软件系统运行的外部环境中与之交互的对象之后，需要为这些对象与软件系统进行的交互指定具体内容。这包括：对交互中包含的动态行为进行详细描述还包括对这些动态行为进行合理的分类和组织使得这些动态行为所代表的软件系统的功能的设置能为用户提供其所需的价值，并具备令用户满意的易用性和效率媒介：交互图状态图9/21/2024678.用例建模8.1活动者(1)概述对软件产品的需求分析就是定义软件系统的边界，包括两个方面的内容：分析软件产品与外界的联系确定软件产品与外界的联系时包含动态行为及其相互关系在UML中，下列建模元素为上述两个方面的内容提供支持：活动者(actor)用例(usecase)它们存在于用例视图中，所在模型图：用例图(usecasediagram)

9/21/202470(2)定义活动者：位于系统之外并和系统进行交互的一类对象用它可以对软件系统与外界发生的交互进行分析和描述软件系统在和外界发生交互时涉及的具体的对象，在UML里，用活动者来建模9/21/202471(3)活动者建模的对象软件系统的使用者：

软件系统的使用者要通过使用软件和系统交互，使用者处于系统之外随着软件系统的应用领域的不同，在用例视图模型中代表系统使用者的活动者的数目也有可能不同对于那些通用的软件产品，如：文字处理软件、网络通讯软件、图形绘制软件，它们的使用者通常是不需要分类的，只需要一个活动者就可以代表其所有的用户对于那些专业化较强的专用软件系统，如，管理信息系统、工业生产流程控制系统等，它们的使用者随其在软件的应用领域的职责的不同，对软件的使用方式也会有所不同，例如，在一个公司的管理信息系统中，公司的管理者对信息系统的存取权限将高于公司的普通员工，有必要对软件系统的使用者进行分类，多个不同的活动者将同时出现在用例视图模型中9/21/202472活动者除了可以代表作为人的软件使用者之外，还可以代表直接和软件系统交互的软件系统赖以运行的软/硬件平台以及与软件系统有信息交换的计算机外部设备例如，绘图软件它调用操作系统提供的图形绘制接口，控制图形在显示设备上的输出，这时可以把操作系统的的图形接口和图形输出设备用一个活动者来建模类似的情形也可以应用于描述软件系统的计算结果的保存上，软件系统的计算结果通常都是通过操作系统的文件存取接口以文件的形式存放在计算机的外部存储器上的，在为软件系统的边界建模时，如果需要强调软件系统的结果的保存，就可以把操作系统的文件存取接口和文件本身用一个活动者来代表9/21/2024739/21/2024748.2用例1)概述指定活动者以后，需要详细描述活动者和软件系统交互的具体内容，对交互所代表的软件系统的功能进行分类，对这些功能详细指定其代表的软件系统的动态行为在UML里，软件系统的功能和其代表的动态行为是用用例来建模的9/21/2024762)什么是用例用例代表系统为响应活动者引发的一个事件而执行的一系列的处理，而且这处理应该为系统作用者产生一种可见的价值用例描述了当活动者和软件系统进行交互时，软件系统所执行的一系列的动作序列，这些动作序列不但应包含正常使用的各种动作序列，而且应包含对非正常使用时软件系统的动作序列的描述用例用来为软件系统所提供的功能及其动态特征建模，在考虑软件系统的功能划分时，要考虑功能设置的合理性和使用的方便性一个用例代表活动者和系统的一次交互，用例视图中用例的设置，就代表了软件系统的功能的划分为了得到合理而方便的软件系统的功能设置，必须仔细考虑每个用例代表的动态行为的内容，使得每个用例都能产生一个有价值的结果在通过用例考虑软件系统的功能划分时，应使得功能的分布较为均衡、易于理解、易于使用，这也是用例的定义中所谓“产生可见的价值”的含义9/21/2024773)用例的例子假定设计开发一个名为“位图观察器(bmpviewer)”的软件产品，它为用户提供图像显示和浏览的功能。经过对用户提出的功能需求的分析和整理，得出的用户期望得到的产品的功能如下：打开一个bitmap文件可对文件进行放大显示(Zoom-in)可对文件进行缩小显示(Zoom-out)可对文件进行浏览(Pan)可将文件继续保存到磁盘9/21/202478利用用例和活动者的概念，把上述功能在通过用例在用例图上加以表达在这里把上列的每项功能都用一个用例表示9/21/2024794)用例与活动者的关联关系活动者和软件系统的交互是具体地和特定的某项功能相联系的，而软件系统的功能在UML模型是用例，所以系统作用者和软件系统的交互表明了活动者和用户之间存在着某种对应为了表达活动者通过某项功能与系统交互，在UML模型中，可以通过用一条直线把活动者和用例相连接来表示9/21/202480这条直线在UML里代表关联关系例如，图中“用户”和“打开文件”用例之间的关联关系代表用户对软件系统的打开文件功能的使用9/21/202481关联关系是UML的关系的一种，它代表两个类的对象之间的语义连接未经过修饰的关联关系是双向的两个类之间有关联关系，代表两个类之间可以互相访问，因而提供了它们进行交互的基础在用例图中使用的关联关系通常被修饰为单向的关联关系，它在模型图被表示为一条带箭头的直线单向关联关系是关联关系的一个特例，它由关联关系经修饰而得，它意味着访问是有向的在处于有向关联关系中的两个类中，位于箭头所指方向的类的对象可以被另一个类的对象访问，反之则不然9/21/202482和系统打交道的外部对象有3个，其中“用户”代表软件的使用者，它通过访问这项用例启动软件“打开文件”的功能。系统对这些事件应采取一系列的动作进行响应，响应的过程中，将访问硬盘中的数据，并更新显示因此，有两个系统作用者与此相对应，“位图文件”，“显示窗口”：“显示窗口”代表用来显示位图的操作系统图形用户界面的一个窗口，“位图文件”代表保存在计算机外部存储器的位图文件从这个例子也可以看到，活动者不仅仅代表人，还可以是软件或硬件系统

9/21/202483关联关系的有向性在图中所示的用例中，“打开文件”对应的系统所采取的动作序列中涉及文件“读取”，但关联关系的箭头仍指向文件而不是反之。这是因为有向关联关系的箭头代表的是访问的方向，而不是数据的流向数据文件不会（主动地）访问用例，所以对读取或保存文件，都应有同样的访问方向9/21/2024845)事件流与场景

事件流用例代表系统和活动者之间发生的一系列的事件，这些事件流构成了用户对系统功能的一次使用在用例图中必须对事件流进行描述，以构成一个完备的用例模型对事件流的描述包括四种形式，即：形式文本非形式文本交互图状态图相应的UML成员作为这些描述的载体文本和正式文本可用注标（note）表示交互图和活动图本身即是一个标准的UML成员9/21/202486

主事件流（mainflowofevents）和次要事件流（alternativeflowofevents）用来区分对系统功能的合法使用和非法使用主事件流（mainflowofevents）合法使用只有一个次要事件流（alternativeflowofevents）可包含若干个在描绘事件流时，必须用足够清晰的语言以使得一个普通的用户能够理解9/21/202487场景（Scenario）一个用例可以有多个事件流，每一个事件流是一个完整的用户对系统的功能的使用。它们出于同一个目的，但出于事件流不同，使得系统产生的响应不同 这样的用例/事件流的对应关系正是前面讲到的UML公用划分机制的一个例子,它是对系统功能使用的特例（合法或非法的）,

因此事件流是用例的实例（instance）用例的实例在UML中被称为场景（Scenario）9/21/2024886)用例图中的关系(1)概述在分析和整理活动者和系统用例的时候，可能用到：使用关系泛化关系包含关系扩展关系9/21/202490(2)使用关联使用关联是指一个用例使用另一个用例的功能行为使用关联用于在用例之间共享公共的功能行为使用关联是一种泛化关联，在用例图上用一个基本用例指向公共的用例的泛化箭头表示，并在箭线上标有构造型<<Use>>9/21/202491(3)泛化关系在UML中，两个类之间的泛化关系代表子类共享了超类的行为和结构。它实际上就是C++里面的类之间的继承和导出关系在用例图中，活动者是类的变体用例是具有类的特征的建模元素（分类符）,因此，可以用泛化关系描述活动者或用例之间的继承9/21/202492在一个帐单管理系统中，用例

PhoneOrder和InternetOrder在结构和行为方面存在很多相似之处。因此可以定义一个通用的用例PlaceOrder，来表示结构和公共的行为。抽象的用例PlaceOrder自身并不一定要是完整的，但是它提供了一个公共的行为框架，子用例可以使自己完整9/21/202493(4)包含关系包含关系(include)：位于两个用例之间的包含关系意味着基用例显式地在其指定位置将另一个用例包含进来,使其成为自己的行为的一部分包含关系可用于提取共用的用例在具有包含关系的两个用例中，被包含的那个用例不能单独存在，它只能以实例的形式存在于包含它的用例之中9/21/202494在一个ATM系统中，用例WithdrawCash,DepositCash和TransferFunds都需要包含系统识别客户这一功能。该行为可以提取出来作为一个新的包含用例，称为IdentifyCustomer,它被其它三个基用例所包含。这些基用例独立于具体的识别方法，该方法被封装在包含用例中。从基用例的观点看，它们不关心用户识别是从银行磁卡上识别出来的还是从视网膜扫描上识别出来的。它们只需要IdentifyCustomer的结果,就是客户的标识符另一方面，从IdentifyCustomer用例的角度看，它不关心基用例是如何使用客户标识的或者在执行它之前，发生了什么——识别的方法始终是一样的9/21/2024959/21/202496(5)扩展关系扩展关系：两个用例之间的扩展关系，代表基用例可以隐式地包含另一个用例作为其行为的一部分，包含的位置间接地由另一个用例（扩展用例）确定。基用例可以独立于扩展用例单独存在当一个用例有多个子流程时，可以用扩展关系对其进行扩展，使得此基用例的不同子流程能在不同的情形下以扩