软件工程第十二讲-uml.ppt

统一建模语言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作了重大的修改,UML模型元素(V1.3),模型中的实体以及实体间相互连接的关系,UML模型元素(V2.0),模型中的实体以及实体间相互连接的关系,UML2.0的13种图-1,用况图 (use case diagram) 类图 (class diagram) 对象图 (object diagram) 构件图 (component diagram) 组合结构图 (composite structure diagram) 顺序图 (sequence diagram) 通信图 (communication diagram),交互图 (interaction diagram),UML2.0的13种图-2,状态机图 (state machine diagram) 活动图 (activity diagram) 部署图 (deployment diagram) 制品图 (artifact diagram) 包图 (package diagram) 时间图 (timing diagram) 交互概览图 (interaction overview diagram),UML图1-用况图,描述参与者与用况(参与者使用系统以实现某一特定目标的情形)之间的关联关系，以及用况之间的扩展、继承等关系,UML图2-类图,展现一组类、接口以及它们相互之间的关系,2条或2条以上的线交于0个或1个点,UML图3-对象图,展现一组对象以及相互之间的关系，是依照类图所建立的一组事物(实例)的静态快照,UML图4-构件图,描述构件、接口以及构件间的组装关系的静态视图，复合构件本身可以由内部的子构件图描述,UML图5-组合结构图,UML2.0新增的图，展示了类或协作的内部结构，与构件差别不大，经常认为与构件图等同,UML图6-顺序图,描述特定场景下交互各方消息发送和接收的顺序,UML图7-通信图,另一种交互图，强调交互上下文：参与交互的对象或角色的结构组织,UML图8-状态机图,以状态机的形式描述目标对象在各种事件作用下的行为,UML图9-活动图,描述一系列活动之间的控制流和数据流,UML图10-部署图,描述系统运行时各相关处理单元结点、各结点上部署的构件、以及相互间的通信协议,UML图10-部署图变体:制品图,部署图的变体：描述系统实现制品的物理结构，制品包括文件、数据库等,,这两个物理文件“承载了”逻辑类HelloWorld的实现,UML图11-包图,描述包(一种模型分解单位)以及包之间的关系,UML图12-时间图,UML2.0新增的图，描述对象间的交互，但关注于关于时间的推理，而不仅仅是相对顺序,添水,加热,UML图13-交互概览图,UML2.0新增的图 可认为是：活动图+顺序图的混合体 使用活动图的表示法，其中的节点或者是一个交互或者是一个交互引用,UML2.0的视图和图,需 求,设 计,实现 部署,UML视图1-用况视图,描述可被最终用户、分析人员和测试人员看到的系统(外部)行为 不涉及系统的内部结构，但却是系统体系结构设计的驱动力 静态方面：用况图 动态方面：交互图、状态机图、活动图,UML视图2-设计视图,描述系统设计方案，主要包括类、接口以及相互之间的协作关系 静态方面：类图、对象图 动态方面：交互图、状态机图、活动图,UML视图3-交互视图,展示系统不同部分之间的控制流，包括并发和同步机制 主要针对系统的非功能性方面，例如性能、可伸缩性、吞吐量等 静态方面：类图、对象图 动态方面：交互图、状态机图、活动图 与设计视图的区别：突出控制系统的主动类以及各部分间消息的流动,UML视图4-实现视图,描述组成最终产品发布的相关制品及其关系，实现单元体现为可装配、打包并发布的文件 体现了逻辑单元(类和构件)到物理制品(物理构件、文件等)的映射 静态方面：构件图 动态方面：交互图、状态机图、活动图,UML视图5-部署视图,描述最终产品物理部署的拓扑结构 包括组成整个系统的各种分布式硬件设备，以及各个软件模块在这些设备上的部署和运行关系 静态方面：部署图 动态方面：交互图、状态机图、活动图,内容摘要,面向对象的基本概念 面向对象的分析和设计过程 UML概述 用况建模 静态建模 动态建模 物理体系结构建模,用况建模,用况：文本形式的情节描述，用以说明某参与者使用系统以实现某一特定目标的情形 用况建模用于描述一个系统应该做什么，用用况图来描述(可能有多幅) 用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能,用况图,用框图展示各类外部执行者(actor)与系统所提供的用况之间的参与关系，包括： 系统边界、用况 执行者(参与者)：可能使用这些用况的人或外部系统，参与者与用况连接表示参与者使用了该用况 模型元素间关系：关联、扩展、包含、泛化等 每个用况的细节通常用文字描述，也可以用活动图来描述,用况之间的关系-1,,用况之间的关系-2,订购系统用况图,,,客户,售票员,送货员,主管,建立信用,供应订单,订单支付,提供 客户数据,产生订单,信用卡 支付,现金支付,设置订单,请求 目录,订购,《include》,《include》,《include》,《extend》,核对身份,,,,,,,,,,,,关联,扩展,包含,泛化,包含,泛化,参与者之间的泛化关系,用况图对于各方的作用,客户：用况模型指明了系统的功能，描述了系统能如何使用 开发者：用况模型帮助他们理解系统要做什么，同时为以后的其它模型建模、结构设计、实现等提供依据 集成测试和系统测试人员：根据用况来测试系统，以验证系统是否完成了用况指定的功能,用况建模步骤,定义系统(总体范围) 确定参与者 确定用况 描述用况 定义用况间的关系 确认模型,用况建模—定义系统范围/边界,根据项目的总体目标/任务以及基本的开发决策决定做什么不做什么 总体目标/任务：实现出版社书籍的网上销售 开发决策：网上支付采用银联支付系统、书籍的基本信息来自于出版社已有的编辑和发行管理系统(遗产系统) 边界外的人或系统(第三方系统、遗留系统等)成为候选的参与者,用况建模—确定参与者,参与者是指与系统交互的人、组织或其它系统 参与者代表一种角色，而不是具体的人 可分成主参与者和辅助参与者 主参与者是用况的直接执行者，例如保险系统中业务员处理保险的注册和管理 辅助参与者对于用况的执行起辅助作用，例如保险系统中管理员负责分配业务员权限,确定参与者的启发式问题,谁使用系统的主要功能(主执行者) 谁需要从系统中得到对他们日常工作的支持 谁需要维护、管理和维持系统的日常运行 系统需要控制哪些硬件设备 系统需要与哪些其它系统交互 哪些人或哪些系统对系统产生的结果(值)感兴趣,用况建模—确定用况,用况的特征 用况总是由参与者启动的 执行者必须直接或间接地指示系统去执行用况 用况向参与者提供服务或返回结果，这些结果必须是可识别的 用况是完整的，一个用况必须是一个完整的描述 (有开始、有结果),用况(Use Case),文本形式的情节描述，用以说明某参与者使用系统以实现某一特定目标的情形 例：顾客携带所购商品到达收银台，收银员使用POS系统记录每件商品，系统连续显示累计金额并逐行显示细目，顾客输入支付信息，系统对支付信息进行验证和记录，成功后更新库存信息，顾客从系统得到购物小票然后离开,场景(Scenario),使用系统的一个特定情节或用况的一条执行路径，即用况实例(Use Case Instance) 主成功场景：顾客携带商品到收银台，顺利地完成商品扫描及信用卡付款等全过程 替代场景1：…商品扫描失败，提示输入商品唯一码… 替代场景2：…信用卡划账通讯失败，提示客户使用现金结帐… …… 替代场景n：用户信用卡支付成功后要求退货…… 因此用况就是一系列可能的场景集合,确定用况的启发式问题,执行者需要系统提供哪些功能？执行者需要系统做什么? 执行者是否需要读、创建、删除、修改或储存系统中的某类信息? 执行者是否要被系统中的事件提醒，或者执行者是否要提醒系统中某些事情?从功能观点看，这些事件表示什么? 执行者的日常工作是否因为系统的新功能(尤其是目前尚未自动化的功能)而被简化或提高效率,用况建模—描述用况,使用文本描述 用况的目的 用况是如何启动的：哪个参与者在什么情况下启动(前提) 参与者和用况之间的消息流(步骤) 主消息流和其它消息流是什么 根据条件或异常情况等选择不同的流程分支 系统中哪些实体被使用或修改(结果)，如何确定用况执行结束 使用活动图描述,用况的简要文字描述,执行者的简要描述，如 客户：向公司订购商品的人 客户代表：公司处理客户请求的雇员 库存系统：记录公司库存的软件 用况的简要描述，如 订购货物：客户创建一个新的请求商品的订单，并为那些商品付费 取消订单：客户取消一个已经存在的订单,用况的详细描述,用况名称、参与者 用况的前置条件和后置条件：用况开始和结束的条件 事件流：一系列陈述句，从参与者的角度出发的一系列步骤 一般有多个事件流：主要流程、其它流程 特殊需求：相关的非功能性需求,用况的详细描述结构,POS系统收银用况详细说明-1,POS系统收银用况详细说明-2,POS系统收银用况详细说明-3,确定用况之间的关系,关联：参与者与用况 扩展：用况与用况 包含：用况与用况 泛化：用况与用况,实例,本实例实现一个简化了的银行储蓄账户管理系统，该系统是在银行的柜台上对客户办理活期储蓄业务。

