uml建模实例讲解优质PPT.ppt

上传人:wj 文档编号:8695230 上传时间:2023-05-13 格式:PPT 页数:77 大小:1.55MB
下载 相关 举报
uml建模实例讲解优质PPT.ppt_第1页
第1页 / 共77页
uml建模实例讲解优质PPT.ppt_第2页
第2页 / 共77页
uml建模实例讲解优质PPT.ppt_第3页
第3页 / 共77页
uml建模实例讲解优质PPT.ppt_第4页
第4页 / 共77页
uml建模实例讲解优质PPT.ppt_第5页
第5页 / 共77页
uml建模实例讲解优质PPT.ppt_第6页
第6页 / 共77页
uml建模实例讲解优质PPT.ppt_第7页
第7页 / 共77页
uml建模实例讲解优质PPT.ppt_第8页
第8页 / 共77页
uml建模实例讲解优质PPT.ppt_第9页
第9页 / 共77页
uml建模实例讲解优质PPT.ppt_第10页
第10页 / 共77页
uml建模实例讲解优质PPT.ppt_第11页
第11页 / 共77页
uml建模实例讲解优质PPT.ppt_第12页
第12页 / 共77页
uml建模实例讲解优质PPT.ppt_第13页
第13页 / 共77页
uml建模实例讲解优质PPT.ppt_第14页
第14页 / 共77页
uml建模实例讲解优质PPT.ppt_第15页
第15页 / 共77页
uml建模实例讲解优质PPT.ppt_第16页
第16页 / 共77页
uml建模实例讲解优质PPT.ppt_第17页
第17页 / 共77页
uml建模实例讲解优质PPT.ppt_第18页
第18页 / 共77页
uml建模实例讲解优质PPT.ppt_第19页
第19页 / 共77页
uml建模实例讲解优质PPT.ppt_第20页
第20页 / 共77页
亲,该文档总共77页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

uml建模实例讲解优质PPT.ppt

《uml建模实例讲解优质PPT.ppt》由会员分享,可在线阅读,更多相关《uml建模实例讲解优质PPT.ppt(77页珍藏版)》请在冰点文库上搜索。

uml建模实例讲解优质PPT.ppt

,UCM工程示例,项目的开发目录结构continue,项目目录参照RUP的工件集来组织ClearcaseVOB的划分:

开发目录结构示例,项目产出的主要文档,证券统一通道平台前景文档证券统一通道平台补充规约证券统一通道平台软件构架文档XXXX详细设计文档软件开发计划测试计划系统性能测试报告系统安装与配置手册外围服务协议API应用开发手册,统一的UML模型,OMG的模型驱动架构,OMG主导的MDA(ModelDrivenArchitecture)正在成为下一代软件开发的主流模式基本的模型转换关系:

ComputationIndependentModel(CIM)-PlatformIndependentModel(PIM)-PlatformSpecificModel(PSM)-Implementation,贯穿全局的统一UML模型,使用一个统一的可视化模型来表达项目的分析、设计思想,进而通过标准的语言(UML)来进行成员间的沟通,以减低传递过程中信息丢失和错误理解的风险利用建模工具(Rose)对双向工程(RoundTripEngineering)的支持,初步实现MDA中平台相关的模型到实施代码框架的转换(PSM-Implementation),统一的Rose模型示例,上下文分析模型示例,需求模型示例,层次结构模型示例,详细设计模型示例,用例实现模型示例,实施(构件)模型示例,部署模型示例,前景文档与目标系统边界,用前景文档定义目标系统,根据软件应用的上下文(或业务建模),将要解决的领域问题,涉众(特别是最终用户)对产品的要求,相关的限制条件等,确定目标系统的定义确定系统的范围,用特性来定义系统,并给出相关的优先级顺序功能性特性将映射到系统用例,产品定位,确定目标系统的市场背景列明系统将要解决的重大问题系统的概括定义,涉众/用户及其需要,标识目标系统的最终用户与其他涉众,以确定需求收集的来源分析用户与涉众的基本特点,以帮助获取与辨别系统的需求列明用户与涉众针对目标系统的各类需要(needs),它们决定了最终系统需求,产品概述,明确地定义目标系统勾画目标系统的上下文环境与边界列明目标系统的主要(能力)特性及其提供给客户的利益明示目标系统当前所做的假定和其依赖的条件,它们将可能是未来引起需求变更的重要因素,产品特性,以特性(Feature)的方式定义目标系统的高层需求特性表达了目标系统为了实现用户利益而必须具备的能力(Capability)特性是一种对外的服务,通常要求用户提供一系列输入以得到响应的结果,其它高层需求,设计约束限定了目标系统设计乃至实现方案的选择范围接口需求质量范围概略描绘了目标系统的重要质量需求适用标准、硬件需求及环境需求等,优先级,目标系统的产品特性优先级大致可以分为:

