uml2.0跟uml1.x有哪些区别
有熟悉uml的人吗？能详细谈谈最好了，要是有这方面的资料文章，可以发给我参考更好，谢谢了！
[解决办法]
上网找找，有很多资料的
[解决办法]
UML2.0完全建立在UML1.x基础之上，大多数的UML1.x模型在UML2.0中都可用。但UML2.0在结构建模方面有一系列重大的改进，包括结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力的增强。当然还有时序框图，但如果你不使用这些功能，也就不用担心这些特性，因为仅使用类框图、顺序框图和状态框图仍可建立非常复杂的实时嵌入式系统。
在UML(统一建模语言)2.0规范中存在4种有关的请求建议(RFP)文件：基础设施(Infrastructure)、对象约束语言(OCL)、元数据交换(XMI) 和超级结构。基础设施RFP涉及UML的定义基础以及与OMG的元对象设施(MOF)的对齐。OCL RFP文件涉及对OCL的改善。实际上， 除了那些定义UML的人员之外， 很少有用户需要使用OCL。 XMI RFP文件定义了一种交换语义模型信息的格式， 但它目前没有指定如何交换框图表。XMI RFP文件则提出了改善定义交换框图表的XMI的建议。
虽然这3个RFP文件非常重要，也很有用， 但它们主要由元模型构建人员(例如定义UML的人员)和UML工具供应商使用。第4个， 也是最后一个RFP――超级结构， 是大多数用户所关注的，这些用户构建实际模型，并建立现实世界中工作的系统。
UML超级结构的内容
在最高层次上，超级结构RFP要求：1)允许结构模式的建模， 例如基于元件的开发以及实时结构规范；2)澄清通用性、依赖性和关联性的语义；3)在行为建模中支持封装和拓展性(scalability)， 特别是在状态机和交互作用的情况下；4)去除在活动框图表建模中由于映射到状态机而产生的限制。
该RFP继而建议在UML1. x 中接口和结构的概念必须要加强， 以支持并简化对标准元件框架和结构的支持。另外它还规定必须加入数据流建模， 并澄清许多关系语义。更为重要的是， RFP提出顺序框图在表现力和语义方面的局限太多，建议应该加强这方面能力。另外， 活动框图在语义上应与状态机相区别。最后， 该RFP给出了去除UML1.x规范中的错误和不一致性。简单地说， 超级结构的请求是在结构和规模拓展性方面改进UML的能力和应用。
超级结构包含了UML2.0规范中“用户可视”部分。拓展性和架构是推动对RFP的需求的两个力量，它们之间有联系， 但又有明显不同的概念。特别是，定义一种能在“小系统”中很好应用，并能升级应用到“大系统”的建模概念(元类型)非常重要。我们不希望突然转换到一套完全不同的概念， 因为我们面对的是架构问题， 而不是别的小问题。这就需要在工作开始之前有预定的假设，该假设在实践中可能会有问题。
定义一套可扩展到架构应用的概念，远胜于一套将架构完全排除在外的概念。这两种概念是明显不同的：在UML2.0中，架构改变主要表现在结构(类)模型方面， 而拓展性变化在改进的顺序框图中表现最为明显。
结构类
元件和子系统显然是架构范畴内的概念，但它们是怎样与类联系起来？它们之间又是如何相互联系的？UML1.x在这些方面是模糊，UML2.0则引进了“结构类”的概念。结构类是一种由外在“嵌套”元件组成的类，目的是对容器分层结构(containment hierarchy)建模，这些分层结构是由“元件(part)”构成的类。
图1所示的简单的Rhapsody(I-Logix公司的UML工具)类解释了UML2.0中结构类的概念。“ElevatorCar” 由一序列的元件组成：按钮、目的楼层列表(和目的楼层本身)以及和一扇门。类似地， 一个楼层类具有一个请求电梯上下的按钮和一个指示电梯到达层面的指示器。它们都是结构类因为它们都能被分解成更基本的元件对象。Door、ElevatorGnome和shaft类也都是结构类， 不过它们在这个模型的其它部分进行分解.
图1。
1 ? 2
[解决办法]
UML只是个工具, 实际用的还是多为流程图, 所谓的UML不过流于行式...当然知道比不知道好, 但不要觉得会了UML,就会了软件设计.