系统的需求陈述如下： 一个客户可以在多个银行中开设账户，一个客户也可在同一银行中开设多个不同的账户客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动其中转账指客户将自己的某个账户上的钱款转入同一银行的不同账户（称为银行内转账）或转入不同银行的账户（称为银行间转账）系统管理员负责系统的账户管理及业务报表的生成识别执行者 客户：到银行办理储蓄业务的人，负责输入密码 银行职员（客户代理）：银行工作人员，代表客户进行储蓄业务的操作 银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户 管理员：银行计算机的管理人员，负责账户的管理和业务报表的生成,识别用况 从系统的需求陈述可知，银行职员（客户代理）需要系统提供开户、存款、取款、转账、注销账户等功能，这些功能都包含了校验密码的功能系统管理员需要系统提供账户管理和报表生成功能银行职员（管理人员）则参与了账户管理中的更新账户的功能此外，转账功能可分为银行内转账和银行间转账，我们可将它们设计成三个用况，其中银行内转账用况和银行间转账用况都继承了基本转账用况据此分析，得到该系统的用况图如下图所示开户用况描述 用况名称：开户 参与的执行者：银行职员（客户代理），客户 前置条件：一个合法的银行职员（客户代理）已登录到该系统 事件流： 1.当选择开户功能时用况开始 2.输入客户信息（姓名、地址、身份证号等） 3.从账户管理系统获取新的账号 4.请客户输入密码 5.请客户再次输入密码 6.如果两次密码不一致则回到第4步，否则继续 7.在账户库中添加新账户 8.打印存折，用况结束 后置条件：在账户库中增加了一个新。