软件公司UML模型映射 映射模型
UML建模软件是干什么的.
首先咱们先一个一个来查阅定义（这里我引用百度百科的部分总结性定义）用例视图：用例视图（Use Case View）是被称为参与者的外部用户所能观察到的系统功能的模型图。
用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。
类图：在UML的静态机制中类图是一个重点，它不但是设计人员关心的核心，更是实现人员关注的核心。
协作图/用例模型：作为客户和开发人员之间的契约。
用例是贯穿整个系统开发的一条主线。
同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。
系统模型：面向计算机世界，描述如何用系统解决问题首先从对应的阅读对象来看：开发人员关心的：用例视图，类图，协作图/用例模型，系统模型产品经理们关心的：协作图/用例模型，系统模型，用例视图客户关心的：系统模型，协作图/用例模型那么从大小涉及面来看（我想描述的类似人的整个身体与最小的细胞的对比层次）：系统模型>协作图/用例模型>用例视图>类图类图，或者说生产过程来讲大部分实际过程中也是按照这个顺序来的.用普通的白话文来讲：系统模型就像是：客户的一个想法，然后被产品经理扩散成了对应的需求文档.（实际过程中，中小型公司在该阶段其实就是一句话甚至一个想法，而系统模型仅仅是我们大致怎么去实现这个内容.例如：我们用OA处理贵公司的XXXX用CRM+OA的基础数据+XXXX实现贵公司的YYYY）协作图/用例模型：有了这个想法后，产品经理通过自己对产品的熟悉程度等，绘制了对应的操作界面.给客户去看.这个软件大致会成为什么样子.（大部分实际操作过程中，中小型公司都会在这个阶段产生第一部分的UI设计初稿）用例视图：被称为参与者的外部用户所能观察到的系统功能的模型图。
用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用。
用来拆分协作图的具体某一个功能（在大部分中小型企业的实际过程中，这里被项目经历的＂概要设计涵盖＂.）类图：这里就比较明显了.我需要实现上述内容.需要哪些东西.总结来看：反序来看它-->N个类图组成或实现了一个用例.不同的交互用例，在互相沟通，调用后，组成了一个用例模型/协作.不同的协作（就像公司不同的部分），运作起来以后，构成了一个系统模型（组成了一个公司）.一个完整的系统模型，处理了某一件具体的事情（例如某公司生产了某产品）.正序来看他->您是一个老板，需要开一个工厂，然后策划公司开始筹备所需内容，首先列举了一个清单->得有个库房，还得有机床，工人开始具体的步骤，采购，招聘->协作图：大家租房子的租房子，买机床的买机床，招聘工人的招聘那么具体怎么采购/招聘/租房子呢？->用例图：如何实现租房子，如何实现买机床，如何实现招聘工人行动起来吧->类图：具体的函数就出来了.对应类有对应方法，只需调用则实现了对应的功能.整体来看->实现了这个系统模型
UML模型的基本概念是什么？
、事物（Things） 2、关系（Relationships） 3、图（Diagams）事物是UML中重要的组成部分。
关系把事物紧密联系在一起。
图是很多有相互相关的事物的组。
1.1 UML的事物UML中有始终类型的事物： 1、结构事物（Stuctual things） 2、动作事物（Behavioal things） 3、分组事物（Gouping things） 4、注释事物（Annotational things）这些事物是UML模型中最基本的面向对象的建筑块。
它们在模型中属于最静态的部分，代表概念上等或物理上的元素。
1.1.1结构事物。
总共有七种结构化事物。
首先是类（class），类是描述具有相同属性、方法、关系和语义的对象的集合。
一个类实现一个或多个接口。
在UML 中类被画为一个矩型，通常包括它的名字、属性和方法。
WindowOigin SizeOpen()Close()Move()Display（) 图1-1 类第二种是接口（inteface），接口是指类或组件提供特定服务的一组操作的集合。
因此，一个接口描述了类或组件的对外的可见的动作。
一个接口可以实现类或组件的全部动作，也可以只实现一部分。
接口在UML 中被画成一个圆和它的名字。
图1-2 接口 第三种是协作（collaoation），协作定义了交互的操作，是一些角色和其它元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。
因此，协作具有结构化、动作化、维的特性。
一个给定的类可能是几个协作的组成部分。
这些协作代表构成系统的模式的实现。
协作在UML 中用一个虚线画的椭圆和它的名字来表示。
图1-3 协作 第四种是use case,use case是描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。
在模型中use case通常用来组织动作事物。
Use case是通过协作来实现的。
在UML 中，use case画为一个实线椭圆，通常还有它的名字。
图1-4 use case 第五种是活动类（active class），活动类是这种类，它的对象有一个或多个进程或线程。
活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的。
在UML 中活动类的画法和类相同，只是边框用粗线条。
EventManageSuspend()Flush（)图1-5 活动类 第六种是组件（component），组件是物理上或可替换的系统部分，它实现了一个接口集合。
在一个系统中，你可能会遇到不同种类的组件，例如COM+ 或JAVA BEANS。
组件在UML中用如下的图表示：图1-6 组件 第七种是结点（node），结点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
一个组件集合一般来说位于一个结点，但有可能从一个结点转到另一个结点。
结点通常用如下的图形表示： 图1-7结点 类、接口、协作、use case、活动类、组件和结点这七个元素是在UML 模型中使用的最基本的结构化事物。
系统中还有这七种基本元素的变化体，如角色、信号（某种类），进程和线程（某种活动类），应用程序、文档、文件、库、表（组件的一种）。
1.1.2 动作事物动态事物是UML 模型中的动态部分。
它们是模型的动词，代表时间和空间上的动作。
总共有两种主要的动作事物。
第一种是ineaction,inteaction是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。
inteaction中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作），连接（对象之间的连接）。
在UML 中消息画成带箭头的直线，通常加上操作的名字。
图1-8 消息 第二种是状态机（state machine），状态机由一系列对象的状态组成。
在UML 中状态表示为下图： 图案1-9 状态 inteaction和状态机是UML 模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。
1.1.3 分组事物分组事物是UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。
总共只有一种分组事物，称为包（package）。
包是一种将有组织的元素分组的机制。
结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。
与组件（存在于运行时）不同的是包纯粹是一种概念上的东西，只存在于开发阶段。
在UML 中用如下图表示包： 图 1-10 包1.1.4 注释事物注释事物是UML模型的解释部分。
UML中用如下图表示： 图 1-11 注释 1.1.5 UML中的关系UML中有四种关系：1. 依赖（Dependencies） （图1-12 依赖） 2. 关联（Association）（图 1-13 关联） 3. 一般化（genealization）（图1-14 一般化） 4. 实现（ealuzation）
UML
好像还真没有。
就算有钱好像也买不到。
号称最牛B的 rational rose 其实只能支持 jdk1.4 1.5以上就报废了。
我的感觉真是难用。
我用过最好用的是 StarUMLStarUML 开源的。
正向工程 逆向工程都可以优点是简单好用。
我用过的的工具里面最好用的。
最大的缺点是不支持 衍型。
如果你的类里有一个 ArrayList或者其他 就不行了。
astah_professional可以支持jdk1.5以上的逆向工程。
但你要在网上搜索破解补丁。
你搜一下 astah_professional 破解版就行了。
trufun 不了解。
因为它是以eclipse 插件的方式运行的，它的eclipse版本总是老版本。
所以我没怎么用过。
不了解。
另外类图生成时序图是不可能的。
时序图其实表现的是方法的调用关系，目前只能靠肉眼观察吧。
即使肉眼观察的话，不搞清整个程序的结构也是画不准确的，想想都难，计算机自动实现更不可能了。
其实，生成类图后再画时序图就简单多了，因为模型里已经有类了。
你首先创建一个时序图，把类用鼠标拉进来，相应的元素就自动生成了。
只要类图生成的准确，其它模型都很简单的。
另外，准确的叫法是“顺序图”，时序图的说法过时了。
还有分吗？
UML在软件开发中各个阶段的作用和意义
统一建模语言（UML是 Unified Modeling Language的缩写）是用来对软件密集系统进行可视化建模的一种语言。
UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
统一建模语言 （UML）是非专利的第三代建模和规约语言。
UML是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。
UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。
UML可以贯穿软件开发周期中的每一个阶段。
被OMG采纳作为业界的标准。
UML最适于数据建模，业务建模，对象建模，组件建模。
UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。
当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。
IBM的Rational Rose和MS的Visio都是UML工具。
同时还有一些免费的UML工具：http://java-source.net/open-source/uml-modeling一. 标准建模语言UML的出现 公认的面向对象建模语言出现于70年代中期。
从1989年到1994年，其数量从不到十种增加到了五十多种。
在众多的建模语言中，语言的创造者努力推崇自己的产品，并在实践中不断完善。
但是，OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于是爆发了一场“方法大战”。
90年代中，一批新方法出现了，其中最引人注目的是Booch 1993、OOSE和OMT-2等。
Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念。
1991年，他将以前面向Ada的工作扩展到整个面向对象设计领域。
Booch 1993比较适合于系统的设计和构造。
Rumbaugh等人提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。
这种方法用对象模型、动态模型、功能模型和用例模型，共同完成对整个系统的建模，所定义的概念和符号可用于软件开发的分析、设计和实现的全过程，软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。
OMT-2特别适用于分析和描述以数据为中心的信息系统。
Jacobson于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。
用例的概念是精确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证。
OOSE比较适合支持商业工程和需求分析。
此外，还有Coad/Yourdon方法，即著名的OOA/OOD，它是最早的面向对象的分析和设计方法之一。
该方法简单、易学，适合于面向对象技术的初学者使用，但由于该方法在处理能力方面的局限，目前已很少使用。
概括起来，首先，面对众多的建模语言，用户由于没有能力区别不同语言之间的差别，因此很难找到一种比较适合其应用特点的语言；其次，众多的建模语言实际上各有千秋；第三，虽然不同的建模语言大多雷同，但仍存在某些细微的差别，极大地妨碍了用户之间的交流。
因此在客观上，极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上，组织联合设计小组，根据应用需求，取其精华，去其糟粕，求同存异，统一建模语言。
1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。
他们首先将Booch 93和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 0.8(Unitied Method)。
1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。
经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 0.9和UML 0.91，并将UM重新命名为UML(Unified Modeling Language)。
1996年，一些机构将UML作为其商业策略已日趋明显。
UML的开发者得到了来自公众的正面反应，并倡议成立了UML成员协会，以完善、加强和促进UML的定义工作。
当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。
这一机构对UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定义和发布起了重要的促进作用。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
它溶入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
面向对象技术和UML的发展过程可用图形来表示，标准建模语言的出现是其重要成果。
在美国，截止1996年10月，UML获得了工业界、科技界和应用界的广泛支持，已有700多个公司表示支持采用UML作为建模语言。
1996年底，UML已稳占面向对象技术市场的85%，成为可视化建模语言事实上的工业标准。
1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。
UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。
UML是一个标准的图形表示法，它不是面向对象的分析和设计，...
UML建立模型有哪些？模型都包括些什么？我想请问一下有关UML建
UML模型包括 用例模型：包括系统需求 分析模型：把用例提炼为概念对象之间的协作，定义中设计和实现中的结构和行为 设计模型：确定了所有的类、子系统、接口和构件。
实施模型：描述物理的计算机结构及将构件分配到不同的网络节点。
实现模型：包括所有的构件（文件和可执行文件） 测试模型：测试用例和测试过程 UML提供类9种图： 用例图、类图、对象图、顺序图、协作图、状态图、动作图、构件图、实施图
UML 怎么学呀？ 现在比较流行的UML工具都有什么？
统一建模语言UML 软件工程领域在1995年至1997年取得了前所未有的进展，其成果超过软件工程领域过去15年来的成就总和。
其中最重要的、具有划时代重大意义的成果之一就是统一建模语言（UML:Unified Modeling Language）的出现。
在世界范围内，至少在近10年内，UML将是面向对象技术领域内占主导地位的标准建模语言。
采用UML作为我国统一的建模语言是完全必要的：首先，过去数十种面向对象的建模语言都是相互独立的，而UML可以消除一些潜在的不必要的差异，以免用户混淆；其次，通过统一语义和符号表示，能够稳定我国的面向对象技术市场，使项目根植于一个成熟的标准建模语言，从而可以大大拓宽所研制与开发的软件系统的适用范围，并大大提高其灵活程度。
统一建模语言（UML）是用来对软件密集系统进行描述、构造、视化和文档编制的一种语言。
首先，也是最重要的一点，统一建模语言融合了Booch、OMT和OOSE方法中的概念，它是可以被上述及其他方法的使用者广泛采用的一门简单、一致、通用的建模语言。
其次，统一建模语言扩展了现有方法的应用范围。
特别值得一提的是，UML的开发者们把并行分布式系统的建模作为UML的设计目标，也就是说，UML具有处理这类问题的能力。
第三，统一建模语言是标准的建模语言，而不是一个标准的开发流程。
虽然UML的应用必然以系统的开发流程为背景，但根据我们的经验，不同的组织，不同的应用领域需要不同的开发过程。
举个例子来说，开发错综复杂的软件是非常有趣的工作，但开发这种软件与构造严格实时的航空电子系统是大不一样的，后者是性命攸关的大事。
因此我们首先把精力集中在设计通用的元模型上（统一不同方法的语义），其次是建立通用的表示法（提供对这些语义的形象化的表达）。
虽然UML的开发者们将继续倡导从用例驱动到体系结构为中心最后反复改进、不断添加的软件开发过程，但实际上设计标准的开发流程并不是非常必要的。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
它溶入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
面向对象技术和UML的发展过程可用上图来表示，标准建模语言的出现是其重要成果。
在美国，截止1996年10月，UML获得了工业界、科技界和应用界的广泛支持，已有700多个公司表示支持采用UML作为建模语言。
1996年底，UML已稳占面向对象技术市场的85%，成为可视化建模语言事实上的工业标准。
1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。
UML代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。
标准建模语言UML的内容 首先，UML融合了Booch、OMT和OOSE方法中的基本概念，而且这些基本概念与其他面向对象技术中的基本概念大多相同，因而，UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言；其次，UML不仅仅是上述方法的简单汇合，而是在这些方法的基础上广泛征求意见，集众家之长，几经修改而完成的，UML扩展了现有方法的应用范围；第三，UML是标准的建模语言，而不是标准的开发过程。
尽管UML的应用必然以系统的开发过程为背景，但由于不同的组织和不同的应用领域，需要采取不同的开发过程。
作为一种建模语言，UML的定义包括UML语义和UML表示法两个部分。
（1） UML语义 描述基于UML的精确元模型定义。
元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。
此外UML还支持对元模型的扩展定义。
（2） UML表示法 定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。
这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。
标准建模语言UML的重要内容可以由下列五类图（共9种图形）来定义： ·第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。
·第二类是静态图（Static diagram），包括类图、对象图和包图。
其中类图描述系统中类的静态结构。
不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。
类图描述的是一种静态关系，在系统的整个生命周期都是有效的。
对象图是类图的实例，几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
包由包或类组成，表示包与包之间的关系。
包图用于描述系统的分层结构。
·第三类是行为图（Behavior diagram），描述系统的动态模型和组成对象间的交互关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常，状态图是对类图的补充。
在实用上并不需要为所有的类画状态图，仅为那些有多个状...
- 上一篇：音乐波动软件 手机音乐波动特效软件
- 下一篇：买视频会议软件 视频会议软件 免费
-