自动生成uml图工具，uml建模工具有哪些

大家好，感谢邀请，今天来为大家分享一下自动生成uml图工具的问题，以及和uml建模工具有哪些的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！

图书管理系统 uml图

【原文出处】现代图书情报技术

【原刊地名】京

【原刊期号】200206

【原刊页号】4～6

【分类号】G9

【分类名】图书馆学、信息科学、资料工作

【复印期号】200301

【标题】基于UML的高校图书馆管理系统

【英文标题】The Application of UML in Digital Library

Jin Yi Yang Zongying

(Institute of Information Science and Technology,Shanghai Jiaotong University, Shanghai 200030,China)

【作者】金毅/杨宗英

【作者简介】金毅，杨宗英，上海交通大学情报科学技术研究所上海 200030

【内容提要】数字图书馆的研究方兴未艾，目前正处于传统图书馆向数字图书馆过渡的阶段，转变过程中需要应用和集成最新的信息技术，以达到对网络信息资源最有效的利用和共享。传统的系统分析设计的方法难以保证开发的效率和质量，将UML应用于数字图书馆建设，可以加速开发进程，提高代码质量，支持动态的业务需求，并方便地集成已有的传统图书馆信息资源。这是UML一个有着很好前景的应用方向。

【摘要题】实践研究

【英文摘要】The study of digital library is booming. Now traditional library is converting to digital library,this needs the application and integration of the latest information technologies for the maximum usage and shareof network information resources. Traditional system analysis and design methods can't guarantee the efficiencyand quality. Using UML in developing digital library can quicken the process, improve the code quality, supportthe dynamic needs and easily integrate the traditional resources. This is a hopeful application field for UML.

【关键词】UML/数字图书馆

UML/Digital library

【正文】

【分类号】G250.76

1引言

在信息技术迅猛发展及基于Internet网络应用日益普及的今天，传统图书馆正在向自动化、网络化、电子化的数字化方向发展，这是目前网络信息资源开发和研究的热点。数字图书馆的建设涉及到信息资源数字化、多媒体数据库、分布式网络、信息管理系统结构等多方面的问题，需要有效地集成和应用最新的信息技术。如何在宏观上有效地把握和组织，并运用到数字图书馆的开发建设上，是数字图书馆研究的重点。UML（The Unified Modeling Language，即统一建模语言）是一种编制系统蓝图的标准化语言，可以对复杂的系统建立可视化的系统模型，目前已经被工业标准化组织OMG（Object Management Group）接受，一经推出便得到许多著名的计算机厂商如Microsoft、HP、IBM、Oracle等的支持，在国际上的应用日益广泛。数字图书馆的开发建设是一个复杂的软件工程，需要集成不同的操作系统、数据库和应用软件，有众多不同级别的用户、管理员，满足图书馆从书目查询、普通和电子书刊借阅到提供网上信息服务、资源共享等各种需求。用传统的系统开发和集成的分析设计方法难以保证效率和质量，UML的特点及数字图书馆的要求，决定UML在数字图书馆中应该有很好的应用前景。

1.1数字图书馆的基本特征和模式

数字图书馆组织了一系列与平台无关、面向对象、分布式的数字化信息资源并且提供相关的服务，它应该具有以下一些特征〔2〕〔4〕：

（1）数字图书馆拥有海量的数字化资源，其信息度量单位不再是KB、MB，而是GB、TB甚至PB。数字化的资源又是多种媒体（如文字、图像、音频、视频、虚拟空间等）的，具有多种存储和压缩格式。

（2）数字化资源并不是孤立的，而是相互关联的动态的。数字图书馆是数字化资源的统一，可以通过一定的相关关系，由特定的协议和存取方法来查找和访问这些数字化资源。

（3）数字图书馆必须为用户提供统一的访问手段，能够让用户透明方便地获取所需的信息而不必关心这些信息的具体位置。对数字资源的检索应该是智能化、交互式的，对全文、多媒体信息、多语言信息的检索都可以达到很好的查全率和查准率。

（4）数字图书馆建立在异构平台上，具有分布、开放的信息结构，高速、可靠的网络环境是其运行的基础。它突破了时间、空间的限制，让用户可以在任何地方、任何时间获取自己所需的信息。在此基础上提供的导航式和个性化的服务，使服务内容更多样、服务模式更广泛，这是对传统图书馆服务功能的突破。

数字图书馆的模式，可以用图1简单说明，用户通过网络和通信系统，连接到数字图书馆的咨询系统，通过这个统一的访问界面，用户可以透明地获取各种信息资源。

附图

图1数字图书馆模式

1.2 UML概述及特点

UML是一种编制系统蓝图的标准化语言，可以对大型复杂的系统的各种成分可视化、说明并构造系统模型，以及建立各种所需的文档。UML通过三类图形建立系统模型：Use Case图、静态结构图（对象类图、对象图、组件图、配置图）和动态行为图（顺序图、协同图、状态图、活动图），这些图可以从不同的抽象角度使系统可视化。UML具有以下特点〔1〕：

