东北大学软件工程复习资料.docx

《东北大学软件工程复习资料.docx》由会员分享，可在线阅读，更多相关《东北大学软件工程复习资料.docx（49页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、东北高校 软件工程 期末复习资料考点：1. 什么是软件，包括什么2. 程序，文档，数据是什么3. 软件类型（两种）4. *软件特点5. 软件危机（定义）6. 软件工程（定义），关注质量，本钱7. 什么是软件生命周期8. 什么是软件过程模型9. 用例是什么的缩写，是什么10. 描绘一个案例，用什么模型11. 需求的重要性12. 软件需求是什么13. 需求工程是什么14. 需求获得的目的15. 需求获得的手段16. 需求分析17. 数据字典流图不考18. 是什么19. 给一个例子，说明缺陷20. 需求验证和管理（理解）21. 面对对象的历史22. 对象，类，消息，继承是什么23. 对象及类的关系2

2、4. 软件建模25. 是什么的缩写26. 关联关系多重性27. 视角28. 面对对象分析是什么29. 面对对象分析建模30. 面对对象分析用例31. 用例是什么，关系，特点32. 用例描绘33. 分析类是什么34. 画类图35. 包是什么36. 包中有什么37. 包之间的关系38. 动态建模39. 状态图40. 类图测试41. 迭代是软件产品内部特点42. 什么是面对对象设计43. 设计的原则44. *模块，耦合，内聚45. 软件复用46. 什么是软件体系构造47. 典型的体系构造风格48. *依次图，协作图49. 问某个方法是哪个对象的方法50. 伪码51. 数据库设计（理解）52. 用户界

3、面设计53. *实现及集成54. 编程及编码的区分55. 编程语言56. 怎么选择适宜的编程语言57. 编码标准，包括哪些58. *维护的类型59. 软件测试60. 软件质量，软件质量保证61. 软件测试类型一： 1. 软件定义n *软件的定义（牢记）l ( ) 在运行中供应所盼望的功能和性能的指令集（即程序）v 程序l 编程语言描绘的一系列语句序列l 供应须要的功能和性能v 数据l 使程序能便利的操纵信息v 文档l 描绘程序研制过程和方法，操作和运用方法的文档n 软件的类型（两种）l 一般软件 干脆供应应市场，或供多个用户运用l 定制软件受某个客户托付，一个或多个软件开发机构为其开发的软件n

4、 *软件的特点（牢记）l , .逻辑产品，非物质的l “ ”.不会磨损l , 开发出来，而非制造l .大部分是定制的l 质量依靠于开发人员的素养l 昂贵l .难以维护2. 软件危机（定义）落后的软件消费方式无法满足快速增长的计算机软件需求，从而导致软件开发及维护过程中出现一系列严峻问题的现象。主要是三个个方面的问题：l 软件的质量低，难以满足需求l 对软件开发时间和本钱的估计缺乏l 如何维护软件数量不断膨胀的已有软件，不断变更的用户需求1. 定义1. 软件工程（定义） 是指导计算机软件开发和维护的工程学科。采纳工程的概念、原理、技术和方法来开发及维护软件，把经过时间考验而证明正确的管理技术和当

5、前可以得到的最好的技术方法结合起来，这就是软件工程。 2. 软件工程的关注（质量，本钱）l 软件质量软件须要一些属性来反响他的质量n 可维护性：适应用户的需求变更n 牢靠性：可依靠，平安的n 效率：不奢侈内存和n 可承受性：便利适用l 软件本钱 用于开发和维护2. 主要元素 过程：软件工程的根底 方法：供应建立软件的技术 工具：供应自动化或半自动化手段来支持过程和方法3. 目的满足用户的需求，同时进步性能，本钱和质量二： 一、 软件生命周期1. *生命周期：一个软件从定义、开发、运用、和维护，直到最终被废弃要经验一个漫长的时期，这个时期称为生命周期。 2. 生命周期涵盖一系列的阶段：l 可行性

