软件工程基础课件

第1章绪论工程与科学Scienceisconcernedwiththeoryandfundamentals;Engineeringisconcernedwiththepracticalitiesofdevelopinganddeliveringusefulproductorsystem.SciencetheoriesarestillinsufficienttoactasacompleteunderpinningforEngineering.曼哈顿工程质能方程Ｅ＝ｍｃ２

科学/技术/工程科学是以发现为核心的，是对自然的本质及其运行规律的探索、发现和揭示，并归纳为真理，科学家的探索往往是出于好奇心，并没有明确的实用目的。技术是以发明为核心的，是改善人类社会生活的手段，可以是方法、装置、工具、仪器仪表、过程，它讲求的是技巧。工程则是集成科学和技术，来解决实际问题，因此工程是利用科学原理和技术在一定边界条件下进行集成优化和综合优化，有目的地完成设计、构建、运行等项目。（人、财、物）

陈清泉院士工程实例1:都江堰水利工程照片地图成功：引水、分水与排沙宝瓶口：引水鱼嘴：分水飞沙堰：排沙工程实例2:法国戴高乐机场失败：坍塌都江堰水利工程短片及思考短片请思考：工程的目的是什么？工程可持续长期发挥作用的关键何在？工程有何特点？工程师应该有哪些优秀特质？举例都江堰水利工程中如何体现科学/技术/工程？古代工程和现代工程大差别何在？工程的目的服务社会：满足社会生活和生产需要。工程就是利用科技知识解决实际问题。都江堰水利工程科技知识之一：河流的曲流原理——河流有一种走曲线的趋势，河槽中的水流呈螺旋状向前流动着，这一种流动的结果使河岸的凹岸侵蚀冲刷，在凸岸将携带的泥沙堆积。解决实际问题：排沙使成都平原成天府之国，促秦灭楚。工程可持续发展工程长期可持续发挥效益在于工程的维护管理。都江堰水利工程：岁修机构专门官员督办制度每年枯水季节预防性岁修技术深淘滩，低作堰（石马/卧铁）费用当地既丰富又廉价的竹子、木料以及和取之不尽的泥沙和卵石工程的特点系统性工程之间相辅相成，互相制约（全局观）复杂性社会影响；运行环境；工程规模交叉性：多学科知识运用综合性：工程目标之间既相互联系，又互相矛盾(多目标优化)工程师精神：李冰精神勤于职守做了大量事实，政绩辉煌尊重科学知地理，知天文身先士卒考察山形水势，察看民情开拓进取前人未作的河道整治科学/技术/工程宝瓶口引水工程知识：物理学原理热胀冷缩技术：先用火围着石头烧，把石头烧得有红又烫又滚以后，再用冰凉的岷江水去浇，石头经过热胀冷缩便炸开，利于开凿。工程：开凿总共花了八年时间。凿开了江面宽度为20米，河长高度为80米呈梯形状的口子。古代工程与现代工程比较工程的三要素：人、技术和过程古代工程：受制于技术现代工程：受制于人（人的因素更大）1.1软件及其发展软件特征--

反映软件的共性软件分类--

反映软件的个性软件发展与危机-

软件共性与个性的表现

软件是计算机系统中看不见、摸不着的逻辑部分，以程序、数据和文档的形式出现。

1.1.1软件特征（共性）软件与硬件相比较不同的地方，也即所有软件具有的共性：软件不是传统意义上的“制造”产生的，而是“研发”出来的。

导致：软件项目管理和软件产品保护困难。软件不会被“用坏”。

导致：软件维护困难（软件维护不能通过重复制造解决）。软件大多是“定制”的。

导致：软件开发的质量和效率受到影响。软件成本难于估计。

导致：软件项目计划失效。软件特征反映了软件发展所需面对的不同问题背景！按应用功能分类

1.1.2软件分类(个性)1.系统软件：与计算机系统硬件紧密交互，协调计算机系统各部分工作的软件。例如操作系统、设备驱动程序及通信处理程序等。系统软件是计算机系统必不可少的一个组成部分。

2.支持软件：协助使用者开发软件的工具性软件。例如程序编译器、自动化测试软件、系统分析辅助工具及软件开发管理工具等。

3.应用软件：为使用一个计算机系统以得到某种功能而专门开发的软件。例如：商业信息处理软件、工程和科学计算软件、智能产品嵌入软件等。

有时，支持软件和应用软件的划分边界比较模糊，如字处理软件，既是支持软件辅助软件开发，又可看成应用软件。

分类标准：GB/T13702-92系统软件（1）支持软件（2）应用软件（3）×××××××第一层，表示大类第二层，表示中类第三层，表示小类例如：操作系统：110；软件开发工具：310；测试工具：31040按服务对象的范围分类项目软件：软件开发机构受特定用户委托开发而成的软件。例如，电信管理系统、空中交通管制系统、军用防空指挥系统、生产过程控制系统等。一般情况下，项目软件在合同的约束下开发。为了争取软件开发合同，软件开发机构必须重视质量管理，而软件开发机构的技术实力、开发经验以及社会信誉等也相当重要。

产品软件：软件开发机构直接为市场开发的软件。例如，字处理软件、多媒体播放软件、游戏软件、教育软件等等。

产品软件的功能、性能、价格和售后服务对开发机构参与市场竞争有重要影响。

程序设计阶段（20世纪50至60年代）特点：专家的个体手工劳动；程序的写法可以不受任何限制；软件受制于硬件的发展。程序系统阶段（20世纪60至70年代）

特点：软件作坊；开始注重程序设计风格；软件供不应求软件危机（内因：软件本身的特点；外因：软件开发和维护以及组织管理不当）。软件工程阶段（20世纪70年代至今）主要思路：要把人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别是人类从事计算机硬件研究和开发的经验教训，应用到软件的开发和维护中来。

1.1.3软件发展与软件危机

1.2软件工程

性质（能力）：指导软件开发和维护的工程性学科；理论基础：计算机科学、管理科学和数学等；手段：采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经过时间证明正确的管理措施和当前能够得到的最好的技术、方法相结合；目的：以期用较少的代价获取高质量的软件。

经济实用1.2.1软件工程的研究内容

工具和环境层方法和技术层过程和模型层标准和规范层质量核心层软件工程层次结构

软件工程管理做什么？怎么做？为何这样做？

效率？质量？

主线GB/T8566-1995信息技术——软件生存期过程

1.4常用软件生存期模型

软件生存期模型描述了软件项目从需求定义开始，到开发成功后投入使用，在使用的过程中不断增补修订，直到最后停止使用这一期间所进行的各种活动如何执行的模型。

软件开发机构应该综合项目和应用的性质、将要使用的方法和工具等，选择其中合适的模型，并将软件生存期过程映射到选定的模型中进行软件开发和维护。1.4.1瀑布模型