（1）面向对象。UML支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念。

（2）可视化，表示能力强。通过UML的模型图能清晰地表示系统的逻辑模型和实现模型，可用于各种复杂系统的建模。

（3）独立与过程。UML是系统建模语言，独立与开发过程。

（4）独立于程序设计语言。用UML建立的软件系统模型可以用Java、VC＋＋、Smalltalk等任何一种面向对象的程序设计来实现。

（5）易于掌握使用。UML图形结构清晰，建模简洁明了，容易掌握使用。

使用UML进行系统的分析和设计，可以加速开发的进程，提高代码的质量，支持动态的业务需求。UML适用于各种规模的系统开发，能促进软件复用，方便地集成已有的系统并有效处理开发中的各种风险。

2 UML在数字图书馆中的应用

UML是一种建模语言，是系统开发的一个组成部分，本身并没有关于开发过程概念的定义和表示符号。UML的创始者Booch、Jacobson和Rumbaugh在Rational公司的支持下综合了多种系统开发过程的长处，提出新的面向对象的开发过程，称为Rational统一过程（RationalUnified Process, RUP）。RUP过程的核心工作流包括：业务建模、需求分析、系统分析与设计、实现、测试和系统配置。下面通过UML来分析并构造数字图书馆模型，并结合Rational统一过程加以描述，图形用Rational Rose工具软件绘制。

2.1数字图书馆的业务建模和需求分析

业务建模和需求分析的目的是对数字图书馆进行评估，采集和分析系统的需求，理解系统要解决的问题，重点是充分考虑系统的实用性。结果可以用一个Use Case模型表达（图2），模型中的活动者代表外部与系统交互的单元，包括用户、图书馆工作人员和外部信息源；UseCase是对系统需求的描述，表达了系统的功能和所提供的服务，包括采购子系统、编目子系统和流通子系统。对于数字图书馆而言，流通子系统还应该考虑到普通书刊流通和电子书刊流通的区别。电子书刊是指内容为数字格式、发行为电子方式、用计算机阅读和存储的电子读物，可以实现普通书刊所没有的全文检索、页面批注、摘要、字体缩放等功能。用户无论何时何地，都可以在线借还，这是数字图书馆服务功能的一个重要组成部分，也是对传统图书馆服务功能的延伸和拓展，其中的关键是流通子系统在实现时必须能对电子书刊的版权、以及可以同时借阅的用户数进行保护和控制。

附图

图2数字图书馆Use Case模型

图2中模型元素之间的实线表示二者存在关联关系，带空心箭头的实箭线说明存在泛化关系，这里有两种情况，一种是一般与特殊的关系，如“流通子系统”与“普通书刊流通”、“电子书刊流通”的关系；另一种是使用关联，表示一个模型元素需要使用另一个模型元素，在箭线上标有＜＜Use＞＞，如“流通子系统”需要使用“编目子系统”生成的书目数据，图2是数字图书馆系统层的Use Case模型，只包含了最基本的Use Case模型，是系统的高层抽象。在开发过程中，随着对系统的认识不断加深，Use Case模型可以从顶向下不断精化，演化出更为详细的Use Case模型。

2.2数字图书馆系统分析与设计

系统分析与设计是研究欲采用的实现环境和系统结构，结果是产生一个对象模型，即设计模型，设计模型包含了Use Case的实现，可以表现对象是如何相互通信和运作来实现Use Case流的。对于系统的静态结构，可以通过对象类图、对象图、组件图和配置图来描述；对于系统的动态行为，可以通过顺序图、协同图、状态图、活动图描绘。这些图再加上支持说明文档就构成一个完整的设计模型。

（1）静态结构的分析与设计

数字图书馆拥有大量数字化信息资源，这些资源是多种媒体、多种格式的，而且还是相互关联的。其数据量大，信息长度不定，非结构化信息与结构化信息并存。传统的数据库和信息管理系统在数据模型、系统结构、用户接口等方面都难以实现对这些数字化信息资源的管理和操作，这就决定了数字图书馆必须采用面向对象的方法来建立数据模型和管理模型，建立面向对象的数据库，实现面向对象的信息管理系统。使用UML对数字图书馆系统进行基于面向对象的分析和设计，可以从开发的第一步开始，从系统的底层就把握住数字图书馆信息资源的特征，为下一步的具体实现打好基础。在为数字图书馆系统建立模型时要涉及到处理大量的模型元素，如对象类、接口、组件、节点、图等，可以将语义上相近的模型元素组织在一起，这就是UML的包，包从较高的层次来组织管理数字图书馆的系统模型。