关键、重要和有用特性优先级为项目开发顺序的选择提供了原始依据(当然目标系统各构件间的依赖关系对开发顺序的影响更大)特性优先级是用于实施需求管理的重要内容,用例规约与补充规约,用例详述是对功能性特性的细化系统用例的整体结构适于用UML的UseCase模型表达在UML模型中使用序列图描述所有的系统用例是一种有效的表达方式补充规约是对公共功能性需求和质量等非功能性需求的细化,软件构架文档与4+1视图,软件构架表述,构架描述(构架文档)的用途,表达(软件)系统及其演化用于系统涉众之间的交流以一致的方式来评估与比较软件构架用来计划、管理与执行系统开发的各项活动表达系统的固有特性与支撑原则,以引导可接受的变更验证系统的实现符合构架描述充实软件密集系统的构架知识库(参考构架),4+1视图,软件系统本身包含的内容太丰富且复杂,就像建筑一样,人们无法同时从一个角度看到其全貌,因此需要使用多个视图(View)来表达系统的构架视图是视点(Viewpoint)的实例,并拥有一个或多个模型(Model)4+1视图分别从外部功能,静态结构,动态行为,运行时刻形态和物理部署拓扑等方面来描述目标软件的构架,构架设计目标与约束,构架设计的目标首先要满足目标系统的关键功能需求目标系统的质量需求、接口要求等对构架往往产生决定性的影响项目开发策略,例如第三方构件的选用等是展开构架设计的重要基础变更案例(ChangeCase)要求构架必须具备相应的可扩展性和适应性设计约束等则限定了构架方案选择的范围,用例视图,用例视图从用户使用的角度描述系统构架的基本外部行为特性,通常包含业务用例模型与系统用例模型。

通常应选取用例模型中对系统构架的内容产生重大影响的应用场景与用例集合,这些用例代表了系统主要的核心功能,往往决定了系统构架的基本组成元素。

系统概念模型,描述目标系统的关键构架机制与概念,主要表达系统为了满足主要软件需求,而采用的相关构架模式、以及引用的重要概念标准的RUP构架文档模板中没有这一部分,但是为了方便涉众理解构架,可以增设此节,逻辑视图,逻辑视图从系统内在逻辑结构的角度描述系统的基本结构与动态行为,通常包括分析模型(AnalysisModel)、设计模型(DesignModel)以及数据模型(DataModel)等。

设计模型说明了系统的组成元素、组织架构和关系,并描述了各组成元素的协作以及状态转换关系等(通过用例实现UseCaseRealization予以表达)。

进程视图,进程视图从系统运行时刻的角度,描述系统划分为进程、线程的结构,及其动态关系。

模型主要说明进程、线程的分类,系统构架敏感的主要边界类、控制类对象等在进程、线程中的分布,以及它们之间的创建、交互与消息通讯关系等,部署视图,部署视图从系统软硬件物理配置的角度,描述系统的网络逻辑拓扑结构。

模型包括各个物理节点的硬件与软件配置,网络的逻辑拓扑结构,节点间的交互与通讯关系等。

同时还表达了进程视图中的各个进程具体分配到物理节点的映射关系,实施视图,实施视图从软件编译与构建的角度,描述系统实施构件的组织结构与依赖关系(主要是编译依赖)。

模型包括实施子系统和构件结构,及其依赖关系。

