uml建模工具

来自: IBM Rational Edge 　 现在是二月，而且到如今你或许已经读到、或听到人们谈论UML 2.0 —— 包括若干进步的 UML 的新规范，所做的变化。考虑到新规范的重要性，我们也正在修改这个文章系列的基础，把我们的注意力从 OMG 的 UML 1.4 规范，转移到 OMG 的已采纳 UML 2.0草案规范（又名 UML 2）。我不喜欢在一系列文章的中间，把重点从 1.4 变为 2.0 ，但是 UML 2.0 草案规范是前进的重要一步，我感觉需要扩充文字。 由于一些理由，OMG 改良了 UML 。主要的理由是，他们希望 UML 模型能够表达模型驱动 架构 （MDA），这意味着 UML 必须支持更多的模型驱动的符号。同时， UML 1.x 符号集合有时难以适用于较大的应用程序。此外,为了要使图变成更容易阅读，需要改良符号元件。（举例来说，UML 1.x 的模型逻辑流程太复杂，有时不可能完成。对UML 2 中的序列图的符号集合的改变，已经在序列化逻辑建模方面取得巨大的进步)。 注意我上面所述的文字：“已采纳UML2.0草案规范。”确实，规范仍然处于草案状态，但是关键 是草案规范已经被 OMG 采用，OMG是一个直到新标准相当可靠，才会采用它们的组织。 在 UML 2 完全地被采用之前，规范将会有一些修改，但是这些改变应该是极小的。主要的改变将会是在 UML 的内部 ——

目录 1、啥是UML类图？ 2、UML类图有啥用？ 3、正式理解UML类图 4、使用idea画第一个UML类图 5、类之间的关系图【必须牢记】 6、类之间的关系 6.1、依赖 6.2、泛化 6.3、实现 6.4、关联 6.5、聚合 6.6、组合 7、简单总结类之间的六种关系 前言 关于UML类图的这篇文章，我觉得把它放在设计模式专栏的篇首最为合适，因为在学习设计模式的时候，经常会遇到有关UML类图，没有去专门学过的童鞋肯定会感觉很复杂。学到后面，发现不掌握UML类图，对设计模式或者某一个框架没有整体的把控。所以学好UML类图，你将会更加有自信！ 如果你对类之间的依赖、聚合、关联、组合等关系还很抵制的话，那么这篇文章就很有必要看了，随着对设计模式的慢慢深入了解，或许你也会发现，UML类图就显得格外重要了，是的，UML类图主要是用来描述类之间的轮廓图，而类之间的常见关系就是泛化（Generalization）、实现（Realization）、依赖（Dependence）、关联（Association）、聚合（Aggregation）、组合（Composition）等。类之间关系的强弱：依赖 < 关联 < 聚合 < 组合 < 泛化（继承） @ 1、啥是UML类图？ 首先来看一个专业一点的定义【来自维基百科】 UML即 统一建模语言 （Unified Modeling Language）

前言 关于UML类图的这篇文章，我觉得把它放在设计模式专栏的篇首最为合适，因为在学习设计模式的时候，经常会遇到有关UML类图，没有去专门学过的童鞋肯定会感觉很复杂。学到后面，发现不掌握UML类图，对设计模式或者某一个框架没有整体的把控。所以学好UML类图，你将会更加有自信！ 如果你对类之间的依赖、聚合、关联、组合等关系还很抵制的话，那么这篇文章就很有必要看了，随着对设计模式的慢慢深入了解，或许你也会发现，UML类图就显得格外重要了，是的，UML类图主要是用来描述类之间的轮廓图，而类之间的常见关系就是泛化（Generalization）、实现（Realization）、依赖（Dependence）、关联（Association）、聚合（Aggregation）、组合（Composition）等。类之间关系的强弱：依赖 < 关联 < 聚合 < 组合 < 泛化（继承） @[toc] 1、啥是UML类图？ 首先来看一个专业一点的定义【来自维基百科】 UML即 统一建模语言 （Unified Modeling Language）,它是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。 不得不说，越专业的描述越让人看得越发懵逼..

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

Visual Paradigm 是包含设计共享、线框图和数据库设计新特性的企业项目设计工具，它可以整合在其他CASE工具或者其他IDE工具中。市场上的UML建模工具百花齐放，为什么Visual Paradigm会受到用户的追捧青睐呢？现在，我们就来给大家盘点一下UML建模工具Visual Paradigm的特点。赶快来看看吧！ Visual Paradigm 为您带来的好处 为您的团队提供一系列设计和项目管理工具。 可视化建模 强大的可视化建模工具，可帮助您构建和管理图表和模型元素： 拖放式图表编辑器 支持UML、BPMN、ArchiMate、DFD、ERD、SoaML、SysML和CMMN 有效的建模工具，如元素可重用性，图表和元素转换，语法验证，自定义属性等 许多格式选项 企业架构 受欢迎的 TOGAF 软件，具有行业独特的TOGAF ADM 生命周期管理工具，被世界上最知名的企业所采用。 过程导航工具，引导您完成各个 ADM 阶段。 可操作的步骤 - 在我们的ADM流程工具中执行ADM活动，并提供指南和明确的示例 - 无需学习。 多种 ADM 工具：ArchiMate、能力分析工具、ADM 可交付工具（表格） 自动生成的 TOGAF交付物 商业分析和设计 端到端业务工具，可帮助您提高业务效率和生产力。 战略规划：流程管理工具，可帮助您发现和定义业务的战略目标。 流程设计

Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 UML分类 （1）静态模型（系统结构）： 用例图、类图、对象图、构件图、部署图 （2）动态模型（系统行为）：状态图、活动图、顺序图、协作图 UML中有4种事务： （1）结构事务：名词、静态部分、物理元素。 （2）行为事务：动词、动态部分、行为。 （3）分组事务：包。 （4）注释事务：注解。 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，用于需求分析阶段。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。 用例之间的关系 （1）包含 (include) 关系 父用例包含子用例，父用例执行，子用例必然被执行 当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行