在详细设计阶段可以对包图中的所有类、对象从实现角度再进一步进行细化，绘制具体的对象类图、对象图等。图3是数字图书馆系统的包图，虚箭线说明包之间的依赖关系，如“流通”包依赖于“数据库”包，要使用“数据库”包中的类及数据。带空心箭头的实箭线说明包之间的泛化关系，这里是一般与特殊的关系，如“编目”包与“本馆编目”包、“联合编目”包之间存在泛化关系。

附图

图3数字图书馆系统包图

（2）动态结构的分析与设计

数字图书馆提供的各种服务都是建立在分布、开放的信息结构之上，依托高速、可靠的网络环境来完成。每项服务都可以看成一个事件流，由若干相关的对象交互合作来完成。对于这种系统内部的协作关系和过程行为，可以通过绘制顺序图和协同图来帮助观察和理解。

一个对象在其生存期间所经历的状态序列，对于把握对象的行为和状态的迁移变化是非常重要的，可以通过状态图来了解一个对象的历史，引起一个状态向另一个状态转移的事件，以及由于状态的转移而引发的动作。

此外，描述工作流和并发处理行为还可以用活动图，表达从一个活动到另一个活动的控制流。

顺序图和协同图适合描述多个对象的协同行为，而状态图适合描述一个对象穿越多个Use Case的行为。状态图与活动图的区别是，状态图描述的是对象类响应事件的外部行为，活动图描述的是响应内部处理的对象类的行为。

附图

图4数字图书馆电子书刊流通服务顺序图

图4是一个电子书刊流通服务的顺序图例子，用以说明数字图书馆电子书刊基本流通服务。用户向流通子系统的用户接口登录，经用户合法性验证后，向流通子系统的电子书刊流通模块提交服务请求，电子书刊需要经过版权和复本的验证，以保证电子书刊的每一个复本在同一时间只允许一个用户借阅或阅读。比如购买了一本电子书的五个复本，那么就可以有五个用户同时借阅或阅读这本书，而且必须能够控制用户对电子书刊的任意复制和打印，以保护电子书刊出版者的合法权益。然后就可以完成电子书刊的借、还、预约、续借等流通服务，最后退出。

通过顺序图可以清晰地看出用户、流通子系统的用户接口和电子书刊流通模块之间按时间顺序的消息交换，这对于把握系统的控制流、顺序行为和交互行为是非常有益的。建立在分布、网络环境下的数字图书馆其事件流和控制流是十分复杂的，需要从层顶到底层进行一步步的分解，用多幅能反映动态结构的图来分析与说明。

2.3数字图书馆的实现、测试和系统配置

经过系统分析与设计后，就可以根据设计模型在具体的环境中实现系统，生成系统的源代码、可执行程序和相应的软件文档，建立一个可执行的系统。然后需要对系统进行测试和排错，保证系统符合预定的要求，获得一个无错的系统实现。测试的结果将确认所完成的系统可以真正使用。最后系统配置的任务是在真实的使用运行环境中配置、调试系统、解决系统正式使用前可能存在的任何问题。

3小结

数字图书馆的发展方兴未艾，目前正处于传统图书馆向数字图书馆过渡的阶段，转变过程中需要应用和集成最新的信息技术，以达到对网络信息资源最有效的利用和共享。传统的系统分析设计的方法难以保证效率和质量，将UML应用于数字图书馆建设，可以加速开发进程，提高代码质量，支持动态的业务需求，并方便地集成已有的传统图书馆信息资源。这是UML一个有着很好前景的应用方向。

【参考文献】

〔1〕张龙详.UML与系统分析设计.人民邮电出版社，2001

〔2〕郑巧英.杨宗英.图书馆自动化新论：信息管理自动化.上海交通大学出版社，1998

〔3〕郑巧英.数字图书馆的一种模式——网络图书馆.现代图书情报技术，2000，（2）

〔4〕陈英.UML多视点建模机制应用研究.北京理工大学学报.2001，（2）

〔5〕于升峰.数字图书馆的关键技术研究.情报学报，1999，（12）

生成uml图要哪些词法语法信息

统一建模语言UML述评

邵维忠梅宏

摘要最近由美国Rational公司发起并与其它十几家公司共同推出的“统一建模语言”UML在OO领域受到广泛的关注.文中首先介绍UML产生的背景及其主要内容，然后评论它对OO建模技术的积极影响以及可能存在的问题.UML是一种表达能力丰富的、强有力的建模语言；然而，目前还不能断定它将取代现有的各种面向对象的分析与设计方法.因为它只是一种建模语言，而不是一种方法；其复杂性可能成为它赢得大量用户的障碍.

关键词面向对象，建模方法，建模语言

中图法分类号 TP311

REVIEW OF THE UNIFIED MODELING LANGUAGE(UML)

SHAO Wei-Zhong and MEI Hong

(Department of Computer Science& Technology,Peking University,Beijing 100871)

