uml图总结

uml图总结（通用8篇）

uml图总结 篇1

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图包含了用例和参与者，用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员（通常是软件的用户），对应的是软件的结构和功能分解。

用例是从系统外部可见的行为，是系统为某一个或几个参与者（Actor）提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

2、扩展(extend)扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用例上有几个扩展点。

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

*****************************************************************

(1)系统整体用例图

(商品用例图)

（购买信息用例）

(用户资料用例)

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别

泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：

●泛化侧重表示子用例间的互斥性；

●包含侧重表示被包含用例对Actor提供服务的间接性；

●扩展侧重表示扩展用例的触发不定性；详述如下：

既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：

⒈无条件发生：肯定发生的；

⒉有条件发生：未必发生，发生与否取决于系统状态；

因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

uml图总结 篇2

关键词：本体,UML类图,形式化,描述逻辑

0 引言

UML[1,2,3]是一种形式化建模语言, 可以对具有静态结构和动态行为的系统进行建模。作为一种通用的建模语言, UML越来越多地用于大型系统的建模, 但复杂系统的建模往往需要进行严格的形式分析和验证以保证其正确性。UML是半形式化的———其语法结构采用了形式化的规约, 但其语义部分则是用自然语言描述的, 缺乏准确的语义[4], 难以对模型进行语义推理验证和检查。

为了提高UML的语义精确性, 许多组织和学者提出了很多形式化UML的方法。如:英国的p UML组 (precise UML group) [5]试图给出一种相对治本的方法, 其目标是运用浅显的数学知识对UML元模型进行形式化, 从而将UML发展为一种精确的 (形式的) 建模语言。此外, 还有研究人员利用形式化语言:Z语言、Object-Z语言、COOZ语言、B语言、PVS、XYZ/E、RAISE等对UML类图进行形式化, 以提高模型的准确性。

本文在详细分析对比领域本体与UML模型之间相似性的基础上, 提出了一种基于本体的UML类图形式化方法, 通过本体的推理实现对UML类图的语义检查。由于本体与UML类图模型有着极为相似之处, 并且, 本体能在语义和知识层次上描述信息系统, 因此, 把UML类图模型转换为本体, 通过对转换后的模型进行推理, 可以检查出模型中存在的语义问题, 从而提高了建模的效率。

1 UML类图与领域本体的对比分析

类是任何面向对象系统的核心, 因此, 类图成了最常用的UML图[3]。系统的结构由一组通常称为对象的部件构成。类描述系统中不同对象的类型, 而类图则显示出这些类以及彼此之间的关系。

一个类图主要包括三部分:类名、属性和操作 (方法) 。并且, 类与类之间还存在着各种各样的关系, 包括:依赖、关联、聚合、组合以及泛化 (继承) , 这些类之间的关系依照顺序依次增强的。两个类之间的依赖, 说明一个类的对象暂时使用另一个类的对象。关联则意味着一个类的对象在一段时间内使用另一个类的对象。关联关系包括关系的方向性、角色以及基数等三个要素。方向性指关联关系是从源类指向目的类, 在不同的关系中源类和目的类具有不同的角色, 并具有1对1或1对n的数量关系。关联关系的语义为源类对象中包含目的类对象或对象引用, 因此只有当两个对象的类之间存在关联关系时, 这两个对象之间才可能会发消息。聚合是整体—部分关系, 聚合关系可以看作特殊的关联关系。组合是比聚合还强的关系 (尽管它们的工作方式非常相近) 。泛化是一种更一般描述和更具体描述之间的分类关系。

本体最早是一个哲学上的概念, 从哲学范畴上讲, 本体是客观存在的一个系统的解释和说明, 关系的是客观现实的抽象本质。在人工智能界, 本体最流行的定义是Gruber给出的即“本体是概念模型的明确的规范说明[6]”。后来, Borst在此基础上给出了本体的另一个定义即本体是共享概念模型的明确的形式化的规范说明。通过分析上述定义, Studer认为其包括四层含义:概念模型、明确、形式化和共享。Perez等人认为本体可以按分类法来组织, 他归纳出本体包含5个基本的建模元语。这些建模元语分别为:类、关系、函数、公理、实例, 通常也把class写成concept。概念的含义很广泛, 可以指任何事物, 如功能、行为、策略等等, 实例代表元素;从语义上讲, 概念就是对象的集合, 实例就是概念;关系代表了在领域中概念的交互作用, 形式定义为n维笛卡尔乘积的子集:R:C1×C2×…×Cn, 关系主要分为四类, part-of (概念之间整体与部分的关系) 、kind-of (概念之间的集成关系) 、instance-of (概念的实例与概念之间的关系) 、attribute-of (概念是另一个概念的属性) ;函数是一类特殊的关系;公理代表永真断言。

通过比较可以容易看出, UML类图与本体两者具有高度的相似性[7], 如:UML类图中的类名对应本体建模元语中的类或概念, 关系对应建模元语中的关系, 对象对应于建模元语中的实例, 属性和操作 (方法) 对应于建模元语中的函数, 但UML类图中的函数和本体建模元语中的函数有些少许差别, 例如, 为证实一个Student (一个Student必须至少选学一门课程) 的身份, 一个方法/函数get_course () 可能被声明或定义。本体中的函数一类特殊的关系。该关系的前n-1个元素可以唯一决定第n个元素。形式化的定义为F:C1×C2×…×Cn-1→Cn。例如mother-of就是一个函数, mother-of (x, y) 表示x是y的母亲。UML类图与本体最大的不同之处在于:本体有公理, 具备推理能力, 可以进行自身推理;而UML类图是形式化语言, 不能进行自身的推理。由于其语义的非形式化特点, 所以, UML类图所描述的系统模型往往会隐藏一些错误, 而自己不能检查出来。因此引入本体以弥补对象模型的缺陷。类图与本体之间的对应关系如表1所示。