UML：统一建模语言，是一种用于软件系统分析和设计的语言工具 2.UMLͼ UML图分类： 用例图 静态结构图：类图，对象图，包图，组件图，部署图 动态行为图：交互图，状态图，活动图 类图是描述类与类之间的关系的，是UML图中最核心的 用于描述系统中类(对象)本身的组成和类(对象)之间的各种静态关系 类之间的关系：依赖，泛化(继承)，实现，关联，聚合与组合 待续......

一、 不同的分析与设计方法 1.功能分解法（ function decomposition ） 以系统需要提供的功能为中心来组织系统。 首先定义各种功能，然后把功能分解为子功能，对较大的子功能进一步分解，直到可给出明确的定义 设计功能 / 子功能所需要的数据结构 定义功能 / 子功能之间的接口。 （作为一种早期的建模方法，没有明确地区分分析与设计） 建模过程：层层进行功能分解 功能分解法得到的系统模型（由模块及其接口构成） 优点与缺点： 直接地反映用户的需求，所以工作很容易开始； 不能直接地映射问题域，很难检验结果的正确性； 对需求变化的适应能力很差； 局部的错误和修改很容易产生全局性的影响。 2.结构化方法： 结构化分析（ structured analysis ， SA ） 结构化设计（ structured design 。 SD ） 结构化分析又称数据流法，其基本策略是跟踪数据流，即研究问题域中数据如何流动，以及在各个环节上进行何种处理，从而发现数据流和加工。得到的分析模型是数据流图（ DFD ），主要模型元素是数据流、加工、文件及端点，外加处理说明和数据字典。 数据流图 结构化设计与功能分解法基本相同，基于模块的概念建立设计模型，分为概要设计和详细设计。 概要设计：确定系统中包含哪些模块以及模块之间的调用关系，得到模块结构图（ MSD ）。 详细设计

软件工程自学 emmm我们专业不学习软件工程，自学一点，权当休闲。 1.概述 应对不断变化的需求 开发占比比测试和维护小得多。 1.2 软件开发的三个阶段 私人化的软件环境中，软件的水平与个人的关系很大。 专家系统：提供专业知识与服务 网格计算：云计算 软件开发的初期，一定要先花时间把需求搞清楚 可读性、可理解性越好，可维护性越好 软件开发追求一致性和标准性 技术先进，需求不清楚是中国的现状。没有技术解决不了的，但是主要问题是把需求提清楚 好的需求本身就是一种资源 维护对一个公司的信誉很重要，要考虑到开发公司的流动性 维护费：技术支持（电话、邮件）、上门解决，这是一个长期的盈利（对客户就是花费） 软件的维护是一件很困难的问题。 软件！=程序，软件是由一个完整的配置组成的，还包括文档和数据。 在软件开发的不同阶段进行修改，需要付出的代价是很不相同的。 一旦发生错误应该马上修改 开发费与维护费是两回事。签合同的时候要说好 1.3 软件工程概述 好的项目管理要尽量准时。 一种策略：快速迭代、抢占市场、尽早上架 开发目的的折中、最优化 易于维护的软件，可靠性一般也比较高 可靠性和性能是互斥的，一个是求稳，一个是性能导向的 软件工程的原则： 例如类，就是对一组有共同特性的对象的抽象 局部化：资源的声明、使用和释放应该放在同一个模块中并且应该尽量靠近 一致性：要培训员工使用公司统一的命名

统一建模语言简介 统一建模语言（Unified Modeling Language，UML）是用来设计软件蓝图的可视化建模语言，1997 年被国际对象管理组织（OMG）采纳为面向对象的建模语言的国际标准。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。 统一建模语言能为软件开发的所有阶段提供模型化和可视化支持。而且融入了软件工程领域的新思想、新方法和新技术，使软件设计人员沟通更简明，进一步缩短了设计时间，减少开发成本。它的应用领域很宽，不仅适合于一般系统的开发，而且适合于并行与分布式系统的建模。 UML 从目标系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图、部署图等 9 种图。 本教程主要介绍软件设计模式中经常用到的类图，以及类之间的关系。另外，在实验部分将简单介绍 UML 建模工具的使用方法，当前业界使用最广泛的是 Rational Rose。使用 Umlet 的人也很多，它是一个轻量级的开源 UML 建模工具，简单实用，常用于小型软件系统的开发与设计。 类、接口和类图 1. 类 类（Class）是指具有相同属性、方法和关系的对象的抽象，它封装了数据和行为，是面向对象程序设计（OOP）的基础，具有封装性、继承性和多态性等三大特性。在 UML 中，类使用包含类名、属性和操作且带有分隔线的矩形来表示。 (1) 类名（Name