UML和程序开发之间有什么的关系_uml中的关系有哪几种

UML是一种用于软件开发过程中进行分析设计的统一建模语言，它可以涵盖整个软件开发过程，可以进行需求分析，系统分析，设计，测试，部署等过程！利用UML标准进行建模的实现需要通过专业的UML建模工具进行，比如trufunplatoUML2建模工具！

一 uml简介 uml（统一建模语言，unified modeling language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用uml来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，uml的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二 用例建模简介

用例建模是uml建模的一部分，在我眼里，它也是uml里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。

依我的理解用例建模可分为用例图和用例描述。用例图由参与者（actor）、用例（use case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。

1 用例图

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时 间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是uml对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

2 用例描述

用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。

对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：

简要描述：对用例的角色、目的的简要描述；

前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；

基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；

其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；

异常事件流：表示发生了某些非正常的事情所要执行的流程；

后置条件：用例一旦执行后系统所处的状态；

三 用例图和用例描述设计实例

这里用我开发的一个家教网站来简单的分析用例图的画法和用例描述的写法。这个网站我用uml完整的分析一下，以下我提取了用例图和用例描述的部分。这个家教网站分为前台客户系统和后台管理系统。

前台客户系统的用例图如下：

后台管理系统用例图如下：

对于用例描述，篇幅有限，我在这里只列了后台管理系统中的网站公告发布这个用例的描述。如下：

四 总结

其实用例建模并不是这么简单，它涉及到的知识还有很多，我这里只是简单的介绍一下，希望对初学uml建模的同学有所帮助。

一 uml简介 uml（统一建模语言，unified modeling language）是一种定义良好、易于表达、功能强大且普遍适用的可视化建模语言。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。在系统分析阶段，我们一般用uml来画很多图，主要包括用例图、状态图、类图、活动图、序列图、协作图、构建图、配置图等等，要画哪些图要根据具体情况而定。其实简单的理解，也是个人的理解，uml的作用就是用很多图从静态和动态方面来全面描述我们将要开发的系统。

二 用例建模简介

用例建模是uml建模的一部分，在我眼里，它也是uml里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。

依我的理解用例建模可分为用例图和用例描述。用例图由参与者（actor）、用例（use case）、系统边界、箭头组成，用画图的方法来完成。用例描述用来详细描述用例图中每个用例，用文本文档来完成。

1 用例图

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时 间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是uml对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

本文会包含几块内容：

流程图= 流程+图。

流程：Flow, 是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列 *** 作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。

图：Chart 或者 Diagram , 是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。

从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。

● 参与者 ：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。

● 活动 ：做了什么事，比如点餐，结帐等活动。

● 次序 ：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。

● 输入 ：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。

● 输出 ：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？

● 标准化 ：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。

常见的流程图有业务流程图（Transaction Flow）, 页面流程图（Page Flow）。

在工作中，作为UED，你可能会发现PD经常谈的是业务流程，而作为交互设计师，我们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？ 先有谁，其次再有谁呢？

先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在杭州开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，**院旁…………等等等等，那么接下来呢？

接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。

这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。

那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。

人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……

所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行 *** 作。

这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？

通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：

●先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）

●然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）

●然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）

●然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）

●业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）

●为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）

●不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）

当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。

我们平时工作中，还会经常听人谈到泳道图啊，任务流程图啊等等概念，究竟是神马关系呢？

在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。

泳道图有几个关键点：两大维度，活动流转，流程要素。

另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。

流程图可以提供一种简单扼要的“缩略俯瞰图”，帮助观众快速了解业务如何运转。它包含了几个关键词： 谁，什么时候，在什么条件下，做了什么事情，输入什么，输出什么，输出给谁……

与系统流程不同，业务流程更关注于业务本身如何运作，讲的是业务故事，包含的是业务规则。而系统流程则是满足业务流程，实现部分流程或全部流程的信息化和系统化。

所以业务流程是所有环节的前置条件——软件需求分析，信息系统建设也会先进行业务流程的梳理。

下面表现了业务流程图是如何在三个主要场景中发挥作用的：

1、培训

在此场景中：流程图能够提供一种快速了解业务如何运作的视图，通过业务流程图，新员工能够快速明白业务的最终目标是什么，中有哪些角色在参与以及他们的职责，以及彼此之间的联接。