Abstract The Unified Modeling Language(UML), published by Rational Software Corporation and other UML partners, is attracting wide attention in the area of object technology. The historical background and the main contents of UML are introduced and then its significance, positive influence and some possible problems are discussed. UML is an expressive and powerful modeling language; however, it cannot be concluded that it would replace all existing object-oriented analysis and design methods. The reason is that UML is only a modeling language rather than a method, and its excessive complexity might become an obstacle to win a great number of users.

Key words object-orientation, modeling method, modeling language

1 UML的背景

由于面向对象的分析与设计（OOA/OOD）方法的重要性日益突出，人们对它的研究、开发和应用的热情也在不断升高.在1989年，以专著、论文或技术报告等形式提出的OOA/OOD方法或OO建模语言有近10种，到1994年，其数量增加到50种以上.各种方法的出现都对OOA/OOD技术的研究与发展作出了或多或少的新贡献.这种“百花齐放”的繁荣局面表明面向对象的方法与技术已得到广泛的认可并成为当前的主流.然而多种方法的同时流行也带来一些问题：各种OOA和OOD方法所采用的概念既有许多共同部分也有一定的差异（例如许多方法在OO基本概念基础上各自提出了一些扩充概念，字面上相同的概念其语义解释也不尽相同）；在表示符号、OOA模型及文档组织等方面差别则更为明显.这种情况往往使一些新用户在进行建模方法及工具的选择时感到难以决策，也不利于彼此之间的技术交流.

鉴于这种情况，1994年同在美国Rational软件公司工作的G.Booch和J.Rumbaugh认为，应该把他们各自提出的方法（Booch方法〔1〕和OMT〔2〕）结合起来，形成一种统一方法.该年10月他们开始了这一工作，并于1995年10月公开发布了第一个版本，即Unified Method 0.8.1995年秋OOSE〔3〕的提出者I.Jacobson加入了Rational软件公司，于是也加入了这一行列.G.Booch，J.Rumbaugh和I.Jacobson共同认为，提出一种统一的建模语言有以下3个理由：第1，他们各自提出的方法在演化中已经有互相结合的趋向；第2，走向统一将带来市场方面的好处；第3，有助于改进他们各自的方法，以获得更多的学习者并解决一些以往在他们各自的方法不能很好解决的问题.

为确定一套用于分析与设计的表示符号，他们遇到了一些需要权衡的问题.一是问题范围的界定.比如；是否应包括需求规约？（回答是，应部分地包括）；是否应包括可视化编程语言？（回答为“否”）.二是必须在表达能力和简单性之间作出折衷.表示法过于简单将使解决问题的能力受到限制，过于复杂则将使普通的开发者不知所措.三是在他们原先的3种方法基础上进行联合，也使他们必须顾忌对原有方法的改动大小；改动过大将引起老用户的混乱，沿用原先的东西则将失去作出改进并嬴得更多新用户的机会.从UML的文献中谈到的这些问题看，UML的提出不是单纯从学术和技术的立场寻找一种最合理的方案，而是必须考虑到与公司、老用户和原先各种方法有关的一些实际背景.

不管怎样，他们作出了在这种背景下他们认为最好的权衡，于1996年6月和10月先后发布了UML 0.9和0.91版本.从此时起，“统一方法”改称为“统一建模语言”（unified modeling language）.因为确切地讲，它并不是一种面向对象的建模方法，而是一种面向对象的建模语言.它只是给出一套用于建模的元素及表示符号并定义了它们的语义，而不是讲述如何进行系统建模.正如M.Fowler在专门介绍UML的著作〔4〕中指出的：“UML被称作建模语言，而不是一种方法.至少从原则上讲，大部分方法是由一种建模语言和一种过程共同组成的.其中建模语言是一种（以图形方式为主的）表示符号，用来表达人们的设计；过程则是对进行这种设计应采取哪些步骤所提出的建议.”M.Fowler的这本书是以UML1.0版本为背景写作的，G.Booch，I.Jacobson和J.Rumbaugh亲自为该书作序.这至少可以表明，该书对UML的这种总体评价是得到其缔造者认可的.

1996年，Rational准备向对象管理组织（Object Management Group，简称OMG）申请将UML作为一种标准建模语言.为此创立了UML伙伴组织，包括Rational本身共有12家公司加入.他们推出了UML1.0版，于1997年1月提交到OMG作为初步的提案申请.1997年另有几家公司分头向OMG提交自己的建模语言提案申请.于是，UML伙伴组织把这些公司也吸收到自己的行列中来.为了反映这些新成员的意见，又对UML1.0进行了修改，于1997年9月1日产生了UML1.1并提交到OMG，同年11月被OMG采纳.目前UML1.1是最新版本，但不是最终版本，因为还在继续进行修改.到UML1.1发布时止参加UML联合行动的有以下17家公司：Rational Software，Microsoft，Hewlett-Packard，Oracle，Sterling Software，MCI Systemhouse，Unisys，ICON Computing，IntelliCorp，i-Logix，IBM，ObjectTime，Platinum Technology，Ptech，Taskon，Reich Technologies和Softeam.

2 UML内容概述

