uml建模技术与应用（UML怎么用的如何建模哪里可以找到模版参考）

UML的主要特点　　标准建模语言UML的主要特点可以归结为三点：　　（1） UML统一了Booch、OMT和OOSE等方法中的基本概念。　　　（2） UML还吸取了面向对象技术领域中其他流派的长处，其中也包括非OO方法的影响。　　UML符号表示考虑了各种方法的图形表示，删掉了大量易引起混乱的、多余的和极少使用的符号，也添加了一些新符号。因此，在UML中汇入了面向对象领域中很多人的思想。这些思想并不是UML的开发者们发明的，而是开发者们依据最优秀的OO方法和丰富的计算机科学实践经验综合提炼而成的。　　　（3）UML在演变过程中还提出了一些新的概念。　　在UML标准中新加了模板(Stereotypes)、职责(Responsibilities)、扩展机制(Extensibility mechanisms)、线程(Threads)、过程(Processes)、分布式(Distribution)、并发(Concurrency)、模式(Patterns)、合作(Collaborations)、活动图（Activity diagram）等新概念，并清晰地区分类型(Type)、类(Class)和实例(Instance)、细化(Refinement)、接口(Interfaces)和组件(Components)等概念。　　因此可以认为，UML是一种先进实用的标准建模语言，但其中某些概念尚待实践来验证，UML也必然存在一个进化过程。UML相关知识　　UML 2.0 中一共定义了13 种图示（diagrams）。为方便了解，可分类成右侧的结构。　　结构性图形（Structure diagrams） 强调的是系统式的建模：　　类别图 (Class Diagram)　　元件图(Component diagram)　　复合结构图(Composite structure diagram)　　部署图(Deployment diagram)　　物件图(Object diagram)　　包图(Package diagram)　　行为式图形（Behavior diagrams） 强调系统模型中触发的事件：　　活动图(Activity diagram)　　状态机图 (State Machine diagram)　　使用个案图 (Use Case Diagram)　　沟通性图形（Interaction diagrams）, 属于行为图形的子集合，强调系统模型中的资料流程：　　通信图(Communication diagram]]　　交互概述图(Interaction overview diagram) (UML 2.0)　　循序图(Sequence diagram)　　时间图(UML Timing Diagram) (UML 2.0)　　协定状态机是状态机的子变种。它用来塑造网络通讯协定模型。　　UML 并不限定 UML 要素型别非得是某图形上的型别。一般来说，每个 UML 要素大约会出现在图的所有型别。这种弹性在 UML 2.0 部分被限定。　　为了要保持工程图的传统，在您的 UML 图上加注用途、约束、或意图永远无伤大雅。

一：UML（Unified Modeling Language的缩写）统一建模语言,是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。二：用例图、类图、序列图、状态图、活动图。三：UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。

UML建模技术是一种建模语言，指用模型元素来组建整个系统的模型，模型元素包括系统中的类、类和类之间的关联、类的实例相互配合实现系统的动态行为等。

UML提供了多种图形可视化描述模型元素，同一个模型元素可能会出现在多个图中对应多个图形元素，人们可以从多个视图来考察模型。

扩展资料：

UML是面向对象开发中一种通用的图形化建模语言，它定义良好、易于表达、功能强大且普遍适用。

面向对象的分析主要在加强对问题空间和系统任务的理解、改进各方交流、与需求保持一致和支持软件重用等4个方面表现出比其他系统分析方法更好的能力，成为主流的系统分析方法。

UML的出现既统一了Booch、OMT、OOSE，以及其他方法，又统一了面向对象方法中使用的符号，并且在提出后不久就被OMG接纳为其标准之一。

从而改变了数十种面向对象的建模语言相互独立且各有千秋的局面，使得面向对象的分析技术有了空前发展。

它本身成为现代软件工程环境中对象分析和设计的重要工具，被视为面向对象技术的重要成果之一。

参考资料：

百度百科-UML建模技术

