软件工程基础知识讲解课件

课名：软件工程主讲：谢明志Email：tommyshell@163.com使用教材：软件系统开发技术（修订版） 潘锦平施小英姚天昉西安电子科技大学出版社12/9/20221课名：软件工程主讲：谢明志使用教材：软件第一章软件工程概述12/9/20222第一章软件工程概述12/7/20222§1.1软件工程的背景和历史1968年由NATO(北大西洋公约组织)在德国Garmish召开的学术会议上，FeitzBauer首先提出了“软件工程”概念。12/9/20223§1.1软件工程的背景和历史1968年由NATO(北大西软件工程与编程前者是一门学科，一种科学理论来指导软件系统开发，标准化，自动化的过程考虑如何分解一个系统，以便各人分工开发；考虑如何说明每个部分的规格要求；怎样才能易于维护单纯的代码编写是软件工程发展的前身是软件工程中占据很少时间和空间的一部分12/9/20224软件工程与编程前者是一门学科，一种科学理论来指导软件系统开发计算机学科的发展计算机科学(CS)计算机科学(CS)计算机工程(CE)软件工程(SE)信息系统(IS)计算学科(computingdiscipline)12/9/20225计算机学科的发展计算机科学计算机科学计算机工程软件工程信息60年代以来工厂管理病人监护工资统发图书馆管理机票预定学籍管理12/9/2022660年代以来工厂管理12/7/20226

早期

第二阶段第三阶段第四阶段面向批处理

多用户

分布式系统

强大的桌面系统有限的分布

实时

嵌入“智能”面向对象技术自定义软件

数据库

低成本硬件

专家系统

软件产品消费者的影响

人工神经网络

并行计算

网络计算机195019601970198019902000Evolutionofsoftware#12/9/20227早期第二阶段第三阶段为什么发展如此之快不准确的时间和金钱的估算软件质量的低下相对硬件产品开发软件开发费用的增加维护、增强软件系统的必要性硬件价格大幅度下降12/9/20228为什么发展如此之快不准确的时间和金钱的估算12/7/2022软件技术面临的问题规模复杂性生产率

12/9/20229软件技术面临的问题规模12/7/20229Windows95有1000万行代码Windows2000有5000万行代码例：Exchange2000和Windows2000开发人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人12/9/202210Windows95有1000万行代码例：Exch《人月神话》焦油坑

史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。

12/9/202211《人月神话》焦油坑史前史中，没有别的场景比巨兽在焦油坑中垂软件危机的主要特征软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证。12/9/202212软件危机的主要特征软件开发周期大大超过规定12/7/20软件工程的定义FritzBauer在NATO会议上给出的定义：“软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。”12/9/202213软件工程的定义FritzBauer在NATO会议上给出的定软件工程的定义（2）IEEE【IEE83】给出的软件工程定义：

“软件工程是开发、运行、维护和修复软件的系统方法。”12/9/202214软件工程的定义（2）IEEE【IEE83】给出的软件工程定软件工程的定义（3）IEEE【IEE93】给出了一个更加综合的定义：

“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。”12/9/202215软件工程的定义（3）IEEE【IEE93】给出了一个更加综合软件工程是一门交叉学科软件工程的主要研究内容软件开发技术:软件开发方法学软件开发过程

软件工具和软件工程环境软件工程管理:软件管理学软件经济学软件心理学

软件工程所包含的内容不是一成不变的，随着人们对软件系统的研制开发和生产的理解。应用发展的眼光看待它。12/9/202216软件工程是一门交叉学科软件工程的主要研究内容12/7/202软件工程—一种层次化技术工具方法过程质量焦点Softwareengineeringlayers软件工程三个要素：方法、工具、过程12/9/202217软件工程—一种层次化技术工具方法过程质量焦点Softwa软件工程与一般工程的差异软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件设计的复杂性软件特征： 功能的多样性 实现的多样性 能见度低 软件结构合理性差智力密集及知识产权保护12/9/202218软件工程与一般工程的差异软件是逻辑产品而不是实物产品12/7软件工程知识结构

2001年5月ISO/IECJTC1（ISO和IEC的第一联合技术委员会）发布了《SWEBOK指南V0.95(试用版)》SWEBOK把软件工程学科的主体知识分为10个知识领域。12/9/202219软件工程知识结构2001年5月ISO/IECJTC1（软件工程知识结构软件需求软件设计软件构造软件测试软件维护软件配置管理软件工程管理软件工程过程软件工程工具和方法软件质量12/9/202220软件工程知识结构软件需求12/7/202220“软件工程”课程

与其它软件专业课的区别(1)立足于系统的整体。(2)讲授系统分析、系统设计、测试及维护的理论和方法。(3)构筑一个软件系统，实践软件开发全过程。12/9/202221“软件工程”课程

与其它软件专业课的区别(1)立足于系“软件工程”课程教学的目标转变对软件的认识：上升

程序系统转变思维定式：上升

程序员系统工程师(系统分析员)12/9/202222“软件工程”课程教学的目标转变对软件的认识：12/7/202软件产品的标准化软件开发过程的标准化12/9/202223软件产品的标准化软件开发过程的标准化12/7/202223软件的工业化生产过程应具备的特点：明确的工作步骤详细具体的规范化文档明确的质量评价标准“一个好的工业，应有一套

良好的标准来配套”12/9/202224软件的工业化生产过程应具备的特点：“一个好的工业，应有一套

软件工程技术的两个特点

强调规范化强调文档化12/9/202225软件工程技术的两个特点强调规范化12/7/202225§1.2软件和软件生命期模型(SoftwareLifeCycle)软件产品或软件系统从设计、投入使用到被淘汰的全过程。12/9/202226§1.2软件和软件生命期模型(SoftwareLife软件生存期的阶段划分(1)可行性研究与计划(2)需求分析(3)总体设计(4)详细设计(5)实现(6)集成测试(7)确认测试(8)使用和维护成长期（开发期）怀孕期（计划期）

成年期（运行期）12/9/202227软件生存期的阶段划分(1)可行性研究与计划成长期（开发期）怀新的国际标准定义的软件生存过程（1995ISO/IEC12207）软件生存期过程支持过程组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问题解决过程管理过程基础设施过程改进过程培训过程12/9/202228新的国际标准定义的软件生存过程（1995ISO/IEC1软件工作的范围只考虑编写程序

涉及整个软件生存周期扩展到12/9/202229软件工作的范围涉及整个扩展到12/7/202229

软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件开发模型也常称为： 软件过程模型 软件生存周期模型 软件工程范型软件开发模型12/9/202230软件开发模型是软件开发全部过程、活动和任务的结构框可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段瀑布模型(WaterfallModel)12/9/202231可行性研究与计划需求分析设计编码运行维护测试定义开维护阶段瀑开发软件不仅仅是编程12/9/202232开发软件不仅仅是编程12/7/202232按照传统瀑布模型开发软件的特点1.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。12/9/202233按照传统瀑布模型开发软件的特点1.阶段间具有顺序性和依赖性。原型模型（快速原型模型）原型范型用户测试运行原型建造/修改原型听取用户意见12/9/202234原型模型（快速原型模型）原型范型用户测试建造/修改听取用1采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运行和维护原型化含原型化的软件生存期12/9/202235采用原型模型的软件生存周期分析定义生成系统程序编码测试运行§1.3软件质量的评价成功的标准：

用户在用用户可很容易做完要做的事失败的根本原因：

开发人员写出的东西达不到用户要求(人的问题.技术问题)12/9/202236§1.3软件质量的评价成功的标准：

用户在用12/7/质量与生产率质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实

质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提

质量与生产率的提高就指望程序员与程序经理

非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二

12/9/202237质量与生产率质量是软件需求方最关心的问题，用户即使不图物美价质量与生产率（2）质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求

高质量对所有的用户都有价值，而高生产率只对开发方有意义

如果一开始就追求高生产率，容易使人急功近利，留下隐患

12/9/202238质量与生产率（2）质量直接体现在软件的每段程序中，高质量自然不贪污的官就是好官吗“运行正确”的程序就是高质量的程序吗？也许运行速度很低并且浪费内存；也许代码写得一塌糊涂

12/9/202239不贪污的官就是好官吗“运行正确”的程序就是高质量的程序吗？1软件的质量因素

软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）

一般说来倾向于可维护性、可靠性、可理解性和效率12/9/202240软件的质量因素软件的质量因素很多，如正确性、精确性、可靠性软件质量因素分类和武学分类正确性与精确性易用性可理解性与简洁性性能与效率可复用性与可扩充性少林派、武当派华山派昆仑派峨嵋派崆峒派12/9/202241软件质量因素分类和武学分类正确性与精确性易用性可理解性与简正确性与精确性

机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的

需求分析错了，那么对客户而言这个软件也存在错误

如果软件没有100%地按需求规格执行，那么这个软件也存在错误程序员要为“正确”、“精确”四个字竭尽全力

12/9/202242正确性与精确性机器不会主动欺骗人，软件运行不正确或者不精确性能与效率

用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）

旧社会地主就是这么对待长工的：干活要快点，吃得要少点

通过优化算法、数据结构和代码组织来提高软件系统的性能与效率优化的关键工作是找出限制性能与效率的“瓶颈”

12/9/202243性能与效率用户都希望软件的运行速度高些（高性能），并且占用易用性

导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也一定会满意

当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“友好”来评价易用性

12/9/202244易用性导致软件易用性差的根本原因是开发人员犯了“错位”的毛可理解性与简洁性（Note1）

开发人员只有在自己思路清晰时才可能写出让别人能理解的程序

编程时还要注意不可滥用技巧，应该用自然的方式编程

简洁是一种美

如果把学术文章写得很简洁，让人很容易理解，它往往中不了

12/9/202245可理解性与简洁性（Note1）开发人员只有在自己思路清晰可复用性与可扩充性

一种方式是原封不动地使用现成的软件构件

一种方式是对现成的软构件进行必要的扩充后再使用

可复用性好的程序一般也具有良好的可扩充性

12/9/202246可复用性与可扩充性一种方式是原封不动地使用现成的软件构件可行性研究与计划需求分析设计编码运行维护测试测试已经开始返回上级，再…..瀑布模型的质量保障体系12/9/202247可行性研究与计划需求分析设计编码运行维护测试测试已经开始返回小结（Note2）软件的高质量主要是设计出来的不是“管”出来的更不能依赖质量检查。

12/9/202248小结（Note2）软件的高质量主要是设计出来的12/7/2第二章

可行性研究与计划12/9/202249第二章

可行性研究与计划12/7/202249系统流程图（Note3）输入单据磁盘文件处理输出单据12/9/202250系统流程图（Note3）12/7/202250数据流程图数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或12/9/202251数据流程图数据源点和终点变换数据的加工文件数据逻辑关系符号：§2.1可行性研究基本概念可行性研究的任务:

可行性研究的主要任务是“了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。”12/9/202252§2.1可行性研究基本概念可行性研究的任务:

可行性研究的可行性研究的内容(1)技术可行性(2)经济可行性(3)操作可行性(4)社会可行性(法律可行性)(5)抉择12/9/202253可行性研究的内容(1)技术可行性12/7/202253技术可行性(Note4)度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题开发风险分析资源分析相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）12/9/202254技术可行性(Note4)度量一个特定技术信息系统解决方案的经济可行性度量系统解决方案的性能价格比考虑的问题成本/效益分析有形成本、效益无形成本、效益价值和成本的关系质量与价值、成本的关系价值/成本的均衡12/9/202255经济可行性度量系统解决方案的性能价格比12/7/202255经济可行性考虑的问题(Note5)成本和效益的估算开发成本的估算开发效益的估算运行成本的估算运行效益的估算12/9/202256经济可行性考虑的问题(Note5)成本和效益的估算12/7成本分析代码行技术（page19）任务估算技术（page20）总成本、总人力相对误差在内Putnam估算模型（page21）COCOMO模型比较复杂12/9/202257成本分析代码行技术12/7/202257效益分析系统的经济效益＝使用新系统增加收入＋使用心系统可以节省的运行费用总的效益和软件生存周期有关货币的时间价值（page23）投资回收期（page23）投资回收率（page23）纯收入（page23）投资回收率12/9/202258效益分析系统的经济效益＝使用新系统增加收入＋使用心系统可以节系统开发和每年运行费用举例1.系统开发费用（一次）.2名系统分析员(450小时/名,45美元/小时)$40,500.5名系统开发人员(275小时/名,36美元/小时)$49,500.1名数据库管理员(30小时/名,42美元/小时)$1,260.2名技术写作者(120小时/名,25美元/小时)$6,000.1名秘书(160小时/名,15美元/小时)$2,40012/9/202259系统开发和每年运行费用举例1.系统开发费用（一次）12/7/系统开发和每年运行费用举例.1名数据通讯专家(60小时/名,42美元/小时)$2,4002名在转换期间数据输入人员$49,500(40小时/名,12美元/小时)12/9/202260系统开发和每年运行费用举例.1名数据通讯专家(60小时/名,系统开发和每年运行费用举例培训：三天的开发人员内部培训课程$7,00030个用户，三天的内部培训课程$10,000物资：复印$500磁盘、纸张等消耗品$65012/9/202261系统开发和每年运行费用举例培训：12/7/202261系统开发和每年运行费用举例购买硬件、软件：20台工作站Windows软件$1,00020台工作站内存升级$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$161,67012/9/202262系统开发和每年运行费用举例购买硬件、软件：12/7/2022系统开发和每年运行费用举例2.年运行费用（每年）人员：维护程序员/分析员(250小时/年,42美元/小时)

$10,500网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级：硬件$5,000软件$6,000物资和杂项$3,500每年总运行费用$40,00012/9/202263系统开发和每年运行费用举例2.年运行费用（每年）12/7/2操作可行性用户使用可能性时间进度可行性组织和文化上的可行性12/9/202264操作可行性用户使用可能性12/7/202264社会可行性(法律可行性)开发项目是否会在社会上或政治上引起侵权、破坏或其它责任问题12/9/202265社会可行性(法律可行性)开发项目是否会在社会上或政治上引起侵可行性研究计划的完成可行性研究计划12/9/202266可行性研究计划的完成可行性研究计划12/7/202266§2.3可行性研究的步骤（page15）

(1)复查确认系统目标、规模(2)研究正使用系统工作流程(3)导出新系统高层逻辑模型(4)重新定义问题(5)导出和评价供选择的方案(6)推荐可行的方案

(7)草拟开发计划(8)编写可行性研究报告，送审12/9/202267§2.3可行性研究的步骤（page15）(1)复查确认系第三章需求分析和规格说明12/9/202268第三章需求分析和规格说明12/7/202268§3.1为什么需要需求分析开发人员往往急于求成希望对开发进行指导希望开发人员对用户的要求理解希望用户理解开发人员测试部门有理可依12/9/202269§3.1为什么需要需求分析开发人员往往急于求成12/7/2需求分析的任务

准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用<需求规格说明书>规范的形式准确地表达用户的需求。12/9/202270需求分析的任务准确地定义未来系统的目标，确定为了满足什么是用户需求思考、涉及的几个问题如何识别、获取需求?你能够采取何种手段与用户进行交流沟通?何为需求建模?你如何理解模型与建模?12/9/202271什么是用户需求思考、涉及的几个问题12/7/202271软件需求分析的几个阶段问题分析问题评估和方案综合建模规约复审系统分析员的主要焦点是“做什么（what）”，不是“怎样做（how）”12/9/202272软件需求分析的几个阶段问题分析12/7/202272需求获取面临的挑战(Note6)客户说不清楚需求需求易变性问题的复杂性和对问题空间理解的不完备性与不一致性12/9/202273需求获取面临的挑战(Note6)客户说不清楚需求12/7§3.2需求获取的常用方法（Note7）建立分析小组领域专家：主角系统分析员：导演客户访谈问题分析与确认12/9/202274§3.2需求获取的常用方法（Note7）建立分析小组12某出版社系统调查表编号提出问题1您在哪个部门工作？2出版业务流程是什么？3您每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？12/9/202275某出版社系统调查表编号提出问题1您在哪个部门工作？2出版业务某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？12/9/202276某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的听一个故事（Note8）主人公：Contoso制药公司的高级管理长官GerhardContoso公司的信息系统开发小组的新管理员Cynthia内容：客户的需求观

12/9/202277听一个故事（Note8）主人公：12/7/202277谁是客户客户是指直接或间接从产品中获得利益的个人或组织

软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者(stakeholder)或是获得产品所产生的结果的人。12/9/202278谁是客户客户是指直接或间接从产品中获得利益的个人或组织12客户与开发人员之间的合作关系（Note10）

高质量的需求来源于客户与开发人员之间有效的交流与合作

通常，开发人员与客户或客户代理人成为一种对立关系

12/9/202279客户与开发人员之间的合作关系（Note10）高质量的需求软件客户需求权利书（1）（Note11）

客户有如下权利：1.要求分析人员使用符合客户语言习惯的表达。2.要求分析人员了解客户系统的业务及目标。3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4.要求开发人员对需求过程中所产生的工作结果进行解释说明。5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度。12/9/202280软件客户需求权利书（1）（Note11）客户有如下权利：软件客户需求权利书（2）(Note12)6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。7.描述产品使其具有易用、好用的特性。8.可以调整需求，允许重用已有的软件组件。9.当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评估。10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

12/9/202281软件客户需求权利书（2）(Note12)6.要求开发人员软件客户需求义务书（1）(Note13)客户有下列义务：1.给分析人员讲解业务及说明业务方面的术语等专业问题。2.抽出时间清楚地说明需求并不断完善。3.当说明系统需求时，力求准确详细。4.需要时要及时对需求做出决策。5.要尊重开发人员的成本估算和对需求的可行性分析。12/9/202282软件客户需求义务书（1）(Note13)客户有下列义务：软件客户需求义务书（2）（Note14）6.对单项需求、系统特性或使用实例划分优先级。7.评审需求文档和原型。8.一旦知道要对项目需求进行变更，要马上与开发人员联系。9.在要求需求变更时，应遵照开发组织确定的工作过程来处理。10.尊重需求工程中开发人员采用的流程（过程）。

12/9/202283软件客户需求义务书（2）（Note14）6.对单项需求、“签约”意味着什么(Note15)客户与开发人员关系中的重要部分

客户代表经常把“签约”看作是毫无意义的

更为重要的是签名是建立在一个需求协议的基线上

与你的重要客户一起讨论权利书和义务书，以达成协议，并付诸实践12/9/202284“签约”意味着什么(Note15)客户与开发人员关系中的高质量的需求过程带来的好处(Note16)开发后期和整个维护阶段的重做的工作大大减少

强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成

12/9/202285高质量的需求过程带来的好处(Note16)开发后期和整个维优秀需求具有的特性(Note17)1.完整性

2.正确性

3.可行性

4.必要性

5.划分优先级

6.无二义性

7.可验证性

12/9/202286优秀需求具有的特性(Note17)1.完整性12/7/§3.3需求获取的内容

1.用户需求分类(1)功能性需求:定义了系统做什么（描述系统必须支持的功能和过程）(2)非功能性需求（技术需求）:定义了系统工作时的特性（描述操作环境和性能目标）12/9/202287§3.3需求获取的内容1.用户需求分类12/7/202两类需求包括的内容(1)功能(2)性能(3)环境(4)界面(5)用户或人 的因素(6)文档(7)数据(8)资源(9)安全保密(10)软件成本消耗 与开发进度(11)质量保证12/9/202288两类需求包括的内容(1)功能(7)数据12/7/2022(1)功能需求

系统做什么？系统何时做什么？系统何时及如何修改或升级？12/9/202289(1)功能需求系统做什么？12/7/202289(2)性能需求软件开发的技术性指标例如：存储容量限制执行速度、相应时间吞吐量12/9/202290(2)性能需求软件开发的技术性指标12/7/202290(3)环境需求硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统网络数据库12/9/202291(3)环境需求硬件设备：机型、外设、接口、12/7/20(4)界面需求有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？12/9/202292(4)界面需求有来自其它系统的输入吗？12/7/202(5)用户或人的因素

用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？12/9/202293(5)用户或人的因素用户类型？12/7/202293(6)文档需求需哪些文档？文档针对哪些读者？12/9/202294(6)文档需求需哪些文档？12/7/202294(7)数据需求输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？12/9/202295(7)数据需求输入、输出数据的格式？12/7/2022(8)资源需求

软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。12/9/202296(8)资源需求软件运行时所需的数据、软件。12/7/2(9)安全保密要求需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？12/9/202297(9)安全保密要求需对访问系统或系统信息加以控制吗？1(10)软件成本消耗

与开发进度需求开发有规定的时间表吗？软硬件投资有无限制？12/9/202298(10)软件成本消耗

与开发进度需求12/7/(11)质量保证

系统的可靠性要求？系统必须监测和隔离错误吗？规定系统平均出错时间？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性？12/9/202299(11)质量保证系统的可靠性要求？12/7/202299怎样写需求分析报告作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题

如图S={D1，D2，D3，…Dn}Di={P1，P2，P3，…Pm}Pj={F1，F2，F3，…Fk}12/9/2022100怎样写需求分析报告作报告时要先从宏观上讲一、二、三、四、五，怎样写需求分析报告12/9/2022101怎样写需求分析报告12/7/2022101§3.4需求的开发和管理 整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适

需求工程域的层次分解示意图

12/9/2022102§3.4需求的开发和管理 整个软件需求工程研究领域划分为需需求开发(Note18)

问题获取（elicitation）分析(analysis)编写规格说明（specification）验证（verification）

12/9/2022103需求开发(Note18)问题获取（elici知识技能

(Note19)

绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右,关于需求工程的培训，开发管理者和客户管理者也应参加让开发人员了解应用领域的基本概念组织一些简短的关于客户业务活动、术语、目标等方面的讨论会以帮助开发人员对应用领域有个基本了解

12/9/2022104知识技能(Note19) 绝大部分的软件开发人员都没有需求获取(1)(Note20)

确定需求开发过程

编写项目视图和范围文档项目视图

将用户群分类并归纳各自特点

选择每类用户的产品代表

建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求

12/9/2022105需求获取(1)(Note20)确定需求开发过程12/7需求获取(2)(Note21)让用户代表确定使用实例

召开应用程序开发联系会议

分析用户工作流程观察用户执行业务任务的过程

确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点

通过检查当前系统的问题报告来进一步完善

可查看需求是否有足够的灵活性以允许重用一些已有的软件组件

12/9/2022106需求获取(2)(Note21)让用户代表确定使用实例12需求分析（Note22）绘制系统关联图。建立数据字典。为需求建立模型。建立用户接口原型。确定需求优先级。

12/9/2022107需求分析（Note22）绘制系统关联图。12/7/2022需求规格说明（SRS）（Note23）采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板

指明需求的来源

为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号

记录业务规范业务规范创建需求跟踪能力矩阵

12/9/2022108需求规格说明（SRS）（Note23）采用原始模板在你的组需求验证（Note24）对需求文档进行正式审查

以需求为依据编写测试用例编写用户手册在需求开发早期即可起草一份用户手册确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的

12/9/2022109需求验证（Note24）对需求文档进行正式审查12/7/需求管理(Note25)确定一个选择、分析和决策需求变更的过程

建立变更控制委员会

评估每项选择的需求变更跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录记录跟踪每项需求的状态建立一个数据库衡量需求稳定性记录基准需求的数量和变更数量使用需求管理工具商业化的需求管理工具

12/9/2022110需求管理(Note25)确定一个选择、分析和决策需求变更的项目管理（Note26）选择一种合适的软件开发方法生存周期项目开发计划的进度安排将会不断改变发生需求变更时协商项目约定编写文档和管理与需求相关的风险跟踪需求工程所耗的工作量

12/9/2022111项目管理（Note26）选择一种合适的软件开发方法生存周期分析编写文档评审，商议基准需求说明需求变更过程管理客户需求市场当前基线修正后基线市场，客户，管理项目环境需求开发与需求管理之间的界限(Note27)

12/9/2022112分析基准需求说明需求变更过程管理客户市场当前基线修正后基线市§3.5改进需求过程(Note28)软件开发过程的改进有以下两个主要目标：解决在以前项目或目前项目中遇到的问题。防止和避免你可能在将来的项目中要遇到的问题。12/9/2022113§3.5改进需求过程(Note28)软件开发过程的改进有四条改进软件的原则(Note29)改进过程应该是革命性的、彻底的、连续的、反复的

人们和组织机构都只有在他们获得激励时才愿意变更

过程变更是面向目标的将改进活动看作一些小项目12/9/2022114四条改进软件的原则(Note29)改进过程应该是革命性的过程改进周期(Note30)

评价当前采用的方法指定活动改进计划创建、实验和实施新过程评价结果图：软件开发过程改进的周期发现和建议活动计划新的过程，实验结果，获得经验实施情况怎样活动计划的效果如何新过程是否达到预期目标？计划下一步的改进周期12/9/2022115过程改进周期(Note30)评价当前采用的方法指定活动改§3.6软件需求与风险管理（Note31）听一个故事：同样在Contoso制药公司主人公“化学制品跟踪系统”的项目管理人员Dave

首席程序员Helen

首席测试员Ramesh

内容需求工程的风险为何物？12/9/2022116§3.6软件需求与风险管理（Note31）听一个故事：1软件风险管理的要素（Note32）风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些风险评价（riskassessment）风险避免（riskavoidance）

风险控制（riskcontrol）

12/9/2022117软件风险管理的要素（Note32）风险管理就是使用某些工具编写项目风险文档(Note33)12/9/2022118编写项目风险文档(Note33)12/7/2022118与需求有关的风险

下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因素清单和减轻风险的策略。使用这里提供的条目来帮助你识别需求风险并采用条件—结果的格式来书写风险说明。12/9/2022119与需求有关的风险下面介绍的风险因素是按需求工程中获取、分析需求获取

（Note34）1)产品视图与范围2)需求开发所需时间3)需求规格说明的完整性和正确性4)对革新产品的需求5)明确非功能需求6)客户赞同产品需求7)未加说明的需求8)把已有的产品作为需求基线9)给出期望的解决办法12/9/2022120需求获取（Note34）1)产品视图与范围12/7/需求分析（Note35）1)划分需求优先级2)带来技术困难的特性3)不熟悉的技术、方法、语言、工具或硬件平台12/9/2022121需求分析（Note35）1)划分需求优先级12/7/2需求规格说明

