"Create" 与 "Instantiate" UML 中的依赖关系
"Create" vs "Instantiate" dependency in UML
根据 UML 规范，我们可以通过 <<Create>> 或 <<Instantiate>> 构造型来表示两个 类 之间的依赖关系。
你知道这些刻板印象有什么区别吗？
它是用 UML 规范 2.5（第 22.3 章标准刻板印象）编写的：
对于<<Create>>
A usage dependency denoting that the client classifier creates
instances of the supplier classifier
对于<<Instantiate>>
A usage dependency among classifiers indicating that operations on the
client create instances of the supplier
我注意到 << Create >> 构造型不仅可以应用于 "Usage" 依赖，还可以应用于
"BehavioralFeature"（参见 UML 规范中的第 22.2 节）。
在 UML 中 "BehavioralFeature" 对应于 class 或接口中的特定方法。
因此，如果我们在 class 中用 << Create >> 或 << Destroy >> 标记特定方法
我们的意思是它 creates/destroys 这个 class.
的一个实例
我们可以将标记方法与 << Create >> 进行比较
并使用 << Create >> 标记使用依赖关系。
如果我们用 << Create >> 标记 Usage Dependency 那么
这意味着 Client Class 中的特定方法创建了 Supplier Class 的实例。
因此，我们在客户 class 的主体中创建了一个 Supplier 实例。
客户和供应商在这里是强耦合的。
另一方面，如果我们用 << Instantiate >> 标记一个 Usage Dependency 那么
Client class 将 Supplier 的创建委托给其他对象。
因此，他间接创建了 Supplier。
在这种情况下，客户和供应商是松散耦合的。
例如，如果我们通过以下创建模式之一创建供应商，就会发生这种情况：对象池、原型、工厂方法等。
注：
总的来说，与规范的区别不是很清楚。
希望在以后的版本中（2.5以上版本）我们有更明确的定义。
迈克尔·杰西·乔诺莱斯
是的，«create» 用于时序图。这是消息的刻板印象。 «Create» 也是 classifier 中行为特征的刻板印象，表明它是 classifier 实例的构造函数（或非面向对象项目的等效项）。
当在依赖项上使用 «Create» 时，它看起来与 «Instantiate» 没有太大区别。就个人而言，我使用依赖项 «Instantiate»。当我的意思是通过调用构造函数实现真正的面向对象的实例化（这就是我将模型转换为代码的方式）。当它是一种不同类型的创作时，我会使用 «Create»，无论是更间接的、概念性的还是非面向对象的特征。
这里有一些例子。我会使用 «Create» 来表示 MSWord-->«Create» 一个文档，一个建模器 «Create» 一个模型。虽然我通常不会对此进行详细建模，但我会使用 «Create» 来指示组件 «Create» 一个新的数据库记录，数据库管理器 «Create» 一个新数据库，程序员 «Create» 一个新的应用程序。或者在（非 oo）数组中创建一个新元素。这些可以在不直接调用传统的面向对象的构造函数的情况下发生——并且不能直接转换为代码。
另一方面，如果我对一个人进行婚姻手术，它可能会“实例化”关联class婚姻对象。
因为我的大部分建模都是概念性的，所以在实践中，我倾向于使用 «create»。不过，即便如此，它也不会经常出现。
在 SyML/UML 上指导我的人已经在 SyML/UML 的大公司里做了很多年的 MSBE。
我问他怎么画图显示：
'system Boot process' 加载（从 ROM）并运行 'system MAIN process/application'。
他说我应该使用 «Create» 用法依赖项。
据我所知：
您使用 «Create» 来表明一个进程运行 'big' 东西 - 例如
启动整个外部进程/软件项目/应用程序。
您使用 «Instantiate» 来表明在给定的过程中，代码
segment 从 class 实例化 "creates" 一个对象实例
定义.
根据 UML 规范，我们可以通过 <<Create>> 或 <<Instantiate>> 构造型来表示两个 类 之间的依赖关系。
你知道这些刻板印象有什么区别吗？
它是用 UML 规范 2.5（第 22.3 章标准刻板印象）编写的：
对于
<<Create>>A usage dependency denoting that the client classifier creates instances of the supplier classifier
对于
<<Instantiate>>A usage dependency among classifiers indicating that operations on the client create instances of the supplier
我注意到 << Create >> 构造型不仅可以应用于 "Usage" 依赖，还可以应用于 "BehavioralFeature"（参见 UML 规范中的第 22.2 节）。
在 UML 中 "BehavioralFeature" 对应于 class 或接口中的特定方法。
因此，如果我们在 class 中用 << Create >> 或 << Destroy >> 标记特定方法 我们的意思是它 creates/destroys 这个 class.
的一个实例我们可以将标记方法与 << Create >> 进行比较 并使用 << Create >> 标记使用依赖关系。
如果我们用 << Create >> 标记 Usage Dependency 那么 这意味着 Client Class 中的特定方法创建了 Supplier Class 的实例。 因此，我们在客户 class 的主体中创建了一个 Supplier 实例。 客户和供应商在这里是强耦合的。
另一方面，如果我们用 << Instantiate >> 标记一个 Usage Dependency 那么 Client class 将 Supplier 的创建委托给其他对象。 因此，他间接创建了 Supplier。 在这种情况下，客户和供应商是松散耦合的。 例如，如果我们通过以下创建模式之一创建供应商，就会发生这种情况：对象池、原型、工厂方法等。
注：
总的来说，与规范的区别不是很清楚。 希望在以后的版本中（2.5以上版本）我们有更明确的定义。
迈克尔·杰西·乔诺莱斯 是的，«create» 用于时序图。这是消息的刻板印象。 «Create» 也是 classifier 中行为特征的刻板印象，表明它是 classifier 实例的构造函数（或非面向对象项目的等效项）。
当在依赖项上使用 «Create» 时，它看起来与 «Instantiate» 没有太大区别。就个人而言，我使用依赖项 «Instantiate»。当我的意思是通过调用构造函数实现真正的面向对象的实例化（这就是我将模型转换为代码的方式）。当它是一种不同类型的创作时，我会使用 «Create»，无论是更间接的、概念性的还是非面向对象的特征。
这里有一些例子。我会使用 «Create» 来表示 MSWord-->«Create» 一个文档，一个建模器 «Create» 一个模型。虽然我通常不会对此进行详细建模，但我会使用 «Create» 来指示组件 «Create» 一个新的数据库记录，数据库管理器 «Create» 一个新数据库，程序员 «Create» 一个新的应用程序。或者在（非 oo）数组中创建一个新元素。这些可以在不直接调用传统的面向对象的构造函数的情况下发生——并且不能直接转换为代码。
另一方面，如果我对一个人进行婚姻手术，它可能会“实例化”关联class婚姻对象。
因为我的大部分建模都是概念性的，所以在实践中，我倾向于使用 «create»。不过，即便如此，它也不会经常出现。
在 SyML/UML 上指导我的人已经在 SyML/UML 的大公司里做了很多年的 MSBE。
我问他怎么画图显示：
'system Boot process' 加载（从 ROM）并运行 'system MAIN process/application'。
他说我应该使用 «Create» 用法依赖项。
据我所知：
您使用 «Create» 来表明一个进程运行 'big' 东西 - 例如 启动整个外部进程/软件项目/应用程序。
您使用 «Instantiate» 来表明在给定的过程中，代码 segment 从 class 实例化 "creates" 一个对象实例 定义.