除了培训新员工，在员工轮岗、调职场景中，员工也需要业务流程图参考，明白新的工作内容如何开展，以及自己所处的位置，自己的上游是谁，下游是谁，自己需要交付的工作内容是什么。

2、流程优化与重组

业务流程重组（Business Process Reengineering）的存在可以明确反驳：存在即合理。事实上，存在的业务流程并未是合理的，有可能是参与的多个角色习惯了某种做法，有可能是变革尚未影响到末端的 *** 作，也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革，不是某个部门的事情，而是需要流程中各个部门的通力配合。

更多时候，业务流程优化是自上而下的，但是老板们未必对实际运作的业务流程那么心知肚明，业务流程图能够很好去表现这个“运作模型”。通过看业务流程图，找关键节点的人访问，能够直接切入：为什么要这么做，为什么不这么做？从而探索出更深层次的问题，而不是问：你们现在怎么做？

通过调研，分析业务流程图，引入更多角色，能够分析出目前业务流程的问题：缺失，重复，风险，效率等等。从而制定相应的优化方案。

3、信息化的基础

正如上文所述的餐馆梦想的案例，信息系统的一项任务就是解放员工的手脚，取代一些重复的人力劳动工作。系统上了之后，不是说业务流程不需要而是经过了一些调整，其中某个参与者变成了系统，或手持设备，或打印机而已。

那么在做系统的功能设计和系统流程设计时，是不是必须先要了解目前业务是如何运作的呢？从而更好分析分析，更好说明系统在什么环节取代了什么类型的人肉工作？

所以我们看到的PRD往往也会先以业务流程图开始说明，而叙述一个系统建设的好处时，也可以用以前的业务流程与系统上了之后的业务流程进行对比。根据分析，将愿景中的新的业务流程图背后需要系统的功能点撰写清楚。

首先绘制业务流程图本身有没有流程？一定是有的。在软件工程学里听说一句话叫：万物皆对象。那么在流程学里，万事皆流程。吃饭难道没流程吗？就吃饭的动作而言，就有流程：拿筷子——夹菜——入口——咀嚼——吞咽。

那么，绘制业务流程图有没有可遵循的流程呢？我建议可以从下面4步着手。

1、调研

如何快速了解业务运作真相？有没有调研的技巧放送？

2、梳理与呈现

能否快速将调研得到的文字和问题，快速转化为业务流程图？

业务流程图的标准图示是什么？

怎么评价一个业务流程图的好与坏？

3、评审与确认——能否真正让业务流程图反映现实中的业务？

4、归档维护——流程不断变更，业务流程图如何快速响应？

在绘制业务流程图前，思考如何精美、如何交互以及使用什么工具，都不应该是重点。

真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题，否则不要开始绘制流程图：

除了在本部分开始的那几个问题要顾及到， 其实调研过程解决的仍然是who，what，why，how，以及where的问题：谁，在什么情况下，做了什么事情，这个事情需要什么前置条件，又输出了什么，这个事情在哪里完成的？ 搞明白这几个问题，我们的调研就可以圆满完成了。

流程图的表现，要回答这几个问题：

1、Who——谁？部门，角色，岗位

2、What——什么事情？

3、Where——在哪里做的？在我梳理的业务流程图上，where更多表示是文档还是各种系统，用来表示信息化的程度。比如当我们梳理中发现，有一项登记，是用excel而不是业务系统来进行的，那么在这里的where就可以表示为：excel文档。

4、Document——那产生的这份文档叫什么名字？也写出来，代表有文件的传递，而以后要进行信息化的话，此份人肉文档也是需要被消除而被系统取代的。（相反，如果这项工作是在某个系统里 *** 作的，where就可以写成“人事系统”，文档可以继续存在，即该系统中的表单名称：“员工登记表单”）

5、Condition——条件。在这种条件下，下一个活动还能够继续，即用逻辑链接线的方式来表示一项活动的输入和输出，指向某个活动的箭头就表示此活动的前置输入条件。

6、Dicision——决策。有些活动会产生一个条件判断，根据不同的判断结果从而走不同的分支流程。比如输入员工信息的时候，可以根据员工之前是否就职过，选择不同的流程，对于已经就职过的，选用之前的工号而不用生成新的工号。

举个案例（如果不太恰当，请意会）。假设你受命要调研两家餐饮店的业务流程，目的是给他们提供性价比最高的点餐系统。

在调研中：