6、探讨l 需求分析l 概要设计l 细微环节设计l 实现l 集成l 维护l 退休1. 软件过程是为了获得高质量软件所须要完成的一系列任务的框架，它规定了完成各项任务的工作步骤2. 典型软件过程模型u 瀑布模型 瀑布模型特点： 阶段间具有依次性和依靠性 每个阶段必需完成规定的文档;每个阶段完毕前完成文档审查,及早改正错误,但：v 开发过程一般不能逆转，否则代价太大。v 实际的工程开发很难严格按该模型进展。v 客户往往很难清晰地给出全部的需求，而该模型却要求如此。应用范围： 软件的实际状况必需到工程开发的后期客户才能看到，这要求客户有足够的耐性。 用户的需求特别清晰全面，且在开发过程中没有或很少变更

7、开发人员对软件的应用领域很熟识。 用户的运用环境特别稳定。 开发工作对用户参及的要求很低 u 快速原型模型 根本是首先建立一个可以反映用户主要需求的原型系统让用户在计算机上运行、试用这个原型系统，通过 及原型交互及早发觉需求的缺陷；设计人员也可检查设计的可行性。快速设计建立原型用户评估原型，提出新需求对原型进展加工开发产品初步需求分析完毕开场原型可以利用第四代语言面对对象的应用程序框架，原型开发活动、用户反响、开发者修改原型的重复迭代过程可进步用户满足程度，也可缩短软件开发周期，从而降低了开发和维护本钱。在该模型中，如何快速进展原型的开发是关键，快速开发原型的途径一般可以有三种：利用计算机模拟

8、一个软件的人机界面及交互方式。开发一个能实现部分功能(如输入界面、输出格式等)的软件，这部分功能往往是重要的，但也可能是简洁引起误会的。找寻一个或几个类似的正在运行的软件，利用这些软件向客户展示软件需求中的部分或全部功能。为了快速地开发原型，要尽量采纳软件重用技术，以争取时间，尽快地向客户供应原型。()特点l 该模型是基于原型驱动的。l 可以得到比拟良好的需求定义，便于开发者及客户进展全面的沟通及沟通。而且原型系统也比拟简洁适应用户需求的变更。l 原型系统既是开发的原型，又可以作为培训的环境，这样有利于开发及培训的同步。l 原型系统的开发费用低、开发周期短、维护简洁且对用户更友好。尽管开发者和

9、客户都喜爱运用原型模型，但原型模型也有其固有的缺点：在对原型的理解上客户及开发者有很大的差异，客户以为原型就是软件的最终版本，而开发者只将原型当作一个美丽美丽的软件外壳，在实际开发过程中要对原型进展不断修改完善，这就须要开发人员及客户互相沟通、互相理解。由于原型是开发者快速设计出来的，而开发者对所开发领域的生疏简洁将次要部分当作主要的框架，做出不切题的原型。软件的整个开发都是围围着原型来绽开的，在肯定程度上不利于开发人员的创新。u 增量模型 把软件产品分解成增量构件。原则：当把新构件集成到原有构件时，所形成的产品必需是可测试的。它能在较短时间内向用户提交可完成部分工作的产品，尽早的得到回报。要

10、求开场实现各个构件前就全部完成的需求分析、规格说明、总体设计。u 螺旋模型 螺旋模型：沿螺线自内向外每旋转一圈便开发出一个更为完善的软件版本 螺旋模型的根本思想：运用原形及其他方法来尽量降低风险。可以看作每个阶段前都加了风险分析的快速原型模型。螺旋模型是风险驱动型的。v 总结u 面对对象模型l 喷泉模型 、喷泉模型的优点各阶段穿插、迭代，支持复用喷泉模型不像瀑布模型那样，须要分析活动完毕后才开场设计活动，设计活动完毕后才开场编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进展开发。其优点是可以进步软件工程开发效率，节约开发时间，适应于面对对象的软件开发过程。、喷泉模型的缺点由于喷泉模

