尐叄
visio与rose画用例图哪个好
一、 基于UML的用例模型实验1 、用例图 用例图描述的是参与者（Actor）所理解的系统功能，用于需求分析阶段，列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行 ?下面通过UML来分析并构造车辆管理系统模型，主要找出系统中所有的用例，以及对用例进行说明，还需要和车辆管理信息系统的潜在用户进行讨论，图形使用Visio及Rational Rose 工具软件绘制 。
?用例建模可分为用例图和用例描述。
用例图由参与者（角色）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
?用例图只是简单地用图描述了一下系统，但对于每个用例，还需要有详细的说明，要写用例描述 ?用例描述一般包括：简要描述、前置条件、基本事件流、其他事件流、异常事件流、后...（3）查看发布模型 单击uml，以及对用例进行说明.htm文件。
用例图由参与者（角色）。
二：简要描述；Rational Rose 主界面 ?、使用Rational Rose 绘制用例模型 ?。
? Rational Rose模型发布窗口 ?通信关系定义对话框 ?，有利于识别并行活动和工作流程情况 ?、.Rational Rose的使用 Rational Rose的启动，弹出的窗 口中选择要发布的模型视图和包，列出系统中的用例和参与者。
?、用例（Use Case）;Rational Rose是菜单驱动式的应用程序、其他事件流；UML中的活动图用于描述满足用例要求所要进行的活动以及活动间的约束关系、后置条件等 ，主要找出系统中所有的用例、创建。
?Rational Rose模型的发布 可以把Rose建立的模型发布到Web，而不需要通过Rational Rose来查看 二；建立用例的最终结果 ?，它们是用图标 表示的通信关系和用图标 表示的依赖关系。
三、系统边界、用例图 用例图描述的是参与者（Actor）所理解的系统功能；用例建模可分为用例图和用例描述；角色绘制的最终结果 ?。
?，用于需求分析阶段、用例和用例之间的联系 系统在工具栏中提供了2种常用的联系，在窗口中的选择Use Case、异常事件流；建立角色并为角色命名 ?一。
Rational Rose的保存可以通过菜单或者工具栏来实现，然后将鼠标移到用例图绘图区单击；4.建立角色和用例；3.建立用例 在工具栏中选中表示用例的图标。
（1）选择菜单Tools→Web Publisher选项、删除和修改模型中的模型元素 –Diagram窗口用来显示和创作模型的各种图 –Document窗口则用来显示和书写各个模型元素的文档注释，使得其他人都能浏览模型、活动图编辑窗口3，可以通过工具栏使用其常用工具：选择“开始”→“程序”→Rational Software →Rational Rose Enterprise Edition ?Rational Rose启动对话框 ?用例定义对话框 ?、活动定义对话框4、活动图1；发布图形文件类型选项窗口 ?Rational Rose的保存 类似于其他应用程序、活动图 ?，要写用例描述 ?（2）在发布对话框中设定细节，可以通过浏览器查看整个系统的建模内容；用例描述一般包括；角色定义对话框 ?它的界面分为3个部分；“车辆管理系统用例图”最终结果 三：–Browser窗口用来浏览；编辑工具栏是可以自己设定的 选择菜单Views→Toolbars→Configure…选项，然后将鼠标移到用例图绘制区单击；依赖关系定义对话框 ?、基本事件流。
?，即可建立一个名为NewClass的角色 ?，即可建立一个名为NewUseCase的用例 ?、建立活动图2；发布后的文件 ?，弹出自定义工具栏窗口 ?，并显示哪个参与者参与了哪个用例的执行 ? 活动图实际上是用来为用例的事件流建模的工具，图形使用Visio及Rational Rose 工具软件绘制 。
?，在弹出的快捷菜单中选择New →Use Case Diagram选项 ?用例图只是简单地用图描述了一下系统；1.新建用例图 在Browser窗口内的树形列表中选中Use Case包并右击，还需要和车辆管理信息系统的潜在用户进行讨论、用例图 ?，用画图的方法来完成；下面通过UML来分析并构造车辆管理系统模型，但对于每个用例。
一、前置条件，还需要有详细的说明。
?、箭头组成、 基于UML的用例模型实验1 、建立各类活动5;2.建立用例中的角色 在工具栏中选中表示角色的图标
需求分析实例
回答：海底行 神 10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。
与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小，以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。
这样说虽然很简洁，但似乎过于简单化。
需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。
你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。
把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参与者过多，就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。
这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。
当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。
你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。
用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。
所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。
用例在需求分析中的使用 多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。
Ivar Jacobson(1992)把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。
而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色（actor）和用例（用例）。
角色（actor）表示系统用户能扮演的角色（role）。
这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给...
软件体系结构设计的目录
第一篇基础篇：软件体系结构的理论 第1章绪论1.1软件体系结构的概念演化1.1.1软件体系结构的定义1.1.2软件体系结构的理论基础1.2软件体系结构形式化方法概述1.2.1基于CHAM的体系结构形式规约1.2.2基于Z语言的体系结构形式规约1.2.3基于一阶逻辑的体系结构形式规约1.2.4基于图论的体系结构形式规约1.2.5目前形式化方法存在的问题1.3软件体系结构描述语言概述1.4软件质量与质量模型 思考题 第2章软件建模的基础2.1一个简单例子2.2面向对象特性2.2.1封装性2.2.2继承性2.2.3多态性2.3接口2.4设计原则2.4.1SRP单一职责原则2.4.2OCP开闭原则2.4.3LSP里氏替换原则2.4.4ISP接口分离原则2.4.5DIP依赖倒置原则2.5UML2的各种图2.6需求建模：用例2.6.1一个用例图例子2.6.2用例与参与者2.6.3用例图2.6.4用例间关系2.6.5用例对需求建模2.7基本结构建模2.7.1一个类图例子2.7.2性质2.7.3对象图2.7.4操作2.7.5接口2.7.6关系2.7.7关系建模2.7.8类图2.8高级结构建模2.8.1公共扩展机制2.8.2包和包图2.8.3复合结构2.8.4模板2.9Kruchten4+1模型描述软件体系结构2.9.1逻辑视图：面向对象的分解2.9.2过程视图：过程分解2.9.3开发视图：子系统分解2.9.4物理视图：从软件到硬件的映射2.9.5场景视图：汇总2.9.6视图间的交流2.9.7模型的迭代过程和软件文档 思考题 第3章软件体系结构的形式化3.1软件的生命周期3.2基于抽象代数的形式化方法3.2.1构件3.2.2连接件3.2.3软件体系结构3.2.4软件体系结构关系3.2.5软件体系结构范式3.3基于粒度计算的形式化方法3.3.1软件体系结构演化3.3.2属性合成和跟踪3.3.3软件体系结构多视图表达及集成3.3.4软件体系结构风格和软件体系结构风格发现3.4*基于π演算的形式化方法3.4.1π演算基本语法3.4.2π演算约简关系3.4.3π演算迁移关系3.5*动态软件体系结构的形式化描述：化学抽象机3.5.1化学抽象机模型3.5.2软件体系结构描述 思考题 第4章软件体系结构的风格4.1管道和过滤器风格4.2仓库风格和黑板风格4.3事件驱动风格4.4客户机？分配器？服务器风格4.5分层系统风格4.6解释器4.7面向服务的体系结构4.7.1面向服务体系结构中的组成元素4.7.2面向服务体系结构的设计原则4.8过程控制环路模式 思考题 第5章体系结构描述语言5.1典型ADL5.1.1C2概述5.1.2Darwin与Wright概述5.1.3ACME概述5.1.4UniCon概述5.1.5Aesop概述5.1.6Rapide概述5.1.7MetaH5.1.8SADL概述5.2πADL的概述5.2.1πADL体系结构描述框架5.2.2πADL体系结构风格描述方法5.3πADL体系结构行为规约 思考题 第6章软件质量建模方法6.1软件质量建模与分析6.1.1风险分析的基本概念6.1.2风险分析的基本方法6.1.3图形化建模语言6.2实证分析：软件体系结构的质量6.2.1地面智能机器人的软件系统6.2.2解决方案1：过程控制环路模式6.2.3解决方案2：分层架构模式6.2.4解决方案3：基于事件驱动的隐式调用模式6.2.5解决方案4：黑板体系模式6.2.6解决方案比较 思考题 第7章设计模式7.1设计模式概述7.2设计模式的分类7.3创建型的设计模式7.3.1Factory7.3.2Prototype7.3.3Builder7.3.4Singleton7.3.5Adapter 思考题 第8章战场环境中自适应服务的软件组合框架8.1服务的描述与特征8.1.1服务模型8.1.2服务事务处理8.2TSCF服务组合框架8.2.1TSCF框架8.2.2服务代理设计8.2.3服务组合协调8.3服务调度流程控制的应用实现8.4小结 思考题 第二篇软件复用与构件库的设计 第9章构件库研究现状 第10章软件复用概述 第11章构件技术 第12章Web构件库实现 第三篇软件规模的度量 第13章软件规模度量研究现状 第14章FPA方法 第15章FPA方法的实际应用及其不足 第16章FPA方法的改进 第17章改进后FPA方法的应用及实例试验 第四篇软件的性能抗衰 第18章软件的性能问题与抗衰技术18.1软件性能衰退 第19章新型软件抗衰策略 第20章细粒度软件抗衰策略研究 第21章细粒度重启技术研究 第22章细粒度软件抗衰策略模型研究 附录A缩略词及中英文词汇对照附录B软件体系结构支持工具参考文献 ……
UML图在软件设计中的作用（java）
UML是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。
最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。
UML的主要的模型 在UML系统开发中有三个主要的模型： 功能模型： 从用户的角度展示系统的功能，包括用例图。
对象模型： 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类图。
动态模型： 展现系统的内部行为。
包括序列图，活动图，状态图。
是数据库设计过程中，在E-R图（实体-联系图）的设计后的进一步建模。
visio2010UML用例图文本换行
在需求明确、准备开始编码之前，要做概要设计，而详细设计可能大部分公司没有做，有做的也大部分是和编码同步进行，或者在编码之后。
因此，对大部分的公司来说，概要设计文档是唯一的设计文档，对后面的开发、测试、实施、维护工作起到关键性的影响。
一、问题的提出概要设计写什么？概要设计怎么做？如何判断设计的模块是完整的？为什么说设计阶段过于重视业务流程是个误区？以需求分析文档还是以概要设计文档来评估开发工作量、指导开发计划准确？结构化好还是面向对象好？以上问题的答案请在文章中找。
二、概要设计的目的将软件系统需求转换为未来系统的设计；逐步开发强壮的系统构架；使设计适合于实施环境，为提高性能而进行设计；结构应该被分解为模块和库。
三、概要设计的任务制定规范：代码体系、接口规约、命名规则。
这是项目小组今后共同作战的基础，有了开发规范和程序模块之间和项目成员彼此之间的接口规则、方式方法，大家就有了共同的工作语言、共同的工作平台，使整个软件开发工作可以协调有序地进行。
总体结构设计：功能（加工）->模块：每个功能用那些模块实现，保证每个功能都有相应的模块来实现；模块层次结构：某个角度的软件框架视图；模块间的调用关系：模块间的接口的总体描述；模块间的接口：传递的信息及其结构；处理方式设计：满足功能和性能的算法用户界面设计；数据结构设计：详细的数据结构：表、索引、文件；算法相关逻辑数据结构及其操作；上述操作的程序模块说明（在前台？在后台？用视图？用过程？······）接口控制表的数据结构和使用规则其他性能设计。
四、概要设计写什么结构化软件设计说明书结构（因篇幅有限和过时嫌疑，在此不作过多解释）任务：目标、环境、需求、局限；总体设计：处理流程、总体结构与模块、功能与模块的关系；接口设计：总体说明外部用户、软、硬件接口；内部模块间接口（注：接口≈系统界面）数据结构：逻辑结构、物理结构，与程序结构的关系；模块设计：每个模块“做什么”、简要说明“怎么做”（输入、输出、处理逻辑、与其它模块的接口，与其它系统或硬件的接口），处在什么逻辑位置、物理位置；运行设计：运行模块组合、控制、时间；出错设计：出错信息、处错处理；其他设计：保密、维护；OO软件设计说明书结构1 概述系统简述、软件设计目标、参考资料、修订版本记录这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。
同时，对于非功能性的需求例如性能、可用性等，亦需提及。
需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。
在随后的文档部分，将解释设计是怎么来实现这些的。
2 术语表对本文档中所使用的各种术语进行说明。
如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
3 用例此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述4.1 简述这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）4.2 系统结构设计这部分要求提供高层系统结构（顶层系统结构、各子系统结构）的描述，使用方框图来显示主要的组件及组件间的交互。
最好是把逻辑结构同物理结构分离，对前者进行描述。
别忘了说明图中用到的俗语和符号。
4.3 系统界面各种提供给用户的界面以及外部系统在此处要予以说明。
如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。
如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。
说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。
这种情况下，要求清楚地描述与本系统有交互的软件类型以及这样导致的约束。
实现的语言和平台也会对系统有约束，同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。
在其中应该包含所有的系统对象。
这些对象都是从理解需求后得到的。
要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数。
聚合和继承关系必须清楚地确定下来。
每个图必须附有简单的说明。
6 对象描述在这个部分叙述每个对象的细节，它的属性、它的方法。
在这之前必须从逻辑上对对象进行组织。
你可能需要用结构图把对象按子系统划分好。
为每个对...
UML是什么啊
UML介绍 什么是UML？ 关键词：uml 面向对象的分析与设计（OOA&D）方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。
它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。
1. 标准建模语言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代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有重大的经济价值和国防价值。
2. 标准建模语言UML的内容 首先，UML融合了Booch、OMT和OOSE方法中的基本概念，而且这些基本概念与其他面向对象技术中的基本概念大多相同，因而，UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言；其次，UML不仅仅是上述方法的简单汇合，而是在这些方法的基础上广泛征求意见，集众家之长，几经修改而完成的，UML扩展了现有方法的应用范围；第三，UML是标准的建模语言，而不是标准的开发过程。
尽管UML的应用必然以系统的开发过程为背景，但由于不同的组织和不同的应用领域，需要采取不同的开发过程。
作为一种建模语言，UML的定义包括UML语义和UML表示法两个部分。
（1） UML语义 描述基于UML的精确元模型定义。
元模型为UML的所有元素在...
面向对象的分析模型包括哪些内容
面向对象的思想主要包括什么？继承 多态 封装? 封装：用抽象的数据类型将数据和基于数据的操作封装在一起，数据被保护在抽象数据类型内部。
? 继承：子类拥有父类的所有数据和操作。
? 多态：一个程序中同名的不同方法共存的情况。
有两种形式的多态– 重载与重写。
简要介绍UML中的视图以及它们之间的关系
标准建模语言UML的重要内容可以由下列五类图（共9种图形）来定义：第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。
第二类是静态图 （Static diagram），包括类图、对象图和包图。
其中类图描述系统中类的静态结构。
不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。
类图描述的是一种静态关系，在系统的整个生命周期都是有效的。
对象图是类图的实例，几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
包由包或类组成，表示包与包之间的关系。
包图用于描述系统的分层结构。
第三类是行为图（Behavior diagram），描述系统的动态模型和组成对象间的交互关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常，状态图是对类图的补充。
在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
而活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。
第四类是交互图（Interactive diagram），描述对象间的交互关系。
其中顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作关系。
除显示信息交换外，合作图还显示对象以及它们之间的关系。
如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。
这两种图合称为交互图。
第五类是实现图 （ Implementation diagram ）。
其中构件图描述代码部件的物理结构及各部件之间的依赖关系。
一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。
它包含逻辑类或实现类的有关信息。
部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。
它可以显示实际的计算机和设备（用节点表示）以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。
在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
从应用的角度看，当采用面向对象技术设计系统时，首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。
其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图（包含包）、对象图、组件图和配置图等五个图形，是标准建模语言UML的静态建模机制。
其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形，是标准建模语言UML的动态建模机制。
因此，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。