瀑布模型最初由W.Royce于1970年提出。可行性研究项目实施计划需求分析概要设计详细设计编码测试维护可行性研究报告软件项目计划需求规格说明概要设计说明程序规格说明原程序代码测试报告维护报告计划时期开发时期时期运行（时期）（阶段）（文档）瀑布模型的特点各阶段顺序相互依赖；每阶段进行评审；强调需求分析和设计。瀑布模型为软件开发和维护提供了一种有效的管理方式。

瀑布模型比较适合于功能和性能需求明确的软件项目的开发和维护，如编译系统等。

瀑布模型的不足实际软件开发中，各阶段之间并非完全的自上而下线性顺序展开；在开发过程中，用户看不见系统，而只有在交付使用时系统才能和用户见面；

不够灵活（针对需求模糊或变化的情况）。1.4.2原型模型

快速分析快速构造原型运行原型评价原型不满意快速修改原型形成最终系统满意原型模型的特点“快速”开发；用户反馈；逐步完善（原型）。

原型模型比较适合于需求模糊或不确定的软件项目的开发和维护。

相对瀑布模型而言，原型模型更符合人们开发软件的习惯。

原型模型的不足不宜利用原型系统作为最终产品（原型成本问题）；原型模型的“快速”特点对最终系统不适用（原型作用问题定义需求）。

采用原型模型开发系统，用户和开发者必须达成一致：原型被建造仅仅是用来定义需求，之后便部分或全部抛弃，最终的软件要在充分考虑了质量和可维护性等方面之后才被开发。

1.4.3RAD模型

RAD小组1业务建模数据建模处理建模应用生成测试RAD小组2业务建模数据建模处理建模应用生成测试RAD小组n业务建模数据建模处理建模应用生成测试……2~3个月Microsoft倡导的开发模型RAD模型的特点顺序开发（如同瀑布模型）；

业务建模：弄清业务活动中的信息流；数据建模：精化业务建模结果；处理建模：依据数据建模结果，创建处理描述；应用生成：组件复用与开发；测试：新的组件及所有接口。强调极短的开发周期（2-3月）。RAD模型主要用于信息系统应用软件的开发

使用基于组件的建造方法获得快速开发

RAD模型的不足技术风险很高的情况不适合采用；

（如新软件要求与已存在的程序有高可互操性时，或系统难以被适当地划分为若干功能等情况）需要足够的人力以创建足够的RAD小组；开发者和用户需要在很短的时间内完成系统开发。1.4.4增量模型

前述生存期模型，均是一次性地将整个系统交给用户：

瀑布模型是假设当线性阶段完成之后就能交付一个完善的系统。原型模型主要用来帮助开发者获取用户需求，待需求稳定后再开发最终系统提供给用户。RAD模型则先将系统主要功能分给若干RAD小组开发，然后集成起来形成最终系统提交给用户。

业务和产品需求的变化，市场竞争和商业压力等等

以逐步增加软件产品的方式构造软件增量模型

增量模型示意图分析设计编码测试使用第1个增量分析设计编码测试使用第2个增量分析设计编码测试使用第n个增量设计组编码组测试组分析组增量模型的特点可以根据需要补充人员；能够有计划地管理技术风险；能够减少全新软件产品对用户带来的影响；不需要大的资金支出；用户能及早使用及早发现问题；投资回报随功能渐增而渐增。增量模型的不足如果产品整体结构设计不当，则难以为其增加新的增量；（对设计水平要求较高）由于采用增量开发，故难于进行彻底的测试。1.4.5螺旋模型

风险分析原型1风险分析风险分析风险分析操作概念需求计划生命周期计划开发计划集成和测试计划需求确认设计确认和验证实现原型2原型3操作原型模拟，模型，基准软件需求软件产品设计详细设计单元测试编码集成测试验收测试确定目标、方案和限制评估方案识别和消除风险开发、验证下一级产品计划下一阶段评审部分承诺累积成本一步步推进螺旋模型的特点既保持了传统生命周期模型中系统的阶段性方法，又将迭代演化的思想吸收到模型中；螺旋模型是风险驱动的。（风险分析使得用户和开发者能够更好地理解和对待每一个阶段的风险）螺旋模型适合于大型软件的开发

螺旋模型的不足要求软件开发人员善长风险分析；风险分析会导致项目终止而终止合同，出现违约诉讼。对于小项目，风险分析的成本可能与整个项目的成本相当。1.4.6RUP模型OrganizationbyCONTENTOrganizationbyTIMERUP模型的特点DevelopIterativelyManageRequirements（UseCase）UseComponentArchitectureModelVisually(UML)ContinuouslyVerifyQualityManageChange用例驱动；体系结构为中心；迭代；增量式RUP模型的不足太复杂针对不同的应用需要裁剪1.5.1软件工程标准类型

软件工程标准类型是多方面的，如产品标准、过程标准、行业标准和记法标准等。

标准的范围和内容与软件工程有关方面的特性相关。

（GB/T15538-1995采用的分类法由标准划分、软件工程划分和这两种划分的表示关系组成，用二维表格来描述，标准划分确定了标准的作用，软件工程划分确定了与标准有关的软件工程方面的特性。该表格描述了一组可能的标准）

GB/T15538-1995的标准划分

术语表示法语言标准划分过程标准方法技术度量需求设计部件描述计划报告认证职业许可课程产品标准行业标准记法标准GB/T15538-1995的软件工程划分

软件工程划分过程管理产品管理资源管理任务功能产品工程功能需求分析设计编码集成转换排错、调试产品支持软件维护概念阶段产品分析评审和审计测试需求阶段软件生存周期验证与确认功能技术管理功能设计阶段标准分类表软件生存周期

任务功能产品工程验证与确认技术管理需求过程方法8566产品行业记法术语11457标准1.5.2软件工程标准层次

根据软件工程标准制定的机构与适用范围的不同，软件工程标准可分为5个由大到小、由普通到特殊的层次。国际标准国家标准行业标准企业规范项目规范1.5.3软件工程国家标准

分类标准名称标准号（相应其它标准）基础标准软件工程术语GB/T11457-95信息处理、数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定GB1526-89（ISO5807-1985）软件工程标准分类法GB/T15538-1995信息处理、程序构造及其表示法的约定GB13502-92信息处理、单命中判定表规范GB/T15535-1995（ISO5806-1984）信息处理系统，计算机系统配置图符号及约定GB/T14085-93（ISO8790-1987）软件工程国家标准(续)开发标准信息技术、软件生存期过程GB/T8566-1995（代替GB8566-88）计算机软件单元测试GB/T15532-1995软件支持环境GB/T15853-1995信息处理、按记录组处理顺序文卷的程序流程GB/T15697-1995（ISO6593-1985）软件维护指南GB/T14079-93DOS中文信息处理系统接口规范GB/T15189-94软件工程国家标准(续)文档标准软件文档管理指南GB/T16680-1996（ISO/IECTR9294-1990）计算机软件产品开发文件编制指南GB8567-88计算机软件需求说明编制指南GB9385-88计算机软件测试文件编制规范GB936-88计算机软件配置管理计划规范GB/T12505-90软件工程国家标准(续)管理标准信息技术软件产品评价、质理特性及其使用指南GB/T16260-1996（ISO/IEC9126-1991）计算机软件质量保证计划规范GB/T12504-90计算机软件可靠性和可维护性管理GB/T14394-93计算机软件分类与代码GB/T13702-92信息技术、软件包、质量要求和测试GB/T17544-1998（ISO/IEC12119-1994）工业控制用软件评定准则GB/T13423-921.6软件开发方法