11、型在各个开发阶段是重叠的，因此在开发过程中须要大量的开发人员，因此不利于工程的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时参加各种信息、需求及资料的状况。l 统一过程模型 用例驱动整个开发过程 迭代增量式开发 基于构件的软件体系构造为中心绽开开发 运用统一建模语言（） ( ) (计算机协助软件工程)用来协助软件开发、运行、维护、管理、支持等过程中活动的软件称为软件工具三： 一、 ?什么是需求工程 (软件需求) 用户对软件功能，性能，设计等方面的需求 （需求工程） 这个过程获得用户或最终运用者对软件的需求 包括一系列的任务来理解软件的需求 扶植软件工程师更好的理解他

12、们须要解决的问题 ( )需求获得 需求分析 需求说明 需求认证 需求管理二、 需求获得技术n 目的确定和搜集及待开发的软件系统相关的信息获得需求，确定问题，定义问题范围，解决冲突n 关键要及用户沟通，搜集和理解需求n 获得方法 采访消费者 研讨需求 问卷调查 建了原型1. 需求分析模型 重点是建立分析模型是对现实的简化，分析模型定义了系统的具体需求，但不限于一种技术 传统方法： (), , (), ,（数据流图，数据字典，状态转换图） 面对对象方法： , , , , （用例，依次图，协作图，类图，状态图） 需求分析过程 定义系统范围 分析需求的可行性 确定需求的优先级 形成需求分析模型 建立数

13、据字典 数据流图 建立一个系统的输入输出模型 用来描绘系统的功能和行为优点 易于理解 便利开发者和用户间的沟通符号（外部实体，处理，数据流，数据储存）1) 外部实体（原点和汇点）外部项是指系统以外的事物或人，表达了该系统数据的外部来源或去处，用方框表示之。2) 处理（加工）处理表达了对数据的逻辑加工或变换功能：对数据的加工处理的结果，或者是变换了数据的构造，或者是在原有数据的根底上产生新的数据。处理用圆表示。3) 数据流数据流指示数据的流淌方向，用单箭头表示。4) 数据存储数据存储指明了保存数据的地方。不代表具体的存储介质。数据存储运用右端开口的矩形框表示。 : 分层数据流图为了表达数据处理过

14、程的数据加工状况，用一个数据流图是不够的。稍为困难的实际问题，在数据流图上经常出现十几个甚至几十个加工。这样的数据流图看起来很不清晰。层次构造的数据流图能很好地解决这一问题。根据系统的层次构造进展逐步分解，并以分层的数据流图反映这种构造关系，能清晰地表达和简洁理解整个系统。画数据流图的方法画数据流图的根本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。检查和修改的原则为：1) 由外及里画数据流图2) 自顶向下分层画数据流图分解应遵循下列原则：l 分解要自然，留意概念上的合理性；l 以分层方式对处理编号；l 留意父图及子图的平衡，即子图全部的输入和输出数据流应当是父图中相应处理的全部输

15、入和输出数据流；l 一个处理一般可分解成个子处理，不宜过多；l 当进一步分解可能涉及具体的物理实现手段时，分解应终止。3) 检查和修改的原则为： 数据流图上全部图形符号只限于前述四种根本图形元素。 顶层数据流图必需包括前述四种根本元素，缺一不行。 顶层数据流图上的数据流必需封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输出数据流。 在数据流图中，需按层给加工框编号。编号说明该加工处在哪一层，以及上下层的父图及子图的对应关系。 规定任何一个数据流子图必需及它上一层的一个加工对应，两者的输入数据流和输出数据流必需一样。此即父图及子图的平衡。 可以在数据流图中参加物质流，扶植用户理解数据流

16、图。 图上每个元素都必需出名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，说明流淌的数据是什么。加工的名字应当是“动词宾语”，说明做什么事情。 数据流图中不行夹带限制流。 初画时可以忽视琐碎的细微环节，以集中精力于主要数据流。数据流图作用：开发人员及用户，软件人员及软件人员之间的桥梁；验收的根据例子 数据字典数据图反映了数据在系统中的流向以及数据的转换过程，但它无法描绘有关数据流、数据存储、处理逻辑和外部项的进一步具体的内容。数据字典用于较具体地定义或说明数据留图的四个根本成分。数据兔和数据字典共同构造系统的逻辑模型。没有数据字典，数据流图就不严格。2. (, 软件需求规格说明)v