你首先可以要求精通业务流程的人给你系统讲解一遍。

调研具体 *** 作的人，来验证他给你讲解的是否全面和偏差。

实地观察和记录（花点时间走遍业务流程）

三种方式相互结合使用。第一种方法可以让你首先建立一个系统观，了解大体枝干，但是很难切入到可能会出现问题的细节。第二种方法太依赖于问题的质量以及问问题的场景。有很多结论的不正确其实是因为问错了人或者问问题的方法不对。那么就需要借助第三种，在观察中再进行验证。

在这些问题中，就涉及到了“分单”，“切菜”，“择菜”，”烹饪”，“传菜”，“上菜”几个活动，也涉及到了“服务员”，“厨师”，“助理”，“刀工”，“传菜员”几个角色。几个活动的次序也比较清楚了。

下面的问题，可能厨师就不了解了，要问点菜员了。

你的调研和观察使你拥有了“烹饪”所需的原材料。

接下来的任务是不是很简单，对，就像填空题一样简单。将活动/事件按照一定的规则填到由部门和时间两条维度决定的框框里。

这个阶段是paper work，你需要将调研阶段收集到的原材料用更直观明了的方式呈现出来。从而能够更好进行评审和确认。也为以后的流程评审和优化做准备。

不可能将所有的活动都放到一张图里呈现。

“业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。这样一个层次关系符合人们的思维习惯，有利于企业业务模型的建立 企业部门之间的层次关系表。一般来说，我们可以先建立主要业务流程的总体运行过程（其中包括了整个企业的大的战略），然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。”

——引自《百度百科》 业务流程词条

对于很多新人来讲， 业务最难的在于划分业务流程图的层次上。

首先，明确你要梳理的业务流程的范围 ——用大的粗略的关键节点，讲清楚这个业务流程范围中的故事，就是顶层业务流程图。你的顶层业务流程图是业务全局故事的简单表达，但是请注意这里的业务全局不见得是公司整体的业务全局，而是你界定好的业务范围。比如，下图是餐厅的日常运作流程图，若你界定的业务范围是面向顾客的点餐和结帐流程，那么这就是顶层业务流程图。但是若你界定的是整个餐厅的运作业务流程，那这显然还是一个子集——并没有包含餐厅的采购、供应商管理、一级库存管理等工作。

其次，先从顶层的业务流程分解开始，由粗至细。 顶层业务流程图的梳理原则：

1、界定范围内的业务全局故事。

2、包含该范围内的关键节点。并且，当被质疑说某某环节怎么不存在时，自己要清楚它在下一层分解中应该被包含在那个关键节点中。比如，赠送10周年优惠券，应该会在结帐节点分解中出现。而打印分单，会在点菜节点中分解。而准备儿童座椅应该是接待入座环节。

3、顶层流程图分解出来的关键节点未必都会细化分解下去，生成二级以及三级的流程图。这要看该节点涉及到的“活动”以及“角色”是否复杂。

再看一个案例，对传统生产型企业的进销存主业务流程进行分解。橙色的代表被分解点，已经可以分解为四层。当我们分解到第四层，发现再往下去涉及到的活动和角色都已经很少时，就不必再分解了，而是可以将第四层的关键节点直接作为第三层业务流程的“活动”，而不是子流程图。

当然，这是依赖于你梳理业务流程的目标。如果你偏偏是要对“打样”环节进行剖析优化，则还可以继续分解下去。

这一步的工作会帮你建立出清晰的流程目录结构，如下图所示是摘选于刚完成的一个流程梳理的项目中的目录结构部分。可以看到全图即是顶层关键节点，作为老大，可能只要看这一层就够了。下面则会对顶层做更多细化拆解。

“H3样品认证”在顶层业务流程图中，仅仅是一个“活动”，而在自己细化的这一个层次中，则会包含详细的子活动一级参与者。

我常用的就是前两行的“活动”，“判断”，“逻辑关系线”，“起始与终止”，以及第二行的“子流程”，和“文件/表单”。如果你不是符号控，我建议这几个就足够了。

其中，“子流程”此图示就是可以帮助你将流程分解得到的子流程能够串联起来，比如，当在”A流程”中涉及到进一步需要分解的”A11流程”时，就可以在”A流程”中用子流程符号代表“A11”。然后你的读者就会明白要想进一步了解”A11″应该参考另外一个流程图。

流程图的常用结构：