用UML建模时，对软件开发过程是有要求的，必须是用例驱动，以架构为中心，迭代和递增的开发，如果软件开发组织的软件开发过程不能满足这三点要求，那么UML的使用效果就会大打折扣，下面详细论述：一、用例驱动用例驱动意味着为系统定义的用例是整个开发过程的基础。用例在多个核心工作流程中都发挥了作用。1、用例的概念可用来表示业务流程，我们称这种用例的变体为“业务用例”。2、用例模型是需求工作流程的输出结果。在这一早期流程中，需要通过用例来建立用户希望系统完成的任务的模型。这样，用例构成了一个重要的基本概念，客户和系统开发人员都必须认可这个概念。3、在分析设计中，用例是在设计模型中实现的。您需要生成用例实现来说明在设计模型中如何通过对象的交互来执行用例。此模型根据设计对象来说明所实施系统的各个组成部分，以及这些部分如何通过相互作用来执行用例。4、在实施阶段，设计模型就是实施的规约。由于用例是设计模型的基础，所以用例需通过设计类来实施。5、在测试期间，用例是确定测试用例和测试过程的基础。也就是说，通过执行每一个用例来核实系统。6、在项目管理过程中，用例被用来作为计划迭代式开发的基础。7、在部署工作流程中，它们构成用户手册阐述内容的基础。用例也可用来确定产品构件如何排列组合。例如，客户可通过将用例进行某种组合来配置一个系统。二、以架构为中心使用UML建模时要以架构为中心，构架之所以重要，原因有以下几点：1、它使您可对项目进行并保持理智的控制，应付项目中复杂多变的情况，同时保持系统的完整性。一个复杂的系统不仅仅是其各组成部分之和，也不光是一连串没有关联关系的、很小的技巧决定。它必须依靠某种连贯统一的结构来有条理地组织那些部分，并且提供准确的规则，使系统发展过程中，其复杂程度不会膨胀，超越人类的理解力。通过建立用于讨论设计问题的一套公共参考材料和一个公共词汇表，构架提供了增进交流和理解的手段。2、它是大规模复用的有效基础。通过明确阐述它们之间的主要构件和关键接口,构架为您决定重复使用提供依据，包括内部复用(确定公用的部分)和外部复用(并入现成的构件)。它还允许更大规模上的复用：构架本身的复用，用于处理同一领域中的不同功能。3、构架还可作为项目管理的基础。项目计划和人员配备是根据主要构件的类别组织进行的。基本的结构决策是由一个人员组成相对固定的构架小组作出的，他们不是分散的。而开发活动则被分配给若干个小组，每个小组负责开发系统的一个或若干个部分。三、迭代和递增的开发使用UML建模时迭代式方法一般要优于线性或瀑布式方法，其原因很多。1、允许变更需求。需求有时会变化，这常常给项目带来麻烦，它们会导致延期交付、工期延误、客户不满意、开发人员受挫。2、逐步集成元素。在迭代式方法中，集成可以说是连续不断的。过去在项目结束时要占到整个项目工作量的那段较长的、不确定的且棘手的时期，现分散到六至九个集成部分中，每一部分要集成的元素都比过去少得多。3、及早降低风险。因为风险一般只有在集成阶段才能发现或得到处理。在初期迭代时，检查所有的核心工作流程，对项目使用的工具、市售软件及人员技能等许多方面进行磨合。过去认定的风险可能被证明不再是风险，而又可能出现一批新的未曾怀疑过的风险。4、有助于组织学习和提高。团队成员有机会在整个生命周期中边做边学，各显其能。测试员可以早一些开始测试，技术文档编写员可及早开始编写，其他人也是如此。如果是非迭代式开发，这些人在初期只能制定计划或培训技能，空等着开始他们的工作。培训需求等也可在评估复审中尽早提出。5、提高复用性。因为分部分设计或实施比起预先确定所有共性更容易确定公用部分。确定和开发可重复使用的部分并非易事。早期迭代中的设计复审可使构架设计师确定毋庸置疑的潜在复用部分，并在以后的迭代中开发和完善这些公用代码。6、生成性能更强壮的产品。因为在多次迭代中您总是不断地纠正错误。在产品脱离先启阶段后的初期迭代中仍然可以发现缺陷。性能上的瓶颈可以尽早发现并处理，而不象在交付前夕，此时已来不及处理。7、容许产品进行战术改变。例如同现有的同类产品竞争。可以决定采用抢先竞争对手一步的方法，提前发布一个功能简化的产品，或者采用其他厂商的已有技术。8、迭代流程自身可在进行过程中得到改进和精炼。一次迭代结束时的评估不仅要从产品和进度的角度来考察项目的情况，而且还要分析组织和流程本身有什么待改进之处，以便在下次迭代中更好地完成任务。通常在软件开发过程中，迭代在数量、持续时间和目标上都是按计划进行的。参与者的任务和职责都已确定好。对进度进行的目标评测都将记录备查。从一次迭代到下一次迭代确实会存在返工现象，但返工也是严格按规定进行的。四、使用不当的问题很多企业员工在使用UML建模的过程中，只是进行了领域建模，没有进行用例建模，这样是不能最大可能地发挥UML的优势的，因为该组织的软件开发过程不是用例驱动的。如果软件开发组织的软件开发过程不能满足上述三点要求，那么UML的使用效果就会大打折扣。也会产生一些问题，有些组织在使用UML之后，发现前期花很长时间设计的模型到了项目的中后期和真正的开发成果相去甚远，以至于全都束之高阁了，如果产生这样的问题，就应该仔细研究一下组织的软件开发过程，是否满足上述三点要求，如果软件开发过程不满足迭代的开发，模型没有随着进度改进，这种问题就很容易出现。UML2.0和MDA(模型驱动架构)提出了一些解决开发周期前期和后续的模型不一致问题的方法，就是通过模型的转换来完成模型的自动变更，而不是对各个抽象层次的模型全部进行修改，但MDA为大部分人所接受还需要些时日。五、总结综上所述，UML建模虽然是软件建模的有利武器，也要遵循一定的规则来使用，否则就不能很好地发挥它的价值，也会事倍功半。理解UML使用的前提，并认真按照这些方法进行实施，相信会有理想的效果。