17、 定义：准确描绘一个软件系统的功能和性能v 软件需求规格说明应包含的内容 引言：软件目的及范围 数据描绘：数据流图（系统逻辑模型）、数据字典（一切数据的定义） 外部接口：怎样及人，硬件，和其他系统交互 功能描绘：功能说明，应当供应什么功能 性能描绘：性能说明 特征描绘：软件的平安性，可操作性等 限制条件：应遵循的标准（语言，环境，标准.）v 不应当包含的内容 开发安排 保险安排 设计细微环节v 的质量 正确性：能争取表达用户的需求 无歧义：每个人都要有一样的理解 完好：须要包括软件的全部任务 可验证性：每一个需求都能验证和确定 一样性：需求的描绘不能有冲突 可修改性：简洁修改，每个应当有索引且

18、需求不能穿插引用 可追溯性：每个需求都和它的资源，设计，代码，测试用例相联络1. 需求确认证好用户对需求是否满足 需求推断 原型评价 生成测试用例分析修改造成的影响，限制修改的过程包括：修改限制，版本限制，需求追踪四： 一、 面对对象方法介绍1. 定义和历史出现后，代替的传统的建模方法2. 面对对象软件工程l ()面对对象分析l ()面对对象设计l ()面对对象编程l 是一个平稳的过度，可以进步开发的效率和质量l ()面对对象测试l 面对对象软件维护二、 面对对象根底v (对象)：系统中用来描绘现实中事物的实体 包括一些属性（描绘静态特征）和操作方法（描绘动态特征） 软件系统的根本单元v （类

19、）：一组拥有一样属性和方法的对象v * 类和对象的比拟 类是静态的，在程序运行前已经定义 对象是动态的，在程序运行是创立 对象是类的一个实例在 的过程中，我们强调类，而不是对象v （消息）：来自于对象的恳求v （封装）：隐藏对象的属性和实现细微环节，仅对外公开接口,限制在程序中属性的读和修改的访问级别 v （继承）：意味着子类可以拥有父类的全部属性和方法v （多态）：多态指同一个实体同时具有多种形式。子类继承的属性和方法，可以不同于父类，供应敏捷的软件设计方法，进步软件复用v 根本概念：1. 软件建模描绘现实世界重要的部分三、 统一建模语言() 一个可视的建模语言，但不是一个可视编程语言 一个

20、支持开发的工具，但不是万能的 一个建模的描绘 (可视化的) (具体描绘的) (构造的) (文档化的)矩形线 其他图形 特征字符串（关于更具体的方法，自己看书吧。）五 面对对象分析的主要任务是用面对对象的概念和方法为软件需求建立模型。 用例建模. 什么是用例？在介始用例方法之前，我们首先来看一下传统的需求表述方式软件需求规约( )。传统的软件需求规约根本上采纳的是功能分解的方式来描绘系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描绘细分的系统模块的功能来到达描绘整个系统功能的目的。一个典型的软件需求规约可能具有以下形式：采纳这种方法来描绘系统需求，特别简洁混淆需求和设计

21、的界限，这样的表述事实上已经包含了部分的设计在内。由此经常导致这样的迷惑：系统需求应当具体到何种程度？一个极端就是需求可以具体到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为内部需求，而对应于用户的原始要求则被称之为外部需求。功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难理解到这些功能项是如何互相关联来实现一个完成的系统效劳的。所以在传统的文档中，我们往往须要另外一些章节来描绘系统的整体构造及各部分之间的互相关联，这些内容使得需求更象是一个设计文档。 参及者和用例从用户的角度来看，他们并不想理解系统

