文档介绍：该【UML课程论文 】是由【mama】上传分享，文档一共【5】页，该文档可以免费在线阅读，需要了解更多关于【UML课程论文 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。UML课程论文姓名:XXX班级:软工085学号:**********一、:捕获商业流程-->捕获系统结构或行为描述如何将系统元素整合在一起-->定义软件构架保持设计和实现的一样性适当的隐藏或暴露细微环节-->管理困难性使人员间的沟通更明确-->促进沟通UML为全部开发者供应了一种表示语言可视化的建模帮助开发组形象化,具体说明,构造并且文档化一个系统的体系结构和行为。、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面对对象的分析与设计,还支持从需求分析起先的软件开发的全过程。常用关系依靠(Dependencies;关联(Association一般化(generalization模型,视图,和图表图表是模型的视图表现给投资者看的,具体的描述;针对系统的局部,供应了具体描述;和别的视图保持语义一样;------------------------------捕获系统的动态行为(面对时间的)-----捕获系统的动态行为(面对消息的)-----捕获系统动态行为(面对事务的)-----捕获动态行为(面对活动的)二,UML建模留意事项用UML建模时,对软件开发过程是有要求的,必需是用例驱动,以架构为中心,迭代和递增的开发,假如软件开发组织的软件开发过程不能满足这三点要求,那么UML的运用效果就会大打折扣,下面具体论述:一、用例驱动用例驱动意味着为系统定义的用例是整个开发过程的基础。用例在多个核心工作流程中都发挥了作用。1、用例的概念可用来表示业务流程,我们称这种用例的变体为“业务用例”。2、用例模型是需求工作流程的输出结果。在这一早期流程中,须要通过用例来建立用户希望系统完成的任务的模型。这样,用例构成了一个重要的基本概念,客户和系统开发人员都必需认可这个概念。3、在分析设计中,用例是在设计模型中实现的。您须要生成用例实现来说明在设计模型中如何通过对象的交互来执行用例。此模型依据设计对象来说明所实施系统的各个组成部分,以及这些部分如何通过相互作用来执行用例。4、在实施阶段,设计模型就是实施的规约。由于用例是设计模型的基础,所以用例需通过设计类来实施。5、在测试期间,用例是确定测试用例和测试过程的基础。也就是说,通过执行每一个用例来核实系统。6、在项目管理过程中,用例被用来作为安排迭代式开发的基础。7、在部署工作流程中,它们构成用户手册阐述内容的基础。用例也可用来确定产品构件如何排列组合。例如,客户可通过将用例进行某种组合来配置一个系统。二、以架构为中心构架之所以重要,缘由有以下几点:1、它使您可对项目进行并保持理智的限制,应付项目中困难多变的状况,同时保持系统的完整性。一个困难的系统不仅仅是其各组成部分之和,也不光是一连串没有关联关系的、很小的技巧确定。它必需依靠某种连贯统一的结构来有条理地组织那些部分,并且供应精确的规则,使系统发展过程中,其困难程度不会膨胀,超越人类的理解力。通过建立用于探讨设计问题的一套公共参考材料和一个公共词汇表,构架供应了增进沟通和理解的手段。2、它是大规模复用的有效基础。通过明确阐述它们之间的主要构件和关键接口,构架为您确定重复运用供应依据,包括内部复用(确定公用的部分)和外部复用(并入现成的构件)。它还允许更大规模上的复用:构架本身的复用,用于处理同一领域中的不同功能。3、构架还可作为项目管理的基础。项目安排和人员配备是依据主要构件的类别组织进行的。基本的结构决策是由一个人员组成相对固定的构架小组作出的,他们不是分散的。而开发活动则被安排给若干个小组,每个小组负责开发系统的一个或若干个部分。三、迭代和递增的开发迭代式方法一般要优于线性或瀑布式方法,其缘由很多。1、允许变更需求。需求有时会变更,这经常给项目带来麻烦,它们会导致延期交付、工期延误、客户不满足、开发人员受挫。2、逐步集成元素。在迭代式方法中,集成可以说是连绵不断的。过去在项目结束时要占到整个项目工作量的那段较长的、不确定的且麻烦的时期,现在分散到六至九个集成部分中,每一部分要集成的元素都比过去少得多。3、及早降低风险。因为风险一般只有在集成阶段才能发觉或得到处理。在初期迭代时,检查全部的核心工作流程,对项目运用的工具、市售软件及人员技能等很多方面进行磨合。过去认定的风险可能被证明不再是风险,而又可能出现一批新的未曾怀疑过的风险。4、有助于组织学****和提高。团队成员有机会在整个生命周期中边做边学,各显其能。测试员可以早一些起先测试,技术文档编写员可及早起先编写,其他人也是如此。假如是非迭代式开发,这些人在初期只能制定安排或培训技能,空等着起先他们的工作。培训需求等也可在评估复审中尽早提出。5、提高复用性。因为分部分设计或实施比起预先确定全部共性更简单确定公用部分。确定和开发可重复运用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分,并在以后的迭代中开发和完善这些公用代码。6、生成性能更强壮的产品。因为在多次迭代中您总是不断地订正错误。在产品脱离先启阶段后的初期迭代中仍旧可以发觉缺陷。性能上的瓶颈可以尽早发觉并处理,而不象在交付前夕,此时已来不及处理。7、容许产品进行战术变更。例犹如现有的同类产品竞争。可以确定采纳抢先竞争对手一步的方法,提前发布一个功能简化的产品,或者采纳其他厂商的已有技术。8、迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的状况,而且还要分析组织和流程本身有什么待改进之处,以便在下次迭代中更好地完成任务。通常在软件开发过程中,迭代在数量、持续时间和目标上都是按安排进行的。参加者的任务和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代的确会存在返工现象,但返工也是严格按规定进行的。四、运用不当的问题很多企业员工在运用UML的过程中,只是进行了领域建模,没有进行用例建模,这样是不能最大可能地发挥UML的优势的,因为该组织的软件开发过程不是用例驱动的。假如软件开发组织的软件开发过程不能满足上述三点要求,那么UML的运用效果就会大打折扣。也会产生一些问题,有些组织在运用UML之后,发觉前期花很长时间设计的模型到了项目的中后期和真正的开发成果相去甚远,以至于全都束之高阁了,假如产生这样的问题,就应当细致探讨一下组织的软件开发过程,是否满足上述三点要求,假如软件开发过程不满足迭代的开发,模型没有随着进度改进,这种问题就很简单出现。(模型驱动架构)提出了一些解决开发周期前期和后续的模型不一样问题的方法,就是通过模型的转换来完成模型的自动变更,而不是对各个抽象层次的模型全部进行修改,但MDA为大部分人所接受还须要些时日。五、总结综上所述,UML虽然是软件建模的有利武器,也要遵循肯定的规则来运用,否则就不能很好地发挥它的价值,也会事倍功半。理解UML运用的前提,并细致依据这些方法进行实施,信任会有志向的效果