2 UML类图与本体的转换

本体与UML类图有着许多相似的特性。基于两者的相似性, 建立UML类图到本体的转换, 将UML的类图模型转换为形式化的本体模型。本体作为一种模型需要使用具体的语言表示, 本文选择描述逻辑作为其描述语言, 同一阶谓词逻辑相比, 描述逻辑具有可判定性, 描述逻辑也已经成为其它本体表示语言 (如OIL、OWL等) 的逻辑基础, 而且, 描述逻辑也可以对象模型进行形式化[8]。最后通过对转换后的本体进行推理, 以检查出UML中存在的语义问题。

定义1一个UML类图模型是一个四元组C= (Cn, Cp, Cr, Cm) , 其中:Cn表示类名, Cp表示类属性, Cr表示类之间的关系, Cm表示多重性。在此只考虑UML类图的静态特性, 由于类的方法属于动态性的知识, 不予考虑。

定义2一个DL (Description Logic) 本体模型是一个二元组O= (N, A) , 其中, N=Concepts∪Properties∪Relationships表示一个有限的标识符 (identifier) 集, A表示一个有限的公理序列, 每个公理由作用于标识符的若干构造算子 (如, ∪, ∩, , , 等) 而实现。

显然, 很容易进行UML类图到DL本体之间的转换, UML类图中的Cn、Cp和Cr可直接转换为DL本体中的N, UML类图中的Cn、Cp、Cr和Cm通过一些构造算子可以构造成为DL本体中的公理。

下面通过一个具体实例来说明两种模型的转换:

根据上述规则, 图1可以转换为DL本体:

N是类、属性和关系的集合, A是包含公理和等价公理的集合。Employee, Name, supervise () 等直接映射为领域本体中的概念, 属性, 关系的集合;通过构造子、∩、∪构造SupervisorEmployee、TeacherEmployee、Supervisor≡Employee∩supervise.Graduate等领域本体中的公理。

3 UML类图语义推理

本文主要借助描述逻辑中的Tableau算法对转换后的本体模型进行推理, Tableau算法通过构造一棵关于概念C的Tableau树来计算C的可满足性。该算法的基本思想是:首先, 将不是NNF (Negation Normal Form) 范式的概念通过使用“德·摩根规则”转换为NNF范式, 初始化树T (T仅包含一个根节点) , 然后反复使用转换规则扩展树T, 直到各分枝出现矛盾或者无规则可用。有关描述逻辑的Tableau的算法详细介绍可参阅文献[9]。目前, 已经出现了很多的本体推理机系统, 其中最新的、应用最广泛的和最具代表性的有:Racer, Pellet, Fa CT。Racer是德国Franz Inc公司开发的一个采用描述逻辑作为理论基础的本体推理机, 不仅可以当作描述逻辑系统使用, 还可以用作语义知识库系统;Pellet是美国马里兰大学MNDSWAP项目组专门针对OWL-DL开发的一个本体推理机, 基于描述逻辑表实现;Fa CT是英国曼彻斯特大学开发的一个描述逻辑分类器, 提供对模式逻辑的可满足性测试。

下面就利用Tableau算法对图1进行推理, 图1中的概念Employee有两个分类, 分别为概念Supervisor和概念Teacher。如果图1能准确地描述现实世界, 那么概念Supervisor和概念Teacher应该是不相交的, 即SupervisorTeacher是可满足的 (satisfiable) 。如果SupervisorTeacher成立, 则Supervisor∩Teacher≠。也就是说, {Employee∩supervise.Graduate}∩{Employee∩supervise. (Bachelor∪Graduate) }是可满足的, 整个推理过程如下:

到此已经不能对树T再使用任何转化规则 (transformation rules) 了, 算法结束。树T的节点和边分别为:

由于C (x1) 含有冲突 (clash) , 所以概念{Employee∩supervise.Graduate}∩{Employee∩supervise. (Bachelor∪Graduate) }是不可满足的, 即Supervisor∩Teacher=, 原假设SupervisorTeacher不成立, 因此图1需要修改, 修改后的图形如图2所示。

归纳总结基于本体的UML类图语义推理的一般过程如下:

(1) 找出类图中的概念、关系、属性等直接转化为对应领域本体中的概念、关系和属性。

(2) 利用⊆, ∪, ∩, ﹁, ∀, Ǝ等构造算子根据类图的概念层次关系和属性构造对应中的公理。

(3) 借助描述逻辑提供的Tableau算法对转换后的本体模型进行推理。初始化树T, 将不是NNF范式的概念通过使用“德·摩根规则”转换为NNF范式。

(4) 反复利用上述规则扩展树T, 直到各分支出现矛盾或无规则可用为止, 修改类图。

4 结论

UML作为一种图形化建模语言, 其语义描述是非形式化的, 且缺乏推理能力, 不能对其所建模系统进行语义检查, 使得所建立的模型存在不一致等问题, 影响了建模效率。本文提出了一种基于本体的UML类图的形式化方法, 通过本体提供的推理能力, 对UML类图进行推理, 从而检测出隐藏在UML类图中的不一致等问题, 以达到精确建模的目的, 提高了建模效率。

参考文献

[1]Grady BoochJ, ames Rumbaugh, Ivar Jacobson.The Unified Modeling Language User Guide SECOND EDITION[M].Addison Wesley Pro-fessional, May 19, 2005.

[2]Kim Hamilton, Russell Miles.Learning UML 2.0[M].O'Reilly, A-pril, 2006.

[3]邵维忠, 蒋严冰, 麻志毅.UML现存的问题和发展道路[J].计算机研究与发展2, 003, 40 (4) :509-516.

