uml统一建模语言有哪几种模型：UML的本质:面向对象的建模语言
uml统一建模语言有哪几种模型：UML的本质:面向对象的建模语言UML中的操作和方法操作和方法要按照作者的意图了解和使用UML，软件架构师和开发人员应该熟悉面向对象分析和设计 （OOAD）和面向对象开发（OOD）的一般概念和方法，以及它们是如何应用于UML本身。这个要求存在一个问题：尽管OOAD / OOD已经使用了几十年，但是对于OOAD甚至OOAD的基本概念还没有达成一致意见。网上书店创建帐户请注意，在UML 1.x和2.x中都使用这种奇怪的约定来发送消息给不存在的对象来创建自己。正如我们上面看到的，在Smalltalk-80中，通过向类发送消息来创建新对象，并创建返回该类的实例。因此，解释UML创建消息表示法的一种方法可能是作为这些操作的捷径。
统一建模语言（Unified Modeling Language，UML）本质上是面向对象的建模语言，它是为面向对象的软件应用程序设计的。应用程序可以基于对象管理组（OMG）推荐的面向对象技术，UML的初始版本（UML 1.x）基于三种主要的面向对象方法 – Booch，OMT和OOSE，堪称“面向对象建模的最佳实践”。UML 2.x本质仍然是面向对象的（虽然有些尝试扩展UML以支持其他开发方法显然不成功）。
下面是UML 1.4.2规范中的UML面向对象的一些说明：
一个经常被问到的问题是：为什么UML不支持数据流图？简单地说，数据流和其他不包含在UML中的图不能很好地符合面向对象的规范。
这可能解释了为什么UML不支持数据库建模，数据库建模仍然主要基于关系模型来描述关系数据库。但它并不能解释为什么UML忽略了对象关系数据库的建模或者图形用户界面（GUI）的建模。GUI设计一直是并且仍然是面向对象设计和编程的突出实例，而UML完全忽略了这些。
要按照作者的意图了解和使用UML，软件架构师和开发人员应该熟悉面向对象分析和设计 （OOAD）和面向对象开发（OOD）的一般概念和方法，以及它们是如何应用于UML本身。这个要求存在一个问题：尽管OOAD / OOD已经使用了几十年，但是对于OOAD甚至OOAD的基本概念还没有达成一致意见。
网上书店创建帐户
请注意，在UML 1.x和2.x中都使用这种奇怪的约定来发送消息给不存在的对象来创建自己。正如我们上面看到的，在Smalltalk-80中，通过向类发送消息来创建新对象，并创建返回该类的实例。因此，解释UML创建消息表示法的一种方法可能是作为这些操作的捷径。
操作和方法
UML中的操作和方法
操作(Operation )在UML 1.4.2中定义为可以从对象请求以实现行为的服务。操作具有签名(signature)，这可能会限制可能的实际参数。
方法(Method )被定义为一个操作的实现。它指定与操作相关的算法或过程。
封装
封装是OOAD概念之一。这个术语在软件开发中已经有很多年了，但我找不到任何可靠的来源。直到发现，在描述编程语言CLU中的抽象机制的文章提到了封装 。
CLU仅允许使用（公共）集群操作（即公共接口）来限制对实现的访问。带来了设计模式提升，抽象被用来定义和简化系统模块之间的连接，并封装可能改变的实现决策。
如果我们查看词典中的英语单词封装，我们会发现两个含义：（1）包装或封装在胶囊中（2）简单地总结一下，概括一下。在OOAD的背景下，这两种封装的含义都是合适的。
假设OOAD中的封装定义如下所示：
封装是一种包含的开发技术
- 通过结合信息（结构）和行为创建新的数据类型（类）
- 限制对实现细节的访问。
封装与抽象概念非常接近或相似。区别可能是“方向” – 封装更多是隐藏（封装）实现细节，而抽象则是寻找和公开接口。这两个概念都涉及访问控制。
访问控制允许隐藏实现（实现隐藏或信息隐藏），并公开类的公共接口。
在UML中封装
UML规范没有提供封装的定义，但在几种情况下使用它很不严谨。
例如，在UML 1.4中， 对象被定义为具有良好定义的边界和标识的实体，它封装了状态（属性和关系）和行为（操作、方法和状态机）。两个包中的元素是封装的，并且不是相互可见的。
在UML 2.4和2.5中，一个组件代表封装其内容的系统的模块化部分，其表现形式在其环境中是可替换的，组件也可以被封装，因此组件和子系统可以灵活地重用和替换通过连接（“连线”）将它们连接在一起。
在UML 2.4和2.5中封装的分类器是通过使用端口从其环境（封装的）隔离的结构化分类器。每个端口指定了分类器与其环境之间的独特交互点
library服务是通过searchPort端口封装的分类器。
UML 2.4规范也使用完全封装的术语， 没有提供任何解释。它在UML 2.5中被删除。
抽象化
在OOD中 没有一个普遍接受的抽象(Abstraction)定义。有些来源将抽象定义为使用简化模型来表示复杂现实的一种方式或机制。它也可以被定义为仅捕获与当前透视图相关的对象的详细信息的方法。我们可以尝试回到起源 – 70年代的某个时候 – 编程语言CLU，Alphard，Modula-2等引入了抽象机制。
CLU中的数据抽象引入了称为集群的抽象数据类型结构。数据抽象要求数据对象的行为完全由一组操作来描述。经典示例是仅使用push和pop操作来定义堆栈集群。
CLU还介绍了抽象与其实现的分离：
抽象将应用与实现隔离开来：抽象可以在不知道其实现的情况下使用，并且在不知道其用法的情况下实现。
集群的描述单元是抽象的接口规范。对于数据抽象，它包括参数的数量和类型、类型参数的约束以及每个操作的名称和接口规范。实现过程包括为数据对象选择一个表示，并根据该数据表示来实现每个集群操作。最终，可以有许多抽象的实现。每个实现必须满足集群的接口规范。
UML中的抽象
UML中的抽象对应于OOD中的抽象概念（如上所述）。UML提供了不同类型的抽象（子类），包括实现（即实现）
抽象是一种依赖关系 ，它涉及两个元素或一组元素（称为需求方和供应方），这些元素代表相同的概念， 但是处于不同的抽象级别或不同的视角。
实现是两组模型元素之间的专门化抽象关系，一组表示规范（供应方），另一组表示后者（需求方）的实现。
继承
在OOAD和UML 1.4中，继承(inheritance )被定义为一种机制，通过这种机制，更具体的类（称为子类或派生类）包含更一般类（称为超类或基类）的结构和行为
UML1.4版本中的继承
UML 1.4.2的 术语表定义了继承，即 “更具体元素包含更一般元素的结构和行为的机制”。继承作为泛化关系的补充。
泛化(Generalization)被定义为一个更一般的元素和一个更具体的元素之间的分类关系。更具体的元素与更一般的元素完全一致，并包含一些额外的信息。在允许更一般的元素的地方，可以使用更具体的元素的实例。
UML 1.4.2中使用完整描述符和段描述符的概念 解释了继承。完整描述符包含对象所包含的所有属性，关联，操作和约束的描述，并且通常是隐式的，因为它们在使用继承时一同被创建。
在面向对象的语言中，对象的描述由增量段构建，这些增量段通过继承进行组合，从而为一个对象生成完整的描述符。这些段是实际在模型中声明的建模元素。它们包括诸如类和其他可概化元素的元素。每个可普遍化元素都包含一系列特征和其他关系，以及它从祖先那里继承的其他关系。
每种可概化元素都有一组可继承的特征。对于任何模型元素，都包括约束。对于分类器，包括特征（属性，操作，信号接收和方法）以及参与关联。[ UML 1.4.2规范 ]
如果可扩展元素具有多个父元素（多重继承），则其完整描述符包含来自其自己的段描述符的特征与其所有祖先的段描述符的并集。
UML 1.4中的属性不能 重新定义， 但可以在多个子类中声明一个方法。在任何段中声明的方法将取代和替换具有在任何祖先中声明的相同签名的方法。。
UML 2.x中的继承
UML 2.4和最新的UML 2.5规范没有提供继承的定义。UML 2.x的规范说，通过泛化专门化分类器继承了更一般的分类器的特性。 适用于一般分类器实例的任何约束条件也适用于特定分类器的实例。
UML 2.5提供了关于 UML中继承如何工作的一些模糊和不完整的解释：
当泛化分类器时，泛化的某些成员是继承的，即它们的行为就像它们在继承分类器本身中定义的一样。例如，作为一个继承成员在继承分类器的任何实例中都具有值或值集合，并且可以在继承分类器的实例上调用作为操作的继承成员。[UML 2.5规范]
多态性
正如其他OOAD概念一样，多态性(polymorphism )的定义也很差。你可以找到各种奇怪的多态性定义，并且没有一个最好。更糟糕的是，我将添加我自己对多态性的定义：
多态性是在不同上下文中对同一个符号（消息，操作）应用不同含义（语义，实现）的能力。
在编译时定义上下文时，它被称为静态或 编译时多态性。在程序执行期间定义上下文时，它是动态或运行时多态性。
据悉，Strachey在1967年引入了术语“多态性” 来描述可以应用于多种类型参数的操作和功能。
程序语言（如ALGOL-60或ALGOL-68）中静态多态的典型例子是：
sum：= x y;
在这个例子中，“ ”是多态操作，它可以用于不同类型的操作数如整数，实数，字符串，复数，矢量等。特定的静态上下文即操作数x和y的类型将在编译时确定，用来实现“ ”。
这种静态多态性通常称为重载(overloading )，意味着在不同类型上使用相同的操作符号或函数名称。请注意，重载也允许不同数量的参数，有时甚至会有不同的优先级（ALGOL-68）。
另一种静态多态是参数多态性BSC 77，它基于特定的格式。在下面的C 示例中，Vector模板定义了泛型方法’elem’和运算符'[]’：
template<class T> class Vector {
T* v;
int size;
public:
Vector();
Vector(int);
T& elem(int i) { return v[i]; }
T& operator[] (int i);
/* … */
};
Vector<int> vi;
Vector<Shape*> vps;
在OOAD多态性中意味着动态多态，通常与后期绑定或动态绑定相关。它可以被定义为：
（动态）多态是不同类对象以不同方式响应同一消息的能力。
虚拟方法(Virtual Functions)
程序语言Algol-60允许将一个程序作为参数传递给另一个程序。在Simula 67中，类似程序可能有形式参数，但它们不允许程序作为类的参数。Simula 67的作者发现了另一种方式，让相同的语句在不同的对象中有不同的效果，通过在C类中声明一个过程为“virtual”，它可以在子类d中重新定义（覆盖）。因此，相同的过程调用可以激活该过程的不同“版本”，至少在不同子类的对象中是这样的。
C ，Java和C＃中 动态绑定机制允许确定为响应特定对象接收到的消息而调用的行为（实现）。为了在C 中获得这种多态行为，成员函数必须是虚拟的，并且必须通过指针或引用来操作对象。
UML中的多态性
在UML规范中没有关于多态性的定义，但是在不同版本的UML中使用这个术语有一些不同之处。
在UML 1.4.2中，通过使用isPolymorphic属性声明它是否可以通过子类中的不同方法实现（与C 中的虚拟函数非常相似）。实现多态操作的方法与操作具有相同的签名，并具有实现操作规范的主体。后代中的方法覆盖并替换从祖先继承的方法。
在UML 2.4和UML 2.5中，isPolymorphic属性不再存在，没有任何解释。这是否意味着所有的操作现在都是多态的（虚拟的），仿佛受到了Java语言的启发？在UML 2.4.1规范有一个模糊的说法提的多态性 在第11章，操作中提到了多态性，这个语句现在从UML 2.5中删除了：
操作可以在模型中声明，且仅通过多态性动态选择。
我记得很久以前，Pascal语言被广泛推行，同过于正式和复杂的Algol-68相比的显着简化。其结果是简单的，语言不清晰，含糊不清的语义。希望UML 2.5的简化工作不会以同样的方式结束，简单的并不总是清晰的。