22、的内部构造和设计，他们所关切的是系统所能供应的效劳，也就是被开发出来的系统将是如何被运用的，这就用例方法的根本思想。用例模型主要由以下模型元素构成： 参及者() 参及者是指存在于被定义系统外部并及该系统发生交互的人或其他系统，他们代表的是系统的运用者或运用环境。 用例( ) 用例用于表示系统所供应的效劳，它定义了系统是如何被参及者所运用的，它描绘的是参及者为了运用系统所供应的某一完好功能而及系统之间发生的一段对话。 通讯关联( ) 通讯关联用于表示参及者和用例之间的对应关系，它表示参及者运用了系统中的哪些效劳（用例），或者说系统所供应的效劳（用例）是被哪些参及者所运用的。这大三种模型元素在中的

23、表述如下图所示。以银行自动提款机()为例，它的主要功能可以由下面的用例图来表示。的主要运用者是银行客户，客户主要运用自动提款机来进展银行帐户的查询、提款和转帐交易。通讯关联表示的是参及者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动承受者；假如你不想强调对话中的主动及被动关系，可以运用不带箭头的关联实线。在参及者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描绘的就是参及者和系统之间的对话），并且信息流向是双向的，它及通讯关联箭头所指的方向亳无关系。 用例的内容用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参及者

24、会及系统发生交互，每一个参及者须要系统为它供应什么样的效劳。用例描绘的是参及者及系统之间的对话，但是这个对话的细微环节并没有在用例图中表述出来，针对每一个用例我们可以用事务流来描绘这一对话的细微环节内容。如在系统中的提款用例可以用事务流表述如下：提款根本领件流. 用户插入信誉卡. 输入密码. 输入提款金额. 提取现金. 退出系统，取回信誉卡但是这只描绘了提款用例中最顺当的一种状况，作为一个好用的系统，我们还必需考虑可能发生的各种其他状况，如信誉卡无效、输入密码错、用户帐号中的现金余额不够等，全部这些可能发生的各种状况（包括正常的和异样的）被称之为用例的场景()，场景也被称作是用例的实例()。在

25、用例的各种场景中，最常见的场景是用根本流( )来描绘的，其他的场景则是用备选流( )来描绘。对于系统中的提款用例，我们可以得到如下一些备选流：提款备选事务流备选流一：用户可以在根本流中的任何一步选择退出，转至根本流步骤。备选流二：在根本流步骤中，用户插入无效信誉卡，系统显示错误并退出信誉卡，用例完毕。备选流三：在根本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到根本流步骤；三次输入密码错误后，信誉卡被系统没收，用例完毕。通过根本流及备选流的组合，就可以将用例全部可能发生的各种场景全部描绘清晰。我们在描绘用例的事务流的时候，就是要尽可能地将全部可能的场景都描绘出来，以保

26、证需求的完备性。 用例方法的优点用例方法完全是站在用户的角度上（从系统的外部）来描绘系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关切系统内部是如何完成它所供应的功能的。用例方法首先描绘了被定义系统有哪些外部运用者（抽象成为），这些运用者及被定义系统发生交互；针对每一参及者，用例方法又描绘了系统为这些参及者供应了什么样的效劳（抽象成为 ），或者说系统是如何被这些参及者运用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。及传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求及设计完全分别开来。在面对对象的分析设计方法中，用例模型主要用于表述系

27、统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的运用环境及上下文，每一个用例描绘的是一个完好的系统效劳。用例方法比传统的更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进展沟通的一个有效手段。在中，用例被作为整个软件开发流程的根底，许多类型的开发活动都把用例作为一个主要的输入工件()，如工程管理、分析设计、测试等。根据用例来对目的系统进展测试，可以根据用例中所描绘的环境和上下文来完好地测试一个系统效劳，可以根据用例的各个场景()来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。. 建立用例模型运用用例的方法来描绘系统的功能需求的过程就是用例