[4]Evans A, Kent S.Core Meta-modeling Semantics of UML:The pUML Approach[DB].http://www.cs.york.ac.uk/papers/pumlun199.pdf, 2005.

[5]Borst P, Akkermans H.An Ontology Approach to Product Disassembly[C]//EKAW 1997, Sant Feliu De Gu5xols, Spain, October:15-19.

[6]Dencho N Batanov, Waralak Vongdoiwang.Using Ontologies to CreateObject Model for Object-Oriented Software Engineering[M].In:Shar-man, Raj, et al.ONTOLOGIES:A Handbook of Principles, Conceptsand Applications in Information System, Chapter 16.New York:Springer, 2007.

[7]Daniela Berardi.Using DLs to reason on UML class diagrams[C]//Proc.Workshop on Applications of Description Logics.2002.

uml图总结 篇3

【关键词】 概念图 高中生物 复习总结 实践应用

【中图分类号】G424.1 【文献标识码】A 【文章编号】2095-3089（2014）08-0083-01

一、概念图的类型和特征

概念图的类型有很多种，主要有一般层级概念图、链状概念图和环状概念图等，但无论是哪种类型的概念图都具备以下几个特征：①概念按分层的形式表现；②泡含着交义连接；③包含许多具体事例，但是由于不同的人的认知方式不同，知识背景不同，所以对同一个知识板块所绘制的概念图也不尽相同。

二、概念图的制作

（1）确定概念图包括的范围。绘制概念图首先要确定包含的知识范围，明确这个知识范围内所涉及的所有概念；

（2）设计好关键概念的排序。要把含义最广、最有包容性的概念放在图的顶端，从最一般、最概括的概念到最特殊、最具体的概念依次排列。虽然这样的排列是很粗糙的，但能帮助确立概念图的结构。需要注意的是每个概念都是一个专有名词，在一个概念图中只出现一次；

（3）初步拟定概念图的纵向分层和横向分支。一个概念图通常只有一个核心概念，核心概念下分出其包含的几个并列概念，每个支概念下又可以分出其包含的几个支概念，依次分支下去。同一个概念在不同的概念图中的地位可能是完全不一样的，这取决于构建概念图的最初规划和作者对概念本身的理解；

（4）建立概念之间的连接。连接两个相关联概念，尽可能选用表达具体明确意义的联系词，概念及连接概念间的词必须能表达一个确完整的观点。概念间的连接线可以相互交错，向上和向两侧的连线需要加箭头，而向下的连线则不加箭头；

（5）不断修改和完善。有了初步的概念图以后，随着学习不断深入，师生对原有知识的理解会加深和改变的。所以，概念图应不断地进行修改和完善。

三、概念图在高中生物教学中的意义

1.作为教师的教学工具

概念图作为教师的教学工具，它能促使教师深层次地把握知识的内在联系和脉络，引导学生建立知识体系；促使教师从全局高度审视整个课堂教学的知识框架和课堂结构；促使教师反思，完善教学方案，改进、创新教学策略；促使教师从学习者的角度，开发并贴近学生实际，挑战学生的思维。

2.作为教师的评价工具

在实际教学中，学生对教师所绘制的概念图的理解和接受的情况，可以作为教师对课堂教学的一种反思。同时，学生所绘制的概念图表达了学生对概念的理解，无论是正确还是错误，都将从他们所绘制的概念图中找寻到蛛丝马迹。这样，就有助于教师了解学生的知识结构，及时发现并寻找纠正错误概念的途径。

3.作为学生的学习工具

运用概念图帮助学生复习生物知识，学生可以对不易理清的各种概念和原理有进一步的了解和更深入的认识，还可使原来迷惑的概念清晰化，零散的知识系统化，机械的知识灵活化。

四、概念图在复习总结时的应用

通过概念图来复习高中生物知识的过程中，应当注重培养学生绘制概念图的能力。针对学生水平的不同，可设计不同的方式，使教学难度循序渐进。

1.在训练之前，应当注重培养学生对概念图的认知度，使学生对概念图由大致了解并且感到熟悉。此时教师可通过为学生大量演示、讲解概念图的使用，以此来向学生传输概念图是一种良好学习工具的思想。与此同时还要加强学生对知识的熟悉度的训练，使同学了解物质之间的关系，为后期绘制概念图打下基础。

2.在初期，让学生参与到概念图的制作中来，与老师共同完成体系结构的建立，从而提高兴趣。此时教师可绘制未完成的概念图，通过对学生的提问或者让同学上黑板上填写的方式来增加学生与老师之间的互动。通过适当的引导，使学生完成课本知识到概念图形的转换，对生物知识活学活用。如在讲解到内环境相关知识时，淋巴、血浆与组织液间的关系是一个重点，教师可以设计一个未完成的关系图，如下：

学生可能会对1和2搞不清楚，此时教师对学生提问“血浆是否可以形成淋巴？组织液呢？他们之间又是以何种方式实现转换？”来引出知识点“组织液投过毛细淋巴管形成淋巴，而淋巴经由淋巴循环重新回归到血液中，组织液与血浆通过毛细血管壁实现转换”，帮助学生建立概念图与知识的联系，从而完成概念图，如下：

3.在中期，培养学生合作完成概念图。教师给定核心概念，通过课后作业的方式让学生经过小组讨论设计概念图，教师对各小组同学的作品进行点评，并由同学间互相指出此概念图的优点以及不足之处，能从通过自身与他人的对比实现取长补短的效果，也可以在他人的概念图中及时发现自己的知识漏洞。点评结束后教师可组织对优秀的概念图进行班级展示，以精神奖励来营造竞争的氛围，从而调动同学们的积极性。这种方式可以使学生在亲身设计的过程中达到复习总结效果，同时也增强了逻辑思维能力。