同时还表达了逻辑视图中各个包和类分配到实施视图中的子系统和构件的映射关系,契约式开发与单元测试,契约无所不在,软件系统的本质特征是由表及里、至顶而下的一种层次结构,其构成是所有相对独立的构件或元素而将所有构件或元素组织成为一个有机整体的正是无所不在的契约在最表层,即系统与外部环境之间,是最终用户与系统整体进行交互的契约(通常可以抽象成系统用例);

次之,各子系统/构件之间,是它们相互通讯协作的契约;

最后,类与类、类操作、以及独立函数之间,是它们相互调用的契约,软件系统契约关系,契约的内容,前置条件,指在执行某种操作(例如启动用例的一条执行路径、调用类的一个方法等)之前,目标和其上下文必须共同满足的条件(例如系统处于正常运行状态、用户账号存在并未冻结、对象从其上下文获取的资源处于可用状态等)合法的输入(例如发送给子系统的请求消息格式正确、取值在规定范围内等)期望的输出(例如系统返回给用户需要的查询结果等)后置条件,指无论某种操作的执行过程怎样,结束后,目标和其上下文必须达到的状态或满足的条件(例如类的不变式不被打破、上下文资源被释放、系统不出现不能预料的边际效应等),契约式需求分析(Analysisforcontract),如果以契约的观点来观察系统的外部行为,我们不妨在契约式设计之上再引入契约式需求分析的概念,这样契约式开发显得更为完整用例本质上是表述目标系统与其最终用户之间交互的契约,它使得需求规格的定义变得更加精确和全面,而传统的功能及质量需求规格说明往往容易遗漏前置条件、输入格式等重要细节用例强调实现体现了用户利益的目标,在较低层面定义契约时,同样可以显式地描述诸如一个类操作的目标,契约式设计(Designbycontract),面向对象的分析、设计其首要问题就是类的划分与职责分配类的职责被确定后,通过定义类的不变式,限定对象的有效状态空间;

通过定义类操作的前置、后置条件和输入输出,精确地描述类的行为契约同样有助于精确地表达对象间的协作,因为这些协作步骤将遵从一系列的契约契约式设计可以通过测试驱动开发等最佳实践来驱使贯彻,契约式编程,契约式编程要求客户(client)代码在调用服务(server)代码时也要遵守契约,意味着双方共同承担使运行获得成功的责任,使得代码间职责的分配更为均衡、合理,避免了服务代码中防错式设计的过度蔓延在代码中加入判别契约是否被遵守的语句(例如assert),使得编码中的缺陷(bug)能及时地暴露出来契约式编程结合测试先行、单元测试等最佳实践,是实现高质量构造(construct)的捷径,测试驱动开发,XP推荐测试先行,即先编写测试代码,之后以通过所有测试为目标来驱动实现源码的开发,这通常也称作测试驱动开发先编写测试代码,使得实施员对目标源码的外部行为能先建立明确无误的理解,并有助于尽早发现设计上的缺陷(赶在实现之前,毕竟编写测试代码的开销较小)测试先行的实质,就是先通过测试代码最精确地表达目标代码的契约(即定义其需求),随后每次测试执行都是为了验证源码是否满足了契约,单元测试,单元测试比集成测试能更大限度地覆盖单元的执行路径,是保证软件质量性价比最高的途径单元测试代码提供了目标代码最直接、便利和相对独立的运行上下文,方便代码的调试和除错单元测试在XUnit等测试框架的支持下,最容易实现测试的自动化,这也是回归测试所依赖的重要基础实施回归测试,增强了项目的可视性,能及时提供反馈,极大地加强了开发的可控性,单元测试编写原则,测试任何可能出错的地方,对于明显不太可能出错的方法(譬如set和get这些非常简单的方法),单元测试几乎没有意义注意测试边界条件,比如未初始化、NULL、最大最小值等,防止实现时忘记处理它们为目标代码编写独立的单元测试代码,尽量不要与其它代码产生依赖针对接口进行测试,测试代码示例,CPPUNIT_TEST_SUITE_REGISTRATION(conversation_test);

/单线程测试caller_conversationvoidconversation_test:

singlethread_caller_conversation()typedefservice1single_service;

run_notifycur_notify(conversation_test:

singlethread_caller_conversation);

