h5学习教程,深圳网站优化项目,兰州做网站企业,吉利网站建设软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 典型表现#xff1a; 开发成本和进度的估计常常很不准确 用户对已完成的软件系统不满意#xff0c;闭门造车 软件质量#xff08;quality#xff09;不可靠 软件常常是不可维护的 软件产品供不应…软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 典型表现 开发成本和进度的估计常常很不准确 用户对已完成的软件系统不满意闭门造车 软件质量quality不可靠 软件常常是不可维护的 软件产品供不应求 软件成本cost的比例逐年上升 软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来以经济地开发出高质量的软件并有效地维护它。 软件工程的目标是研制、开发与生产出具有良好软件质量(quality)和费用合算的(economical)产品 采用工程化方法和途径来开发与维护软件 应该开发和使用更好的软件工具 采取必要的管理措施 软件的生命周期是从提出软件产品开始直到该软件产品被淘汰的全过程。是一个孕育、诞生、成长、成熟、衰亡的生存过程。 软件生存周期的六个步骤即制定计划、需求分析、设计、程序编码、测试及运行维护。 瀑布模型 特点 阶段间具有顺序性和依赖性推迟实现的观点质量保证的观点文档驱动 缺点 模型缺乏灵活性不容易应对快速变化的需求开发过程一般不能逆转否则代价太大规格说明很难理解软件的实际情况必须到项目开发的后期客户才能看到文档驱动的两面性 快速原型模型演化模型 特点 针对事先不能完整地定义需求针对用户地核心需求开发核心系统根据用户的反馈实施活动的迭代 优点 可以处理模糊需求开发者与用户可以充分沟通系统对用户更友好降低系统失败风险降低总的开发费用缩短开发时间 缺点 如果核心需求识别错误可能导致原型系统不合要求资源规划和管理较为困难容易忽视原型环境与最终用户环境的差异 增量模型 优点 每个阶段交付一个可用的产品减少一个全新产品给客户带来的心理上的影响分阶段地交付产品不需要大的资金支出需求经常变化增量模型的灵活性使其具有更加优越的适用性 缺点 需要一个开放的结构方便构件的加入由于一些模块必须在另一个模块之前完成所以必须定义良好的接口 螺旋模型大规模软件项目 活动 制定计划风险分析实施工程客户评估 优点 容易确定什么时候已经对某一阶段的产品充分测试完毕维护和开发之间没有什么本质上的差别 缺点 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识 喷泉模型 迭代重复、演进无间隙各阶段间无明显界限 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成而对成本、人员、进度、质量、风险等进行分析和管理的活动。 成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。 软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下以预定成本按期、按质的完成软件然后交付用户使用。 时间、质量和成本管理构成了三角形 时间约束完成项目所需的时间以及时间进度安排。 成本约束为完成项目而需要的各种资源所产生的成本费用包括人力、物力、财力等。 范围约束定义了项目要完成的工作内容和最终交付的产品特性、功能等。 进度是对执行的活动和里程碑制定的工作计划日期表 进度管理是为了确保项目按期完成所需要的过程 甘特图能很形象地描绘任务分解情况以及每个子任务(作业)的开始时间和结束时间因此是进度计划和进度管理的有力工具。 优点直观简明和容易掌握、容易绘制 缺点 不能显式地描绘各项作业彼此间的依赖关系进度计划的关键部分不明确难于判定哪些部分应当是主攻和主控的对象计划中有潜力的部分及潜力的大小不明确往往造成潜力的浪费 · 软件需求的概念和分类 · 数据流图 · 数据字典的概念 软件需求用户解决问题或达到目标所需要的条件。系统或系统部件要满足合同、标准、规范或其他正式规定的文档所要具有的条件。反映上面两条的文档说明。 “需求”就是用户的需要它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件它是一个程序或系统开发工作的说明表现形式一般为文档形式。 希望通过需求分析 对开发进行指导 开发人员理解用户的要求 用户理解开发人员 测试部门有理可依 需求分析确定系统需要实现的功能和性能以及系统要求的运行环境。以一种清晰、简洁、一致且无二义性的方式对一个系统各方面描述的一个集合以文档形式表现。 类别 功能需求性能需求可靠性和可用性需求出错处理需求接口需求约束逆向需求将来可能提出的要求 数据流图 数据流图有两个目的指明数据在系统中移动时如何被变换描述对数据流进行变换的功能和子功能。它可以用于信息域的分析作为功能建模的基础。 顶层流图仅包含一个加工它代表将被开发系统。它的输入流是该系统的输入数据输出流是系统所输出数据。 建立数据流模型的基本步骤概括地说就是自外向内、自顶向下、逐层细化、完善求精。 数据字典的作用就是描述软件中的每个数据和加工的具体含义以保持数据在系统中的一致性。数据字典对数据流图中出现的所有名字数据流、加工、数据存储进行定义 数据流条目 文件条目列出数据存储的组成数据项及文件的组织方式 数据项条目无论是独立的还是包含在数据流或文件中的数据项一般都应在字典中设置相应的条目 加工条目 状态转换图状态图描绘系统的状态及引起系统状态转换的事件来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作。 状态是任何可以被观察到的系统行为模式 在状态图中定义的状态主要有初态、终态、中间状态 事件是某个特定时刻发生的事情它引起系统做出动作或系统状态转变 状态图中两个状态之间带箭头的连线称为状态转换箭头指明了转换方向 · 模块独立性的概念、意义 · 模块独立性的两个度量标准耦合、内聚 · 耦合、内聚的几种类型 模块化将程序划分为若干个独立的模块每个模块完成一个特定子功能每个模块既是相对独立的又是相互联系的它们共同完成系统指定的各项功能 模块化的目的降低软件的复杂性 信息隐藏在设计和确定模块时使得一个模块内包含的信息过程和数据对于不需要这些信息的模块来说是不能访问的。 模块独立性概括了把软件划分为模块时要遵守的准则也是判断模块构造是不是合理的标准同时也是模块化和抽象及信息隐藏概念的直接产物 坚持模块独立性是获得良好设计的关键 希望这样设计软件结构使得每个模块只完成系统要求的一个相对独立的特定子功能并且和其他模块之间的关系很简单 模块本身的内聚、模块之间的耦合 内聚从功能角度对模块内部各个成分之间的紧密程度的度量。即内聚是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量 偶然性内聚/巧合内聚块内各组成成分在功能上是互不相关的逻辑性内聚这种模块把几种相关、相似功能组合在一起每次被调用时由传递给模块的参数来确定该模块应该完成哪一种功能时间性内聚如果一个模块所包含的任务必须在同一“时间”内完成过程性内聚当一个模块中包含的一组任务必须按照某一特定的次序执行时通信性内聚模块内部各个成分都使用同一种输入数据或者产生同一个输出数据。它们靠公用数据而联系在一起顺序性内聚/信息内聚如果一个模块内的处理元素和同一个功能密切相关而且这些处理必须顺序执行通常一个处理元素的输出数据作为下一个处理元素的输入数据功能性内聚如果一个模块包括仅为完成某一具体任务所必需的所有成分或者说模块中所有成分结合起来是为了完成一个具体的任务 耦合是对软件内部模块之间相互联系的紧密程度的度量 非直接耦合若两个模块没有直接联系它们之间的联系完全是通过主程序的控制和调用来实现的便称这两个模块为非直接耦合这样独立性最强。 数据耦合两个模块之间仅通过参数表传递简单数据。即一个模块调用另一个模块被调用模块的输入和输出都是简单的数据。 特征耦合模块间通过参数表传递一个数据结构并且只使用其中的一部分 控制耦合一个模块传送给另一个模块的参数中包含了控制信息控制接收模块的执行逻辑。用作控制信号的开关值或标志量flag 外部耦合若允许一组模块访问同一个全局变量可称它们为外部耦合。 公共耦合若允许一级模块访问同一个全局性数据结构则称之为公共耦合。 内容耦合 如果发生下列情形两个模块之间就发生了内容耦合 一个模块直接访问另一个模块的内部数据一个模块不通过正常入口转到另一模块内部两个模块有一部分程序代码重迭一个模块有多个入口 · 数据流图映射成软件结构图变换型、事务型 1变换流 信息沿输入通路进入系统由外部形式变换成内部形式进入系统的信息通过变换中心经加工处理以后再沿输出通路变换成外部形式离开软件系统。当数据流图具有这些特征时这种信息流就叫作变换流。 2事务流 数据沿输入通路到达一个处理T这个处理根据输入数据的类型在若干个动作序列中选出一个来执行。这类数据流应该划为一类特殊的数据流称为事务流。 · 过程设计工具程序流程图、盒图N-S图、PAD图、判定表/树、PDL 程序流程图优点 采用简单规范的符号画法简单结构清晰逻辑性强便于描述容易理解 开始、结束椭圆矩形 输入输出为平行四边形 判断菱形 其他矩阵 盒图N-S图每个处理步骤用一个盒子表示。盒子可以嵌套。盒子只能从上头进入从下头走出除此之外别无其他出入口所以盒图限制了随意的控制转移保证了程序的良好结构 特点 功能域(即一个特定控制结构的作用域)明确可以从盒图上一眼就看出来。 不可能任意转移控制。 很容易确定局部和全程数据的作用域。 很容易表现嵌套关系也可以表示模块的层次结构 PAD图问题分析图 优点 清晰的反映了程序的层次结构 支持逐步求精的设计方法 易读易写使用方便 支持结构化程序设计 可自动生成程序 PDL 优点 可以作为注释直接插在源程序中间。可以使用普通的正文编辑程序或文字处理系统很方便地完成PDL的书写和编辑工作。已经有自动处理PDL的程序存在而且可以自动由PDL生成程序代码。 缺点不如图形工具形象直观描述复杂的条件组合与动作间的对应关系时不如判定表清晰简单。 软件测试 目的是希望以最低代价以尽可能多地找出软件中潜在的各种错误和缺陷。 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 软件测试基本原则 尽早、不断地进行测试每个测试用例都必须包含测试输入数据和对应地预期输出的描述在某一程序片段中发现的错误越多则这个程序段所隐含的尚未发现错误的可能性越大完全测试程序是不肯的寄生虫特性找到的软件缺陷越多就说明软件缺陷越多杀虫剂怪事软件测试越多其对测试的免疫力越强的现象 是否执行程序静态测试、动态测试 软件测试用例的设计方法白盒测试、黑盒测试 1 静态测试 通过检查和评审软件而不是运行软件对软件进行测试的方法。静态测试可以手工进行也可以借助软件工具自动进行 测试对象各类文档、源代码等 特点 不必动态的运行程序也就不必进行测试用例的设计和结果判读等工作 静态测试可以由人工进行充分发挥人的逻辑思维优势行之有效 静态测试实施不需要特别条件容易开展 人工进行 桌面检查程序员阅读自己所编的程序。效率不高代码审查代码走查提供若干测试用例程序的输入数据和期望的输出结果用头脑来执行程序技术评审 主要由软件工具自动进行的静态分析 广义理解还包括软件需求分析和设计阶段的技术评审 内容 需求定义的静态测试测试对照条例设计文档的静态测试源代码的静态测试 2 动态测试 通过运行软件来检验软件的动态行为和运行结果的正确性两个基本要素被测试程序、测试数据测试用例核心内容生成测试用例、运行程序、验证程序的运行结果 测试用例Test Case是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果以便测试某个程序路径或核实是否满足某个特定需求。 单元测试时通常采用白盒测试或白盒测试与黑盒测试相结合的方法而在集成测试、确认测试或系统测试中大都采用黑盒测试 2.1 黑盒测试 功能性测试基于规格说明的测试数据驱动测试 是在已知软件产品具有何种功能的前提下用来检验每个功能是否能够正常使用需求是否满足的一个测试方法在软件开发后期进行。 把程序看成是一个不能打开的黑盒子在不考虑程序内部结构的情况下测试人员用操作接口的方式进行测试检查程序能否按照需求指定的功能接收输入数据产生正确的结果。黑盒测试方法是在程序接口上进行测试。 优点 比较简单不需要了解程序内部的代码及实现 与软件的内部实现无关如果实现发生变化黑盒测试用例仍然可用 从用户角度出发能很容易的知道用户会用到哪些功能会遇到哪些问题 基于软件开发文档所以用例设计可以与软件的实现同时进行 缺点 不能覆盖所有代码覆盖率较低只能找到缺陷难以查找错误的具体原因 2.1.1 等价类划分 等价类测试是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构只依据程序的规约来设计测试用例 把程序的输入定义域划分成若干部分然后从每个部分中选取少数代表性数据当作测试用例 在分析程序的规约的基础上划分等价类列出等价类表 可以把全部的输入数据划分成若干个等价类在每一个等价类中取一个数据来进行测试 优点能以较少的具有代表性的数据进行测试而取得较好的测试效果 有效等价类对于程序的规约来说是合理的、有意义的输入数据所构成的集合。利用它可以检验程序是否实现了预期的功能和性能。在具体问题中有效等价类可以有一个也可以是多个 无效等价类对于程序的规约来说是不合理的、没有意义的输入数据所构成的集合。利用它可以检验程序对于无效数据的处理。对于具体的问题无效等价类可以有一个也可能有多个 划分等价类 覆盖 不相交 代表性 对每个输入或外部条件进行等价类划分形成等价类表为每一等价类规定一个唯一的编号 设计一测试用例使其尽可能多地覆盖尚未覆盖的有效等价类重复这一步骤直到所有有效等价类均被测试用例所覆盖 设计一新测试用例使其只覆盖一个无效等价类重复这一步骤直到所有无效等价类均被覆盖 2.1.2 边界值分析 1边界值分析 关注输入空间的边界从中标识测试用例 原理错误更可能出现在输入变量的极值附近。 关键假设“单缺陷”假设失效问题极少是由两个或多个缺陷的同时发生引起的 方法仅让一个变量取极值其他所有变量取正常值 在最小值、略高于最小值、正常值、略低于最大值、最大值处取输入变量值 对于一个n变量函数让一个变量依次取min、min、nom、max-、max各个极值而其他所有变量取正常值。依次对每个变量都重复这个过程即可 对于一个关于n变量的函数边界值分析会产生4n1个不同的测试用例 2健壮性测试 除了对变量5个边界值进行分析之外还要进一步考察略大于最大值max的值以及略小于最小值min-的值 对于健壮性测试最重要的不是输入而是预期的输出 最主要的价值在于把注意力集中在系统对异常情况的处理上 一个变量个数为n的函数的健壮性测试会产生6n1测试用例 3最坏情况测试 对每一个变量分别构造包含min、min、nom、max-、max这5个基本值的取值集合然后通过计算这些集合的笛卡尔积来构造测试用例 对一个n变量函数来说最坏情况测试将会构造出5n个测试用例 4健壮最坏情况测试 对每一个变量分别构造包含min、min、nom、max-、max以及max略大于最大值和min-略小于最小值这样7个元素的集合然后计算这些集合的笛卡尔积以生成测试用例 对n个变量的函数来说健壮最坏情况测试会产生7n个测试用例 错误猜测法列举出程序中所有可能有的错误和容易发生错误的特殊情况根据这些内容选择测试用例。更多地依赖人们的先验知识。 因果图从程序规格说明书的描述中找出因输入条件和果输出或程序状态的改变之间的关系通过将因果图转换为判定表最后为判定表中的每一列设计一个测试用例。 2.2 白盒测试 结构性测试基于程序的测试逻辑驱动测试 前提知道软件产品内部工作过程。 目标通过测试来检测软件产品内部动作是否按照规格说明书的规定正常进行。 重点从程序的控制结构导出测试用例。按照软件内部的结构测试程序软件中的每条通路是否都能按预定要求正确工作。 在软件开发早期执行。 2.2.1 逻辑覆盖 语句覆盖设计若干测试用例运行被测程序使程序中每个可执行语句至少执行一次。可以很直观地从源代码得到测试用例无须细分每条判定表达式。语句覆盖是最弱的逻辑覆盖。对程序的逻辑覆盖很少只关心判定表达式的值而没有分别测试判定表达式中每个条件取不同值时的情况。 判定覆盖分支覆盖设计若干测试用例运行被测程序使得程序中每个判定的取真分支和取假分支至少经历一次即判定真假值均曾被满足。 条件覆盖设计若干测试用例执行被测程序以后要使每个判定中每个条件的可能取值至少满足一次。条件覆盖不一定包含判定覆盖条件覆盖只能保证每个条件至少有一次为真而不考虑所有的判定结果。 判定 - 条件覆盖设计足够的测试用例使得判定条件中的所有条件可能取值至少执行一次同时所有判定的可能结果至少执行一次。未考虑条件的组合情况。 条件组合覆盖设计足够的测试用例使得每个判定中所有可能的条件取值组合至少执行一次。 路径覆盖设计所有的测试用例来覆盖程序中的所有可能的执行路径。需要设计大量、复杂的测试用例使得工作量呈指数级增长不见得把所有的条件组合都覆盖。 2.2.2 基路径测试 如果可以把程序看做是一种向量空间则这种空间的基就是要测试的非常有意义的元素集合。如果基没有问题则可以期望能够用基表达的一切都是没有问题的。 基路径测试法是在程序控制流图的基础上通过分析控制构造的圈复杂度导出基本可执行路径集合从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行路径至少执行一次。 McCabe圈复杂度 圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量将该度量用于计算程序的基本的独立路径数目。圈复杂度对应着独立路径数目。 独立路径必须包含一条在定义之前不曾用到的边即至少经过一条以前未走过的边 V(G) e – n 2p e控制流图的边数n控制流图的节点数P图的连通区域数图的连通区域是相连节点的最大集合。一般条件下控制流图的节点都是连通的以此所有节点连接形成一个大的连通区域所以控制流图的p一般为1. 即V(G)e-n2 V(G) 判定节点数1 V(G) 控制流图中有界或无界的封闭区域个数 基路径测试步骤 导出程序流程图的拓扑结构——控制流图程序图 计算控制流图的McCabe圈复杂度设为n 确定基本路径集即构造n条独立路径 1任意构造一条从唯一入口节点到唯一出口节点的路径将该路径加入基本路径集 2修改基本路径集中路径至少经过一条以前未走过的边将新路径加入基本路径集 重复第2步直到基本路径集中包含n条路径 设计测试用例使基本路径集中的路径能走通 3 软件测试步骤与策略 单元测试又称模块测试是要检验程序的最小单位模块有无错误它是在编码完成后进行的测试工作。 驱动模块(driver)相当于所测模块的主程序。它接收测试数据把这些数据传送给所测模块最后再输出实际测试结果 桩模块(stub)用于代替所测模块调用的子模块。桩模块可以做少量的数据操作 集成测试指每个模块完成单元测试以后需要按照设计时确定的结构图把它们连接起来进行集成测试。 非增量式集成 大爆炸集成 增量式集成 自顶向下自底向上三明治集成 确认测试确认测试又称为有效性测试和合格性测试。确认测试是在模拟环境下利用一系列黑盒测试检验所开发的软件是否能按用户提出的要求进行工作。确认过程的重要环节就是配置审查工作。其目的在于确保已开发软件的所有文件资料均已编写齐全并得到分类编目足以支持投入运行以后的软件维护工作。 系统测试系统测试是基于实际应用环境对计算机系统的一种多方位的测试每一种测试都具有不同的目的但所有的测试都是为了检验各个系统成分能否正确集成到一起并且是否能完成预定的功能 软件维护 软件维护是指在软件的运行/维护阶段由软件厂商向客户所提供的服务工作。是在软件交付使用后为了改正错误或满足新的需求而修改软件的过程。 纠错性维护/改正性维护改正在特定的使用条件下软件中暴露出来的错误与缺陷这些错误或缺陷在测试时并未被发现适应性维护使软件产品能够适应变化了的运行环境如操作系统版本的升级、机器配置的变化、软件使用对象的变化等完善性维护为适应用户对软件功能、性能或接口方面提出的新要求以使产品更加完善与合理而进行的修改预防性维护提高产品的可靠性和可维护性减少今后维护的工作量有利于系统和进一步改造或升级换代而进行的维护 副作用 代码副作用对代码的修改最容易发生副作用修改会使程序混乱、结构不清晰、可读性变差而且会产生连锁反应。代码的副作用有时通过回归测试可以发现一经发现应立即采取补救措施 。数据副作用数据结构是程序的骨架在维护阶段一旦修改了数据结构软件设计与数据可能就不再吻合错误随即出现。容易产生数据副作用的修改包括局部常量与全局常量的再定义、记录与文件格式的改变、增减数据结构的容积、修改全局数据、重新初始化控制标志与指针、重新排列I/O表或子程序的参数表、修改用户数据等文档副作用对软件的任何修改都应在相应的技术文档中反映出来如果设计文档不能与软件当前的状况对应则会比没有文档更糟。因为用户很多情况下都按照使用说明来使用软件 · 什么是UMLUML的特点UML包含哪些模型图 · 重点用例图、类图、状态图、顺序图、活动图 UML 标准建模语言UML是一种建模语言而不是一种方法它统一了面向对象建模的基本概念、术语及其图形符号为人们建立了便于交流的共同语言 特点 统一标准面向对象可视化表示能力强大独立于过程容易掌握使用 静态模型图/结构图 类图展示对象类、接口及其相互合作与关联 对象图展示对象及其相互之间的关系 实现图 构件图描述部件的物理结构以及各部件之间的依赖关系配置图定义系统中软硬件的物理架构 动态模型图/行为图 用例图从用户角度描述系统的行为并指出各功能的操作者 状态图描述由事件驱动的系统/对象的状态转移 活动图描述活动之间的控制流用于企业的工作流程建模 交互图 顺序图描述消息发生的事件顺序合作图描述各个对象之间收发消息的情况 类图 关联关系描述的是类与类之间的连接表示一个类知道另一个类的属性和方法。可以是单向的或者双向的一般以成员变量形式出现 聚合关系整体与部分、拥有的关系且部分可以离开整体而单独存在车和门、引擎组合关系整体与部分是不可分的整体的生命周期结束也就意味着部分的生命周期结束大雁和翅膀 继承关系类与类之间的继承关系 实现关系类与接口 依赖关系表示一个类依赖于另一个类的定义一般来说被依赖的对象往往是以局部变量、方法参数的形式存在于依赖对象中与关联关系不同它不会以成员变量的形式存在于依赖对象中 关联、集成、实现、依赖、聚合、组合 用例图 参与者Actor与应用程序或系统进行交互的用户、组织或外部系统用例就是外部可见的系统功能对系统提供的服务进行描述子系统用来展示系统的一部分功能这部分功能联系紧密 关联表示参与者与用例之间的通信任何一方都可发送或接受消息 泛化 包含表示一个用例的行为包含了另一个用例 扩展常指用例功能的延伸相当于为基础用例提供一个附加功能 顺序图 对象对象、对象的生命线、激活的对象和对象的删除消息简单消息、同步消息、异步消息、返回消息条件、注释体和注释连接 三对象模型 实体对象表示系统将跟踪的持久信息边界对象表示参与者与系统之间的接口和交互控制对象负责用例实现 边界类位于系统与外界的交界处 图形用户界面、窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类通过用例图可以确定需要的边界类每个Actor/Use Case对至少要一个边界类但并非每个Actor/Use Case对要唯一的边界类。 实体类一般用于保存系统中要放进持久存储体的信息以及提供针对这些信息的相关处理行为 持久存储体就是数据库、文件等可以永久存储数据的介质。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表实体类中的属性对应数据库表中的字段。 控制类是控制其他类工作的类 每个用例通常有一个控制类控制用例中的事件顺序控制类也可以在多个用例间共用。其他类并不向控制类发送很多消息而是由控制类发出很多消息。 状态图 状态图描述系统对象的动态行为一般描述一个特定对象在其生命周期中的所有可能状态以及由于各种事件的发生而引起状态的转移条件。 基本要素 状态 条件和转移 注释 持久性数据是系统关闭后必须要保存的数据 持久性数据的生命周期比系统的一次执行周期要长 数据的存储地点以及如何存储会对系统的分解产生影响 比如仓库体系结构某个子系统完全用于数据存储数据库管理系统的选择也对全局控制策略和并发管理有影响 主要存储策略文件、数据库