4.在后期，培养学生独立完成概念图。学生独立设计概念图可以有更大的发挥空间，出现并落实各种新奇的想法。同时培养了学生独立思考、独立解决问题的习惯。此时教师应针对不同同学间的差异来分别进行辅导，实现师生间的高效互动。教师可通过小测的方式要求同学们进行概念图制作，这样可以使教师节省审阅的时间同时也能准确掌握学生情况，及时发现学生的问题。

参考文献：

[1]王伟.概念图在高中生物教学中的运用研究[J].课程教育研究，2013-11-15

[2]马宁.综合型概念图在高中生物复习课中的应用研究[D].天津师范大学2013-04-01

UML实验报告总结 篇4

二、时序图和协作图建模

实习三 UML类图与包图建模（2学时）实验四 状态图和活动图建模 实验五

组件与部署图

实验一 熟悉Rational Rose及建立用例模型

（2学时）

一、实验名称：熟悉（2学时）

二、实验目的与要求：

 了解和掌握Rose建模工具的使用  掌握怎样进行案例需求分析；  掌握UML用例图建模技术

三、实验内容：

1、熟悉rose上机环境及设置

2、根据以下谈话设计出用例图

Rational Rose及建立用例模型

四、实验步骤：

见实验说明书

实习二（2学时）

一、实验名称：

时序图和协作图建模（2学时）

二、实验目的与要求：

 了解和掌握Rose或Visio建模工具的使用

 掌握怎样进行系统分析，并进行UML静态建模分析；  掌握UML时序图和协作图建模技术

三、实验内容：

根据以下谈话设计出时序图和协作图建模。

四、实验步骤：

、UML类图与包图建模（2学时）

一、实验名称：UML类图与包图建模（2学时）

二、实验目的与要求：

 了解和掌握Rose或Visio建模工具的使用

 掌握怎样进行系统分析，并进行UML动态建模分析；

三、实验内容：

四、实验步骤：

实习四（2学时）

一、实验名称：

状态图和活动图建模（2学时）

二、实验目的与要求：

 了解和掌握Rose或Visio建模工具的使用

 掌握怎样进行系统分析，并进行UML动态建模分析；  掌握UML状态图和活动图建模技术

三、实验内容：

四、实验步骤：

实习五

组件与部署图与代码生成（2学时）

一、实验名称：

组件与部署图（2学时）

二、实验目的与要求：

三、实验内容：

实图总结 篇5

 11G101-1《混凝土结构施工图平面整体表示方法制图规则和结构详图（现浇混凝土框架，剪力墙，梁，板）》

 11G101-2《混凝土结构施工图平面整体表示方法制图规则和构造详图（现浇混凝土板式楼梯）》

 11G101-3《混凝土结构施工图平面整体表示方法制图规则和构造详图（独立基础，条形基础，筏形基础和桩基础）》

 本图集适用于非抗震和抗震等级设防烈度为6—9度地区的现浇混凝土框架，剪力墙，框架——剪力墙和部分狂支剪力墙等

 在平面布置图上表示个构建尺寸和配筋方式，分为平面注写方式，列表注写方式和截面注写方式

 按平法设计绘制结构施工图时，应用表格或其他方法注明包括地下和地上各层结构层的楼（地）面标高，结构层标高，相应的结构层号

 挡结构详图有很多方法时，当未写明时，则为设计人员自动授权施工人员可以任选一种构造做法进行施工

 轴心受拉构件和小偏心手拉构建的纵向钢筋不得采用绑扎搭接

 柱采用列表注写方式或截面注写方式

 在主屏法施工图中，按108条规定注明个各结构层楼面标高，结构层标高及相应的结构层号、尚应注明上部结构的嵌固部位位置

 框架柱和框支柱的根部标高系之基础顶面标高

 剪力墙平面布置图上采用列表注写方式或截面注写方式

 剪力墙有剪力墙柱，剪力墙身和剪力墙梁组成 拉筋有双向和梅花双向两种布置形式

 巨型洞口JDXX/圆形洞口YDXX

 OS剪力墙外筋H水平V竖向贯通筋，tb拉筋

 梁采用平面注写方式或截面注写方式

 当同排钢筋中有通长筋又有架立筋时用+连接，前面是角筋，后面括号里是架立筋  梁构造筋和受扭筋是必注值，当H>450时，有构造筋

 附加箍筋和吊筋直接画在主梁用引线表明总配筋值

 有梁楼盖的制图规则适用于以梁为支座的楼面与屋面板平法施工图设计

 当轴网向心布置时，切向为X，径向为Y

思维导图学习总结 篇6

作为张庄镇明德小学的一员有幸参加了2017年11月29日在解放路小学召开的禹城市德州规划课题暨思维导图专项培训会议，在我们的教师生涯中经历过很多形式各级各类的培训，也许大多数老师也经历过培训师的感动和激动，但回来后却一动不动，因为我们惊叹于培训者的优秀，但是又有点望尘莫及。但是思维导图的培训和学习不仅留给我们感动和激动，而且也留下了我们自己行动的足迹，更期待的是我们明天迈向教育生涯的脚步会更加矫健，因为我们真真实实的学到了东西，也真真切切的用到了教学实践，确确实实的体验到了培训带给我们的喜悦和收获。一下午的时间分别听了谷月老师的《You Can Play Football Well》，这节课谷老师讲的非常生动形象，利用道具与学生演练，通过实际参与让学生理解“接球”“传球”，利用思维导图围绕课题中心，引导学生顺着内容扩散，有序的将知识点进行了梳理，起到了总结，引导的作用。德开小学的于跃老师讲的四年级的《平均数》，利用投篮入筐，贴近生活实际的例子引入课题，课中利用思维导图将平均数的意义，方法，特点梳理的特别清晰，将知识点展示的淋漓尽致，通过思维导图学生就能了解到本课的知识点，重难点，在课后总结时起到了很好地引导梳理的作用；第三节课是听了德开小学的刘晓慧老师的《生命 生命》，利用思维导图将生命讲的生动感人，展现生命的顽强。沿着生命这一中心点，伸枝“我的感悟”，“飞蛾批货”以及原因（被捉，想活下去），“香瓜苗的生长”，“我听心跳”，将一篇课文的知识点，体现生命的点全部展现在学生眼前，旁观者不用读课文通过观看思维导图就能知道这篇文章讲的什么。理论指导实践，实践证明理论，第一次的集训中开了三节精彩的公开课，展示思维导图在不同课型中的运用。