按照UML文件的说法，“统一建模语言（UML）是一种用于软件系统制品规约的、可视化的构造及建档语言，也可用于业务建模以及其它非软件系统.”UML1.1提供了6份文件，均以UML伙伴组织中17家公司的名义联合印发.本节首先简略地介绍这些文件，下一节将对其中的UML表示法指南作较详细的介绍.

（1） UML概要（UML Summary）：是对UML的概括介绍，包括其动机、目标、范围、历史与现状.

（2） UML语义（UML Semantics）：定义了UML的语义.定义采用了形式化技术，但并不是完全形式化的规约.对语法结构给出了精确的规约，对其动态语义则是用自然语言描述的.UML的语法是一种与表示符号无关的抽象语法，它可以映射到不同的符号体系中.尽管没完全形式化，但其定义方式也颇为复杂：采用了4级元模型体系结构，文本的篇幅达到160余页.在该文件的2.2节介绍了模型的4个级别，即：

①元-元模型（meta-metamodel）：元模型的基础体系结构，定义一种说明元模型的语言.

②元模型（metamodel）：元-元模型的一个实例，定义一种说明模型的语言.

③模型（model）：元模型的一个实例，定义一种语言来描述信息领域.

④用户对象（user object）：模型的一个实例，定义一个特定的信息领域.

对各级模型元素的定义方式是，首先给出它的抽象语法（采用UML的类图表示法描述元素之间的关系），然后给出其形式化规则（采用正文和对象约束语言），最后描述其语义（采用准确的正文）.按这种方式总共定义了118个元素，划分到3个部分和9个包（package）中分别加以定义.

（3） UML表示法指南（UML Notation Guide）：该文件给出UML的可视化表示法，通过例子给出模型元素的图形表示符号，详见下一节.

（4）对象约束语言规约（Object Constraint Language Specification）：该文件定义并介绍了一种对象约束语言（简称OCL），其用途是用来说明一些在图形化的系统模型中不能充分表达的建模信息.它是一种形式化的语言，但容易书写和阅读.作为一种建模语言，它并不表示实现方面的问题.就是说，它是用来对模型作详细说明的，而不是可编译执行的.

（5）用于软件工程对象过程的UML扩充（UML Extension for Objectory Process for Software Engineering）：针对软件工程中的要求，定义了一些UML的扩充概念.例如，将模型分为Use Case模型、分析模型、设计模型和实现模型4种，对每一种扩充的模型概念给出其定义.它并未介绍面向对象的开发过程，也不讲在过程中如何运用UML.文件内容很短，只有5页.

（6）用于业务建模的UML扩充（UML Extension for Business Modeling）：定义了用于业务建模的一些UML扩充概念，与上一个文件相似，只是它的扩充是针对一般业务处理建模，而不是对软件工程的.该文件也很短.

3 UML表示法指南

该文件给出UML的可视化表示法，通过例子给出模型元素的图形表示符号.从系统模型这一级别上看，UML表示法由9种图构成，它们是：

静态结构图（Static Structure Diagram），其中包括类图（Class Diagram）和对象图（Object Diagram）；

Use Case图（Use Case Diagram）；

顺序图（Sequence Diagram）；

协作图（Collaboration Diagram）；

状态图（Statechart Diagram）；

活动图（Activity Diagram）；

实现图（Implementation Diagram），其中包括成分图（Component Diagram）和展开图（Deployment Diagram）两种图.

尽管UML文件称“UML表示法指南定义了表示法并提供了例子”，但确切的说法应该是：该文件对建模元素的表示法给出了一般的文字描述，其图形的画法是通过例子表现的，并没有给出一般的图示.本文大部分插图是参照M.Fowler的著作〔4〕的作法从一般意义上给出的.

UML定义了一些在各种图中常用的元素，例如String（串）、Name（名）、Label（标签）、Keyword（关键词）、Expression（表达式）、Note（注释条）等，并给出它们的表示符号，例如关键词由一个被书名号括起的串表示，注释条用一个折起一角的长方形内的正文表示.在各种图中用来对一组模型元素打包的元素叫做“包”（Package），其表示法是用一个大的方框围起这组元素，并在角上用一个小框给出包的名字.

此外，UML还定义了一些称作“扩充机制”的元素.这种元素可以附加到其它模型元素之上，将原有的建模元素特化成一种语义较特殊的新变种，或者表示出它们的某些细节.这些元素可以起到对表示法进行扩充或细化的作用，它们是：

Constraint（约束）：约束是模型元素之间的一种语义关系，它说明了某种条件和某些必须保持为真的命题.其表示法是在大括号{}之间用一种工具能识别的语言（如UML提供的OCL）写出表示条件的正文串.

Comment（注释）：注释是写在注释条表示符号（折起一个角的长方形）之内的正文串.所使用的语言应易于人的理解，不必考虑被工具理解.

