uml建模实例讲解.ppt

RUP过程与UML模型驱动开发方法在证券研发项目中的应用实践,新思维金融软件研发中心,软件构架师 胡协刚,内容提要,软件开发没有银弹统一通道平台开发项目简介项目的开发目录结构与RUP核心工件贯穿全局的统一UML模型用前景文档定义目标系统软件构架文档与4+1视图契约式开发与单元测试自动化构建与持续集成迭代开发模式,软件开发没有银弹,软件项目复杂、不确定和高风险,软件因其固有的复杂、不确定和高风险等属性，使得其开发活动非常难以控制软件产品用于解决一个或多个领域的现实问题，不仅与其开发者本身直接相关，还牵涉到客户、最终用户、第三方伙伴等众多涉众，所谓众口难调，但一个成功的软件必须能满足多方面的需求软件所依赖的核心技术、项目的开发方法、软件过程、项目管理和团队协作等，都是事关项目成败的关键因素,CMMI与RUP,根据CMMI的定义，软件过程要达到第三成熟度等级，需要实施十八个关键过程域；普通团队虽然不一定向此标准看齐，但实际上仍然涉及到这十八个关键过程域所涵盖的近百项活动，只不过可能实施的力度较小、质量不高、或者忽略了活动本身的含义而已RUP与CMMI第三成熟度等级相对应，定义了九个核心准则（Discipline），和几百项活动这还仅仅只是软件过程的范畴，项目中人的管理、沟通以及具体的关键技术等等，其牵涉面将更广,软件开发没有银弹,诸多因素分属不同的范畴，针对不同的问题，需要应用不同的技术、技能和方法，要求项目成员拥有不同的知识、素质与背景没有一种方法或途径能够解决软件项目中所有的问题，即所谓“没有银弹”，所以不要迷信存在所谓的一劳永逸的终极解决方案,成功意味着多方面的艰苦努力,软件项目适用于“木桶原理”，要获得成功，必须由所有成员在多个方面都付出艰苦的努力，包括完成一些繁琐与枯燥的工作，并保证任何一个环节都不出重大问题在下面介绍的一个实际项目中，将会看到我们是如何通过裁减RUP过程来主导项目的开发活动，使用统一的UML模型来表达和沟通设计，利用共享的产品目录结构来协同开发，并通过加强团队建设，扬长避短，发挥各成员的长处等总之从多个方面来努力，方才最终达成项目成功的过程,实例项目简介,证券统一通道平台项目,项目的目标系统（统一通道平台）是在证券公司总部和所有营业部网点统一部署的、适应不同网络拓扑结构的、支持内外网段物理安全隔离的、基于消息的通讯中间件平台系统，用以支持热自助、电话委托等各类外围客户端系统，集中经纪业务系统、传统营业部柜台系统等核心服务系统，以及银行端银证业务系统等第三方系统的透明接入,UCS 辐射型拓扑部署结构,项目开发过程概貌,项目采用RUP的迭代开发生命周期模型，总计经历了六次迭代，持续约八个月，项目组成员36人，耗费共计685个工作人日，最终有效代码30,471 行，千行代码集成缺陷率低于1 使用Clearcase UCM实施配置管理，并基于此组织项目的产品目录结构，囊括了RUP定义的主要核心工件使用Rose开发了统一的UML模型，从上下文分析、功能用例模型、到设计模型、进程模型、部署模型等，涵盖了项目大部分分析、设计成果，利用了Rose的正向工程生成大部分代码框架目标系统的分析、设计、编码完全实现面向对象,项目开发过程概貌continue,项目以软件构架文档为中心，配合Rose模型、详细设计文档，使得产品的设计比较到位项目引入了契约式编程方法，编码语言为标准c+，使用CppUnit测试框架进行较为广泛的单元测试，对产品的质量改进帮助很大使用Ant+Cpptasks工具初步实现了自动化构建与集成项目本身系公司的过程改进试点项目，集中了部门最优秀的人员，大家都表现了良好的团队协作精神，建立了密切的私人关系作为试点项目，其成果，已经作为模板工程在公司大力推广,项目的开发目录结构,开发（产品）目录结构,开发（产品）目录结构的规划原则：满足不同角色，在不同的项目阶段，对不同类型工件进行访问的多种场景需求ClearCase Stream（流）的划分：,UCM工程示例,项目的开发目录结构continue,项目目录参照RUP的工件集来组织Clearcase VOB的划分：,开发目录结构示例,项目产出的主要文档,证券统一通道平台前景文档证券统一通道平台补充规约证券统一通道平台软件构架文档XXXX详细设计文档软件开发计划测试计划系统性能测试报告系统安装与配置手册外围服务协议API应用开发手册,统一的UML模型,OMG的模型驱动架构,OMG主导的MDA（Model Driven Architecture）正在成为下一代软件开发的主流模式基本的模型转换关系：Computation Independent Model(CIM)-Platform Independent Model(PIM)-Platform Specific Model(PSM)-Implementation,贯穿全局的统一UML模型,使用一个统一的可视化模型来表达项目的分析、设计思想，进而通过标准的语言（UML）来进行成员间的沟通，以减低传递过程中信息丢失和错误理解的风险利用建模工具（Rose）对双向工程（Round Trip Engineering）的支持，初步实现MDA中平台相关的模型到实施代码框架的转换（PSM-Implementation）,统一的Rose模型示例,上下文分析模型示例,需求模型示例,层次结构模型示例,详细设计模型示例,用例实现模型示例,实施（构件）模型示例,部署模型示例,前景文档与目标系统边界,用前景文档定义目标系统,根据软件应用的上下文（或业务建模），将要解决的领域问题，涉众（特别是最终用户）对产品的要求，相关的限制条件等，确定目标系统的定义确定系统的范围，用特性来定义系统，并给出相关的优先级顺序功能性特性将映射到系统用例,产品定位,确定目标系统的市场背景列明系统将要解决的重大问题系统的概括定义,涉众/用户及其需要,标识目标系统的最终用户与其他涉众，以确定需求收集的来源分析用户与涉众的基本特点，以帮助获取与辨别系统的需求列明用户与涉众针对目标系统的各类需要（needs），它们决定了最终系统需求,产品概述,明确地定义目标系统勾画目标系统的上下文环境与边界列明目标系统的主要（能力）特性及其提供给客户的利益明示目标系统当前所做的假定和其依赖的条件，它们将可能是未来引起需求变更的重要因素,产品特性,以特性（Feature）的方式定义目标系统的高层需求特性表达了目标系统为了实现用户利益而必须具备的能力（Capability）特性是一种对外的服务，通常要求用户提供一系列输入以得到响应的结果,其它高层需求,设计约束限定了目标系统设计乃至实现方案的选择范围接口需求质量范围概略描绘了目标系统的重要质量需求适用标准、硬件需求及环境需求等,优先级,目标系统的产品特性优先级大致可以分为：关键、重要和有用特性优先级为项目开发顺序的选择提供了原始依据（当然目标系统各构件间的依赖关系对开发顺序的影响更大）特性优先级是用于实施需求管理的重要内容,用例规约与补充规约,用例详述是对功能性特性的细化系统用例的整体结构适于用UML的Use Case模型表达在UML模型中使用序列图描述所有的系统用例是一种有效的表达方式补充规约是对公共功能性需求和质量等非功能性需求的细化,软件构架文档与4+1视图,软件构架表述,构架描述（构架文档）的用途,表达（软件）系统及其演化用于系统涉众之间的交流以一致的方式来评估与比较软件构架 用来计划、管理与执行系统开发的各项活动 表达系统的固有特性与支撑原则，以引导可接受的变更 验证系统的实现符合构架描述充实软件密集系统的构架知识库（参考构架）,4+1视图,软件系统本身包含的内容太丰富且复杂，就像建筑一样，人们无法同时从一个角度看到其全貌，因此需要使用多个视图（View）来表达系统的构架 视图是视点（Viewpoint）的实例，并拥有一个或多个模型（Model）4+1视图分别从外部功能，静态结构，动态行为，运行时刻形态和物理部署拓扑等方面来描述目标软件的构架,构架设计目标与约束,构架设计的目标首先要满足目标系统的关键功能需求 目标系统的质量需求、接口要求等对构架往往产生决定性的影响项目开发策略，例如第三方构件的选用等是展开构架设计的重要基础变更案例（Change Case）要求构架必须具备相应的可扩展性和适应性设计约束等则限定了构架方案选择的范围,用例视图,用例视图从用户使用的角度描述系统构架的基本外部行为特性，通常包含业务用例模型与系统用例模型。通常应选取用例模型中对系统构架的内容产生重大影响的应用场景与用例集合，这些用例代表了系统主要的核心功能，往往决定了系统构架的基本组成元素。,系统概念模型,描述目标系统的关键构架机制与概念，主要表达系统为了满足主要软件需求，而采用的相关构架模式、以及引用的重要概念标准的RUP构架文档模板中没有这一部分，但是为了方便涉众理解构架，可以增设此节,逻辑视图,逻辑视图从系统内在逻辑结构的角度描述系统的基本结构与动态行为，通常包括分析模型（Analysis Model）、设计模型（Design Model）以及数据模型（Data Model）等。设计模型说明了系统的组成元素、组织架构和关系，并描述了各组成元素的协作以及状态转换关系等（通过用例实现Use Case Realization予以表达）。,进程视图,进程视图从系统运行时刻的角度，描述系统划分为进程、线程的结构，及其动态关系。模型主要说明进程、线程的分类，系统构架敏感的主要边界类、控制类对象等在进程、线程中的分布，以及它们之间的创建、交互与消息通讯关系等,部署视图,部署视图从系统软硬件物理配置的角度，描述系统的网络逻辑拓扑结构。模型包括各个物理节点的硬件与软件配置，网络的逻辑拓扑结构，节点间的交互与通讯关系等。同时还表达了进程视图中的各个进程具体分配到物理节点的映射关系,实施视图,实施视图从软件编译与构建的角度，描述系统实施构件的组织结构与依赖关系（主要是编译依赖）。模型包括实施子系统和构件结构，及其依赖关系。同时还表达了逻辑视图中各个包和类分配到实施视图中的子系统和构件的映射关系,契约式开发与单元测试,契约无所不在,软件系统的本质特征是由表及里、至顶而下的一种层次结构，其构成是所有相对独立的构件或元素而将所有构件或元素组织成为一个有机整体的正是无所不在的契约在最表层，即系统与外部环境之间，是最终用户与系统整体进行交互的契约（通常可以抽象成系统用例）；次之，各子系统/构件之间，是它们相互通讯协作的契约；最后，类与类、类操作、以及独立函数之间，是它们相互调用的契约,软件系统契约关系,契约的内容,前置条件，指在执行某种操作（例如启动用例的一条执行路径、调用类的一个方法等）之前，目标和其上下文必须共同满足的条件（例如系统处于正常运行状态、用户账号存在并未冻结、对象从其上下文获取的资源处于可用状态等）合法的输入（例如发送给子系统的请求消息格式正确、取值在规定范围内等）期望的输出（例如系统返回给用户需要的查询结果等）后置条件，指无论某种操作的执行过程怎样，结束后，目标和其上下文必须达到的状态或满足的条件（例如类的不变式不被打破、上下文资源被释放、系统不出现不能预料的边际效应等）,契约式需求分析（Analysis for contract）,如果以契约的观点来观察系统的外部行为，我们不妨在契约式设计之上再引入契约式需求分析的概念，这样契约式开发显得更为完整用例本质上是表述目标系统与其最终用户之间交互的契约，它使得需求规格的定义变得更加精确和全面，而传统的功能及质量需求规格说明往往容易遗漏前置条件、输入格式等重要细节用例强调实现体现了用户利益的目标，在较低层面定义契约时，同样可以显式地描述诸如一个类操作的目标,契约式设计（Design by contract）,面向对象的分析、设计其首要问题就是类的划分与职责分配类的职责被确定后，通过定义类的不变式，限定对象的有效状态空间；通过定义类操作的前置、后置条件和输入输出，精确地描述类的行为契约同样有助于精确地表达对象间的协作，因为这些协作步骤将遵从一系列的契约契约式设计可以通过测试驱动开发等最佳实践来驱使贯彻,契约式编程,契约式编程要求客户（client）代码在调用服务（server）代码时也要遵守契约，意味着双方共同承担使运行获得成功的责任，使得代码间职责的分配更为均衡、合理，避免了服务代码中防错式设计的过度蔓延在代码中加入判别契约是否被遵守的语句（例如assert），使得编码中的缺陷（bug）能及时地暴露出来契约式编程结合测试先行、单元测试等最佳实践，是实现高质量构造（construct）的捷径,测试驱动开发,XP推荐测试先行，即先编写测试代码，之后以通过所有测试为目标来驱动实现源码的开发，这通常也称作测试驱动开发先编写测试代码，使得实施员对目标源码的外部行为能先建立明确无误的理解，并有助于尽早发现设计上的缺陷（赶在实现之前，毕竟编写测试代码的开销较小）测试先行的实质，就是先通过测试代码最精确地表达目标代码的契约（即定义其需求），随后每次测试执行都是为了验证源码是否满足了契约,单元测试,单元测试比集成测试能更大限度地覆盖单元的执行路径，是保证软件质量性价比最高的途径单元测试代码提供了目标代码最直接、便利和相对独立的运行上下文，方便代码的调试和除错单元测试在XUnit等测试框架的支持下，最容易实现测试的自动化，这也是回归测试所依赖的重要基础实施回归测试，增强了项目的可视性，能及时提供反馈，极大地加强了开发的可控性,单元测试编写原则,测试任何可能出错的地方，对于明显不太可能出错的方法（譬如set 和get这些非常简单的方法），单元测试几乎没有意义注意测试边界条件，比如未初始化、NULL、最大最小值等，防止实现时忘记处理它们为目标代码编写独立的单元测试代码，尽量不要与其它代码产生依赖针对接口进行测试,测试代码示例,CPPUNIT_TEST_SUITE_REGISTRATION(conversation_test);/单线程测试caller_conversationvoid conversation_test:singlethread_caller_conversation()typedef service1 single_service;run_notify cur_notify(conversation_test:singlethread_caller_conversation);mock_manager test_manager;single_service svr(,自动化构建与持续集成,集成与构建,软件开发的目标是得到满足需求的可运行的交付工件，即通常是将源码等中间工件编译、链接并集成而生成的一个建造（build）构建集成是一项看似简单实际上充满了陷阱的工作，在团队开发的场景下，将牵涉到将不同成员开发的源码等集成一体，解决各类冲突与依赖等复杂情况，这个过程直接依赖于软件配置管理流程的支持一个合格的集成员需要掌握多项知识和技能,集成与构建的内容,配置项目集成的开发工具（列如msvc6/bcc55等编译器）和自动构建工具（列如ant/cpptasks）配置软件配置管理环境（例如clearcase客户端）制定不同构件间的编译引用、库链接等集成原则确定针对第三方开发包的源码结构组织与构建步骤确定针对项目构件的源码结构组织与构建步骤编制构建脚本制定集成计划执行实施单元测试提交集成冒烟测试流程,构建计划,说明要在此迭代中实施哪些子系统/构件，并说明为及时做好集成准备而实施这些子系统的首选顺序，这一顺序取决于构件间的依赖关系 列明增量集成的工作版本（Working Version），每次迭代可能包含多个可测试的集成构造版本，它们决定了每次集成构建周期,Ant构建脚本,Ant配置文件描述了一个构建项目（project），它由一些属性定义（property）和一个目标树（target tree）组成；目标代表了一个期望的构建结果（例如生成一个链接好的可执行文件），并表述了其依赖的其它目标，常见的构建目标有初始化（Init）、编译（Compile）、单元测试（Test）、安装（Install）、清除（Clean）等；每个目标包含了实现它而将要执行的任务（task），Ant支持的任务种类非常丰富，例如源码编译、文件拷贝、执行命令行操作等。,Ant执行示例,源码目录组织原则,开发（产品）目录提供了项目团队进行开发、管理等活动的统一共享场所，它需要满足不同涉众（角色），在不同的阶段，对不同类型工件进行访问的多种场景需求因为项目的编码实施、集成等活动相互间的依赖关系远比其它文档编写类活动要复杂，协同整合更为困难，使得合理的源码组织结构变得极为重要构架师和配置管理员必须投入更多精力关注开发（产品）目录中的源码组织部分,源码目录结构示例,第三方开发包的源码结构组织,第三方开发包每个产品有各自不同的目录结构，组织的方式不统一，直接使用将增加引用和依赖关系的复杂性；产品目录全部展开后有时文件数量非常庞大，如果直接纳入配置管理的话，加入源码控制的开销很大，而当其版本升级时替换原有文件更是非常繁琐且容易出错，但是不控制的话又会造成第三方开发包版本冲突和安装路径不一致的问题项目中对第三方开发包的引用，通常不直接使用其源码，而是链接其编译好的静态库。,第三方开发包构建方案示例,第三方开发包构建脚本示例,Build file for all log4cplus library projectavailable file=$unisrc_dsw filepath=$int.msvchome,迭代开发模式,迭代开发模式,软件的不确定和高风险等特性，使得传统的瀑布式开发力不从心迭代有助于尽快发现和解决风险迭代有助于控制项目的节奏，加快反馈，增强项目的控制力度，实现过程的有序化迭代符合人们对事物的认识逐步加深，解决问题的能力随经验逐步提高，人类最根本的技能就是实践、总结和学习的能力等客观事实,迭代计划,确定本次迭代的目标，这包括：技术与开发、方法与过程、团队与管理三个方面定义迭代产出的工件，例如文档、模型、代码等细化迭代的任务,迭代总结,回顾上次迭代目标的达成情况回顾迭代进度执行结果统计迭代工件产出量，例如文档页数、代码行等简述迭代集成测试的结果总结经验与教训，例如团队建设、内外沟通、项目开发过程、需求、设计等各方面的成功经验和失败教训提出改进建议,其它内容,业务建模系统测试软件配置管理使用优秀的开放源码Rational Case工具的使用开发/工作网络环境配置,Q&A,谢谢！,