28、建模，用例模型主要包括以下两部分内容： 用例图( ) 确定系统中所包含的参及者、用例和两者之间的对应关系，用例图描绘的是关于系统功能的一个概述。 用例规约( ) 针对每一个用例都应当有一个用例规约文档及之相对应，该文档描绘用例的细微环节内容。在用例建模的过程中，我们建议的步聚是先找出参及者，再根据参及者确定每个参及者相关的用例，最终再细化每一个用例的用例规约。 找寻参及者所谓的参及者是指全部存在于系统外部并及系统进展交互的人或其他系统。通俗地讲，参及者就是我们所要定义系统的运用者。找寻参及者可以从以下问题入手： 系统开发完成之后，有哪些人会运用这个系统？ 系统须要从哪些人或其他系统中获得数据？

29、 系统会为哪些人或其他系统供应数据？ 系统会及哪些其他系统相关联？ 系统是由谁来维护和管理的？这些问题有助于我们抽象出系统的参及者。对于机的例子，答复这些问题可以使我们找到更多的参及者：操作员负责维护和管理机系统、机也须要及后台效劳器进展通讯以获得有关用户帐号的相关信息。 系统边界确定了参及者参及者是由系统的边界所确定的，假如我们所要定义的系统边界仅限于机本身，那么后台效劳器就是一个外部的系统，可以抽象为一个参及者。假如我们所要定义的系统边界扩大至整个银行系统，机和后台效劳器都是整个银行系统的一部分，这时候后台效劳器就不再被抽象成为一个参及者。值得留意的是，用例建模时不要将一些系统的组成构造作

30、为参及者来进展抽象，如在机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参及者；在一个管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参及者。 特殊的参及者系统时钟有时候我们须要在系统内部定时地执行一些操作，如检测系统资源运用状况、定期地生成统计报表等等。从外表上看，这些操作并不是由外部的人或系统触发的，应当怎样用用例方法来表述这一类功能需求呢？对于这种状况，我们可以抽象出一个系统时钟或定时器参及者，利用该参及者来触发这一类定时操作。从逻辑上，这一参及者应当被理解成是系统外部的，由它来触发系统所供应的用例对话。 确定用例找到参及者之后，我们就可以根据

31、参及者来确定系统的用例，主要是看各参及者须要系统供应什么样的效劳，或者说参及者是如何运用系统的。找寻用例可以从以下问题入手（针对每一个参及者）： 参及者为什么要运用该系统？ 参及者是否会在系统中创立、修改、删除、访问、存储数据？假如是的话，参及者又是如何来完成这些操作的？ 参及者是否会将外部的某些事务通知给该系统？ 系统是否会将内部的某些事务通知该参及者？综合以上所述，系统的用例图可表示如下，在用例的抽取过程中，必需留意：用例必需是由某一个主角触发而产生的活动，即每个用例至少应当涉及一个主角。假如存在及主角不进展交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参及者是否被遗漏，

32、假如是，则补上该参及者。反之，每个参及者也必需至少涉及到一个用例，假如发觉有不及任何用例相关联的参及者存在，就应当考虑该参及者是如何及系统发生对话的，或者由参及者确定一个新的用例，或者该参及者是一个多余的模型元素，应当将其删除。可视化建模的主要目的之一就是要增加团队的沟通，用例模型必需是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必需留意参及者和用例的名称应当符合肯定的命名约定，这样整个用例模型才可以符合肯定的风格。如参及者的名称一般都是名词，用例名称一般都是动宾词组等。对于同一个系统，不同的人对于参及者和用例都可能有不同的抽象结果，因此得到不同的用例模型。我们须要在多

33、个用例模型方案中选择一种最佳（或较佳）的结果，一个好的用例模型应当可以简洁被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应当是一样的。 描绘用例规约应当避开这样一种误会认为由参及者和用例构成的用例图就是用例模型，用例图只是在总体上大致描绘了系统所能供应的各种效劳，让我们对于系统的功能有一个总体的相识。除此之外，我们还须要描绘每一个有例的具体信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的具体描绘用例规约所组成的。中供应了用例规约的模板，每一个用例的用例规约都应当包含以下内容： 简要说明 ( ) 简要介绍该用例的作用和目的。 事务流 ( ) 包括根本流和备选流，事务流应