（Note36）1)需求理解2)时间压力对TBD的影响3)具有二义性的术语4)需求说明中包括了设计

12/9/2022122需求规格说明（Note36）1)需求理解12/7/2需求验证

（Note37）1)未经验证的需求2)审查的有效性12/9/2022123需求验证（Note37）12/7/2022123需求管理

(Note38)1)变更需求

2)需求变更过程

3)未实现的需求

4)扩充项目范围

12/9/2022124需求管理(Note38)1)变更需求12/7/202建立项目视图与范围(Note39)一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。12/9/2022125建立项目视图与范围(Note39)一个项目可能包括一些与软通过业务需求确定项目视图(Note40)项目视图可以把项目参与者定位到一个共同和明确的方向上

项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能

市场需求文档&视图和范围的文档

来自各个渠道的业务需求可能会发生冲突

12/9/2022126通过业务需求确定项目视图(Note40)项目视图可以把项目项目视图和范围文档的模板(Note41)a.业务需求a.1背景a.2业务机遇a.3业务目标a.4客户或市场需求a.5提供给客户的价值a.6业务风险b.项目视图的解决方案b.1项目视图陈述b.2主要特性b.3假设和依赖环境c.范围和局限性c.1首次发行的范围c.2随后发行的范围c.3局限性和专用性d.业务环境d.1客户概貌d.2项目优先级e.产品成功的因素12/9/2022127项目视图和范围文档的模板(Note41)a.业务需求b.计算机学科的发展计算机科学(CS)计算机科学(CS)计算机工程(CE)软件工程(SE)信息系统(IS)计算学科(computingdiscipline)计算学科是研究通过在计算机上建立模型并模拟物理过程来进行科学调查和研究的学科.12/9/2022128计算机学科的发展计算机科学计算机科学计算机工程软件工程信息学科的3个形态理论抽象(模型化)设计重复出现的概念绑定(binding)概念与形式模型一致性和完备性抽象层次重用……典型的学科方法：数学方法系统科学方法……计算中抽象的本质和使用。在处理复杂事务、构造系统、隐藏细节和获取重复模式方面使用抽象，通过具有不同层次的细节和指标的抽象，能够表达一个实体和系统计算机科学与技术学科的方法论12/9/2022129学科的3个形态计算中抽象的本质和使用。在处理复杂事务模型(model)模型:现实世界某些重要方面的表示。有时我们使用术语“抽象”来表示模型，因为我们从现实世界中抽象出对我们特别有用的东西。12/9/2022130模型(model)模型:现实世界某些重要方面的表示。12/抽象(模型化)源于实验科学,主要要素为数据采集方法和假设的形式说明,模型的构造与预测实验分析结果分析.在为可能的算法数据结构和系统结构等构造模型时使用此过程.抽象的结果是概念符号模型12/9/2022131抽象(模型化)源于实验科学,主要要素为数据采集方法和假设的形§3.4需求分析的步骤当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化抽象化具体化实例化怎么做做什么当前系统目标系统需求定义12/9/2022132§3.4需求分析的步骤当前目标物理逻辑逻辑物理模型化抽象化逻辑模型和物理模型模型是对对象系统的形式化的特征抽象，概括性或近似地表示构造模型的过程是一个抽象、分析的过程。对象系统模型系统抽象（映射）模型应用模型构造的过程12/9/2022133逻辑模型和物理模型模型是对对象系统的形式化的特征对象模型抽象

逻辑模型物理模型

(本质模型、概念模型)

(实施模型、技术模型)现行系统目标系统描述重要的业务功能，无论系统是如何实施的。描述现实系统是如何在物理上实现的。描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。描述新系统是如何实施的（包括技术）。12/9/2022134逻辑模型物理模型现目描述重要的业务分析阶段中常用的模型

（逻辑模型）数据流图（DFD）实体―联系图（ERD）类图实例图时序图状态图协作图事件列表数据流定义数据元素定义……12/9/2022135分析阶段中常用的模型

（逻辑模型）数据流图（DFD）协作图1数据流图

(DFD，DataFlowDiagram)(Note42)

描述逻辑模型的图形工具，表示数据在系统内的变化。 DFD可以用来表示一个系统或软件在任何层次上的抽象。较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。12/9/2022136数据流图

(DFD，DataFlowDiagram)(数据流程图的表示（32）数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或12/9/2022137数据流程图的表示（32）数据源点和终点变换数画数据流图（page32－33）规则：由外向里画画系统的输出、输入化系统的内部画加工的内部12/9/2022138画数据流图（page32－33）规则：由外向里画12/7/应该注意的几个问题（34）适当地命名画数据流而不是控制流先考虑稳定状态忽略琐碎的枝节随时准备重画12/9/2022139应该注意的几个问题（34）适当地命名12/7分层数据流图对于大型系统，往往使用一张数据流图画出所有数据流和加工是不可能的自顶向下逐层分解不要一下子引入过多细节，应该逐步增加细节例子（page35）：

图3.13（a）画出了…..。图3说明“产生新文件”……。显然……。12/9/2022140分层数据流图对于大型系统，往往使用一张数据流图画出所有数据流由顶向下画分层数据流图（page37）描绘中应该注意的问题：编号父图和子图的平衡局部文件分解的程度12/9/2022141由顶向下画分层数据流图（page37）描绘中应该注意的问题实例——运动会管理系统自学3.3.5节（Page40）12/9/2022142实例——运动会管理系统12/7/2022142数据流图的改进检查数据流图的正确性数据守恒（42）文件的使用（page42）父图和子图的平衡（43）提高数据流图的易理解性简化加工间的联系（page43）分解的均匀（page43）适当地命名（44）重新分解（page44）12/9/2022143数据流图的改进检查数据流图的正确性12/7/2022143数据实体关联图(Note43)与数据流图描绘了系统中发生的过程一样，实体联系图（entity-relationshipdiagram，ERD）描绘了系统的数据关系

分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。

实体（entity）是物理数据项（包括人）或者数据项的集合，这对所分析的业务或所要构造的系统是很重要的

12/9/2022144数据实体关联图(Note43)与数据流图描绘了系统中发生的化学制品仓库存货清单化学制品容器存储执行化学制品请求1MM1“化学制品跟踪系统”的实体联系图12/9/2022145化学制品仓库存货清单化学制品容器存储执行化学制品请求1MM1需求建模实例

酒店管理系统的局部DFD已预订的入住预订请求预订预订确认未预订的入住已预订的入住请求未预订的入住请求客人数据客房数据预订确认信息客人信息夜审结算信息财务系统时钟12/9/2022146需求建模实例

酒店管理系统的局部DFD已预订预订请求预订预订需求建模实例：

某金融贸易系统用例图(UML)风险分析交易估计进行交易进行交易接待员酒店系统财务系统12/9/2022147需求建模实例：

某金融贸易系统用例图(UML)风险分析交易需求建模实例：

用例图举例（UML）签定一份保险单客户保险销售人员销售统计客户统计12/9/2022148需求建模实例：

用例图举例（UML）签定一份客户保险销销售需求建模实例：

UML类图实例(Note44)客人姓名地址身份证号码护照号码……预订……入住住宿编号付款方式……退房……客房状态日期人数……设置状态……客房……服务日期数量设置……读取……服务类别名称价格设置……10..*10..*0..*0..11..*10..*1*12/9/2022149需求建模实例：

UML类图实例(Note44)客人姓名预需求建模实例：

描述客房状态的状态图(Note45)取消预定入住已预订空闲占用维修维修完成退房换房入住事件创建12/9/2022150需求建模实例：

描述客房状态的状态图(Note45)取消预需求建模实例：

接电话的顺序图（UML）受话者交换机远程交换机受话者拿起话筒听通话声拨号码铃响信号铃响铃响停止信号拿起话筒铃响停止<10deabc{b-a<1}{e-d<5}{c-b<10}路径12/9/2022151需求建模实例：

接电话的顺序图（UML）受话者交换机远程需求建模实例：

UML协作图举例计算机队列打印服务器打印机打印文件打印机忙保存打印文件打印机空闲打印文件12/9/2022152需求建模实例：

UML协作图举例计算机队列打印打印机打印§3.5数据词典

(DD，DataDictionary) DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解12/9/2022153§3.5数据词典

(DD，DataDictionary词典与数据流图之间关系（page44）数据流图描述了系统的“分解”；依靠“词典”来说明各个成分的含义；数据流图中所有名字的定义就构成一本词典；数据流图和词典结合在一起构成了“需求说明书”数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应该有一个条目给出这个名字的定义。12/9/2022154词典与数据流图之间关系（page44）数据流图描述了系统的词典条目的各种类型（page.45）四个类型条目数据流文件数据项（指不在分解的数据单位）加工词典条目的实例（page46－47）结合上次自习的内容自行学习本节12/9/2022155词典条目的各种类型（page.45）四个类型条目12/7/需求建模实例：

数据字典条目的定义预订请求＝客人数据＋住宿期限+客房类别客人数据＝客人姓名+地址+身份证号码+[护照号码]+支付方式身份证号码=十进制15{数字}18护照号码＝字母+8{数字}8字母＝“A”…“Z”十进制数字＝“0”…“9”12/9/2022156需求建模实例：

数据字典条目的定义预订请求＝客人数据＋住宿期需求建模实例：

数据字典条目的定义F1:航班信息文件＝{航空公司名称＋航班号＋起点＋终点＋日期＋起飞时间＋降落时间}航空公司名称＝2{字母}4航班号＝3{十进制数字}3字母＝“A”…“Z”十进制数字＝“0”…“9”起点＝终点＝1{汉字}10起飞时间＝降落时间＝时＋分12/9/2022157需求建模实例：

数据字典条目的定义F1:航班信息文件＝{航空需求建模实例：

数据字典条目的定义

时＝“00”…“23”分＝“00”…“59”日期＝年＋月＋日年＝[2000｜2001｜2002｜2004]月＝“01”…“12”日＝“01”…“31”12/9/2022158需求建模实例：

数据字典条目的定义12/7/2022158§3.6小说明数据流图中每一个基本加工（即不再进一步被分解的加工）都必须有一个“小说明”小说明中应精确描述用户要求一个加工“做什么” 加工的激发条件加工逻辑加工优先级加工执行频率出错处理12/9/2022159§3.6小说明数据流图中每一个基本加工（即不再进一步被分解结构化的语言（page51）构成方式语态词汇举例12/9/2022160结构化的语言（page51）构成方式12/7/202216判定表与判定树（56）有些问题不易用单纯的语言表达判定表组成：条件桩条件条目操作桩操作条目判定树12/9/2022161判定表与判定树（56）有些问题不易用单纯的语§3.7模型的作用在建模过程中了解系统通过抽象降低复杂性有助于回忆所有的细节有助于开发小组间的交流有助于与用户的交流为系统的维护提供文档

12/9/2022162§3.7模型的作用在建模过程中了解系统12/7/20221需求分析建模方法分析建模方法结构化分析(传统建模方法)面向对象分析12/9/2022163需求分析建模方法分析建模方法12/7/2022163模型的作用计算机世界现实世界影射12/9/2022164模型的作用计算机世界现实世界影射12/7/2022164计算机世界现实世界结构化开发方法结构化分析结构化设计结构化编程OOAOODOOP面向对象开发方法模型的作用12/9/2022165计算机世界现实世界结结构化结构化结构化OOAOODOOP面模结构化分析模型的组成结构数据流图(DFD)E-R图状态变迁图(STD图)加工说明控制说明数据对象说明数据字典（DD）12/9/2022166结构化分析模型的组成结构数据流图E-R图状态变迁图加工说明控面向对象分析模型的组成结构对象-关系模型类/对象模型对象-行为模型使用实例(UseCase)操作、属性、协作者12/9/2022167面向对象分析模型的组成结构对象-关类/对象对象-行为模型使用重点小结12/9/2022168重点小结12/7/2022168§3.8结构化分析方法(StructuredAnalisys,SA)基于数据流技术的分析方法

需求获取应遵循的三条基本原则：分解抽象投影12/9/2022169§3.8结构化分析方法(StructuredAnalis分析模型的元素数据字典(DD)：模型核心(中心库)E-R图(ERD)：数据流图(DFD)

指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能;DFD中每个功能的描述包含在加工规约(小说明)。状态变迁图(STD)指明作为外部事件的结果,系统将如何动作。12/9/2022170分析模型的元素数据字典(DD)：模型核心(中心库)12/7/E-R图是数据建模的基础客人入住客房状态客房服务服务类别姓名地址身份证号码护照号码电话……客房号床位数房间类别价格1……住宿编号住宿时间支付方式……日期，客人数状态(已预定/占用/维修中)……日期，数量……名称，价格……12/9/2022171E-R图是数据建模的基础客人入住客房状态客房服务服务类别姓名将分析模型转换为软件设计数据字典数据流图E-R图状态变迁图加工规约控制规约数据对描

述象数据设计体系结构设计接口设计过程设计分析模型设计模型12/9/2022172将分析模型转换为软件设计数据数据E-R图状态变迁图加工规约控§3.9实例考务处理系统功能(1)对考生送来的报名单进行检查;(2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站;(3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者;(4)制作考生通知单(含成绩及合格/不合格标志)送给考生;(5)按地区进行成绩分类统计和试题难度分析，产生统计分析表。12/9/2022173§3.9实例考务处理系统功能(1)对考生送来的报名单实例

考务处理系统功能考务处理系统的分层DFD如下：12/9/2022174实例考务处理系统功能12/7/2022174顶层数据流图考生考务处理系统考试中心阅卷站不合格报名单报名单准考证考生通知单成绩清单合格标准错误成绩清单考生名单统计分析表12/9/2022175顶层数据流图考考务考阅卷站不合格报名单报名单准考证考生通知单0层数据流图登记报名单报名单准考证1统计成绩2不合格报名单考生通知单成统计分析表考生名册绩清单合格标准考生名单成绩清单错误12/9/20221760层数据流图登记报名单准考证1统计成绩2不合格考生通知单成统一层数据流图(a)检查报名单报名单准考证1.1编准考证号1.2不合格报名单考生名册考生名单合格报名单登记考生1.312/9/2022177一层数据流图(a)检查报名单准考证1.1编准考证号1.2不一层数据流图(b)检查成绩清单2.1审定合格者2.2考生名册正确成绩清单制作通知单2.3分析统计成绩2.4分析试题难度2.5试题得分清单考生通知单难度分析表合格标准分类统计表成绩清单错误成绩清单经审定的成绩清单12/9/2022178一层数据流图(b)检查2.1审定2.2考生名册正确制作2.S23.13.2顶层（不编号）0层1层12/9/2022179S23.13.2顶层0层1层12/数据字典举例F1:航班信息文件＝{航空公司名称＋航班号＋起点＋终点＋日期＋起飞时间＋降落时间}航空公司名称＝2{字母}4航班号＝3{十进制数字}3字母＝“A”…“Z”十进制数字＝“0”…“9”起点＝终点＝1{汉字}10起飞时间＝降落时间＝时＋分12/9/2022180数据字典举例F1:航班信息文件＝{航空公司名称＋航班号12/再来看看——

结构化分析模型的组成结构数据流图(DFD)E-R图状态变迁图(STD图)加工说明控制说明数据对象说明数据字典（DD）12/9/2022181再来看看——

结构化分析模型的组成结构数据流图E-R图状态变§3.11需求分析的其他工作（page63）确定设计限制确定验收标准编写“初步用户手册”复查需求说明书12/9/2022182§3.11需求分析的其他工作（page63）确定设计限制补充知识UML语言和图12/9/2022183补充知识UML语言和图12/7/2022183UML简介（NoteL1）UML定义由信息系统三位专家GradyBooch，JamesRumbaugh和IvarJacobonOMG组织采奶作为业界标准12/9/2022184UML简介（NoteL1）UML定义12/7/202218UML的开发历程（NoteL2）Booch’91其它方法OMT-1OOSEBooch’93OMT-2UML0.8UML0.9&0.91UML1.0UML1.1UML同行专家意见OMG认证10/9510/96&9/96OMG审核,1/97OMG修正,9/97OMG采用,11/97UML1.312/9/2022185UML的开发历程（NoteL2）BoochUML架构（NoteL3）UML由图和元模型组成元元模型层元模型层模型层用户模型层12/9/2022186UML架构（NoteL3）UML由图和元模型组成12/7/UML的模型、视图、图与

系统架构的建模（NoteL4）用例视图逻辑视图并发视图组件视图展开视图12/9/2022187UML的模型、视图、图与

系统架构的建模（NoteL4）用UML与面相对象的软件分析与设计（OOA&D）（NoteL5）标准的表示方法与软件开发的成功经验集成12/9/2022188UML与面相对象的软件分析与设计（OOA&D）（NoteUML的应用领域（NoteL6）UML被用来为系统建模，它可应用的范围非常广泛在不同系统中的应用信息系统技术系统嵌入式实时系统分布式系统商业系统12/9/2022189UML的应用领域（NoteL6）UML被用来为系统建模，它在软件开发不同阶段的应用（NoteL7）需求分析分析设计构造测试12