Element Property（元素特征）：用来显示模型元素的一些附带特征，如属性、关联、目标值等.其表示法是在大括号{}内写出形式为关键词=值的正文串，多个串之间彼此用逗号隔开.

Stereotype（版式）：用来附加到其它模型元素之上，将原有的建模元素特化成一种语义较特殊的新变种.带有版式的建模元素可看作原先建模元素的一个子类，它在属性、关系等方面与原先的元素形式相同，但用途更为具体.板式是用书名号《》括起来的关键字表示的.上述概念的表示法如图1所示.

图1图元素、包和扩充机制

以下分别介绍各种图以及图中用到的建模元素与表示法.

（1）静态结构图

静态结构图包括类图（class diagram）和对象图（object diagram）.“类图是静态结构模型的图形化示图.”“类图是（静态）声明的模型元素集合.”关于对象图，该文献中说道：“对象图是实例的一种图形，包括对象和数据的值，静态的对象图是类图的一个实例；它显示了在一个时间点上系统细节状态的一个快照”.该文献又指出：“对象图的用处是很有限的”，“工具没有必要支持独立形式的对象图.类图能包括对象，一个有对象而没有类的类图便是一个‘对象图’.不过这个术语对于刻画在各种方式下可能达到的特殊用法还是有用的”.静态结构图中用到的各种建模元素的表示法如图2所示，以下分别加以介绍.

图2静态结构图中的建模元素表示法

Class（类）：类是对具有相似的结构、行为和关系的一组对象的描述.UML对类提供了3种图形表示符.第1种是细节抑制方式，只在一个方框中给出类名；第2种是分析级细节方式，在上、中、下3栏分别给出类名、属性名与类型、操作名；第3种是实现级细节方式，给出更多的细节.

Name Compartment（名字栏）：定义了类符号的名字栏的书写规范.

List Compartment（列表栏）：定义了类符号的属性栏和操作栏的书写规范.

Attribute（属性）：规定了属性的写法，以及以下3种可见性符号：“+”表示public（公共），“#”表示protected（保护），“-”表示private（私有）.

Operation（操作）：规定了操作的写法，采用与属性相同的3种可见性符号.

Type vs. Implementation Class（类型与实现类）：这是将版式关键词《type》或《implementation class》附加到类表示符号之上，并在属性栏和操作栏中给出属性与操作的定义细节而得到的两种较特殊的类元素.其中“类型”刻画一个对象可能采用然后又放弃的可变规则；“实现类”定义了在用一种语言实现时对象的物理数据结构与过程.以下7种表示符号都是用这种方式得到的.

Interface（接口）：接口是对一个类或其它实体（诸如包这样的大单位）的对外可见操作的说明，它不说明实体的结构.其表示法很像类符号，但没有属性栏；在名字栏中加关键词《interface》，在操作栏填写接口定义.

Parameterized Class（Template）（参数化类，又称模板）：它是带有一个或多个未绑定的形式参数的类，因此它定义一个类家族，将参数与一个实际值绑定便说明了其中一个类.参数化类的表示法是在类符号的右上角加一个虚线框，框内中说明各个形参的不同实现类型.

Bound Element（绑定元素）：它的作用是将模板的参数与实际的值联系（绑定）.其表示法是用文字说明模板的参数值表.

Utility（实用程序）：以类的形式声明的一组全局变量与过程.它不是一种基本构造，而是一种编程便利设施.其表示法是在类符号的类名栏中标以关键字《utility》.

Metaclass（元类）：即类的类，它的实例是类.其表示法是在类名栏中加关键词《metaclass》.

Class Pathname（类路径名）：用以表示对一个类的引用.表示法是在引用这个类的地方（在其它包中）以符号“∷”指出被引用的类名.

Importing a Package（引入一个包）：表明在一个包中可以引用另一个包中的类.这是一种特殊的依赖（dependency）关系.其表示法是在dependency符号（虚箭头）上旁加关键字《import》.

Object（对象）：对象是类的一个特殊实例.UML给出的对象表示法是一个只有两栏的方框.名字栏填写对象（实例）名并指出它所属的类名.属性栏中给出每个属性的值.

Composite Object（组合对象）：由一些紧绑在一起的部分所构成的高层对象，它是组合类（composite class）的实例.用含有两栏的方框表示，在上栏填写组合对象名并指出其类名，在下栏画出它的各个部分对象.

Association（关联）：分为二元关联和多元关联，在以下的条目中分别介绍.

Binary Association（二元关联）：是两个类之间的关联（包括从一个类到它自身的关联这种特殊情况）.其表示法是用一条实线连接两个类符号.这条线可根据绘图时的方便画成平直的、斜的或弯曲的.也可由若干段组成.线的端点与类符号相接的地方叫作关联端点，端点附近可以注明一些有用的信息，表明关联的不同情况（稍后介绍）.整个关联也可以带有一些附加信息，包括：关联名（association name），通过这样的命名表明关联的作用；关联类（association class）符号，和普通的类符号相同，但必须附着在一个关联上，用于表明关联的属性与操作.这些东西都是任选的、非强制的.