思维导图，又叫心智图，是表达发射性思维的有效的图形思维工具。是一种革命性的思维工具。简单却又极其有效。思维导图运用图文并重的技巧，把各级主题的关系用相互隶属与相关的层级图表现出来，把主题关键词与图像、颜色等建立记忆链接，思维导图充分运用左右脑的机能，利用记忆、阅读、思维的规律，协助人们在科学与艺术、逻辑与想象之间平衡发展，从而开启人类大脑的无限潜能。思维导图因此具有人类思维的强大功能。

思维导图是一种将放射性思考具体化的方法。放射性思考是人类大脑的自然思考方式，每一种进入大脑的资料，不论是感觉、记忆或是想法--包括文字、数字、符码、食物、香气、线条、颜色、意象、节奏、音符等，都可以成为一个思考中心，并由此中心向外发散出成千上万的关节点，每一个关节点代表与中心主题的一个连结，而每一个连结又可以成为另一个中心主题，再向外发散出成千上万的关节点，而这些关节的连结可以视为记忆，也就是个人数据库。

通过观看三位老师的公开课，我觉得思维导图很神奇，能起到那么大作用，所以我觉得将思维导图用在课堂上很有必要，首先围绕课题顺着内容扩散起到了梳理知识点的作用；其次思维导图将知识点分条着类的进行展示，清晰而明了更易于学生记忆。而且思维导图形式的不固定，可以画图也可以贴图，丰富多样的图形能够吸引学生的注意力，提高学生课堂兴趣。刘老师讲到画图时要注意：①按顺时针画图②图形分支要注意颜色的区分，每条分支用不同颜色③用思维导图时也要注意教师的主导性学生的主体性，注意引导学生。

回校后在学校的组织下我们老师也集体讨论了思维导图在课堂中如何开展，我们觉得思维导图基本适用于各个年级，关键在于老师的把握应用能力和对知识内容的掌握程度。在校领导的带领下我们所有老师积极开展思维导图教学，逐渐摸索，遇到困难的时候会在数学教研会上大家集体讨论解决方法。特别是电脑课件上的思维导图起初我们不会设计，就邀请了计算机专业的老师现场指导教授我们如何插入分支，经过老师的指导和我们自己课下的摸索才慢慢掌握这项技术。

我现在任教一年级数学，一年级的内容是比较简单的，我将思维导图积极应用到课堂中来，一开始的时候我是将思维导图放在课堂的最后，通过画图的形式将课堂内容知识点进行总结，体现在图上，图形我并没有局限于一种图形，几乎每节课我都尝试变换图形，尽量画不同图形例如画一棵树，画一朵花，画一个太阳，画一只小鸟，总之通过变换图形不同样式的图，展现给学生，学生每次看到我画图的时候都特别兴奋，这极大的提高了学生的积极性，活跃了课堂气氛。慢慢的我将思维导图提到了课中，不再是总结的时候用，而是每讲到一种计算方法就体现在图上，有时候我会故意画一个不完整的小鸟或其他图形，根据知识点的数量画图形的残缺点，然后将知识点补充到图形上，将图形拼凑完整，每次拼凑完整学生都会特别高兴，就像完成了一件特别厉害的事情，兴高采烈。例如讲两位数加两位数时，我画了一个小人“三毛”，学生特别好奇而且很兴奋，课堂上我用他的三根头发作为分支，并用三种颜色展示三种方法分别是摆小木棒计算，计数器计算和竖式计算。教学中我始终秉承教师主导学生主体为原则，引导学生发现信息提出问题，鼓励他们自主解决。在讲尺子这节课时我换了一种方法，采用了贴图的形式，将图纸剪成苹果的形状，把尺子的各个特点和测量方法以及注意事项分别写在图形上，在黑板上画一棵苹果树再画出几枝分枝，每讲到一处讲完后把图形贴到树枝上，这节课讲完时就变成了一棵硕果累累的苹果树，同学们很有丰收的感觉，纷纷争抢要吃苹果。贴图式的思维导图比画图式的思维导图在操作上更麻烦一些，它需要老师在课下做大量的工作，自我认为它用在知识点更多地课堂上效果会更好。

在课上思维导图这一环节中，作为新手的我存在很多的不足，需要去改进。例如①在教学过程中思维导图呈现时机不能正确把握，有时提前又有时候延后；②我觉得思维导图在我的课上起到的作用有点单一，只是单纯的展现知识点和最后的总结作用，并没有进行延伸和更深层次的加工；③起初思维导图的应用在课上并没有起到明显的效果，效果非常低，我想这跟我的教学经验和掌握的思维导图技巧有关，需要我去做更多地工作更多的学习；④作为体育专业出身的我，绘画并不是我的强项，所以在绘制思维导图时不是那么美观，这就需要我去改变自己的方式减少绘图更多地采用贴图形式的思维导图。在今后的思维导图环节上我觉得应该主题明确，分支规范正确把握关键词，将知识点梳理有序。