mock_managertest_manager;

single_servicesvr(,自动化构建与持续集成,集成与构建,软件开发的目标是得到满足需求的可运行的交付工件,即通常是将源码等中间工件编译、链接并集成而生成的一个建造(build)构建集成是一项看似简单实际上充满了陷阱的工作,在团队开发的场景下,将牵涉到将不同成员开发的源码等集成一体,解决各类冲突与依赖等复杂情况,这个过程直接依赖于软件配置管理流程的支持一个合格的集成员需要掌握多项知识和技能,集成与构建的内容,配置项目集成的开发工具(列如msvc6/bcc55等编译器)和自动构建工具(列如ant/cpptasks)配置软件配置管理环境(例如clearcase客户端)制定不同构件间的编译引用、库链接等集成原则确定针对第三方开发包的源码结构组织与构建步骤确定针对项目构件的源码结构组织与构建步骤编制构建脚本制定集成计划执行实施单元测试提交集成冒烟测试流程,构建计划,说明要在此迭代中实施哪些子系统/构件,并说明为及时做好集成准备而实施这些子系统的首选顺序,这一顺序取决于构件间的依赖关系列明增量集成的工作版本(WorkingVersion),每次迭代可能包含多个可测试的集成构造版本,它们决定了每次集成构建周期,Ant构建脚本,Ant配置文件描述了一个构建项目(project),它由一些属性定义(property)和一个目标树(targettree)组成;

目标代表了一个期望的构建结果(例如生成一个链接好的可执行文件),并表述了其依赖的其它目标,常见的构建目标有初始化(Init)、编译(Compile)、单元测试(Test)、安装(Install)、清除(Clean)等;

每个目标包含了实现它而将要执行的任务(task),Ant支持的任务种类非常丰富,例如源码编译、文件拷贝、执行命令行操作等。

Ant执行示例,源码目录组织原则,开发(产品)目录提供了项目团队进行开发、管理等活动的统一共享场所,它需要满足不同涉众(角色),在不同的阶段,对不同类型工件进行访问的多种场景需求因为项目的编码实施、集成等活动相互间的依赖关系远比其它文档编写类活动要复杂,协同整合更为困难,使得合理的源码组织结构变得极为重要构架师和配置管理员必须投入更多精力关注开发(产品)目录中的源码组织部分,源码目录结构示例,第三方开发包的源码结构组织,第三方开发包每个产品有各自不同的目录结构,组织的方式不统一,直接使用将增加引用和依赖关系的复杂性;

产品目录全部展开后有时文件数量非常庞大,如果直接纳入配置管理的话,加入源码控制的开销很大,而当其版本升级时替换原有文件更是非常繁琐且容易出错,但是不控制的话又会造成第三方开发包版本冲突和安装路径不一致的问题项目中对第三方开发包的引用,通常不直接使用其源码,而是链接其编译好的静态库。

第三方开发包构建方案示例,第三方开发包构建脚本示例,Buildfileforalllog4cpluslibraryprojectavailablefile=$unisrc_dswfilepath=$int.msvchome,迭代开发模式,迭代开发模式,软件的不确定和高风险等特性,使得传统的瀑布式开发力不从心迭代有助于尽快发现和解决风险迭代有助于控制项目的节奏,加快反馈,增强项目的控制力度,实现过程的有序化迭代符合人们对事物的认识逐步加深,解决问题的能力随经验逐步提高,人类最根本的技能就是实践、总结和学习的能力等客观事实,迭代计划,确定本次迭代的目标,这包括:

技术与开发、方法与过程、团队与管理三个方面定义迭代产出的工件,例如文档、模型、代码等细化迭代的任务,迭代总结,回顾上次迭代目标的达成情况回顾迭代进度执行结果统计迭代工件产出量,例如文档页数、代码行等简述迭代集成测试的结果总结经验与教训,例如团队建设、内外沟通、项目开发过程、需求、设计等各方面的成功经验和失败教训提出改进建议,其它内容,业务建模系统测试软件配置管理使用优秀的开放源码RationalCase工具的使用开发/工作网络环境配置,Q&

A,谢谢!

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 医药卫生 > 基础医学

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2