AssociationEnd（关联端点）：关联端点不是独立的元素，它是关联的一部分，用于表明关联的一些细节内容.一部分细节内容通过在关联端点旁边附加一些字符或图形来表示，包括多重性（multiplicity）、有序性（ordering）、限制（qualifier）、角色名（rolename）、可变性（changeability）、可见性（visibility）.另一些细节是通过关联线端点的不同形状来表示的，包括：开放形的箭头表示可导航性（navigability），即表示从关联一端的对象实例能够找到另一端与它关联的对象实例；空心的菱形箭头表示聚合（aggregation），即表示关联一端的对象实例是另一端对象实例的组成部分；实心的菱形箭头表示强形式的聚合关系，称作组装（composition）.

Multiplicity（多重性）：在关联端点上标注数字（表示具体的数量）或“*”号（表示多个），以表明本端有多少个对象实例与另一端的对象实例相关联.

Qualifier（限制），在关联的一端与类符号相接口的地方画一个矩形框，框中给出一些属性值指明关联另一端的对象符合什么条件才有资格与本端的对象关联，它是关联的一部分，而不是类的一部分.

Association Class（关联类），用于表明一个关联带有类的特征（包括属性和操作），用普通的类符号表示，附着在关联线上.

N-Ary Association（多元关联），3个以上的类之间的关联.其表示法是从一个菱形向各个相关联的类符号画出连接线.

Composition（组装）按UML的说法，composition是aggregation的形式之一，它表示整体对部分有很强的拥有关系和相同的生存时间.其表示法是在关联线的端点加一个实心的菱形箭头.

Link（链），链是关联的一个实例，表明两个对象之间的联系.其表示法是在两个对象实例之间画一条直线.

Generalization（一般化）：“是较为一般的元素和与之完全一致而又增加了更多信息的较为特殊元素之间的分类学关系.”此概念和大部分OO技术文献中所讲的“继承关系”或“一般特殊关系”基本相同，不过，UML的generalization除用于表示类之间的关系外还用于包、Use Case和其它元素.表示法有两种方式.一种是共享方式，在一般元素的符号旁边画一个三角形，从三角形的底边引出一条连线，而这条连接有若干分枝，分别连向各个特殊元素；另一种是分散式，在一般元素的符号旁边画多个三角形，每个三角形的底边画出引向一个特殊元素的连线.在连线旁边可以加一个文字标注，叫做discriminator（鉴别器），标明是按什么进行分类的.

Dependency（依赖）：UML对dependency的语义是这样定义的：“指出两个（或多个）模型元素之间的语义关系.其涵义只涉及这些元素本身而不涉及他们的实例.它指出在这种依赖中对目标元素的一个改变可能需要对源元素的一个改变.”依赖有以下几种：

trace-Trace：在不同的表意层次上表示同一概念的两个元素之间的一种历史连接.

refine-Refinement：两个有映射（未必完全）关系的元素之间的历史或衍生连接.

use-Usage：为了一个元素的正确实现或功能履行需要另一个元素出现.

bind-Binding：将模板参数绑定到一个实际的值，以创建一个非参数化元素.

依赖的表示法是在两个模型元素之间画一条带箭头的虚线，旁边可以标明该依赖关系属于以上哪一种，也可加一个名字.UML表示法指南在介绍dependency时没有谈到它与message（消息）的概念有什么联系和区别.UML的“消息”、“消息流”等概念分别用于顺序图和协作图（详见后文），而不用于类图.但是M.Fowler在文献〔4〕中作了这样的解释：“对类而言，dependency可以为如下几种理由而存在：一个类向其它类发送消息；一个类以其它类作为其数据的一部分；一个类提及其它类作为对一个操作的参数.”

Derived Element（派生元素）：派生元素是可以从其它元素计算出来的元素.尽管它没有增加语义信息，但是有了它可以更清楚或者更有利于设计.其表示法是在派生元素的名字前加一条斜线“／”.

（2） Use Case图

“use case图用于表现活动者与use case之间的关系.”“use case模型表现一个系统或一个类对于系统外部的交互者的功能.”UML定义了如下几种构成use case图的元素(如图3).

图3 Use Case图

Use Case：一个use case是一个系统或一个类提供的紧凑的功能单元，它是由系统与一个或多个外部交互者（即活动者）之间交换的消息序列以及系统执行的活动共同体现的.

Actor（活动者）：活动者是直接与系统交互的外部对象所扮演的角色.

Use Case Relationship（use case关系），包括如下3种关系：communicates（通信），这是活动者与use case之间仅有的关系，是活动者对use case的参与；extends（延伸），从use case A到use case B的延伸关系表明B的实例（在延伸说明的特殊条件下）可能包含了在A中说明的行为；uses（使用）：从A到B的使用关系表明A的实例也包括了在B中说明的行为.