所谓软件开发方法就是使用定义好的技术及表示符号来组织软件生产过程的方法。

一般说来软件开发方法必须在以下三个方面作出规定：

①开发步骤（包括每步相应的技术和符号）；②软件文档格式；③开发方案评价标准。

主要软件开发方法：结构化方法、面向对象方法、形式化方法。1.6.1结构化方法

指导思想：自顶向下、逐步求精、单入口、单出口；基本原则：抽象和功能分解；方法论：系统是由一些功能的相互联系、相互作用而形成；结构化方法系列：结构化分析方法、结构化设计方法和结构化程序设计方法。（具体）技术方法：面向数据流图的方法、IDEF0方法、Jackson方法、LCP（LogicalConstructionPrograms）方法等。

结构化方法的特点强调阶段划分；简单实用；技术成熟；应用广泛。特别适合于需求能够预先指定的系统的开发

结构化方法的不足不太适应规模大及特别复杂的项目；难于解决软件重用（复用）问题；难于适应需求变化或模糊的问题；软件维护依然比较复杂。1.6.2面向对象方法

指导思想：尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界的方法与过程。基本原则：对象+类+继承+消息通信。方法论：系统是由一些对象的相互联系、相互作用而形成。

方法系列：面向对象分析、面向对象设计、面向对象程序设计。（具体）技术方法：Coad/Yourdon方法、Booch方法、OMT方法、OOSE方法、IDEF4方法、CRC方法等。面向对象方法的特点对象与功能相比，前者更易于被人们所理解、接受和掌握，确定时客观性更强更稳定，且修改起来也更容易。（类&对象易复用、易维护）描述问题的问题空间与在计算机上解决问题的解空间在结构上相一致。（易理解）面向对象方法中的概念和表示符号，适用于整个软件开发过程。（易学习）软件开发阶段的划分通常比较模糊，分析和设计之间没有鸿沟。（易处理需求模糊或变化的情况）面向对象方法的不足类作为复用单元，有时显得太小；继承会增加类间的耦合性；面向对象方法没有结构化方法成熟；（如对象语义缺乏严格的普遍认可的数学模型）...1.6.3形式化方法

指导思想：借助数学方法来描述目标软件系统。基本原则：形式分析和推理。方法论：系统可以通过严格的、规范化的数学理论经分析、推理得到。方法系列：形式化分析方法、形式化设计方法、转换方法。（具体）技术方法：VDM(ViennaDevelopmentMethod,维也纳)方法、RASIE方法等。形式化方法的特点形式模型完整、一致和无二义性；支持形式推理，便于软件验证；便于软件自动生成；......形式化方法的不足开发成本高；一般人不易接受，需要培训；灵活性差；难以与软件开发过程平滑地结合；支持工具少；......1.6.4开发方法的结合研究

利用各种方法的长处，从而实现优势互补

.S.Liu等人提出了一门SOFL（StructuredObject-basedFormalLanguage）语言和一种集成了结构化方法、面向对象方法和形式化方法于一体的SOFL开发方法学。

在需求分析和规格说明阶段采用结构化方法，在设计和实现阶段采用面向对象方法，在软件开发全过程中一些对软件质量有重要影响的部分采用形式化方法。1.7软件工程工具和环境

工欲善其事，必先利其器;对一个待开发的系统，先考虑采用何种方法（看待系统的立场、观点等），然后再考虑采用何种工具（提高开发质量和效率）。1.7.1软件工具

软件工具是指为支持计算机软件的开发、维护及有关工作而研制的程序系统。

使用软件工具的目的是降低软件开发和维护的成本，提高软件产品的生产效率和质量。

软件工具分类软件开发工具

软件开发工具用于软件开发过程的各种开发活动。需求分析工具设计工具编码工具测试工具分析、设计工具MicrosoftVisioRationalRose编码工具Eclipse（Java程序编辑器）软件维护工具辅助维护人员对代码及其有关文档进行各种维护活动。版本控制工具文档分析工具逆向工程工具（代码-〉设计-〉分析）再工程工具（含逆向和正向工程）再工程工具软件重构工具软件管理和支持工具辅助软件项目管理人员和支持人员的各种管理和支持活动。项目管理工具配置管理工具

开发信息库工具

软件评价工具

软件工具的特点与不足一般情况下一种软件工具只支持一种活动。（软件开发和维护过程中进行的活动较多）工具界面不统一，工具内部无联系，工具切换由人工操作。（对大型软件的开发和维护的支持能力受限）

工具集成化1.7.2集成型软件开发环境

由软件工具集和环境集成机制构成。软件工具集用以支持软件开发的相关过程、活动和任务；（支持某种开发方法）环境集成机制为工具集成和软件开发、维护和管理提供统一的支持。

CASE将软件工具和开发方法集成集成化项目支持环境（IntegratedProjectSupportEnvironment,IPSE）

宿主机硬件和操作系统环境数据库或文件工具与系统界面核心层装入程序测试程序基本层调试程序运行程序配置管理操作支持工具命令解释程序编辑程序各种语言编译程序连接程序需求分析工具测试分析工具维护管理工具快速原型开发工具美化打印工具其它工具用户界面各种方法开发工具（支持软件工程各种方法学）应用层UNIXShell语言ECMA软件开发环境的参考模型

数据存取服务消息服务用户界面服务数据集成服务工具槽任务管理服务北大：青鸟系统1.8软件文档

软件文档为提高软件工程项目的开发和管理能力提供了重要的基础。

在软件生存周期中，软件文档种类多、编制工作量大、技术性强。

一方面要对软件文档的地位和作用应有充分的认识，另一方面要提高文档的质量。1.8.1软件文档的含义及要求

文档是指某种数据媒体和其中所记录的数据。

作用：提高了软件开发过程的可视性；有利于及时纠正错误，减少返工，提高软件开发效率；为开发人员、管理人员以及用户等之间的协作和交流提供了基础。

要求：及时性；完整性；实用性；规范性。1.8.2软件文档的种类

