从图像www.uml.org该
物品是专门用于UML和其在当前时间应用的特殊性。很少有历史信息，只有要点：
如果您查看UML的现在和现在的应用方式并加以思考，您可以得出以下结论：让UML版本现在为2.5，但是使用该语言的原理自第一个版本以来没有改变。
结果是：分析师使用了描述软件系统的概念，该概念是20多年前提出的。概念本身很好，但是您需要将其与使用的位置和上下文相关联。
如果我们继续对UML的使用进行分析，并将其与当前时间的需求相关联，则结论如下：
- 使用UML的所有技术都是“用例”驱动的用例驱动开发。
- UML模型缺乏完整性。选择的分别描述结构和行为，业务和应用程序级别方面的方法使整个模型的感知复杂化。
- UML是一种面向对象的语言，这使其很难表达其他概念。
我不会谈论用例驱动开发方法，它的一个体现是Rational Unified Process。接下来，我将讨论最后两点。
表现方面
UML由许多图表组成。每个人都遵守自己的规则，在自己的理解中使用元素和箭头。从外部看，它看起来不像是统一的语言，而是作为一组不同的表示形式，通常是作为一种机会从不同的角度看待主题区域。同样成功的是，瑞士刀可以被称为统一工具，它实际上是一套由刀片，螺丝刀，开瓶器，汤匙，叉子等组成的工具。
分析师尝试将所有图表拟合为一个模型时会做什么？他开始构建混合图表和链接表。结果不是单个模型，而是一组图表，向其中添加了更多图表和表格。
演讲水平
假设业务分析师使用UML图描述了一个主题领域。现在，系统分析师或同一位分析师需要形成软件系统的模型。如果分析人员专注于UML，那么他将开始创建与之前所做的表示相对应的表示，但是已经在系统框架内。它将再次看起来像类似的图。
分析人员在想要比较主题区域的描述和系统模型时会做什么？
他开始构建混合图，链接表并再次进行跟踪。
结果又是大量的图表。
仍然需要注意的是，UML是一种古老的语言，并且有大量的书籍和古老的示例。其中主要描述了从手动业务过渡到自动化业务的情况。分析人员从这些例子中学习。但是今天，信息技术已渗透到各处。“单独进行业务，单独进行IT”的方法是不可接受的。
面向服务的方法
UML是一种面向对象的语言，这使其很难表达其他概念。例如，面向服务。UML标准概要文件没有“服务”的概念，但是有一个SoaML概要文件被吹捧为面向服务的体系结构建模语言。
我将简要讨论面向服务的方法，以便进一步理解为什么SoaML不适合其建模。让我们以TOGAF中的定义解释为基础。
对于面向服务的方法的简单形式化，我们需要2个抽象：
- 流程是服务之间/对服务的控制流。还必须说，一个过程是一系列动作共同达到一定的结果。
- 服务 -一种行为元素，可响应主体或其他服务的请求提供某种功能。服务提供或支持功能，具有明确定义的接口并受到明确控制。
让我们看看如何在SoaML中建模。同时，让我们比较一下UML中的面向对象建模和SoaML中的面向服务建模将如何不同。
人与商店
目标：描述在商店中购买商品的模型。
我认为，面向对象的方法对每个人都清晰而简单。为了不浪费时间，我们将不考虑业务水平。我认为每个人都可以想到活动场景或序列图形式的建议用例及其细节。
一个人不是充当用户，而是充当交互的参与者之一。
现在，我们将严格按照规范使用SoaML解决此问题。
在此图中，我们定义了交互人员的社区，即商店和人员。
我们确定它们之间的业务流程“销售商品”，其中商店充当“卖方”，而人员充当“买方”。
现在，基于业务流程，我们可以标识以下业务服务；在SoaML中，为此使用ServiceContract分类器。
在此服务的框架内：卖方充当提供者，买方充当消费者。
卖方作为供应商提供“销售”操作。业务分析结束了，我们进入了系统级别。
我们需要在系统级别对销售产品的业务流程进行更新建模。为此，我选择了一个时序图，您可以使用任何其他行为图。
从更新的业务流程中，我们可以选择一个操作“出售”，将其安排到“谁知道如何销售”的基本界面中。
接下来，我们需要描述将用于实现服务的服务接口。
我们获得以下服务接口：
- “希望出售”，它是从“销售”界面继承的；
- “需要购买”，这取决于“销售”界面。
现在，您可以将目标服务模型表示为复合结构图。
让我们比较一下UML中的面向对象建模和SoaML中的面向服务建模的结果。
在视觉上，整体差异在于组件边框上的这些小方块。我用红色标记了它们。这是所有区别吗？
面向对象的建模和面向服务的建模之间确实存在区别，只是SoaML将所有内容简化为对象。但是稍后会更多。
现在，我们将在一个更复杂的情况下完成对SoaML的考虑，然后我们将大致获得以下方案。
我认为SoaML有什么问题。
首先：再次，由于语言的完整性以及业务级别和应用程序级别之间的关系问题，您自己看到了彼此之间有多困难。
其次：服务被描述为结构的对象，这不好。在俄语语音中，短语“提供者代表服务”很常见，这是在SoaML中实现的面向组件的方法。但是在以服务为导向的范例中，说“由供应商提供服务”更为正确。并且，如果您将“服务”翻译成俄语的方式不同，那么一切都会立即落到位：“供应商提供服务”。从这个角度来看，“服务”不是“对象”，而是“行为”。
第三：在有关面向服务的体系结构的幻灯片上，我谈到了两个抽象：流程和服务。坦率地说，通过面向对象方法的视角来查看和描述它们是一项艰巨的任务。
范式
回到UML。UML通过其范式试图描述其他范式。
而且，如果一切都以面向组件的范式解决，那么它可以表示为面向对象的范式的逻辑延续。面向服务的服务不能很好地工作。
在这种情况下，通过另一个不幸的想法来表达一个范例。
我以“人员和商店”问题为例，演示了将这种概念与SoaML一起使用。
如下所示，它与范例之间的联系更好。
我将演示面向服务的建模与面向对象的建模有何不同。
人与狗
目标：描述交互模型-一个人与狗同行。
技术学院的任何学生都可能会毫不犹豫地解决此问题。在相关专业的学校和大学中，面向对象的编程是强制性的。下面介绍了面向对象的方法。
面向服务的模型是什么样的？我不知道学生是否会回答这样的问题。
这是我想收到的。（为自己想一分钟，然后看看）
, . - . () () «».
, . - . () () «».
您可以回顾一下面向对象编程的历史。甚至Edsger Dijkstra和Niklaus Wirth等非常有权威的人在出道之初就对此表示怀疑。而且，有些人认为OOP值得关注。
好吧，这种模式也会引起笑容。关键是，面向服务的范例在编程和设计的初始阶段没有足够的支持。对于程序员，仅由框架（例如Java Enterprise Edition或Spring）提供支持。我认为程序员已经为面向对象的方法格式化了头脑。
分析师对Internet上的文章有不同的理解，而他们对面向服务的体系结构和设计的理解是基于Internet的，并且有些文章没有深入探讨具体细节和技术细节，因此通常晦涩难懂。结果，分析人员返回了系统和用户之间公认的用例。通常，系统架构及其组件组成已经由架构师或由于所选平台而固定。然后，分析师再次简单地描述系统和用户之间的用例。
将面向对象的方法与这种看似荒谬的方法进行比较，在该方法中，Man为Dog提供了Walk服务。当它不再对您变得有趣时，但是人类实施“行走”方法的面向对象方法似乎很有趣，在送达狗的入口处！那是您了解面向服务的范例的时候。
应当指出，这些范例是完全兼容的。一个人仍然可以执行其通常的动作：睡觉和跳舞，狗则吠叫。
还有一点：在此示例中，我引入了一个新概念“服务”。同时，我尚未明确定义其使用规则，但是它与SoaML中的规则不同。在这里，您需要小心，不要对此太迷惑，因为这种扩展是指元建模。所创建的模型可能是矛盾且晦涩的。
而不是结论
- UML . , . .
- . , . .
- UML . , . , UML, .