（3）顺序图

UML给出了两种形式的交互图（Interaction Diagram），一种叫顺序图，另一种叫协作图.它们基于相同的基本信息但强调不同的方面.顺序图（Sequence Diagram）展示按时间顺序排列出来的交互.特别是，它展示对象在其“生命线”上参加的交互和它们按时间顺序交换的消息.它不展示对象之间的关系.顺序图所表示的交互是一组在对象之间为产生所要求的操作或结果而进行合作时所交换的一组消息.顺序图有简单形式和详细形式两种画法，后一种画法与OOSE〔3〕等著作介绍的交互图大体一致——在水平方向展示各个参加交互的对象，垂直方向表示时间；整个平面显示各个对象之间进行交互的时间及空间关系，顺序图如图4所示.用于顺序图的建模元素有：

图4顺序图

Object Lifeline（对象生命线）：一条垂直的虚线，用于展示对象在从创建到撤消的时间范围内所扮演的角色.

Activation（活动期）：展示对象直接地或通过其下级过程执行一个活动的时间段.

Message（消息）：消息是对象之间的一次通信，用于传送信息并期望发生某种活动.消息的接收是一种事件.

Transition Time（过渡时间）：消息发送或接收所用的时间.二者可能相同也可能不同.

（4）协作图

协作图（Collaboration Diagram）是UML所说的另一种交互图，它表示在一些对象之间组织的操作和它们之间的链.与顺序图不同的是，协作图表示的是对象角色之间的关系，而不表示时间顺序.协作图描绘了在特定上下文中一组相关对象之间的协作，以及这组对象为产生所要求的操作或结果而进行协作时所交换的一组消息.协作图的图形表示以对象为结点，结点之间既有表示消息的箭头连线，也有表示关联的连线.消息连线有3种，分别表示调用、控制流和异步3种不同的消息，但仍有一些不能表示的情况，如阻塞（balking）和超时（time out）等，需要用一些进一步扩充的表示符号.协作图中使用的关联符号也包括多种不同的端点情况，如qualifier和composition等等.协作图如图5所示.

图5协作图

UML表示法指南为协作图定义的概念或建模元素有：Collaboration（协作）、Collaboration Content（协作内容）、Interaction（交互）、Pattern Structure（模式结构）、Collaboration Role（协作角色）、Multiobject（多对象）、Active Object（主动对象）、Message Flows（消息流）、Creation/Destruction Markers（创建/折构标记），这里不再一一介绍.

（5）状态图

状态图（Statechart Diagram）在UML中也称作状态机，它表现一个对象或一个交互在整个生存期内接受剌激时的状态序列以及它的反应与活动.它附属于一个类或一个方法.建立状态图所用的建模元素有：State（状态）、Composite State（复合状态）、Substate（子状态）、Event（事件）、Simple Transition（简单转换）、Complex Transition（复杂转换）、Nested State（嵌套状态）、Sending Message（发送消息）、Internal Transition（内部转换）等.状态图及其有关元素的表示法和现有的大部分OOA／OOD方法大同小异，这些不再详述.

（6）活动图

活动图（Activity Diagram）是状态图的变种，它的状态表示操作所执行的活动（activity），其转换（transition）是由操作的完成而触发的.它表示了一个过程本身的状态机，过程是对类中一个操作的实现.构成活动图的元素有：Action State（活动状态）、Decision（判断）、Swimlane（泳道，在图中画出来就象游泳池中的泳道，把各个活动组放在不同的泳道中以便更加清晰）、Action-Object Flow Relationship（活动-对象流关系，表示一个活动与有关对象之间的消息和输入/输出关系）、Control Icon（控制图符，表示信号的发送与接收）等.活动图如图6所示.

图6活动图

（7）实现图

实现图（Implementation Diagram）表现实现方面的问题，包括源代码结构和运行时的实现结构.实现图分为两种，一种是表示代码自身结构的成分图，另一种是表示运行时系统结构的展开图.

成分图（Component Diagram）表示源代码、二进制代码及可执行代码等软件成分之间的依赖关系.各种软件模块在图?/ca>

画ER图常用工具是什么

一、画ER图常用工具是Microsoft Visio或者亿图图示软件绘制出实用的ER图表

二、Microsoft Visio是Windows操作系统下运行的流程图和矢量绘图软件，它是Microsoft Office软件的一个部分；亿图图示是一款基于矢量的绘图工具，可以绘制各种程序流程图、数据流程图、软件设计图。

扩展资料：

关系模型转化：

1:1关系的话在两个实体任选一个添加另一个实体的主键即可。

1:N关系的话将联系转换为一个独立的关系，其关系的属性由与该联系相连的各实体集的码以及联系本身的属性组成，而该关系的码为n端实体集的码；

m:n联系转换为一个关系,与该联系相连的各实体集的码以及联系本身的属性均转换为关系的属性，新关系的码为两个相连实体码的组合。

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！