给大家看一些案例：

基本上包含大多数图示的流程图：

只用到少数几个图示画的简单流程图（台湾人的文档中称为程序图——不过这里的程序不是指计算机程序，而是process，仅仅是体现任务之间的处理流程，所以使用极简单的符号也不为怪了）：

以上两个流程图案例，从符号的复杂程度上来讲，一个是完整流程图，一个是基本流程图，但是从表现形式来讲，都属于“泳道图”——Swimlane。这也是我们最常用的一种表现形式了。泳道图能够很好体现部门或者角色在流程中的职责以及上下游的协作关系。且流程图本身的标准容易掌握，达成共识也就更加容易。

验证你是否做到了以上的DO，以及规避了Donnot的做法是什么？

很好办，及时与各位进行评审。将各个涉众都叫到一起，给他们看你梳理出来的成果。

这会发现一些有意思的事情，除了评审你的流程图是否符合现实外，也会评审目前的业务流程是否符合理想。不同的部门和岗位的代表会在这个评审中，确认当前，也会相互提出意见，甚至吵起来，这不失于做流程优化的一个很好的契机。暂且不表了。

UML的基本概念

Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。下面我为大家整理了关于UML基本概念的文章，希望能为你提供帮助：

第一：作为Object的表现形式的模型技术

进入UML技术的说明之前，我们首先来谈谈Object指向技术。Object指向是软件开发的一种先进技术，正如[Object]名字所暗示的，该技术的所有考虑出发点都是Object

使用Object可以提高大型软件项目的开发效率和速度。

所谓的Object指向，就是说要把复杂的问题细化分解，用图表的方式表达出来。比如下图

如上图所示，一个好的模型能够正确的合理的表达复杂的意思。上图中复杂的路径信息经过简化之后就会变成清晰可见的模型图。

但是，模型图的画法是各种各样的，如何才能准确的统一的画出来呢请看下节：

第二：作为统一表达模型的UML技术

如上所示，用图形来表达复杂的逻辑和需求是个很好的选择和做法。

但是每个人的思路都不一样，每个人画出来的图也都不一样，怎么样才能让大家都能听得懂对方的思路呢。

在这个时候，UML登场了。UML是1997年由OMG组织推出来的，全球统一的模型图形技术。

第三：UML技术可以提高分析和设计的精度

在没有UML技术的'时候，大家都知道随口乱说。

需求分析的时候，客户随口说说需求。

系统设计的时候，架构师随口说说设计。

程序开发的时候，开发者随口编写程序。

一切都是无序和混乱的，但是，有了UML就不会再出现这种问题了。

所有的交流和文档都能够有一种大家都能听得懂的好方法传递，这就是UML。

第四：UML的内容

如下所示，我们可以这样使用UML技术

并且在很多自动开发工具之中，可以根据以上图形自动生成代码。

第五：UML是必须的知识

对于现代软件开发和管理而言，UML是必需的知识，无论是外包还是内包，UML都是不可或缺的技术。

;