按照文档产生和使用的范围不同，软件文档可以分成三类，即：技术文档、管理文档和用户文档。其中，技术文档和管理文档又统称为系统文档。

技术文档是指在软件开发过程中作为开发人员前一阶段工作成果和后一阶段工作依据的文档。

管理文档是指在软件开发过程中由开发人员等制定并提交给管理人员的工作计划或报告，使管理人员能够通过这些文档了解软件项目的安排、进度、资源使用及成果等。

用户文档是软件开发人员为用户准备的有关该软件使用、操作、维护的资料。

1.8.3软件文档的编写步骤

准备工作；确定写作内容；编写定稿；更新完善。什么是可行性研究？

任何工程项目均应进行可行性研究。软件工程项目可行性研究实质是一次大大压缩和简化了的分析和设计过程，主要在较高层次上以较抽象的方式进行，其目的是在尽可能短的时间内以最小的代价确定该项目是否能够开发，是否值得开发。

2.1可行性研究内容与步骤

可行性研究不是去开发一个软件项目，而是研究该项目能否在给定的资源和给定的时间开发，是否能够开发，是否值得开发。

2.1.1可行性研究的内容

技术可行性（相关技术分析、资源有效性分析、风险分析）；经济可行性（成本估计、效益分析）；操作可行性（就政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等，分析系统能否运行及运行好坏程度）。2.1.2可行性研究的步骤

系统目标和范围的定义

-

要解决的根本问题、达到目标所需的资源和经费；对现行系统进行分析研究

-

现有系统的物理模型和逻辑模型；（入口：现有系统的组织结构）导出新系统的逻辑模型；（解决了有关问题）设计新系统的物理方案；（最先进的方案、实用、基本方案）推荐可行的方案；（包括推荐理由）编写可行性研究报告。（结论：继续、延期和拒绝）2.2系统分析

系统分析是可行性研究阶段对现有系统的功能、数据及约束条件的初步研究，了解现有系统能做什么。

系统分析往往先从系统的组织结构入手，进而分析组织的业务功能及业务流程，最后用数据流图明确信息如何在组织中流动完成指定的业务功能。

2.2.1系统组织结构定义

系统的组织结构反映了组织内部的组成以及它们之间的关系。

内容：组织结构图

业务联系图

业务功能树

组织结构图

在组织结构图中，每个方框表示一个业务域，通过层次分解精化，直至小的工作组或某个个体。例如：

总公司人事处供销处生产处财务处行政处人事科劳资科供应科销售科调研科调度科质检科第一车间第二车间财务科出纳室工会党办总务科业务联系图

业务联系图反映组织各部分与各项业务之间的联系。例如：

业务功能树

用于描述组织内部各部分的业务和功能。2.2.2系统处理流程分析

了解和分析现有系统的业务流程，并以概括的形式表达对现有系统的认识。

系统流程图是描绘物理系统的传统工具，可以采用系统流程图来描述项目的大概业务处理流程，其基本思想是用图形符号以黑盒子形式描绘系统各部件（如程序、数据库、文档、人工过程等）。

系统流程图

系统流程图表达的是信息在系统中各部件之间流动的情况，而不是对信息进行加工处理的控制过程。

开购书证明购书证明开购书发票领书书费单收书费发票学生2.2.3系统数据流分析

数据流图描述的是系统的逻辑模型，图中没有具体的物理元素，只是描绘信息在系统中的流动和处理情况。（数据流图是逻辑系统的图形表示）2.3.1自顶向下成本估计

通常仅由少数上层技术与管理人员参加。依据先前已完成项目所耗费的总成本（总工作量），推算新开发软件的总成本（总工作量），然后在项目内部进行成本分配。

优点:工作量小，速度快。缺点:对开发中某些局部问题或特殊困难易低估，甚至没有考虑。如果所开发的软件缺乏可借鉴的经验，则估计偏差可能较大。

各阶段工作量分配参考2.3.2自底向上成本估计

估计者必须先了解待开发软件的范围。软件范围包括功能、性能、限制、接口和可靠性等。在估算开始之前，应对软件范围进行适当的细化，以提供较详细的细节。对于细化得到的任务单元可交给该任务的开发人员去估计，得到各任务单元的估计成本。然后，将各任务单元的成本汇合成项目的总成本。对涉及全局的花费（如质量管理）可能估计不足甚至完全忽视，使成本估计可能偏低。

基于LOC的成本和工作量估算

2.3.3基于经验模型的成本估计

利用已完成项目的样本数据进行分析，从而建立有关经验公式来预测项目所需的成本、工作量等，具有比较客观（与前面的估算方法相比）、计算结果可重复（即无论何时使用模型，其结果相同）等优点。

由于经验数据是从一些有限的项目中得到的，而且软件类型和开发环境各不相同，因而模型中得到的结果必须慎重使用。

主要经验模型：静态单变量模型；动态多变量模型；

COCOMO模型

静态单变量模型

典型结构为：

E=A+B*(估计变量)C

其中，A、B和C是由经验导出的常数；E是以人月（PM）为单位的工作量；“估计变量”是被估软件特征的估计量，如代码行数等。例如：Walston和FelixE=5.2*(KLOC)0.91D=4.1*(KLOC)0.36=13.47*E0.35DOC=49*(KLOC)1.01S=0.54*E0.6其中，KLOC表示千行源代码行数，以一条机器指令为一行源代码，对于非机器指令编写的源程序，应转换成机器指令源代码行数来考虑。

动态多变量模型

模型把项目的资源需求看成是时间的函数。例如PutnamL=Ck*K4/3*t4/3d其中，L表示源代码行数（以LOC计算）；K表示软件全生存周期（含维护在内）所需工作量（以人年计）；td表示项目开发持续时间（以年计）；CK表示技术状态常数。这表明，如果缩短开发时间，将意味着增加项目的开发工作量。

COCOMO模型

Boehm将软件成本估算分成3个由粗到细的层次：基本层、中间层和详细层。每个层次又按软件项目的应用领域和复杂程序分成3种类型：组织型、半独立型和嵌入层。

模型形式为：TDEV=c*(MM)d

其中MM表示开发工作量，以人月计；KDSI表示源指令条数，以千行计算；TDEV表示开发时间，以月计算；fi(i=1～15)表示15项项目影响调节因子；a,c表示模型系数；b,d表示模型指数。

基本层COCOMO模型

不考虑成本影响调节因子，是对软件成本的一种宏观粗略估计，是一个静态单变量模型。

组织型——较小、较简单的软件项目。

MM=2.4*(KDSI)1.05TDEV=2.5*(MM)0.38半独立型——软件的需求介于“组织型”和“嵌入型”之间。

MM=3.0*(KDSI)1.12TDEV=2.5*(MM)0.35

嵌入型——必须在一组严格的硬件、软件及操作约束下开发的软件项目，对接口、数据结构、算法要求较高。