UML：统一建模语言

作用：用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。

UML并不是一个工业标准，但在Object Management Group的主持和资助下，UML正在逐渐成为工业标准。OMG之前曾经呼吁业界向其提供有关面向对象的理论及实现的方法，以便制作一个严谨的软件建模语言（Software Modeling Language）。

扩展资料

在UML系统开发中有三个主要的模型：

1、功能模型：从用户的角度展示系统的功能，包括用例图。

2、对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图、对象图。

3、动态模型：展现系统的内部行为。包括序列图，活动图，状态图。

建模:分析 + 设计即发现正确的问题,发现正确的解决方案。 注:软件开发的最终目标:“儒”:满足人的需要

建模产生的结果。模型是对现实的简化,是对事物(如实体或变化规律)的抽象,因为会剔除和问题无关,非本质的东西。

我们不能完整地理解一个复杂的系统，所以我们要对它建模,来辅助我们理解。

1 选择要创建什么模型。如类图,用例图等 2 每一个模型可以在不同的精度级别上表示。如类图的操作和方法是否显示 3 最好的模型和现实相关联。原因模型是对现实的简化,对事物的抽象。 4 单个模型是不充分的,对每一个重要的系统最好用一组几乎独立的模型去处理。原因:没有模型都是从一个角度来理解现实或事物,都会有一些片面。

基于算法建模:如分页组件 面向对象建模:软件开发最常用的建模方法

工具包，是软件分析师,设计师工具包,用于创建各种模型。

一个系统可以从不同的角度来观察,一个视图就是一种观察角度。一个视图可以由多种图来描述。

先有用例图,再有其他四种图。

用例视图:从用户的角度来展示系统的功能。 逻辑视图:描述如何实现用例视图所展示的系统功能。 并发视图:考虑高并发的处理。 组件视图:描述组件的信息。 配置视图:系统的物理部署。

站在用户的角度描述系统功能和各功能之间的交互

显示系统的静态结构,表示不同实体间如何关联

类图的一个实例，描述系统在具体时间点上所包含的对象以及各个对象的关系

描述对象的所有状态以及事件发生而引起的状态之间的转移

活动状态代表一个工作流步骤或者一个操作的执行,活动图由多个动作状态组成,一个动作完成后，转为新的动作状态。

多个对象之间的交互,主要侧重于时间先后关系

对个对象之间的交互,主要侧重于交互过程和关联关系

各组件之间的关系

描述硬件的关系