用例图当然很好用，不然RUP（Rational Unified Process，统一软件开发过程，统一软件过程)也不会让用例驱动作为核心方法论之一，当然用例图自身也有很多不足，需要其它技术作补充。一、优点：简洁、直观。是的，确实比较直观，几个小人人、几个椭圆，外加几条不多的线，用一个矩形一框就出来了，了不起再弄个用例描述，系统交互行为很清晰地表达出来。规范、易理解。用例图是UML建模里比较常用的一个图，你用，我用，大家都用，并且标识、要素等均符合UML2中的约定，并且不依赖开发语言，所以说它和其它图一样规范因为规范所以对UML建模用户来说是易理解的。用户导向、描述精准。用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。我们不管系统内部实现功能的机制，仅仅把系统看作一个黑盒，然后参与者与其进行交互，也就是用例是基于用户场景的，所以能更精准地表达用户功能需求。需求与设计分离。因为用例图是站在系统外的视角描述系统需求的，所以并没有介入到系统内部实现细节，这就让需求和设计工作分离开来，条理清晰。便于设计测试用例。用例图描述的就是一个用户场景，测试设计人员正好可以根据用例图设计测试用例。边界清晰。一个矩形框把系统边界清晰、明确地表达出来，便于设计人员据此把握系统范围。敏捷。用例图允许我们讲故事、写卡片，允许我们比较敏捷地实现功能需求方面的管理与交流。二、不足：不能表达非功能需求。用例图是描述用户功能需求的工具，对于可靠性、性能等非功能需求无能为力。对不懂UML的客户或程序员来说难以理解。对UML支持者来说，用例图可能是规范的、清晰的、简单的、易理解的，但对并未掌握UML建模技术的人来说理解那些椭圆并非易事，再说还有一系列如同伪代码似的事件流。粗粒度。是的，用例图不涉及设计实现细节，只是一个功能划分，粒度非常粗，很多细节无从描述，需要用其他工具进行辅助说明。三、常见的错误用法和问题：客户看不懂用例图，又要提供一个高大上（画UML图）的需求规格文档。这时候怎么办呢？作者建议画客户需要画的，然后把用例图制作成一个个卡片去跟客户讲故事，客户不会连故事都听不懂吧除非你讲故事的水平比画图的水平还拙劣。架构师或程序员看不懂用例图。看不懂的话这些用例委实就成了摆设，这时又该怎么办呢？对的，仍旧讲故事，说业务场景并用用例规约加以辅助说明。用例图涉及到实现细节。这个要加以避免，如果过早介入系统内部实现细节，过多的系统内部设计描述会让客户和程序员疲惫不堪。系统边界模糊不清。建议用例图绘制时从上往下画，比较复杂的子系统可以拆在不同的用例图中。用例过多。系统总的用例数不宜超过50个，建议最好是20-30个。过多的用例必定会有过多的Association、include、extend、generalize等关系，各种关系错综复杂违背了我们使用用例图的初衷。

简单地了解一下UML设计中有的图例及基本作用。首先对UML中的各个图的功用做一个简单介绍： 1、用例图 描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

2、类图 类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。 3、对象图 与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。

　4、活动图 描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。

　5、状态图 描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。 6、序列图 （顺序图） 序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。

7、协作图 和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。

8、构件图 （组件图） 描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。

　9、部署图 （配置图） 是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。 一：这九种模型图各有侧重， 1:用例图侧重描述用户需求， 2:类图侧重描述系统具体实现； 二：描述的方面都不相同， 1:类图描述的是系统的结构， 2:序列图描述的是系统的行为； 三：抽象的层次也不同， 1：构件图描述系统的模块结构，抽象层次较高， 2：类图是描述具体模块的结构，抽象层次一般， 3：对象图描述了具体的模块实现，抽象层次较低。 在有的文献书籍中，将这九种模型图分为三大类： 结构分类、动态行为和模型管理： 1：结构分类包括用例图、类图、对象图、构件图和部署图， 2：动态行为包括状态图、活动图、顺序图和协作图， 3：模型管理则包含类图。

uml是面向对象的分析设计方法，dfd是面向数据流的设计方法。当然uml功能强,表述容易清晰,对将来采用面向对象的实现会省很多力气。

uml是面向对象分析方法的表达工具,涉及的图包括用例图,活动图,类图,时序图,协作图,状态图等等;可以涵盖从需求分析到设计,编码整个开发过程用到的模型。

dfd是面向过程分析方法的表达工具,功能大概等价于用例图,活动图,加上e-r模型,可以涵盖面向过程分析(业务建模,概念建模)中所用到的模型。

基于UML的图书馆借阅管理系统设计（1）系统分析（包括系统描述（问题域描述）、用例模型、分析类图）。（2）系统设计（包括系统的逻辑模型如设计类图、顺序图、状态图及组件图等）。（3）系统实施（包括信息代码设计、数据库设计、输入设计、输出设计、用户界面设计和处理过程的设计以及最终的程序设计）。（4）编制好程序后，设计若干测试用例，上机测试并通过所设计的程序系统。（5）设计报告格式按附件要求书写。课程设计报告书正文的内容应包括： 1．问题描述； 2．用例模型及分析类图的描述； 3．设计类图、核心用例的顺序图与状态图、组件图等的描述； 4．信息代码设计、数据库设计、输入设计、输出设计的描述； 5．用户界面设计和处理过程的设计的描述； 6．给出软件的测试方法和测试结果。 7．设计的特点、不足、收获与体会。

以上就是关于UML和程序开发之间有什么的关系_uml中的关系有哪几种全部的内容，包括:UML和程序开发之间有什么的关系_uml中的关系有哪几种、UML用例建模的慨念和应用、UML建模（二）--流程图等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！