我在三月份和其他乡镇同事一起赴烟台交流学习两个月，在这期间在烟台市高新区实验小学跟岗学习，听了那里老师的很多公开课，在数学课上老师们加入德育内容，间接培养学生的品德素质。在公开课上烟台市高新区实验小学的老师也采用思维导图的形式，有用画图的思维导图，有用贴图的思维地图，形式比较多样化，但都做的特别仔细，观赏感很强，充分调动了学生的注意力提高了学生课堂兴趣。思维导图在烟台市高新区实验小学开展的已经很成熟，老师们运用起来已经相当娴熟，这必然是长期实施的结果。这里的老师们大多数还是采用贴图的思维导图形式，也有进行手绘的，但是比较少。贴图想多来说对老师的工作要求更高，需要精心设计每一种图案，然后还需要老师有很好的剪纸工艺，剪出不同形状的图案，还需要老师设计如何在课堂黑板上摆设造型；而手绘的思维导图就需要老师现场的思维扩散能力和绘画技艺。就像邢老师的三角形的面积》这节课，她的思维导图上面的贴图，是在前面学生进行自助探究，现场上台操作后摆上去的，三角形拼凑成的四种图形都是学生自主探究发现的，邢老师的这个思维导图非常规范有序，知识点把握准确，构成一个循环式的过程。

uml图总结 篇7

审批工作[1]是目前企业普遍存在的一种基础性管理业务,是审批者对需要审批对象进行相关审核和批准认可,对合格对象给予某种资格或行为的小范围合理性。其中,图文档的审批工作占企业全部审批工作的绝大部分,其审批方式主要依靠各职能部门对纸质媒介的图文档进行手工审查批改,这种传统的图文档审批流程存在效率低、成本高和安全性差等不足,已无法满足产品快速研发的需求。随着企业信息化水平的提高,基于网络的图文档在线审批管理势在必行[2,3]。如何加快图文档的审批流程、减少审批时间、加速产品上市,这已成为缩短产品生命周期的重要环节。

2 图文档审批流程定义

在对图文档的审批变更流程进行分析时,需明确各流程模板节点的定义、审批人员身份/角色、表决的类型、完成时的状态、流程审批对象及流程备注等内容。针对某企业对图文档管理[4]的需求,定义了其图文档审批流程的主要节点任务,如表1所示。

(1)流程模块定义:给出了任务节点/功能块的名称,可定义为与角色名相关的名称,如部长审批,也可定义为与任务有关的名称,如校对评审等。在流程模块定义的同时,可预先定义审批人员身份,也可不定义,对于不定义审批人员身份的流程,流程发起者必须定义审批人员。对于执行多种操作需要预先定义,如当执行者拒绝或批准同意上游的申请时,流程将如何流转。

(2)审批人员身份:用于设定任务审批人员,审批人员可以是组织、角色或具体的某个人。表中“*/设计者”表示组织部门没有限制,也没用指定某个特定的角色,但对角色进行了限制,即只允许设计者角色可参与设计模板的操作。

(3)表决类型:决定了任务节点的操作方式,表决类型的设定是依据流程对具体角色任务节点的需求,对于审批人员可设置批准、拒绝和不作决定等操作,对于某些只具有浏览过程的角色,可只设置完成等操作,减轻系统对用户决定方式的判断运行负担。

(4)完成状态:完成状态的设定用于区别审批和未审批状态的对象信息,无论是生产部门还是工艺部门只可对具有完成状态的对象进行调用。

3 图文档审批流程分析

根据表1定义,给出某企业工程图样审批流程,如图1所示。设计人员在图文档审批系统中对零部件工程图样发起审批流程,并对每个节点进行人员指派,系统自动检测所发起审批的零部件图样是否符合系统预定义要求,若符合将流转至下一个任务节点校核。校核节点处有三种操作:批准、拒绝和不作决定,当选择拒绝时,流程将退回至设计节点,若选择不作决定将使图样审批被挂起,若选择批准流程将流转至下一步审核。审核角色是工艺部相关工艺人员,操作与校核类似,工艺人员对图样进行产品加工工艺方面的审核,审核通过则零部件图样自动流转至标准化节点处,负责执行企业标准化的角色将检查是否符合企业规定标准,操作与校核类似,若通过则流转至定义设计部部长角色的标审任务节点,部长对图样也有三种操作,若通过则到批准节点。批准节点的角色是部长或副总经理,当审批对象是总装图样时,发起者在指派人员时应指派副总经理进行批准,当审批对象为其它,指派部长即可,部长或副总经理同意发放则零部件工程图样完成了整个审批的流程,会对发布的图样进行状态标记,并通知初始发起者。

4 图文档更改审批流程UML建模

图文档更改审批流程包括问题报告审批流程、变更申请审批流程和变更审批流程三个子流程,它远比图文档审批流程复杂得多,涉及的人员众多,任务处理也多样化。而统一建模语言UML(Unified Modeling Language)的活动图往往用来表示在处理某个活动时,两个或者更多类对象之间的过程控制流[5,6]。活动图既可以用于对高级别的业务过程进行建模,也可以对低级别的内部类操作进行建模。为能够更好地表达更改审批流程的交互性,对图文档更改审批流程进行了UML活动图建模,如图2所示。

(1)问题报告审批流程

创建问题报告节点:企业产品图样并不是一成不变的,对其更新或问题零部件图样进行更改都可用更改审批流程,在此任务节点上,用户发现需要修改的对象,并创建对象的问题报告(Problem Report,PR)附属在对象中,用于发起问题报告审批流程。