34、当表示出全部的场景。 用例场景 ( ) 包括胜利场景和失败场景，场景主要是由根本流和备选流组合而成的。 特殊需求 ( ) 描绘及该用例相关的非功能性需求（包括性能、牢靠性、可用性和可扩展性等）和设计约束（所运用的操作系统、开发工具等）。 前置条件 () 执行用例之前系统必需所处的状态。 后置条件 () 用例执行完毕后系统可能处于的一组状态。用例规约根本上是用文本方式来表述的，为了更加清晰地描绘事务流，也可以选择运用状态图、活动图或序列图来协助说明。只要有助于表达的简洁明了，就可以在用例中随意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描绘困难的决策流程，状态转移图有助于描绘

35、及状态相关的系统行为，序列图合适于描绘基于时间依次的消息传递。 根本流根本流描绘的是该用例最正常的一种场景，在根本流中系统执行一系列活动步骤来响应参及者提出的效劳恳求。我们建议用以下格式来描绘根本流：) 每一个步骤都须要用数字编号以清晰地标明步骤的先后依次。) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过阅读标题来快速地理解用例的主要步骤。在用例建模的早期，我们也只须要描绘到事务流步骤标题这一层，以免过早地陷入到用例描绘的细微环节中去。) 当整个用例模型根本稳定之后，我们再针对每一步骤具体描绘参及者和系统之间所发生的交互。建议采纳双向()描绘法来保证描绘的完好性，即每一步骤都须

36、要从正反两个方面来描绘:()参及者向系统提交了什么信息；()对此系统有什么样的响应。具体例子请参见附录。在描绘参及者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参及者输入了客户信息就不够明确，最好明确地说参及者输入了客户姓名和地址。通常可以利用词汇表让用例的困难性保持在可控范围内，可以在词汇表中定义客户信息等内容，运用例不至于陷入过多的细微环节。 备选流备选流负责描绘用例执行过程中异样的或间或发生的一些状况，备选流和根本流的组合应当可以覆盖该用例全部可能发生的场景。在描绘备选流时，应当包括以下几个要素：) 起点：该备选流从事务流的哪一步开场；) 条件：在什么条件下会触发该备选

37、流；) 动作：系统在该备选流下会实行哪些动作；) 复原：该备选流完毕之后，该用例应如何接着执行。备选流的描绘格式可以及根本流的格式一样，也须要编号并以标题概述其内容，编号前可以加以字母前缀()以示及根本流步骤相区分。 用例场景用例在实际执行的时候会有许多的不同状况发生，称之为用例场景；也可以说场景是用例的实例，我们在描绘用例的时候要覆盖全部的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描绘可以由根本流和备选流的组合来表示。场景既可以扶植我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的扶植：开发人员必需实现全部的场景、测试人员可以根据用例场景来设计测试用例。 特殊需求特殊需

38、求通常是非功能性需求，它为一个用例所专有，但不合适在用例的事务流文本中进展说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、牢靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。须要留意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在补充规约中。 前置和后置条件前置条件是执行用例之前必需存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。 检查用例模型用例模型完成之后，可以对用例模型进展检查，看看是否有遗漏或错误之

39、处。主要可以从以下几个方面来进展检查： 功能需求的完备性 现有的用例模型是否完好地描绘了系统功能，这也是我们推断用例建模工作是否完毕的标记。假如发觉还有系统功能没有被记录在现有的用例模型中，那么我们就须要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。 模型是否易于理解 用例模型最大的优点就在于它应当易于被不同的涉众所理解，因此用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系困难程度都应当由该指导原则确定。 是否存在不一样性 系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特殊留意不同工件之前是否存在前后

