截图
简介
这是一个关于GIS软件工程的设计方法介绍PPT课件，主要介绍了结构化设计方法、Jackson方法、Booch方法、Coad设计方法、OMT设计方法、UML方法等内容。软件工程第7章 GIS软件工程的设计方法第7章 GIS软件工程的设计方法结构化设计方法 Jackson方法 Booch方法 Coad设计方法 OMT设计方法 UML方法 结构化设计 结构化设计概述数据流图到软件体系结构的映射结构化设计结构化设计(Structured Design，简称SD)是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则分为概要设计和详细设计两大步骤概要设计是对软件系统的总体设计，采用结构化设计方法，其任务是：将系统分解成模块，确定每个模块的功能、接口(模块间传递的数据)及其调用关系，并用模块及其对模块的调用来构建软件的体系结构详细设计是对模块实现细节的设计，采用结构化程序设计(Structured Programming，简称SP)方法 SA、SD和SP构成完整的结构化方法体系 结构图用结构图(Structure Chert)来描述软件系统的体系结构描述一个软件系统由哪些模块组成，以及模块之间的调用关系结构图的基本成分有：模块、调用和数据模块(module) 模块是指具有一定功能的可以用模块名调用的一组程序语句，如函数、子程序等它们是组成程序的基本单元一个模块具有其外部特征和内部特征外部特征包括：模块的接口(模块名、输入/输出参数、返回值等)和模块的功能内部特征包括：模块的内部数据和完成其功能的程序代码在SD中，我们只关注模块的外部特征，而忽略其内部特征，欢迎点击下载GIS软件工程的设计方法介绍PPT课件哦。
GIS软件工程的设计方法介绍PPT课件是由红软PPT免费下载网推荐的一款学校PPT类型的PowerPoint.
软件工程第7章 GIS软件工程的设计方法第7章 GIS软件工程的设计方法结构化设计方法 Jackson方法 Booch方法 Coad设计方法 OMT设计方法 UML方法 结构化设计 结构化设计概述数据流图到软件体系结构的映射结构化设计结构化设计(Structured Design，简称SD)是将结构化分析得到的数据流图映射成软件体系结构的一种设计方法强调模块化、自顶向下逐步求精、信息隐蔽、高内聚低耦合等设计准则分为概要设计和详细设计两大步骤概要设计是对软件系统的总体设计，采用结构化设计方法，其任务是：将系统分解成模块，确定每个模块的功能、接口(模块间传递的数据)及其调用关系，并用模块及其对模块的调用来构建软件的体系结构详细设计是对模块实现细节的设计，采用结构化程序设计(Structured Programming，简称SP)方法 SA、SD和SP构成完整的结构化方法体系 结构图用结构图(Structure Chert)来描述软件系统的体系结构描述一个软件系统由哪些模块组成，以及模块之间的调用关系结构图的基本成分有：模块、调用和数据模块(module) 模块是指具有一定功能的可以用模块名调用的一组程序语句，如函数、子程序等它们是组成程序的基本单元一个模块具有其外部特征和内部特征外部特征包括：模块的接口(模块名、输入/输出参数、返回值等)和模块的功能内部特征包括：模块的内部数据和完成其功能的程序代码在SD中，我们只关注模块的外部特征，而忽略其内部特征 调用和数据调用(call)：用从一个模块指向另一个模块的箭头来表示，其含义是前者调用了后者为了方便，有时常用直线替代箭头，此时，表示位于上方的模块调用位于下方的模块数据(data)：模块调用时需传递的参数可通过在调用箭头旁附加一个小箭头和数据名来表示 结构图中的辅助符号结构化设计：启发式设计策略-1 按照模块化设计原则，相应的启发式设计策略如下：改造程序结构图，降低耦合度，提高内聚度避免高扇出，并随着深度的增加，力求高扇入避免如图a那样的“平铺”形态，较好的结构图形态是如图b那样的“椭圆”型启发式设计策略-2 模块的影响范围应限制在该模块的控制范围内，例如下图中图a中，模块B2的影响范围(模块A)不在其控制范围(模块B2)内决策控制是在顶层模块，其影响范围(A、B2)在控制范围内，但是从决策控制模块到被控模块之间相差多个层次 c和d较合适，d为最好启发式设计策略-3 降低模块接口的复杂程度和冗余程度，提高一致性模块接口上应尽可能传递简单数据，而且传递的数据应保持与模块的功能相一致，即不传递与模块功能无关的数据模块的功能应是可预测的，避免对模块施加过多的限制模块功能可预测是指该模块对相同的输入能产生相同的输出限制一个模块只处理单一的功能，那么，这个模块体现出高内聚尽可能设计单入口和单出口的模块单入口和单出口的模块能有效地避免内容耦合 结构化设计的步骤建立初始结构图将整个软件看作一个大的功能模块，通过功能分解不断将其分解成若干个较小的功能模块，直至得到一组不必再分解的模块(结构图中的底层模块) 对结构图进行改进可根据设计准则和启发式设计策略对初始结构图进行改进书写设计文档书写设计规格说明，特别要为每个模块书写模块的功能、接口、约束和限制等设计评审 结构化设计内容摘要 结构化设计概述数据流图到软件体系结构的映射数据流图到软件体系结构的映射结构化设计是将结构化分析的结果(数据流图)映射成软件的体系结构(结构图) 信息流：变换流和事务流将数据流图分为变换型数据流图和事务型数据流图，对应的映射分别称为变换分析和事务分析变换流特征：数据流图可明显地分成输入、变换、输出三部分信息沿着输入路径进入系统，并将输入信息的外部形式经过编辑、格式转换、合法性检查、预处理等辅助性加工后变成内部形式内部形式的信息由变换中心进行处理然后沿着输出路径经过格式转换、组成物理块、缓冲处理等辅助性加工后变成输出信息送到系统外事务流特征：数据流沿着输入路径到达一个事务中心，事务中心根据输入数据的类型在若干条动作路径中选择一条来执行事务中心的任务是：接收输入数据(即事务)；分析每个事务的类型；根据事务类型选择执行一条动作路径数据流图映射到结构图的步骤复审和精化数据流图确定数据流图的类型(变换型、事务型) 将DFD映射成初始结构图：采用变换分析或事务分析技术，将DFD映射成初始结构图改进初始结构图变换分析变换分析的任务是将变换型的DFD映射成初始的结构图，步骤如下：划定输入流和输出流的边界，确定变换中心进行第一级分解：将DFD映射成变换型的程序结构进行第二级分解：将DFD中的加工映射成结构图中的一个适当的模块标注输入输出信息：根据DFD，在初始结构图上标注模块之间传递的输入信息和输出信息确定输入/出流边界和变换中心-1 相关概念：物理输入：指系统输入端的数据流物理输出：指系统输出端的数据流逻辑输入：指变换中心的输入数据流逻辑输出：指变换中心的输出数据流划分可能因人而异，但差别不会太大并可通过以后的结构图改进进行调整有的时候物理输入无须预处理而直接用于系统的加工处理，此时物理输入就是逻辑输入(同样也存在物理输出就是逻辑输出的情况) 确定输入/出流边界和变换中心-2 基本步骤确定逻辑输入：根据DFD从物理输入端开始，一步步向系统的中间移动，可找到离物理输入端最远的，但仍可被看作系统输入的那个(或那些)数据流，就是逻辑输入确定逻辑输出：根据DFD，从物理输出端开始，一步步向系统的中间移动，可找到离物理输出端最远的，但仍可被看作系统输出的那个(或那些)数据流，就是逻辑输出确定变换中心：确定了所有的逻辑输入和逻辑输出后，位于逻辑输入和逻辑输出之间的部分就是变换中心 示例：统计成绩子图的输入、输出流边界进行第一级分解将DFD映射成变换型的程序结构 大型的软件系统第一级分解时可多分解几个模块，以减少最终结构图的层次数例如，每条输入或输出路径画一个模块，每个主要变换功能各画一个模块进行第二级分解将DFD中的加工映射成结构图中的一个适当的模块分解步骤如下输入控制模块的分解：从变换中心的边界开始，沿着输入路径向外移动，把输入路径上的每个加工映射成结构图中受输入控制模块控制的一个低层模块输出控制模块的分解：从变换中心的边界开始，沿着输出路径向外移动，把输出路径上的每个加工映射成结构图中受输出控制模块控制的一个低层模块变换控制模块的分解：把变换中心的每个加工映射成结构图中受变换控制模块控制的一个低层模块 “统计成绩”第二级分解的结构图事务分析将事务型DFD映射成初始的结构图实例：银行业务中有存款、取款、查询余额、开户、转帐等多种事务，这种软件通常是接收一个事务，然后根据事务的类型执行一个事务处理的功能事务型的结构图如图所示，包括：主控模块：完成整个系统的功能接收模块：接收输入数据(事务) 发送模块：根据输入事务的类型，选择一个动作路径控制模块动作路径控制模块：完成相应的动作路径所执行的子功能 事务分析的步骤确定事务中心：事务中心位于数条动作路径的起点，这些动作路径呈幅射状从该点流出将DFD映射成事务型的结构图分解每条动作路径所对应的结构图接收模块的分解：从事务中心开始，沿着输入路径向外移动，把输入路径上的每个加工映射成结构图中受接收模块控制的一个低层模块动作路径控制模块的分解：首先确定每条动作路径的流类型(变换流或事务流)，然后，运用变换分析或事务分析，将每条动作路径映射成与其流特性相对应的以动作路径控制模块为根模块的结构图 分层DFD的映射 0层图反映了系统由哪些子系统组成，此时可先将0层图映射成下图中的结构 0层图每个加工的DFD子图可映射成以相应模块为根模块的结构子图如果DFD子图中的加工还可分解成一张子图，则再将其映射成以相应模块为根模块的结构子图依次一层一层分解下去得到最终的初始结构图如果初始结构图太大，我们也可以将它组织成分层的结构图第二节 Jackson方法 JSP：Jackson结构程序设计方法 JSD：Jackson是在JSP的基础上扩展的系统开发方法注意区别：SA，SD，SP。内容摘要 JSP方法 JSD方法简介小结内容摘要 JSP方法 JSD方法简介小结 JSP方法总结了COBOL（面向商业的通用语言）事务处理程序中的开发方法而发展起来的，特点：重点不是自顶向下逐步求精，而是在数据结构基础上进行构造根据输入/输出的数据结构建立程序结构 目标：获得简单清晰的设计方案设计原则：使程序结构与问题结构(数据结构)相对应数据结构和程序结构一般的数据处理系统处理的是具有层次结构的数据，因而其问题结构可以用它所处理的数据结构来表示数据结构与程序结构的表示 JSP方法采用Jackson图来表示数据结构和程序结构结构图是一种从左到右阅读的树状层次结构图数据结构图中方框表示数据，程序结构图中方框就表示模块(过程或函数) 底部的叶子节点称为基本元素在底部枝干以上的节点称为结构元素三种元素类型：顺序元素、选择元素、重复元素顺序元素一个顺序元素由一个或多个从左到右的元素组成每个组成的元素只出现一次 选择元素选择是“If Then Else”或“Case”的结构，而且必须有两个或多个元素使用选择元素时根据指定的条件从这些子元素中选择一个子元素供选择的子元素用右上角标以小圆的矩形表示示例：左图中A、B、C是D的可选项，而S是选择条件如果需要一个“If A=B Then X Else do nothing”那么需要加入一个空元素示例：右图 中空元素用一个标有连字符的矩形表示重复元素重复元素仅由一个子元素构成，表示重复元素由子元素重复0次或多次组成子元素用右上角标以星号的矩形表示下图表示元素D由元素A重复0次或多次组成，其中I是重复条件结构正文的表示形式-1 结构正文又称伪码，完全与结构图相对应分为：顺序结构正文、选择结构正文、重复结构正文顺序结构正文 D Seq 顺序 A； 元素D是由一个元素A B； 跟随一个元素B C； 跟随一个元素C组成 D END 元素D是元素A、元素B、元素C的序列结构正文的表示形式-2 选择结构正文 D Select cond1 选择 A 元素D或是由一个元素A Or cond2 B 或是由一个元素B Or cond3 C 或是由一个元素C组成 D END cond1、cond2、cond3分别是选择A，B，C的条件重复结构正文 D Iter until cond 重复 A； 元素D是由1个或多个元素A组成。 D END 元素D 是元素A的重复 或 D Iter while cond A； 元素D是由0至多个元素A组成 D END cond为循环条件 示例：打印表格程序的输出数据结构和对应的程序结构 JSP方法的分析和设计步骤-1 例：一个正文文件由若干个记录组成，每个记录是一个字符串，要求统计每个记录中空格个数，以及文件中空格的总数。 要求输出的格式是：每复制一行输入字符串后，另起一行输出该字符串中的空格数，最后输出文件空格的总数 JSP方法的分析和设计步骤-2 第1步.分析并确定输入和输出数据结构的逻辑结构，并用Jackson图画出 JSP方法的分析和设计步骤-3 第2步.找出输入数据结构与输出数据结构中有对应关系的数据元素有对应关系是指有直接因果关系，即在程序中可以同时处理的数据元素对于表示“重复”的数据元素，只有其重复次数和次序都相同时才有对应关系输入/输出数据结构最高层次的两个数据元素总是有对应关系的 JSP方法的分析和设计步骤-4 第3步.从描述数据结构的Jackson图导出描述程序结构的Jackson图，导出规则：有对应关系的数据元素，按照它们在数据结构图中的层次在程序结构图的相应层次上画一个处理框(如果它们在输入和输出图中的层次不同，则程序结构图中处理框层次与较低的那个对应为输入数据结构图中剩余的每个数据元素，在程序结构图的相应层次上画一个处理框， 在模块名称上增加“分析”或“处理”或取一个具有实际含义的名称为输出数据结构图中剩余的每个数据元素，在程序结构图的相应层次上画上一个处理框 JSP方法的分析和设计步骤-5 程序结构图导出结果 JSP方法的分析和设计步骤-6 第4步.列出所有操作和条件，并将它们分配到程序结构图的适当位置首先从输出操作开始，再回到输入操作加入必须的与条件有关的操作最后把每个操作都分配到程序结构中去 JSP方法的分析和设计步骤-7 设变量sum存放一行字符串中的空格数；totalsum存放空格总数；pointer用来指示当前分析的字符在字符串中的位置，可列出其所有操作，并对其编号如下： ①停止 ② 打开文件 ③ 关闭文件 ④ 打印字符串 ⑤ 打印空格数 ⑥ 打印空格总数 ⑦ sum:=sum+1 ⑧ totalsum:=totalsum+1 ⑨ 读入字符串 ⑩ sum:=0 totalsum:=0 pointer:=1 pointer:=pointer+1 条件列表如下： I(1)：文件结束 I(2)：字符串结束 S(3)：字符是空格将条件与相应的循环条件关联，并将①～ 操作按次序与相当的模块进行关联，按从左至右决定先后顺序，关联后的程序结构图 JSP方法的分析和设计步骤-8 第5步.把带有操作的程序结构图转换成结构正文，同时加入选择及迭代条件 JSP方法的特点简单、易学、形象直观、可读性好便于表示层次结构适用于小型数据处理系统 内容摘要 JSP方法 JSD方法简介小结 JSD方法 JSP广泛使用十多年后，Jackson把它进行了扩充，不再局限于中小规模范围的问题及顺序范围，新的开发方法称为JSD JSD覆盖了整个系统的分析到实现 JSD的本质：先建立一个现实模型，然后加入功能性处理，最后阶段逻辑系统才转换为实际设计 JSD方法步骤标识实体与行为：建立现实的模型，列出与系统有关的实体表及活动表生成实体结构图：分析实体表中实体之间的关系，形成实体结构图创造软件系统模型：根据现实世界，对实体与行为的组合建立进程模型扩充功能性过程：说明系统输出的功能，必要时在规格说明中加入附加的处理施加时间控制：开发者考虑进程调度的某些特征，这些特征可能影响系统功能所输出的结果的正确性及时间关系实现：开发者考虑运行系统的软硬件方面的问题，采用变换技术、调度技术、数据库定义技术等，以使系统能有效地运行 内容摘要 JSP方法 JSD方法简介小结小结面向数据结构的分析和设计方法是以数据结构为中心，从输入/输出的数据结构导出程序结构由于这种方法在国内用得比较少，因此只作了简单介绍，主要是通过一个实例来介绍JSP方法，使读者对这种方法有一个大致的了解面向对象设计 （Object_Oriented Design） Booch方法 Coad 设计方法 OMT方法第三-五节面向对象设计 （Object_Oriented Design） 面向对象设计的一般步骤如下：系统设计将子系统分配到处理器选择实现数据管理、界面支持和任务管理的设计策略为系统设计合适的控制机制复审并考虑权衡（折衷） 对象设计在过程级别（procedural lavel）设计每个操作，即设计每个操作的实现细节定义内部类为类属性设计内部数据结构消息设计 使用对象间的协作和对象--关系模型，设计消息模型复审 复审设计模型并在需要时迭代。 1. 系统设计 1) 将分析模型划分成子系统 在OO系统设计中，我们把分析模型中紧密相关的类、关系等设计元素包装成子系统。 通常，子系统的所有元素共享某些公共的性质，它们可能都涉及完成相同的功能；它们可能驻留在相同的产品硬件中；或者它们可能管理相同的类和资源。子系统由它们的责任所刻画，即，一个子系统可以通过它提供的服务来标识。在OOD中，这种服务是完成特定功能的一组操作。 子系统的设计准则是： (1) 子系统应具有定义良好的接口，通过接口和系统的其它部分通信； (2) 除了少数的“通信类” 外，子系统中的类应只和该子系统中的其它类协作； (3) 子系统的数量不宜太多； (4) 可以在子系统内部再次划分，以降低复杂性。 2) 标识问题本身的并发性，并为子系统分配处理器 通过对对象--行为模型的分析，可发现系统的并发性。如果对象（或子系统）不是同时活动的，则它们不需并发处理，此时这些对象（或子系统）可以在同一个处理器上实现。反之，如果对象（或子系统）必须对一些事件同时异步地动作，则它们被视为并发的，此时，可以将并发的子系统分别分配到不同的处理器，或者分配在同一个处理器，而由操作系统提供并发支持。 3) 任务管理设计 Coad和Yourdon提出如下管理并发任务对象的设计策略： (1) 确定任务的类型； (2) 必要时，定义协调者任务和关联的对象； (3) 将协调者任务和其它任务集成。 通常可通过了解任务是如何被启动的来确定任务的类型，如事件驱动任务，时钟驱动任务。每个任务应该定义其优先级，并识别关键任务。当有多个任务时还可以考虑增加一个协调者任务，以控制这些任务协同工作。 4) 数据管理设计 通常数据管理设计成层次模式，其目的是将数据的物理存储及操纵与系统的业务逻辑加以分离。 数据管理的设计包括设计系统中各种数据对象的存储方式（如内部数据结构、文件、数据库），以及设计相应的服务，即为要储存的对象增加所需的属性和操作。 5) 资源管理设计 OO系统可利用一系列不同的资源（如磁盘驱动器、处理器、通信线路等外部实体或数据库、对象等抽象资源），很多情况下，子系统同时竞争这些资源，因此要设计一套控制机制和安全机制，以控制对资源的访问，避免对资源使用的冲突。 6）人机界面设计 对大多数应用系统而言，人机界面本身是一个非常重要的子系统。人机界面主要强调人如何命令系统，以及系统如何向人提交信息。它包括窗口、菜单、报告的设计。 7) 子系统间的通信 子系统之间可以通过建立客户/服务器连接进行通信，也可以通过端对端（peer to peer）连接进行通信。我们必须确定子系统间通信的合约（contract），合约提供了一个子系统和另一个子系统交互的方式。 2. 对象设计 对象设计是为每个类的属性和操作作出详细的设计，并设计连接类与它的协作者之间的消息规约。 1) 对象描述 对象的设计描述可以采取以下形式之一：（1） 协议描述：描述对象的接口，即定义对象可以接收的消息以及当对象接收到消息后完成的相关操作；（2） 实现描述：描述传送给对象的消息所蕴含的每个操作的实现细节，实现细节包括有关对象私有部分的信息，即关于描述对象属性的数据结构的内部细节和描述操作的过程细节。 对对象的使用者来说，只需要协议描述就够了。 2）设计算法和数据结构 为对象中的属性和操作设计数据结构和实现算法。 3. 设计模式（design patterns） 在许多面向对象系统中，存在一些类和通信对象的重复出现的模式。这些模式求解特定的设计问题，使面向对象设计更灵活，并最终可复用。这些模式帮助设计者复用以前成功的设计，设计者可以把这些模式应用到新的设计中。 一个设计模式通常可用四个信息来描述： 1）模式名 设计模式名应具有实际的含义，它能反映模式的适用性和意图。 2）使模式可被应用所必须存在的环境和条件。 3）设计模式的特征 模式特征指出一些设计的属性，调整这些属性使该模式能适应各种不同的问题。这些属性表示设计的特征，这些特征能被用于检索（通过数据库）以找到合适的模式。 4）应用设计模式的结果（consequences） 对于一个设计模式的使用结果表明设计决策的走向。第六节 统一建模语言UML Unified Modeling Language UML概述 为何研究UML—结束方法大战发展历史 1994年Booch和Rumbaugh在Rational Software Corporation开始了UML的工作，其目标是创建一个“统一的方法”， 1995年OOSE的创始人Jacobson加盟到这项工作中，工作重点转移到创建一种统一的建模语言UML 1996年6月、10月、1997年1月、11月分别推出了UML0.9、 UML0.91、 UML1.0、 UML1.1 UML概述 1997年11月，OMG(Object Management Group)批准把UML1.1作为基于面向对象技术的标准建模语言 之后，UML进行了持续的修订和改进，先后产生了UML1.2、1.3、1.4、1.5版本 2004年推出了UML2.0，UML2.0对UML1.x作了重大的修改。 模型元素 模型元素指模型中的实体以及实体间相互连接的关系 视图与图 静态视图静态视图对应用领域中的概念以及与系统实现有关的内部概念建模，主要由类以及类之间的相互关系组成，在静态视图中不描述依赖于时间的系统行为。静态视图用类图来展示。设计视图设计视图对应用自身的设计结构建模，例如，将设计结构扩展成：结构化类元(classifier)、为实现功能所需的协作以及良定义接口的构件的组装。设计视图由内部结构图、协作图和构件图实现。 用况视图用况视图对被称为执行者的外部代理（他与特定视点的主题交互）所感受到的主题（如系统）功能建模。用况视图的意图是列出系统中的用况和执行者，并显示哪个执行者参与了哪个用况的执行。用况的行为用动态视图，特别是交互视图来表示。用况视图用用况图来展示。 状态机视图状态机视图对一个类的对象的可能生命历程建模。一个状态机包括用迁移连接的状态，每个状态对一个对象在其生命期中满足某种条件的一个时间段建模。当一个事件发生时，它会导致触发对象的一个状态向另一个新状态的迁移，附加在迁移上的动作或活动也同时被执行。状态机视图用状态机图来展示。 活动视图活动展示了包含在执行计算或工作流中的计算活动的控制流。一个动作是一个基本的计算步，一个活动结点是一组动作或子活动，一个活动可描述顺序的和并发的计算。活动视图用活动图来展示。交互视图交互视图描述系统各部分中消息交换的顺序。交互视图提供了系统中行为的整体视图，也就是说，它展示了多个对象间交叉的控制流。交互视图用顺序图和通信图来展示。 部署视图部署视图描述了运行时结点上制品的分布。制品是一个物理实现单元，如一个文件，它也可以表示一或多个构件的实现（一种表现形式）。结点是运行时表示计算资源的物理对象，如，计算机、设备或内存。部署视图允许对分配的结果和资源分配进行评估。部署视图用部署图来展示。 模型管理视图模型管理视图对模型自身的组织建模。一个模型由一组保存模型元素（如类、状态机、用况）的包组成。包还可以包含其它的包，因此，一个模型从一个间接包含所有模型内容的根包（root package）开始。包是操纵模型内容的单元，也是访问控制和配置控制的单元。每个模型元素可以被一个包或另一个元素拥有。模型管理信息通常展示在包图中，它是类图的变种。 剖面（profile） UML是用一个元模型（metamodel）定义的，元模型是指描述建模语言自身的模型。通常元模型的改变是复杂的，也是危险的。剖面机制允许在不修改基础元模型的前提下对UML作有限的变化。UML包含三个主要的可扩展结构：约束（constraints）、版型（stereotypes）和标签值（tagged values）。约束是以自然语言或特定形式语言的正文表示的语义条件或限制，约束写在花括号中（｛｝），如｛value≥0｝，｛or｝。版型是在基于现有各类模型元素的外形中定义模型元素的新类型，它本质上是一种新元类（metaclass）。版型可以扩展语义，但不能扩展原元模型类的结构。用《 》标记版型，如《signal》。标签值是贴在任何模型元素上的被命名的信息片。下图给出了版型和标签值的应用实例。 类图 类图展示了系统中类的静态结构，即类与类之间的相互联系。类之间有多种联系方式，如关联（相互连接）、依赖（一个类依赖或使用另一个类）、泛化（一个类是另一个类的特殊情况）等。可以把若干个相关的类包装在一起作为一个单元（包），相当于一个子系统。一个系统可以有多张类图，一个类也可以出现在几张类图中。 对象图 对象图是类图的实例，它展示了系统执行在某一时间点上的一个可能的快照。对象图使用与类图相同的符号，只是在对象名下面加上下划线，同时它还显示了对象间的所有实例链接（link）关系。 内部结构图内部结构图展示了类的分解，给出了组成一个结构化类元的相互连接的部分、端口和连接器。 协作图协作图展示了协作的定义，是一种合成的结构图。协作是为了完成某一目的而一起工作的一组对象间的上下文关系。 构件图构件图展示了系统中的构件（即来自应用的软件单元），构件间通过接口的连接，以及构件之间的依赖关系。构件是一种结构化类元，可以用内部结构图来定义它的内部结构。 用况图用况图展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述，执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况。用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能。用况通常用普通正文描述，也可以用活动图来描述。 状态机图状态机图通常是对类描述的补充，它说明该类的对象所有可能的状态以及哪些事件将导致状态的改变。一个事件可以是另一个对象向它发送的一条消息，或者是满足了某些条件。状态的改变称为迁移（transition）。一个状态迁移还可以有与之相关的动作，该动作指出状态迁移时应做什么。并不是所有的类都要画状态机图，有些类有一些意义明确的状态，并且其行为受不同的状态所影响和改变，这些类才需要画状态机图。 活动图活动图展示了连续的活动流。活动图通常用来描述完成一个操作所需要的活动。当然它还能用于描述其它活动流，如描述用况。活动图由动作状态组成，它包含完成一个动作的活动的规约(即规格说明)。当一个动作完成时，将离开该动作状态。活动图中的动作部分还可包括消息发送和接收的规约。 顺序图顺序图展示了几个对象之间的动态交互关系。它主要是用来显示对象之间发送消息的顺序，它还显示了对象之间的交互，即系统执行的某一特定点所发生的事。 通信图通信图用几何排列来表示交互作用中的角色，它显示了有协作关系的复合结构组成部分或角色范围内的交互。它明确地显示元素之间的协作关系，而不显示作为独立维的时间，消息的顺序和并发线程必须由顺序号确定。 部署图部署图展示了运行时处理结点和在结点上生存的制品的配置。结点是运行时的计算资源，制品是物理实体，如构件、文件。部署图中显示部署在结点上的制品和它们之间的关系，以及结点之间的连接和通信方式。 包图包图是由包和它们间的关系组成的结构图模型是在某一视点给定的精度上对系统的完整描述，一个系统可以从不同的视点（如分析模型、设计模型）存在多个模型。一个模型可看作一个特定类型的包，通常仅显示包就足够了（不必显示包内部的细节）。下图给出了剧院系统所细分成的包以及它们之间的依赖关系。 内容摘要 UML概述用况建模静态建模动态建模物理体系结构建模用况建模 用况建模是用于描述一个系统应该做什么的建模技术，用况建模不仅用于新系统的需求获取，还可用于已有系统的升级。用况模型用用况图来描述。 用况图展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述，执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况。用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能。 用况通常用普通正文描述，也可以用活动图来描述。 任何一个涉及到系统功能活动的人都会用到用况模型。 客户：用况模型指明了系统的功能，描述了系统能如何使用。用况建模时客户的积极参与是十分重要的。 开发者：用况模型帮助他们理解系统要做什么，同时为以后的其它模型建模、结构设计、实现等提供依据。 集成测试和系统测试人员：根据用况来测试系统，以验证系统是否完成了用况指定的功能。 用况建模步骤创建用况模型的步骤包括： 1．定义系统 2．确定执行者 3．确定用况 4．描述用况 5．定义用况间的关系， 6．确认模型 用况模型由用况图组成，用况图展示了执行者、用况以及它们之间的关系。用况通常用正文形式来描述。一个用况模型可由若干幅用况图组成。一幅用况图包含的模型元素有系统、执行者、用况，以及表示它们间的不同关系，如关联、扩展、包含、泛化等。用况图 一. 确定执行者执行者是指与系统交互的人或其它系统执行者代表一种角色，而不是具体的某个人 执行者可分成主执行者和副执行者：主执行者使用系统的主要功能 例如，保险系统中主执行者处理保险的注册和管理 副执行者处理系统的辅助功能 例如，管理数据库、通信、备份以及其它管理等系统维护 执行者还可分为主动执行者和被动执行者：主动执行者开始一个用况被动执行者从不开始用况，只是参与一个或多个用况 我们可以通过回答下列问题来确定执行者：谁使用系统的主要功能（主执行者）？谁需要从系统中得到对他们日常工作的支持？谁需要维护、管理和维持系统的日常运行（副执行者）？系统需要控制哪些硬件设备？系统需要与哪些其它系统交互？哪些人或哪些系统对系统产生的结果（值）感兴趣？ 确定用况 1. 用况的特征用况总是被执行者启动的（initiated），执行者必须直接或间接地指示系统去执行用况用况向执行者提供值，这些值必须是可识别的用况是完整的，一个用况必须是一个完整的描述 用况是一个类型，而不是实例，用况的实例称为场景（scenario） 2. 寻找用况可以通过让每个执行者回答以下问题来寻找用况：执行者需要系统提供哪些功能？执行者需要系统做什么？执行者是否需要读、创建、删除、修改或储存系统中的某类信息？执行者是否要被系统中的事件提醒，或者执行者是否要提醒系统中某些事情？从功能观点看，这些事件表示什么？执行者的日常工作是否因为系统的新功能（尤其是目前尚未自动化的功能）而被简化或提高了效率？ 另外还有一些不是目前的执行者回答的问题：系统需要哪些输入/输出？谁从系统获取信息？谁为系统提供信息？与当前系统（可能是人工系统而不是自动化系统）的实现有关的主要问题是什么？ 对同一个项目，不同的开发者选取的用况数是不一样的。例如一个10个人年规模的项目，有人选取了20个用况，而在一个类似的项目中，有人选用了100个用况。 似乎20个太少，而100个太多，希望在项目规模和用况数之间保持均衡。 3. 用况的描述 用况通常用正文（text）来描述，也可用活动图来描述 。 用况的正文描述应包括以下内容：用况的目的：用况的最终目的是什么？它试图达到什么？用况是如何启动（initiate）的：哪个执行者在什么情况下启动用况的执行？执行者和用况之间的消息流：用况与执行者之间交换什么消息或事件来通知对方改变或恢复信息？描述系统与执行者之间的主消息流是什么？以及系统中哪些实体被使用或修改？ 用况中可供选择的流：用况中的活动可根据条件或异常（exception）有选择地执行。如何通过给执行者一个值来结束用况：描述何时可认为用况已结束. 执行者的简要描述 如客户：向公司订购商品的人 客户代表：公司处理客户请求的雇员 库存系统：记录公司库存的软件用况的简要描述 如订购货物：客户创建一个新的请求商品的订单，并为那些商品付费 取消订单：客户取消一个已经存在的订单 用况的详细描述前置条件和后置条件前置条件和后置条件表示用况开始和结束的条件事件流（flow of events）事件流是一系列陈述句，它是从执行者的角度看，列出用况的各个步骤用况描述中可以包含条件、分支和循环。例如：订购货物用况的描述如下 用况名称：订购货物参与的执行者：客户、客户代表前置条件：一个合法的客户已经登录到这个系统事件流：当客户选择订购货物时，用况开始客户输入他的姓名和地址如果客户只输入邮编，系统将给出州和城市名当客户输入产品代码 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束 5. 客户输入信用卡支付信息 6. 客户选择提交 7. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息。如果客户提交的信息不正确，系统将提示客户修改。 8. 当支付确认后，订单就被标记上已经确认，同时返回给客户一个订单ID，用况也就结束了。如果支付没有被确认，系统将提示客户改正支付信息或者取消。如果客户选择修改信息，就回到第5步；如果选择取消，用况结束。后置条件：如果订单没有被取消，它将保存在系统中，并做上标记 其他需求在用况中还可描述一些特殊的需求，这些需求常常是非功能性需求，如可用性、安全性、可维护性、负载、性能、自动防故障、数据需求等。如订购货物用况的其他需求：前置条件：（略）事件流： （略）特殊需求： 系统必须在一秒内响应客户的输入后置条件： （略） 事件流可分为两部分：基本路径 基本路径是运转正常时的路径，是一系列没有分支和选择的简单陈述句可选路径 可选路径是指不同于基本路径而允许不同的事件序列的路径。 对于明显有可能随时发生的事情来说，可选路径非常有效。 如订购货物用况的基本路径：事件流：基本路径当客户选择订购货物时，用况开始客户输入他的姓名和地址当客户输入产品代码时 a. 系统给出产品描述和价格 b. 系统往客户订单中添加该物品的价格 循环结束 4. 客户输入信用卡支付信息 5. 客户选择提交 6. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息 7. 当支付确认后，订单就被标记上已经确认，同时返回给客户一个订单ID，用况结束 如果在订购货物用况中，客户可以在提交订单前随时取消订单，其可选路径如下：可选路径：在选择提交前的任何时候，客户都可以选择cancel。这次订购没有被保存，用况结束。在基本路径第6步，如果有任何不正确的信息，系统提示客户去修改这些信息。在基本路径第7步，如果支付没有被确认，系统将提示客户改正支付信息或者取消。如果客户选择修改信息，就回到基本路径第4步；如果选择取消，用况结束。 确定用况之间的关系 实例本实例实现一个简化了的银行储蓄账户管理系统，该系统是在银行的柜台上对客户办理活期储蓄业务。系统的需求陈述如下：一个客户可以在多个银行中开设账户，一个客户也可在同一银行中开设多个不同的账户。客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动。其中转账指客户将自己的某个账户上的钱款转入同一银行的不同账户（称为银行内转账）或转入不同银行的账户（称为银行间转账）。系统管理员负责系统的账户管理及业务报表的生成。 识别执行者客户：到银行办理储蓄业务的人，负责输入密码银行职员（客户代理）：银行工作人员，代表客户进行储蓄业务的操作银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户管理员：银行计算机的管理人员，负责账户的管理和业务报表的生成 识别用况从系统的需求陈述可知，银行职员（客户代理）需要系统提供开户、存款、取款、转账、注销账户等功能，这些功能都包含了校验密码的功能。系统管理员需要系统提供账户管理和报表生成功能。银行职员（管理人员）则参与了账户管理中的更新账户的功能。此外，转账功能可分为银行内转账和银行间转账，我们可将它们设计成三个用况，其中银行内转账用况和银行间转账用况都继承了基本转账用况。据此分析，得到该系统的用况图如下图所示。 开户用况描述用况名称：开户参与的执行者：银行职员（客户代理），客户前置条件：一个合法的银行职员（客户代理）已登录到该系统事件流： 1.当选择开户功能时用况开始 2.输入客户信息（姓名、地址、身份证号等） 3.从账户管理系统获取新的账号 4.请客户输入密码 5.请客户再次输入密码 6.如果两次密码不一致则回到第4步，否则继续 7.在账户库中添加新账户 8.打印存折，用况结束后置条件：在账户库中增加了一个新账户，得到一张新存折 取款用况描述用况名称：取款参与的执行者：银行职员（客户代理）前置条件：一个合法的银行职员（客户代理）已登录到该系统事件流：基本路径： 1.当选择取款功能时用况开始 2.当输入客户信息（姓名、账号等）后 a）如果客户信息与账户不一致，显示错误信息，可以重新输入或结束用况 b）如果该账户被冻结（如因挂失而冻结），显示冻结信息并结束用况 3.输入并校验密码 4.输入取款金额，如果该账户的余款小于取款金额，显示错误信息，要求重新输入 5.打印取款单，交客户签字 6.建立取款事件记录，更新账户信息 7. 打印存折，用况结束可选路径： 1.在第5步客户签字之前的任何时刻，客户可以取消本次取款，用况结束 2.第3步校验密码时，如发现密码不一致，则重新输入密码，或用况结束后置条件：如果取款成功，客户账户中的余额被更新（减少），否则余额不变。 描述取款用况的活动图内容摘要 UML概述用况建模静态建模动态建模物理体系结构建模静态建模 （类和对象建模） 类和对象模型的基本模型元素有类、对象以及它们之间的关系。系统中的类和对象模型描述了系统的静态结构，在UML中用类图和对象图来表示。 类图由系统中使用的类以及它们之间的关系组成。类之间的关系有关联、依赖、泛化、实现等。类图是一种静态模型，它是其它图的基础。一个系统可以有多张类图，一个类也可出现在几张类图中。 对象图是类图的一个实例，它描述某一时刻类图中类的特定实例以及这些实例之间的特定链接。对象图使用了与类图相同的符号，只是在对象名下附加下划线，对象名后可接以冒号和类名，即 object-name:class-name 类图和对象图确定类 1. 标识类 这里介绍一种类—责任—协作者（class—responsibility—collaborator，简称CRC）技术。CRC实际上是一组表示类的索引卡片，每张卡片分成三部分，它们分别描述类名、类的责任和类的协作者。 (1) 标识潜在的对象类 通常陈述中的名词或名词短语是可能的潜在对象，它们以不同的形式展示出来，如： 1) 外部实体（如，其它系统、设备、人员），他们生产或消费计算机系统所使用的信息； 2) 物件（如，报告、显示、信函、信号），它们是问题信息域的一部分； 3) 发生的事情或事件（如，性能改变或完成一组机器人移动动作），它们出现在系统运行的环境中； 4) 角色（如：管理者、工程师、销售员），他们由与系统交互的人扮演； 5) 组织单位（如：部门、小组、小队），他们与一个应用有关； 6) 场所（如：制造场所、装载码头），它们建立问题和系统所有功能的环境； 7) 构造物（如，四轮交通工具、计算机），它们定义一类对象，或者定义对象的相关类。 回答下列问题来识别潜在对象：是否有要储存、转换、分析或处理的信息？是否有外部系统？是否有模式（pattern）、类库和构件等？是否有系统必须处理的设备？是否有组织部分（organizational parts）? 业务中的执行者扮演什么角色？这些角色可以看作类，如客户、操作员等。 （2）筛选对象类，确定最终对象类我们可以用以下选择特征来确定最终的对象： 1) 保留的信息：仅当必须记住有关潜在对象的信息，系统才能运作时，则该潜在对象在分析阶段是有用的； 2) 需要的服务：潜在对象必须拥有一组可标识的操作，它们可以按某种方式修改对象属性的值； 3) 多个属性：在分析阶段，关注点应该是“较大的”信息（仅具有单个属性的对象在设计时可能有用，但在分析阶段，最好把它表示为另一对象的属性）； 4) 公共属性：可以为潜在的对象定义一组属性，这些属性适用于该类的所有实例； 5) 公共操作：可以为潜在的对象定义一组操作，这些操作适用于该类的所有实例； 6) 必要的需求：出现在问题空间中的外部实体以及对系统的任何解决方案的实施都是必要的生产或消费信息，它们几乎总是定义为需求模型中的类。 对象和类还可以按以下特征进行分类： 1) 确切性（tangibility）：类表示了确切的事物（如，键盘或传感器），还是表示了抽象的信息（如，预期的输出）？ 2) 包含性（inclusiveness）：类是原子的（即不包含任何其它类），还是聚合的（至少包含一个嵌套的对象）？ 3) 顺序性（sequentiality）：类是并发的（即，拥有自己的控制线程），还是顺序的（被外部的资源控制）？ 4) 持久性（persistence）：类是短暂的（即，它在程序运行期间被创建和删除）、临时的（它在程序运行期间被创建，在程序终止时被删除）、还是永久的（它存放在数据库中）？ 永久对象（persistent object）：其生存周期可以超越程序的执行时间而长期存在的对象。 5) 完整性（integrity）：类是易被侵害的（即，它不防卫其资源受外界的影响），还是受保护的（该类强制控制对其资源的访问）。 基于上述分类，CRC卡的内容可以扩充，以包含类的类型和特征。 2. 标识责任 责任是与类相关的属性和操作，简单地说，责任是类所知道的或要做的任何事情。 （1） 标识属性 属性表示类的稳定特征，即为了完成客户规定的目标所必须保存的类的信息，一般可以从问题陈述中提取出或通过对类的理解而辨识出属性。分析员可以再次研究问题陈述，选择那些应属于该对象的内容，同时对每个对象回答下列问题：“在当前的问题范围内，什么数据项（复合的和/或基本的）完整地定义了该对象？” （2） 定义操作 操作定义了对象的行为并以某种方式修改对象的属性值。操作可以通过对系统的过程叙述的分析提取出来，通常叙述中的动词可作为候选的操作。类所选择的每个操作展示了类的某种行为。操作大体可分为三类：以某种方式操纵数据的操作（如，增加、删除、重新格式化、选择）；完成某种计算的操作；为控制事件的发生而监控对象的操作。 3. 标识协作者 一个类可以用它自己的操作去操纵它自己的属性，从而完成某一特定的责任，一个类也可和其它类协作来完成某个责任。如果一个对象为了完成某个责任需要向其它对象发送消息，则我们说该对象和另一对象协作。协作实际上标识了类间的关系。 为了帮助标识协作者，可以检索类间的类属关系。如果两个类具有整体与部分关系（一个对象是另一个对象的一部分），或者一个类必须从另一个类获取信息，或者一个类依赖于（depends-upon）另一个类，则它们间往往有协作关系。 4. 复审CRC卡 在填好所有CRC卡后，应对它进行复审。复审应由客户和软件分析员参加，复审方法如下： 1) 参加复审的人，每人拿CRC卡片的一个子集。注意，有协作关系的卡片要分开，即，没有一个人持有两张有协作关系的卡片。 2) 将所有用况/场景分类。 3) 复审负责人仔细阅读用况，当读到一个命名的对象时，将令牌（token）传送给持有对应类的卡片的人员。 4) 收到令牌的类卡片持有者要描述卡片上记录的责任，复审小组将确定该类的一个或多个责任是否满足用况的需求。当某个责任需要协作时，将令牌传给协作者，并重复4）。 5) 如果卡片上的责任和协作不能适应用况，则需对卡片进行修改，这可能导致定义新的类，或在现有的卡片上刻画新的或修正的责任及协作者。 这种做法持续至所有的用况都完成为止。 UML对属性的描述 UML中，描述一个属性的语法如下： visibilityopt /opt attribute-name : type opt multiplicityopt = initial-valueopt {property-string}opt 其中带下标opt或 opt的部分表示该部分是任选的。 visibility（可见性）：表示该属性在哪个范围内可见（即可使用），见下表。 attribute-name：表示属性名。 type（类型）：用来指明属性名的类型。 multiplicity（重数）：用来指出该属性可能的值的个数以及它们的排列次序和唯一性。值的个数写在方括号([ ])中，其形式是：[minimum..maximum]。maximum可以是“*”，表示“无限”。当值的个数是单一值（如值的个数是3）时，可写成[3..3]或简写成[3]。典型的写法有：[0..1]，[1]（表示[1..1]），[*]（表示[0..*]），[1..*]，[1..3]。当重数缺省时，隐含表示重数为1。当一个属性有多个值时，可在值的个数后面指明值元素的排列次序和唯一性，排列次序和唯一性写在花括号({ })中，可使用的关键字如下表所示，其默认值是set，即无序且值元素唯一。 initial-value（初值）：在创建一个类的实例对象时，应对其属性赋值，如果类中对某属性定义了初值，那么该初值可作为创建对象时该属性的默认值。 property-string（特征字符串）：用来明确地指明该属性可能的候选值，如｛红，黄，绿｝指出该属性可枚举的值只能是红、黄、绿。 属性还可以定义为类属性（class attribute，C++或Java中称为静态属性—static attibute） ，表示被这个类的所有实例对象共享该属性的值。类属性是这个类的名字空间中的全局变量。类属性用下划线来指明。 UML对操作的描述 UML中描述一个操作的语法如下： visibilityopt operating-name（parameter-list） : return-type opt { property-string }opt 操作可见性的含义与属性中的含义相同。参数表是用逗号分隔的形式参数序列，描述一个参数的语法如下： directionopt parameter-name ：type multiplicityopt = default -valueopt 其中：direction（方向）：用来指明参数信息流的方向 。 方向的取值 type 和multiplicity的含义与属性中的含义相同，default –value（默认值）是在操作的调用者未提供参数时，用它作为该参数的值。 类也可以定义类操作（class operation）。通常操作是在该类的对象实例上被调用的，而类操作可以在没有对象实例的情况下被调用，但此时只允许访问类属性。 类之间的关系 1. 关联关联描述了系统中对象之间或其它实例之间的连接。关联的种类主要有二元关联，多元关联，受限关联，聚集（aggregation）和组合（composition）。 (1)二元关联 二元关联表示为在两个类之间用一条直线连接，直线上可写上关联名。 关联的两端可加上重数（multiplicity） ，表示该类有多少个对象可与对方的一个对象关联 (2)多元关联 三个或三个以上的类之间可以互相关联 （3）受限关联（qualified association）：受限关联用于一对多或多对多的关联。限定符（qualifier）用来区分关联“多”端的对象集合，它指明了在关联“多”端的某个特殊对象 （4） 聚集和组合 聚集（aggregation）是表示整体-部分关系的一种关联，它的“部分”对象可以是任意“整体”对象的一部分。 组合（composition）：组合是一种更强形式的关联，代表整体的组合对象有管理它的部分对象的特有责任，如部分对象的分配和解除分配。组合关联具有强的物主身份，即“整体”对象拥有“部分”对象，“部分”对象生存在“整体”对象中。 （5）关联类 ：UML中可以把关联定义成类，该关联的每个链都是这个类的实例 （6）导航性（navigability） 导航性 泛化 泛化指出类间的“一般—特殊关系” （is-a）一般类定义了它的特殊类的公共属性和操作对一般类扩展一些属性和/或操作后，可以特化（specialize）成特殊类一般类是特殊类的父类，特殊类是一般类的子类特殊类可以继承一般类的属性和操作子类可以定义自己的属性和操作，也可重新定义父类中的操作，但重新定义的操作必须与父类具有相同的操作特征（signature） 泛化是一种分类学关系，一个一般类可以从不同的维或方面将其特化（specialization）成不同的特殊类集合，用一个类元（用作分类符）来表示一个维或方面，由一个类元特化而成的特殊类组成一个泛化集（generalization set）。在泛化集中可对其元素应用约束，在UML中提供以下约束，见下表。 泛化集的约束 3. 实现：实现关系将一个模型元素（如类）连接到另一个模型元素（如接口），后者（如接口）是行为的规约（specification），而不是结构，前者（如类）必须至少支持（通过继承或直接声明）后者的所有操作。可以认为前者是后者的实现。泛化和实现都可以将一般描述与具体描述联系起来。其区别是，泛化是同一语义层上的元素之间的连接，通常在同一模型内；而实现是不同语义层中的元素之间的连接，它通常建立在不同的模型内，如设计类到分析类是一种实现关系。 4. 依赖：依赖指出两个或多个模型元素之间语义上的关系。它表示被依赖元素的变化会要求或指示依赖元素的改变。 依赖关系用一个虚线箭头表示，箭头上可附加含关键字的版型，关键字用来指明依赖的种类。在UML2．0中的依赖种类如下： Access（访问）， bind（绑定）， call（调用）， create（创建）， derive（派生）， instantiate（实例化）， permit（允许）， realize（实现）， refine（精化）， send（发送）， substitute（替换）， trace（追踪依赖）， use（使用） 5. 约束和派生（constraint & derivation）约束是用自然语言或特定的形式语言正文表示的语义条件或限制，它用“｛正文字符串｝”形式表示。约束可以附加到任何模型元素上，如前面有关泛化的约束有：不相交、交迭、完全的、不完全的。 内容摘要面向对象的基本概念面向对象的分析和设计过程 UML概述用况建模静态建模动态建模物理体系结构建模动态建模 动态建模用来描述系统的动态行为，显示对象在系统运行期间不同时刻的动态交互。UML中用状态机图、活动图、顺序图、通信图和协作图来建立动态模型。 状态机图状态机图通常是对类描述的补充，它说明该类的对象所有可能的状态，以及哪些事件将导致状态的改变。状态机图描述了对象的动态行为，是一种对象生存周期的模型。画状态机图的步骤 1）列出对象具有的所有状态 状态分为起始状态、结束状态和中间状态。一张状态机图可以有一个起始状态和若干个（可以为0）结束状态。 2）标识导致状态转换的事件 当一个对象接收到某个事件时，会导致从一个状态转换到另一个状态，称为状态迁移（transition）。 3）为状态和迁移定义状态变量和动作 在状态迁移和/或处于某个状态中时都可能需要执行一些相应的动作，综合这些动作，使得对象完成相应的功能。 状态一个状态由状态名、状态变量和活动三部分组成。状态变量是状态机图所显示的类的属性，也可以是临时变量。活动部分列出了处于该状态时要执行的事件和动作。 有三个标准事件：entry，exit和do。 Entry和exit事件用于指明进入和退出该状态时的特定动作。 do事件用于指明处于该状态中时执行的动作。活动区中事件的语法如下： event-nameopt (argument list ) opt [guard-condition] opt /activity-expressionopt 其中，事件名可以是包括三个标准事件（entry，exit，do）在内的任何事件，参数表表示该事件所需的参数，警戒条件是一布尔表达式，动作表达式是该事件将被执行的动作。 状态迁移 1. 状态迁移 引起状态迁移的原因通常有两种：当标在迁移箭头上的事件出现时会引起状态的迁移。此时，首先执行引起迁移的事件中的动作，然后迁移到新的状态，执行新状态中的内部动作（包括entry、exit、do以及用户定义的动作）。在执行do或用户定义的动作时，可以被外部的事件（将导致该状态的迁移）中断，但entry动作和exit动作是不能被中断的，并且它们总是要执行完的。 当状态机图中相应的迁移上未指明事件时，表示当位于迁移箭头源头的状态中的内部动作（包括entry、exit、do以及用户定义的动作）全部执行完后，该状态迁移被自动触发。 状态迁移的语法如下： event-name opt ( parameter-list ) opt [guard-condition] opt /effect-listopt 其中：事件名及其参数表指出触发迁移的事件，参数表的语法与“操作”中定义语法相同。警戒条件是一个布尔表达式。如果状态迁移中既有事件特征又有警戒条件，则表示仅当这个事件发生并且警戒条件为真时才触发相应的状态迁移；如果状态迁移上只有警戒条件，则表示当该条件变为真时，触发状态迁移。 effect-list是当该迁移触发时执行的过程表达式，即动作表达式。表达式中可引用相应对象中的属性、操作，或者事件特征中的参数。动作可以包括调用、发送和其它种类的动作。一个状态迁移上可以有多个用′/′符号分隔动作表达式，它们按从左到右的次序依次执行。不允许有嵌套的或递归的动作表达式。 事件事件是指已发生并可能引发某种活动的一件事 事件的种类活动图活动图可看作一种特殊形式的状态机，用于对计算流程和工作流建模。活动图的状态表示计算过程中所处的各种状态。活动图用来描述完成一个操作所需要的活动，或者是一个用况实例（场景）的活动。活动图使用状态机图的符号表示，活动图中的状态称为动作状态，用圆角矩形表示，动作状态之间的迁移用箭头表示，迁移上可以附加警戒条件、发送子句和动作表达式。与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发。 一张活动图可划分成若干个矩形区，每个矩形区为一个泳道，泳道名放在矩形区的顶端。通常根据责任把活动组织到不同的泳道中，它能清楚地表明动作在哪里执行（在哪个对象中），或者表明一个组织的哪部分工作（一个动作）被执行。一个动作迁移可以分解成二个或多个导致并行动作的迁移，若干个来自并行活动的迁移也可以合并成一个迁移。值得注意的是，在合并之前并行迁移上的活动必须全部完成。在活动图中用黑体线来表示迁移的分解和合并。活动图中可以表示对象，对象用对象符号（矩形）表示，它可作为活动的输入或输出（用虚线箭头连接），也可展示一个对象受一特定动作的影响（用动作和对象之间的虚线表示）。 活动图中可以描述信号的发送和接收 活动图还可以用来描述用况 顺序图顺序图用来描述对象间的交互行为，它关注于消息的顺序，即对象间消息的发送和接收的顺序。顺序图还揭示了一个特定场景的交互，即系统执行期间发生在某时间点的对象之间的特定交互。它适合于描述实时系统中的时间特性和时间约束。顺序图有两个坐标，垂直坐标表示时间（从上到下），水平坐标表示一组对象（用对象框表示）。 顺序图中对象框下可画一垂直的虚线，称为该对象的生存线（lifeline），用来指出该对象执行期间的时序。对象之间的消息发送用生存线之间的消息箭头表示。当一个对象接收到一个消息时，该对象开始活动，称为激活。激活画成对象生存线上的一个长方形框，表示该对象可能在执行自己的代码，可能在等待另一对象的返回。按垂直坐标从上到下的次序读顺序图，可以观察到随时间的前进消息通信的顺序。 呼叫方拿起受话器 拨号音开始 拨数字（2） 拨号音结束 拨数字（2） 拨数字（8） 拨数字（2） 拨数字（1） 铃声 电话振铃 应叫方摘机 铃声消失 停止振铃 电话接通 电话接通 呼叫方挂机 电话被切断 电话被切断 应叫方挂机 顺序图中描述消息的语法如下： attribute = opt name (argument-list) opt :return-valueopt 其中：attribute是生命线的属性（对象名），用以存储返回值。name是消息名（信号或操作名）。argument-list是一个参数值的表，每个参数值可有下列形式之一： argument-value parameter-name=argument-value – 当参数值是“–”时，表示任何参数值都是与模型一致的。 name (argument-list) opt可以用“*”替代，此时，它表示任何消息都是与模型一致的。 在顺序图中，不同的消息表示对象间不同类型的通信。简单消息表示消息类型未知或与消息类型无关，或是一个同步消息的返回。同步消息表示发送对象必须等接收对象完成消息的处理后才能继续执行。异步消息表示发送对象在消息发送后立即继续执行，而不必等待接收对象的返回。传送延迟可用倾斜的箭头表示，意思是消息发送后需经历一段延迟时间才被接收（可以注明最大延迟时间）。 带条件和分支的顺序图消息上可附加条件，当条件为真时消息才被发送或接收。条件可用于描述分支，当几个消息箭头上的条件互斥时，表示某一时刻只有一个消息被发送。如果条件不是互斥的，则消息会并行地发出。 顺序图中可以用标记来定义循环和约束。 顺序图中还可出现递归，即一个对象发消息给自身，这种消息通常是同步的。 创建对象和对象的消亡 一个对象可以通过一条消息创建另一个对象，被创建的对象可在创建它的地方（垂直时间轴上）画一个对象符号。当对象消亡时，在图中用一个×符号表示。此时对象的生命线仅画到消亡的点上。创建或消亡一个对象的消息通常是同步消息。 结构化控制结构前面的顺序图中描述的都是顺序的控制流，对于复杂的控制流可以用组合片段（combined fragment）来表示。一个组合片段有一个关键字和一或多个子片段（subfragment），关键字指明操作符，子片段指出操作对象。下表给出了部分关键字及其含义。 片段中的关键字及其含义 通信图通信图展示了围绕着组合结构的各部分或协作的各角色而组织的一种交互。通信图与顺序图都展示了交互，但它们强调不同的方面。顺序图清晰地展示了时间顺序，但不明确显示对象之间的关系；通信图清晰地展示了对象间的关系，但消息顺序和并发线程必须通过顺序号来指明。 通信图对包含在交互中的角色和链（link）建模，角色与对象绑定，链与对象间的关联绑定，用附加到关联上的箭头表示角色之间的消息通信。同一进程中的所有消息是顺序排列的，不同进程中的消息可以是并发的，也可以是顺序的。消息流通信图中描述消息的语法如下： seguence-expressionopt message 其中：message与顺序图中消息的语法相同，Sequence-expression的语法如下： integer iteration-expressionopt 或 name iteration-expressionopt 其中integer是指定消息顺序的顺序号，如：1、1.1、1.2、2、2.1等。这种顺序号描绘了消息的顺序和嵌套关系。如果是同步消息，则嵌套地调用操作并返回。 name表示并行的控制线程，如1.2a和1.2b是并行发送的并发消息。 iteration-expression表示有条件地或重复地执行，它有如下两种形式： *[iteration-clause] （表示重复） [condrtion-clause] （表示分支）这里iteration-clause是重复条件(循环执行的条件)，即循环执行，如1.1*[x=1..10]:dosomething( )。第二种形式中的condition-clause用于指定分支，如[x < 0]，[x >= 0]，表示仅执行条件为真的分支（发送的消息连接到那个分支）。 链 链是两个对象之间关联的实例，在关联的末端可以标上角色名和约束，约束和角色均应在包含该对象的类图中指明。在链角色上附加的约束可以是： global 、local 、parameter 、self （它们都是应用于链角色的约束）： global （全局）表示该角色是全局的； local （局部）表示该角色是一个操作中的局部变量； parameter （参数）表示该角色是一个操作中的参数； self （自身）指出对象可以向自身发送消息。 vote （表决）是应用于消息的一种约束（约束一个回送消息集合），它指出回送值是通过对集合中所有回送值的表决（多数）来选择的。 broadcast （广播）是应用于一组消息的约束，它指出这组消息不按一定的次序产生。 通信图中对象的生存期 在通信图的对象框中，可用{new}或{destroyed}表示该对象在协作期间被创建或消亡。{transient}则表示对象在同一个协作期间被创建并消亡。 内容摘要 UML概述用况建模静态建模动态建模物理体系结构建模物理体系结构建模系统的体系结构用来描述系统各部分的结构、接口以及它们用于通信的机制。物理体系结构涉及系统的详细描述，它显示了硬件的结构，包括不同的结点和这些结点之间如何连接，它还图示了代码模块的物理结构和依赖关系，并展示了对进程、程序、构件等软件在运行时的物理分配。 物理体系结构应回答以下问题：（1）类和对象物理上位于哪个程序或进程？（2）程序和进程在哪台计算机上执行？（3）系统中有哪些计算机和其它硬件设备？它们如何相互连接？（4）不同的代码文件之间有什么依赖关系？如果一个指定的文件被改变，那么哪些其它文件要重新编译？ UML中物理体系结构用构件图、内部结构图和部署图来描述。 构件图 构件图显示构件类型的定义、内部结构和依赖。构件是系统设计的模块化部分，它给出一组外部的接口，而隐藏了它的实现。在系统中满足相同接口的构件可以自由地替换。构件的接口有二种：供应接口（provided interface）:供应接口声明该构件为其它请求者提供某种服务请求接口（required interface）:请求接口声明该构件请求其它供应者为其提供某种服务，以完成其功能需求。 构件的内部结构用内部结构图定义 构件图显示了系统中的构件（来自应用的软件单元）及其依赖关系部署图部署图展示了运行时处理结点和在结点上生存的制品的配置。部署图描述了处理器、设备和软件构件运行时的体系结构。在这个体系结构上可以看到某个结点上在执行哪个构件，在构件中实现了哪些逻辑元素（类、对象、协作等），最终可以从这些元素追踪到系统的需求分析（用况图）。部署图的基本元素有结点、连接、构件、对象、依赖等。 结点是运行时的计算资源，通常计算资源至少有一个存储器和良好的处理能力，如计算机、设备（如打印机，读卡机，通信设备）等。结点既可看作类型，也可看作实例。结点用三维立方体表示，中间写上结点名，当结点表示实例时，名字应加下划线。结点通过版型来区分不同种类的资源，如《computer》。结点之间的关联表示通信路径，可用版型来区分不同种类的通信路径，如《TCP/IP》。 在结点中可以包含制品（artifact），制品是一个物理实现单元，如文件。可以用版型来区分不同种类的制品。如果一个制品实现了一个构件或其它类，可以从制品到实现它的构件之间画一个虚线箭头，并在箭头上附加关键词《manifest》，这种关系称为“体现”（manifestation）。
展开