发起流程节点:该任务节点用于对上一节点创建的问题报告(PR)发起审批流程,流程的发起者需要对问题报告(PR)自审查,指派问题报告审批流程中各个人物节点的审批人员。若发起流程的内容符合系统定义范围之内则流转至设计校核节点中。

设计校核节点:角色与发起流程的角色相同,用于对问题报告(PR)和问题对象的核查,拥有同意和拒绝两种操作选择,若同意进入部长审批节点。

部长审批节点:角色为部门的部长,审核对象与设计校核节点类似,不同之处在于部长拥有批准、拒绝和不作决定三种操作选择,若批准则进入副总批准节点。

副总批准节点:角色是副总经理,任务与操作类型与部长审批节点类似,若批准同意,系统将提示流程的发起者问题报告审批流程的完成,并提示发起下一步流程。

完成通知节点:角色为初始流程的发起者,用于接收提示信息,此时发起者也具有变更申请审批流程权限。问题报告审批流程到此已经完全完成。

(2)变更申请审批流程

变更申请节点:角色为流程的初始发起者,在该节点的任务是创建变更需求(Change Request,CR)、设置变更申请审批流程节点中审批人员,当前两部完成后,可发起变更申请审批流程。

分析创建节点:用于分析变更需求(CR)对对象的影响,建立变更申请计划表,系统提供完成和未完成两种操作,完成后将进入部长会签节点中。

部长会签节点:审批角色为若干部门部长,对象的变更会影响多个部门,如零部件产品的变更会涉及到设计部、工艺部、生产部等部门。只有部长全部同意通过流程才可继续下去。

副总批准节点:该节点名称与问题报告审批流程中节点名称类似,但它们还是有本质的区别,首先是审批对象不一样,其次是系统提供的操作不一样,在该节点中不仅提供了批准、拒绝和不作决定操作,而且提供了拒绝所有操作。当副总经理选择拒绝时,该变更申请审批流程会返回流程的第一个节点变更申请中,若选择拒绝所有更改,审批流程会自动结束并通知发起者。

变更通知节点:角色是初始流程的发起者,用于通知变更申请流程的完成和提示发起下一流程。

(3)变更审批流程

申请更改节点:角色为流程的初始发起者,该节点的任务包括创建变更通知(Change Notice,CN)、指定审批对象人员角色和发起变更审批流程。

分析创建节点:用户接收上一流程的变更通知(CN),创建执行变更时间计划表并确定相关变更对象。完成后流程进入部长审批节点。

部长审批节点:角色是部门部长,批准同意变更通知(CN)的发放,用于下一流程对象的设计者对对象的更改,对更改实现授权。

执行更改节点:角色为设计者,设计者对自己设计的对象有着其他人无法比拟的优势,可以快速进行对象的重设计和更改。设计者接到变更通知(CN)时,依据变更通知(CN)的要求结合更改时间计划表进行对象的更改。更改完成后提交,流程流转至多人会签节点中。

多人会签节点:角色为若干部门的专家审核人员,流程的发起者开始已指定。只有所有人员同意流程才会流转至下一步。

副总批准节点:角色为副总经理,此处节点与变更申请审批流程副总批准类似,不再详细描述。当副总批准同意后,对象变更审批流程完成,更改审批流程也完成,并对流程发起者和执行更改者发放批准通知。

审批流程是动态变化的工作流程,由于各种不确定因素(如审批人员出差等),正在运行中的审批流程可能无法继续下去,而且企业对时间审批流程的任务和节点的定义也会出现新的要求。因此,对系统审批流程提供良好的实施监控工具是非常必要的,以提高系统的应变能力和可用性。

5 结论

针对某企业图文档管理系统开发需求,分析并定义了其图文档审批流程的主要节点任务,并进行了相应的图文档审批流程分析。针对图文档更改需求,将图文档更改审批流程细分为问题报告审批、变更申请审批和变更审批三个子流程,对各子流程的主要节点任务进行了详细设计,在此基础上,基于UML建模方法建立了图文档更改审批流程的活动图模型,为图文档在线审批管理系统的开发提供了理论基础。

摘要：国内企业图文档的传统审批主要依靠职能部门对纸质媒介进行审批修改,存在效率低、成本高和安全性差等不足,无法满足产品快速研发的需求,基于网络的图文档在线审批管理势在必行。针对某企业图文档管理系统开发需求,分析并定义了图文档审批流程的主要节点任务,并进行了相应的图文档审批流程分析。针对图文档更改需求,将图文档更改审批流程细分为问题报告审批、变更申请审批和变更审批三个子流程,对各子流程的主要节点任务进行了详细设计,在此基础上,基于UML建模方法建立了图文档更改审批流程的活动图模型,为图文档在线审批管理系统的开发提供了理论基础。

关键词：图文档,审批流程,更改流程,节点任务,UML建模

参考文献

[1]王正方,南琳,王作鹏,等.企业信息系统中的业务信息审批模型[J].计算机工程,2008,34(9):257-259.

[2]辛华,薛福任,等.工作流技术及其在网上审批中的应用[J].计算机工程与应用,2004,40(22):217-219.

[3]于重重.基于UML的网上审批系统的建模研究[J].计算机仿真,2004,21(7):169-171.

[4]李宗学,胡志勇,范文学,等.企业实施图文档管理系统的关键技术[J].机械制造与自动化,2007,36(4):76-80.

[5]蒋胜龙,郑忠,高小强,等.基于UML的炼钢物流仿真系统分析与设计[J].系统仿真学报,2007,19(16):3676-3679.

uml图总结 篇8

1.社保系统中的UML2.0应用分析

UML2.0建模语言采用图形表示法。在社保系统设计中，笔者利用UML2.0技术手段实现了保险管理信息系统领域建模的基本过程，大大提高软件开发周期各阶段之间表示的一致性，缩小开发各阶段之间的间隙。UML2.0以对象为单位进行分割、包装，提高了组件重用率，使整个社保系统的可重组性明显增加。