40、冲突或冲突的地方，避开在模型内部产生不一样性。不一样性会干脆影响到需求定义的准确性。 避开二义性语义 好的需求定义应当是无二义性的，即不同的人对于同一需求的理解应当是一样的。在用例规约的描绘中，应当避开定义含义模糊的需求，即无二义性。. 系统需求中根据模型将系统需求分为以下几类： 功能() 可用性() 牢靠性() 性能() 可支持性() 设计约束等除了第一项功能性需求之外的其他需求都归之为非功能性需求。 需求工件集用例模型主要用于描绘系统的功能性需求，对于其他的非功能性须要用其他文档来记录。中定义了如下的需求工件集合。 用例模型：记录功能性需求o 用例图：描绘参及者和用例之间的关系o 用例规约

41、：描绘每一个用例的细微环节信息 补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等 词汇表：记录一些系统需求相关的术语在实际应用中，除了这些工件之外，我们还可以根据实际需求敏捷选用其他形式的文档来补充说明需求。并不是全部的系统需求都适保合用用例模型来描绘的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种状况下，采纳传统的范式来表述更加适宜一些。在电信软件行业中，许多电信标准都是采纳语言来描绘的，我们也不必用来改写这些标准（对存在着这样的兼容性），只需将形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不行拘泥于用例建模的形式，应敏捷运用各

42、种方式的特长。 补充规约补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。 功能性 功能性需求主要在用例模型中刻画，但是也有部分需求不合适在用例中表述。有些功能性需求是全局性的，适用于全部的用例，如出错处理、支持等，我们不须要在全部的用例中描绘这些功能性需求，只须要在补充规约中统一描绘就可以了。 可用性 记录全部可用性相关的需求，如系统的运用者所须要的培训时间、是否应附合一些常见的可用性标准如界面风格等。o 牢靠性 定义系统牢靠性相关的各种指标，包括： 可用性：指出可用时间百分比()，系统处于运用、维护、降级形式等操作的小时数；o 平均故障间隔时间()：通常表示为小时数，但也可

43、表示为天数、月数或年数；o 平均修复时间()：系统在发生故障后可以暂停运行的时间；o 准确度：指出系统输出要求具备的精细度（辨别率）和准确度（根据某一已知的标准）；o 最高错误或缺陷率：通常表示为（每千行代码的错误数目）或（每个功能点的错误数目）。o 性能 记录系统性能相关的各种指标，包括： 对事务的响应时间（平均、最长）；o 吞吐量（例如每秒处理的事务数）；o 容量（例如系统可以包容的客户或事务数）；o 降级形式（当系统以某种形式降级时可承受的运行形式）；o 资源利用状况：内存、磁盘、通信等。 可支持性 定义全部及系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对

44、系统进展维护操作和相应的维护好用工具等。 设计约束 设计约束代表已经批准并必需遵循的设计确定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。 词汇表词汇表主要用于定义工程特定的术语，它有助于开发人员对工程中所用的术语有统一的理解和运用，它也是后续阶段中进展对象抽象的根底。. 调整用例模型在一般的用例图中，我们只表述参及者和用例之间的关系，即它们之间的通讯关联。除此之外，我们还可以描绘参及者及参及者之间的泛化()、用例和用例之间的包含()、扩展()和泛化()关系。我们利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来重用，使得用例模型更易于

45、维护。但是在应用中要当心选用这些关系，一般来说这些关系都会增加用例和关系的个数，从而增加用例模型的困难度。而且一般都是在用例模型完成之后才对用例模型进展调整，所以在用例建模的初期不必要急于抽象用例之间的关系。 参及者之间的关系参及者之间可以有泛化()关系（或称为继承关系）。例如在需求分析中常见的权限限制问题（如下图所示），一般的用户只可以运用一些常规的操作，而管理员除了常规操作之外还须要进展一些系统管理工作，操作员既可以进展常规操作又可以进展一些配置操作。在这个例子中我们会发觉管理员和操作员都是一种特殊的用户，他们拥有一般用户所拥有的全部权限，此外他们还有自己独有的权限。这里我们可进一步把一般用户和管理员、操作员之间的关系抽象成泛化()关系，管理员和操作员可以继承一般用户的全部特性（包括权限），他们又可以有自己独有的特性（如操作、权限等）。这样可以显著减速少用例图中通讯关联的个数，简化用例模型，使之更