MM=3.6*(KDSI)1.20TDEV=2.5*(MM)0.32中间层COCOMO模型

主要考虑了从整个生存期来衡量成本影响调节因子，共15项，分成4类：产品、硬件、人员及项目。中间层COCOMO模型形式

组织型：

MM=3.2*(KDSI)1.05*（f1*f2*…*f15）

TDEV=2.5*(MM)0.38

半独立型：

MM=3.0*(KDSI)1.12*（f1*f2*…*f15）

TDEV=2.5*(MM)0.35

嵌入型

MM=2.8*(KDSI)1.2*（f1*f2*…*f15）

TDEV=2.5*(MM)0.32

详细层COCOMO模型

详细层COCOMO模型需要考虑各调节因子对于不同开发阶段的影响。

针对每一个影响因素，按模块级、子系统级和系统级，有三张工作量因素分级表，供不同级别的估算使用。

详细层COCOMO模型的模型形式与中间层COCOMO模型相同，只是fi的取值在详细层COCOMO模型中应分级和分阶段给定。

COCOMO模型评价改进：COCOMOII模型可以处理较广泛的软件工程技术，例如，面向对象、包含瀑布模型及其它生存期模型、复用、第四代语言等等。

Boehm关于自己提出的COCOMO模型的评价意见是：一个软件估算模型能够在成本估算上相差不到20%，时间估算上相差不到70%，就相当不错了。

经验模型运用

当开发产品时，实际的开发工作量应与预测值进行比较。出现偏差可作为一个有问题的早期警告。管理者应该分析出现问题的原因，如开发小组不胜任，产品规模低估了等，并采取合适的行动使影响最小化。

对于经验模型，使用时应根据实际环境进行调整以适合自己的应用项目。同时对于估算结果的精度也不应期望过高。

2.4效益分析

系统的效益有两部分：经济效益和社会效益。

经济效益是指用使用新系统而增加的收入，包括使用新系统节省的运行费用，是一种有形的效益。社会效益是一种无形的效益，主要从性质上、心理上进行衡量，很难直接量化，但在某些情况下，无效的效益能转化成有形的效益。

2.4.1度量指标

货币的时间价值

纯收入投资回收期

投资回收率

货币的时间价值

通常投资在前，取得效益在后，因此要考虑货币的时间价值。货币的时间价值常用利率的形式来表示。

设年利率为i，当前存入的货币数为P(Present)元，则n年后可得到的货币数为F（Future）元：F=P*(1+i)n。

纯收入

其值等于整个生存周期内系统的累积经济效益（折算成当前值）与投资之差。

从经济的观点来看，考虑到软件项目开发的风险，只有当纯收入大于零时才能考虑投资。

投资回收期

投资回收期也是衡量工程价值的一项经济指标，其值等于使累计的经济效益（折算成当前值）等于最初投资所需要的时间。

投资回收期越短，就能越快地获得经济效益，因而这项工程也就越值得投资。

投资回收率

投资回收率可用来衡量投资效益的大小，并可以和银行年利率进行比较，在衡量工程的经济效益时是重要的参考数据。

投资回收率的计算可以通过解下列方程得出：

P=F1/(1+j)+F2/(1+j)2+…+Fn/（1+j）n其中，P表示当前的投资额，Fi表示第i年年底的效益（i=1,2,…,n），n表示系统的使用寿命，j表示投资回收率。

2.4.2效益分析

系统的效益分析随系统的特征而异。

根据总投资的情况和年度效益分析的结果，可以进一步计算纯收入、投资回收期和投资回收率等。管理者根据有关分析结果，结合其它潜在的对投资的使用，考虑有关社会效益，可以在经济上确定系统是否值得投资开发。某大型企业CIMS项目的效益分析示例（1）直接经济效益（每年）总额约为796万元，其中：①实现以物资为主线的生产信息集成，合理制定物资储备定额，缩短物资库存周期，可降低库存2%（平均库存周期从30天降到24天），按现有月未库存1800万元，年利率6.75%计算，每年可节约利息：1800×20%×6.75%=24.3（万元）；

②

…（2）社会效益分析

①通过CIMS应用工程的实施，引入计算机集成制造系统，可加快公司员更新观念的速度，加速公司人员素质的转变，为公司的人才培养战略提供良好的环境。②CIMS工程的实践，…………

2.5可行性研究文档

引言可行性研究的前提（基本要求、开发目标、限定条件等）对现有系统的分析（系统的处理流程和数据流程、存在的问题）所建议的系统（技术可行性）可供选择的其它系统方案

投资及收益分析（经济可行性）社会条件方面的可行性（操作可行性）结论（立即进行；推迟到条件成熟后进行；对开发目标进行某些修改后进行；不能或不必进行等等）文档的编制必须适应软件项目的需要

软件项目计划概述事实表明:软件工程项目的失败，大多是由于计划不周而引起的。软件项目计划的目标就是提供一个框架，使管理者有能够对资源、成本、风险及进度进行合理的估算分析和调度，为软件工程过程提供管理依据。

软件项目计划一般由软件项目的管理员、系统分析员与用户共同制订。

在需求分析阶段弄清软件系统的详细情况后才能正式定稿

3.1风险分析

T.Gilb:如果你不主动攻击风险，风险就会主动攻击你。

主动的、明智的风险管理策略应该在技术工作开始之前，先标识出潜在的风险，评估它们出现的概率及产生的影响，并按重要性加以排序，然后项目组织再制订一个计划来管理风险。风险分析活动：风险标识、风险估计、风险评价和风险管理与监控。

3.1.1风险标识

类型宏观：项目风险、技术风险和商业风险。例如：资金不足（项目风险—预算问题）规格说明存在二义性（技术风险）开发的产品过时（商业风险）

Charette：已知风险、可预测风险和不可预测风险。例如：自然灾害(不可预测风险)