在社保管理信息系统的UML2.0建模中，经过了开始、细化、构造和交接等几个阶段。在UML2.0建模的开始阶段，根据用户提出的需求产生角色及使用案例，并采用使用案例框图进行可视化描述，清晰的表达了用户系统的真实目标；在细化阶段，首先要进一步分析开始阶段产生的使用案例模型，对使用案例低层要求进行详细描述，包括使用案例的处理流程，使用案例中涉及的角色、对象，并用交互框图描述出所有角色对象之间的详细交互活动及对象本身的状态变化，用类框图显示要建立的类对象及其相互关系；构造阶段和细化阶段类似，是围绕使用案例来进行的。该阶段根据已有的工作基础，设计出组件和组件框图，自下而上建立一个完整的系统模型，并通过一系列迭代过程来构造实际可用的系统。每一次迭代开发都是一个小项目，每一个小项目完成后，就向用户演示，并完成局部系统测试，证明已正确实现了用例要求的功能。待全部小项目完成时，进行整体的测试集成。移交阶段的任务是将设计完成的软件产品交给用户，接受用户的检测，并完善设计文档的存档。

2.UML2.0在社保系统中的使用案例模型

根据UML2.0建模的几个基本阶段划分，可以看出，使用案例是系统建模的关键。下面给出社保系统利用UML2.0建模时，使用案例模型的相关分析。

本节分析UML2.0建模中的第一类图，即用例图，它包括用例（USERCASE）和角色（ACTOR），是用来从用户角度描述系统的功能，并指出系统各功能的操作者。USE CASE是UML2.0的核心，也是使用案例模型的重点。在传统的面向对象的系统模型中，很难明确地说明系统是怎样完成其目标的，这是由于系统在执行特定的任务时，并没有一条主线。而在UML2.0中，因为USE CASE定义了系统的行为，它实际上就是一条这样的主线。USE CASE在软件开发的需求、分析、设计、实现、测试几个核心流程中扮演着非常重要的角色。其中用例图描述的社保系统一共包括38个使用案例和29个角色。图1所示为社保系统中参保人员就诊与费用结算处理的USE CASE模型框图。

图1描述了社保系统中的5个用例和3个角色。5个用例是：看病、参保身份验证、处方单费用计算、药品准入验证、付款和欠费处理，而其中的参保身份验证和药品准入验证属于《Use》用例，欠费处理则是《Extends》用例。3个角色是就诊者、医生和支付系统。

3.社保系统中相关对象的顺序图、合作图和活动图模型

本节分析UML2.0建模中的第三类图，即交互图和活动图。交互图包括顺序图和合作图，用来描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。合作图与顺序图相似，也描述对象间的协作关系与动态合作关系。但两者有侧重，如果强调时间顺序，则使用顺序图，如果强调上下级关系，则选择合作图。

活动图，用来描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件，它是对类图的补充。在实用上，往往并不需要为所有的类画状态图，通常仅为那些有多个状态且其行为受到外界环境的影响而发生改变的类画状态图。由于活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别、表达和进行活动。

社保系统中共有顺序图、合作图和活动图50多张。其中对象之间动态协作关系的顺序图描述如图1所示。

顺序图模型非常直观地展示了对象之间传送消息的时间顺序，反映了对象之间的一次特定的交互过程。在本系统中，就诊者对象向医院门诊发送参保身份验证的消息，门诊完成身份验证后便向医生对象发送就诊人看病的消息，医生看病开处方单后，向处方单对象发出保存处方单的消息，处方单对象完成保存工作，并同时对处方单进行药品准入验证，然后向支付系统发送处方单费用计算的消息。支付系统完成处方单费用计算后，通知就诊人付款。整个过程是顺序完成的。其它交互图描述从略。

4.社保系统的类图模型

类图，是静态图的一种。而静态图是UML2.0建模中的第二类图。类图通常显示了一组类、接口和协作以及它们之间的相互关系。类图在面向对象的建模设计中是很常用的。类图能有效表示系统中的类以及类与类之间的关系，它是对系统静态结构的描述。因此，我们常利用类图来阐明系统的静态设计。类与类之间有多种连接方式（或称关系），比如关联（彼此间的连接）、依赖（一个类使用另一个类）、通用化（一个类是另一个类的特殊化）或打包（多个类聚合成一个基本元素）。

由于类图描述系统中类的静态结构，表达了系统在一个稳态必须满足的对象间的关系。所以，类图描述的这种静态关系，在系统的整个生命周期都是有效的。

对象图也是静态图的一种，它是类图的实例，几乎使用与类图完全相同的标识，不同点在于对象图显示的是类的多个对象实例，而不是实际的类。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

静态图还有一种结构形式是所谓的包图，包图由包或类组成，表示包与包之间的关系。包图用于描述系统的分层结构，是将大系统拆分为小系统的工具，可以帮助理解与维护系统。

社保系统中的类图模型之一，即帐务管理部分的类图模型如图3.3所示。社保系统中的帐务管理部分一共包含基金总帐、实收帐、应收帐、住院基金、风险基金、个人帐户、住院费用单以及门诊费用单、购药费用单、参保职工、参保单位、缴费凭证等12类对象。其中的类对象实收帐和应收帐都是基金总帐的一部分，它们之间的关系是整体与部分的关系，是一种组成关系。同样的，住院基金、风险基金和个人帐户与实收帐之间的关系也是一种组成关系。住院基金和住院费用单是一种带约束的一对多关系，即如果费用单金额之和超过定额支付数，则只支付定额数。同样的，风险基金和住院费用单的关系也是一种带约束的关系。