用户计算机知识欠缺（已知风险）用户改变需求（可预测风险）风险标识方法：风险项目检查表(Bohem）产品规模：与待开发或修改的软件的总体规模相关的风险。

商业影响：与管理或市场所加约束相关的风险。

客户特性：与客户的素质以及开发者和客户定期通信的能力相关的风险。

过程定义：与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。

开发环境：与用以建造产品的工具的可用性及质量相关的风险。

建造技术：与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。人员数量及经验：与参与工作的软件技术人员的总体水平及项目经验相关的风险。

3.1.2风险估计

估计风险发生的可能性。风险可能性尺度可以用布尔值、定量或定性的方式表示。（概率）估计与风险相关的问题出现后将会带来的损失：灾难的、严重的、轻微的和可忽略的。（影响值）。3.1.3风险评价

根据风险估计的结果，建立一系列三元组：[ri,pi,ei]，其中ri表示风险，pi表示风险出现的概率，ei表示风险产生的影响；定义项目的各种风险参考水准，如成本、进度等；

找出每个[ri,pi,ei]与各参考水准之间的关系；

预测一组临界点以定义项目的终止区，该区由一条曲线或易变动区域来界定；

预测怎样的风险组合，会影响参考水准。

风险表样本

风险参考水准曲线

估计进度延迟估计成本超支临界点（成本值，时间值）终止项目区3.1.4风险管理与监控

风险管理是指利用某些技术，如原型化、软件自动化、可靠性工程学，以及某些项目管理方法等设法避免或转移风险。

实施风险管理策略会带来一些额外的开销。仅当实施风险管理策略所需的成本小于风险管理带来的效益（即风险带来的影响）时才可考虑实施风险管理策略。高影响且发生概率为中到高的风险以及低影响且高发生概率的风险，应该首先列入管理的考虑之中。

按照Pareto的80-20规则，80%的软件风险能够由仅仅20%的已标出风险来说明。

风险监控

事件和主要风险因素的跟踪，判断一个预测的风险事实上是否发生了；

风险估计，确保针对某个风险制定的风险管理措施正在实施；

收集可用于将来风险分析的信息。

3.2进度安排

方式1:系统最终交付日期已经确定，软件开发组织在这一约束下将工作量进行分配；方式2：系统最终交付日期只确定了大致的期限，最终发布日期由软件开发组织确定，工作量以一种能够最好地利用资源的方式进行分配。

在实际工作中，第一种方式发生的频率远高于第二种方式。

3.2.1进度安排的基本原则

任务分解：将软件工程项目的任务分解成易管理的子任务,即作业;作业依存：确保作业间的依存关系——顺序和并发；时间分配：为每个作业指定开始和终止时间；

资源约束：在进行时间分配时应考虑资源约束，如人员数量、工具；

定义责任：应指定某特定小组负责某个作业；

定义结果：对每个作业定义相应的结果——产品或产品的一部分；

定义里程碑：每个作业或作业系列应与项目的里程碑相联系。

3.2.2工作量分配

40-20-40规则：在整个软件开发过程中，编码的工作量约占20%，编码前的工作量占40%，编码后的工作量也占40%。实际统计:CAD应用开发软件包工作量分配方案示例

3.2.3进度安排方法

原则上可以把一般工程项目的进度安排方法和工具应用于软件工程项目。

首先识别一组项目任务作业，建立任务作业之间的相互关联，然后估算各个任务的工作量，分配人力和其它资源，指定进度时序。

方法：PERT技术和Gantt图方法。

PERT技术

PERT技术（ProgramEvaluation&ReviewTechnique，PERT）

又叫计划评审技术、工程网络技术。

20世纪50年代后期，美国海军和洛克希德公司首次提出这一技术，并成功地应用于北极星导弹的研究和开发。

PERT图

1234567分析3概要设计

3详细设计

4文档整理2测试计划2测试方案设计

3产品测试

4编码30事件作业依赖关系计算事件的EET通常规定，起始事件的最早发生时刻为0；考虑进入该事件的所有作业；对于每个作业均计算其起始事件的最早发生时刻EET与持续时间之和；选取上述和数中的最大值作为该事件的最早发生时刻EET。

计算事件的LET通常规定，工程最后一个事件的最迟发生时刻等于最早发生时刻；考虑离开该事件的所有作业；对于每个作业都计算其结束事件的最迟发生时刻LET与作业持续时间之差；选取上述差数中的最小值作为该事件的最迟发生时该LET。确定关键路径

粗线箭头所示为关键路径

关键事件的EET等于LET利用机动时间安排进度

机动时间=LET-EET-作业持续时间先安排关键作业，再利用机动时间安排非关键作业。3.3.1人员组织规律

Rayleigh-Norden曲线

如果在软件生存周期平均使用人力，则会造成：起始阶段人力过剩（图中①）、开发后期和维护前期人力不足（图中②）和维护时期人力补偿为时已晚（图中③）

各类人员参与程度曲线

初级技术人员在编码时参与最多，而在其它阶段参与则较少；高级技术人员在软件开始的开始阶段和结束阶段参与较多，在中间阶段参与较少；管理人员在项目开始阶段参与较多，其它则参与较少。

人员——时间权衡定律

软件开发工作量与软件开发时间的4次方成反比。如果适当延长软件开发时间，则可减少软件开发的工作量；反之，如果缩短软件开发时间，则工作量会大幅度增加。

Brooks定律

向一个已经延期的软件项目追加开发人员，可能会使它完成得更晚。当开发人员以算术级数增长时，人员之间的通信将以几何级数增长。

由这两条定律，可以得出：对于软件项目，开发时间宁可长一些，开发人员可少而精一些。3.3.2人员组织形式

软件开发机构选择怎样的人员组织形式，要针对软件项目的特点和参与人员的素质来决定。在建立软件开发组织时，应注意：

责任到人——尽早将责任落实，便于管理；

合理分工——减少不必要的通信，提高工作效率；

责权均衡——责任与权力的平衡，有助于任务的完成。

层次模式

软件经理负责整个开发部门的管理工作，在各项目之间分配和协调各种资源。项目经理负责一个具体项目开发的各个方面。每个小组负责项目的一部分工作。审查小组与项目经理同属一个层次，主要从事质量保证活动，在项目开发的里程碑进行技术审查和管理复审。

软件经理项目1经理项目n经理审查小组小组11小组12小组1m小组n1小组n2小组nm………矩阵模式

项目经理注重于问题域知识，阶段经理则熟悉阶段的开发知识。

总经理项目1经理项目2经理项目n经理阶段1经理阶段m经理子项1,1子项2,1子项n,1子项1,m子项2,m子项n,m阶段2经理子项1,2子项2,2子项n,2……………………主程序员小组

最早由H.Mills提出，并由Baker描述出来。主程序员负责制订计划、协调与审查工作，并完成结构设计及代码中关键和复杂部分的实现。技术人员负责项目的具体分析与开发以及文档资料的编写工作。

后备程序员主要协助主程序员的工作，必要时可替代主程序的工作。

1971年，IBM公司首次使用主程序员小组开发《纽约时报》的剪辑文件项目。

主程序员后备程序员其他人员技术人员民主小组

1971年Weinberg首次描述了民主小组的组织形式。

民主小组的最基本概念是“无我程序设计”（egolessprogramming）

日本许多公司使用权用民主小组的组织形式进行软件开发

层次小组

层次间按隶属关系进行通信，组内平等通信。这种组织方式适合于大型软件开发项目，尤其是项目本身就是层次结构状的课题。

项目负者人高级程序员高级程序员程序员程序员程序员程序员程序员程序员3.4软件项目开发计划文档

目的：用文件的形式，把对于在开发过程中各项目工作的负责人员、开发进度、所需经费预算、所需软/硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查项目的开发工作。只有在需求分析之后才能正式定稿。

可能要随项目的进展而不断改变。

需求分析是什么？

需求分析是指开发人员通过细致的调查分析，详细、准确和完整地理解用户需要什么样的软件，将用户非形式的需求陈述转化为完整的需求定义，再将需求定义转换到相应的需求规格说明的过程。通常，把一整套的需求分析方法、技术和工具等的集合称为建模方法。4.1需求分析的特点

问题的复杂性；交流障碍；需求易变性；不一致性和不完整性。开发人员必须与有关人员密切配合，充分交换意见；借助各种建模方法；对用户提出的各项要求开发人员应认真分析，不能机械地全盘接受。

我知道你相信你理解你认为我所说的，但是我不能确定你是否认识到你听到的并不是我所意指的。

SOLUTION4.2需求收集

同各种用户进行交流;收集各种用户的信息;理解用户的各项要求;对信息进行分析;澄清一些模糊的要求;向用户解释不合理的或暂时无法实现的要求

;...如何办？4.2.1

需求收集的内容

信息需求（数据需求）；功能需求；性能需求；运行需求；未来需求。其它方面的需求，如系统交付需求、标准需求、实现方法需求、资源使用需求等。信息功能性能运行未来好难！4.2.2需求收集的方式

访谈；（程式化的访谈和非程式化的访谈）。问卷调查；场景使用；用户资料收集。4.3数据流建模数据流建模方法是一种结构化分析方法；自顶向下、逐层分解地定义系统需求；特点是利用数据流图来对用户需求进行分析；可用于分析任何应用系统的需求（why?）。4.3.1数据流图

数据流(用箭头表示）；加工（加工一般用一个圆圈或圆角方框来表示）；数据存储(一般用开口的矩形框或双划线来表示)；

数据的源点和终点（一般用正方形或立方体来表示）；扩展符号主要有：*、+和⊕。2产生报表定货报表更新库存事务仓库管理员采购员1处理事务D1库存清单D2定货信息分层数据流图

只用一张数据流图来描述，不尽难于一次画齐，而且也难于理解。

分层数据流图可以避免一次引入过多的细节，有利于控制问题的复杂度，从而便于对大型系统描述的实现。

不同的用户可以只选择分层数据流图中与本身有关或感兴趣的部分，不必阅读全图，从而便于用户的使用和理解。

(1)顶层数据流图

顶层数据流图主要描述整个系统的作用范围，说明系统的边界，反映系统和外部环境之间的关系，即系统的输入和输出数据流。

顶层数据流图只有一张。考试事务管理系统考生考试中心阅卷点考生通知单准考证报名表统计报表合格标准考生名单成绩表（2）底层数据流图

底层数据流图由一些不必再进行分解的加工组成。（基本加工）1.1报名表检查1.2准考证编号1.3考生登记F1考生花名册不合格报名表报名表合格报名表准考证已编号报名表考生名单图1（3）中间层数据流图

中间层数据流图是通过分解高层加工得到的，其中有些加工还需进一步分解。

F1考生花名册1报名登记2成绩统计考生名单报名表准考证成绩表考生通知单统计报表合格标准图04.3.2数据词典

数据词典（DataDictionary，DD），又称数据字典，是关于数据信息的集合，是对数据流图中的每个数据，包括数据流和数据存储，进行严格定义的场所，以保持数据在系统中的一致性。

组成描述符数据词典卡片示例

名称：考生名单别名：描述：供阅卷点使用的考生信息表组成：{考生编号+考生姓名}注释：名称：考生编号别名：考号、准考证号描述：考生的统一编号取值及含义：YY××××YY—表示加参考试的年份2位数字××××—表示顺序号，4位数字注释：顺序号从0001开始至9999（a）数据流（b）数据项名称：考生花名册别名：描述：保存考生的个人信息组成：{考生编号+考生姓名+通讯地址+[电话电子邮箱]+（照片）}组织方式：按考生编号从小到大排列注释：照片为彩色，1寸大小名称：查询别名：描述：查询顾客、存货和发票的有关信息组成：[顾客状态查询|存货查询|发标存根查询]数据量：2000次/天峰值：每天上午9:00~10:00有1000次注释：到2005年底预计增加3到5种查询（c）数据存储（d）扩展的数据词（字）典卡片4.3.3加工说明

数据流图中的“基本加工”由于没有进一步分解得到子图，因而需要加工说明来对其进行描述。

描述基本加工如何把输入数据流变换成输出数据流的加工规则；描述实现加工的策略而不是实现加工的细节。

IPO图、结构化语言、判定表、判定树等均可作为加工说明的工具。

（1）IPO（Input/Process/Output）图

IPO图除可用于分析阶段描述加工逻辑说明外，也常与层次图（HierachyChart,HC）一起用于设计阶段，形成HIPO图。

输入框1．主文件2．事务文件处理框1．校验主记录2．校验事务记录3．更新主记录输出框1．有效主记录2．有效事务记录3．更新后的主文件（2）结构化语言

结构化语言，又称PDL（ProgramDesignLanguage,PDL）或伪代码（PseudoCode），是一种介于自然语言和形式语言之间的一种半形式语言。

IF发货单金额>1万元人民币

THENIF账上欠款时间>30天

THEN

在尝还欠款前不批准ELSE

发批准书及发货单ENDIF...（3）判定表/判定树

适合:完成加工的一组动作是由于某一组条件取值的组合而引发的动作。

（续）判定树判定树是判定表的图形表示，有时比判定表更直观。

计算水费固定比率可变比率季度用水<160t季度用水≥160t季度用水≥160t季度用水<160t季度用水≥160t按固定比率计算按表Ⅰ中的比率计算按表Ⅱ中的比率计算按表Ⅱ中的比率计算4.4.1IDEF0图

IDEF0图的主要元素是简单的盒子及箭头。盒子代表系统的功能（活动）。箭头表示系统处理的数据约束，可以是具体的事物，也可以是抽象的信息。

IDEF0图有时也称为活动图形盒子

IDEF0功能建模方法要求一张IDEF0图中的盒子最多只能有6个（子图形还要求不少于3个）

蓝图工单坯料刀具机器制造零件

1调度表样板成品零件切屑输入边线what控制边线why输出边线what机制边线how箭头

分支箭头

表示多个活动需要同一种数据或同一种数据的不同成份。IDEF0图中，箭头代表数据约束，而不是数据流或执行顺序。在同一图上，若几个盒子所需的数据约束都满足，则这个几个活动可同时时执行。

箭头汇合箭头

表示多个活动产生（或合成）同一种数据。

123箭头通道箭头

表示箭头描述的数据约束不出现在子图（或父图）中。

X1a（）

bce（）

d通道箭头可使子图的描述能够得到简化，也可避免在高层父图中出现信息过细的现象，干扰用户对图形的理解。箭头

双向箭头

表示两个盒子描述的活动互为输入或互为控制，且将先触发的盒子画在较高的位置上。

箭头虚线箭头

表示活动触发的先后顺序。

123abcdef箭头选择箭头

表示数据的选择关系。

a或bababa或b分层IDEF0图

为了明确分解过程中数据和图形间的关系，采用ICOM码和结点号来进行标识。

对于来自父盒子的数据约束，分别用I、C、O、M表明来自父盒子的输入、控制、输出及机制边线，并在字母之后跟上数据约束在父盒子中的数字顺序号（编号顺序为：从上至下，从左至右）以表明数据约束在父盒子中的位置，统称为ICOM码。

结点号用来表明图形或盒子在分层IDEF0图中的位置。

ICOM码例子结点树例子对于图形的文字说明，其编号为图形结点号加上字母“T”例如A12T；对于图形的其它参考图形，其编号为图形结点号加上字母“F”后再跟上顺序号，例如A1F4。

A-1A-0A0A1AnA2A21A22A2m……顶层图IDEF0图示例

4.4.2IDEF0建模步骤

IDEF0方法在详细的功能需求调研基础上，用严格的自顶向下、逐层分解的方式来进行。确定建模的范围、观点及目的；建立系统的内外关系图，即A-0图；建立A0图的一系列子图；书写文字说明。4.5IDEF1X数据建模

IDEF1X方法是IDEF1方法的扩展版本。

IDEF1用来表示系统的信息结构和语义。

IDEF1X方法增强了图形的表达能力，丰富了语义和简化了开发过程。4.5.1IDEF1X图实体

实体是具有相同属性或特征的现实或抽象事物的集合，这个集合中的一个元素便称为实体的一个实例。

在一张IDEF1X图中

，一个实体只能在图中出现一次。

实体名/实体编号供应商/2实体名/实体编号供应合同/6（a）独立实体及示例（b）从属实体及示例IDEF1X图联系确定联系：一对一（多）非确定联系：多对多可标定联系非标定联系连接联系分类联系完全分类联系不完全分类联系连接联系

分类联系

·非确定联系及转化实体A/实体A编号·.A到B的联系名/B到A的联系名实体B/实体B编号学期/1课程/2PP·开设/在…开设学期/1学期/2··提供/3属性

属性表示现实或抽象的事物一种特性或性质。

实体名/实体编号属性名……属性名……关键字属性次关键字属性和其它一般属性职员/3职员编号身份编号（AK1）姓名（AK2）生日（AK2）4.6UML建模语言

UML（UnifiedModelingLanguage,UML）是一种可以应用于任面向对象软件开发方法的标记法和语义语言。

如果你有好的思想，那他也是我的。MeyerBeforeandafterconditionsHarelStatechartsGamma,etalFrameworksandpatterns,HPFusionOperationdescriptionsandmessagenumberingEmbleySingletonclassesandhigh-levelviewWirfs-BrockResponsibilitiesOdellClassificationShlaer-MellorObjectlifecyclesRumbaughOMTBoochBoochmethodJacobsonOOSE4.6.1UML结构

构造块

公共机制

构架（4+1视图）物件（建模元素）关系（物件间的联系）

关联、依赖、泛化和实现图（表示模型）结构物件行为物件分组物件注释物件规格说明（图中各元素语义的文字描述）修饰（增强图的整体清晰性和可读性）公共划分（两种公共划分方法：一种是类元和实例；另一种是接口和实现。）扩展机制（三种扩展机制：约束、构造型和标记值。）关系的标记法和语义

UML图

扩展机制

约束是用花括号（{}）括起的文本字符串，用以说明必须维持为真的、有关建模元素的条件和规则。

构造型表示已有模型元素的变体，用以引入新的建模元素，元素的名称用书名号（《》）括起。

标记值的表示为用花括号括起的标记值列表。标记值列表是用逗号分隔的标记值系列，标记和值之间由等到号分隔，例如{tag1=valuel,tag2=value2,…,tagN=valueN}。

UML“4+1”视图构架

逻辑视图（类图、状态图、包图、对象图）实现视图（组件图）进程视图（类图、对象图）部署视图（部署图）用例视图（用例图、活动图、顺序图、协作图）描述用来发布实际系统的文件和软件部件，关注配置管理和系统组装面向编程人员描述硬件拓扑结构和分布。面向系统工程师系统的面向对象模型面向最终用户，分析设计人员描述系统的并发和同步机制，包括进程、线程的组织面向集成人员描述系统行为，用户和系统的交互面向最终用户，分析员和测试人员4.6.2UML静态模型图

类图类图描述了系统的静态特性描述了对象的结构将行为实体描述成“离散”的模型元素，不包括他们的动态行为细节关键元素是类元（类、接口等）以及它们之间的关系类元之间有关联、泛化及各种不同的依赖关系，包括实现和使用关系。类图例子<名称><属性><操作><名称><属性><操作>附加信号信息包图包图由包或类组成，表示包与包、包与类之间的关系，用于描述系统的分层结构。

包图中包用文件夹图形来描述。

保险单填写界面内部系统保险单客户数据库界面Oracle界面Sybase界面组件图

组件图，又称构件图，用来描述软件的各个组件（包括源代码文件、二进制文件、脚本、可执行文件等）之间的依赖关系。

在UML中，组件使用左侧带两个小矩形的大矩形表示。

image.javacomponent.javaImageObserver《interface》ImageObserverabort:int{finalstatic}error:int{finalstatic}imageUpdate()image.javacomponent.java部署图

部署图，又称配置图，显示的是对运行时处理节点以及其中的组件的配置，反映了系统硬件的物理拓扑结构。

在UML中，节点用一个三维矩形表示。

客户PC保险服务器保单填写界面保险系统保险数据库保险系统配置《TCP/IP》对象图

对象图描述的一组对象以及它们之间的关系。

对象是类的一个具体实例，在UML中采用矩阵形表示。其中标明对象名和属性取值。

李冰：Authorname=”李冰”age=28李冰的台式电脑：Computername=”联想1+1”supplier=”联想集团”李冰的手提电脑：Computername=”ThinkPad”supplier=”IBM”使用使用4.6.3UML动态模型图--用例图

用例图从系统外部执行者的角度来描述系统需要提供哪些功能，指明这些功能的参与者，即用例图描述了参与者和用例及它们之间的关系。

简单ATM系统取款存款转帐维护顾客管理员银行系统顺序图

顺序图用来建模以时间顺序安排的对象间的交互。

：Mechanic：Diagnosis：CarTurnOnTurnOnCheckDiagnosisDiagnoseRepairCarTurnOffTurnOff控制权异步消息同步消息协作图

协作图，又称合作图，用来建模对象或角色之间的交互，描述这些对象或角色之间是如何彼此通信的。

：Mechanic：Diagnosis：Car7: