Чем не является uml
Зачем нам UML? Или как сохранить себе нервы и время
Многие программисты, столкнувшись со сложной задачей, пренебрегают этапом проектирования, ссылаясь на то, что проектирование — это потеря времени, и в данном случае оно будет мне только мешать.
Зачастую это утверждение оказывается верным, если задача и правда небольшая и квалификации программиста достаточно для определения наиболее оптимального решения.
Программисты, не использующие UML, делятся на несколько групп:
Можно провести аналогию с постройкой дома. Когда кто-то хочет построить дом, он не просто бьет молотком и приступает к работе. Ему нужно иметь план — план проектирования, чтобы он мог анализировать и модифицировать свою систему.
Если вы уже начали описывать на бумаге вашу задачу, это уже огромный плюс.
Что такое UML
UML – унифицированный язык моделирования (Unified Modeling Language) – это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. Его можно использовать для визуализации, спецификации, конструирования и документирования программных систем.
Проще говоря, если посмотреть картинки в поисковых системах, то станет понятно, что UML – это что-то про схемы, стрелочки и квадратики.
Важно, что UML переводится как Unified Modeling Language. Главное здесь слово Unified. То есть наши картинки поймём не только мы, но и остальные, знающие UML. Получается, это такой международный язык рисования схем.
Плюсы и минусы UML проектирования
Все представленные ниже диаграммы связаны между собой. Комбинируя их, мы можем добиться необходимого уровня декомпозиции отдельно взятых задач.
Предлагаю познакомиться с одними из самых полезных и часто используемых диаграмм.
Речь пойдет о диаграммах последовательности, состояний, деятельности и самой сложной из них — диаграмме классов.
Представьте, что вам нужно описать последовательность действий для заказа товара в интернет-магазине. Кто должен участвовать в процессе? Какие фазы проходит заказ прежде, чем он будет оформлен?
Обычно, мы пишем длинный список этапов, которые должна пройти заявка, чтобы получить гордый статус «Оформлена». Затем описываем, кто именно будет выполнять конкретное действие. И только после этого начинаем программировать.
В чем недостаток данного подхода? Он не нагляден.
Представьте, перед вами лежит длинный список описанных ранее этапов и комментариев к ним. Насколько просто вам будет разобраться в нем? Сколько времени может на это потребоваться? Предполагаю, что достаточно.
Альтернативой данному подходу является использование диаграммы последовательностей, представленной на рисунке ниже.
Сверху отображены действующие лица, а каждая стрелка это конкретное действие, связанное с ними. Подробнее о данной диаграмме можно узнать здесь
Диаграмма состояний. Настраиваем старые электронные часы
Диаграмма состояний позволяет описать поведение отдельно взятого объекта при определенных условиях. Также она покажет нам все возможные состояния, в которых может находиться объект, а также процесс смены состояний в результате внешнего влияния.
Предположим, мы программируем советские электронные часы.
Для настройки нам дано всего несколько кнопок. Довольно негусто. При этом мы знаем, что одна из кнопок переключает режим настройки часов. Другая кнопка в первом режиме меняет минуты, а во втором часы.
Инструкция по настройке и так достаточно небольшая, но благодаря диаграмме состояний она визуально воспринимается гораздо проще.
Подробнее о диаграмме состояний можно прочитать здесь.
Диаграмма классов, или как рассказать о своем коде без кода
Диаграммы классов используются при моделировании ПС наиболее часто. Они являются одной из форм статического описания системы с точки зрения ее проектирования. Диаграмма классов не отображает динамическое поведение объектов изображенных на ней классов. На диаграммах классов показываются классы, интерфейсы и отношения между ними.
В различных документациях, описании паттернов проектирования, а также, читая хабр, все мы часто встречаем диаграмму классов. Почему же ее так часто используют?
Предположим, вам нужно спроектировать систему. Прежде чем приступить к реализации нескольких классов, вы захотите иметь концептуальное понимание системы, — какие классы мне нужны? Какая функциональность и информация будет у этих классов? Как они взаимодействуют друг с другом? Кто может видеть эти классы? И так далее.
Вот где появляются диаграммы классов. Диаграммы классов — это отличный способ визуализировать классы в вашей системе, прежде чем вы начнете их кодировать. Они представляют собой статическое представление структуры вашей системы.
Именно диаграмма классов дает нам наиболее полное и развернутое представление о структуре и связях в программном коде. Понимание принципов построения данной диаграммы позволяет кратко и прозрачно выражать свои мысли и идеи.
Рассмотрим, как с помощью диаграммы классов описать известный паттерн проектирования «Посетитель».
«Посетитель» — это поведенческий паттерн проектирования, который позволяет добавлять в программу новые операции, не изменяя классы объектов, над которыми эти операции могут выполняться.
Самыми значимыми достоинствами этой диаграммы являются:
Подробнее о диаграмме классов можно прочитать здесь, а о паттерне «Посетитель» здесь.
Диаграмма деятельности
Диаграмма деятельности – это технология, позволяющая описывать логику процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают блок-схемы, но принципиальная разница между диаграммами деятельности и нотацией блок-схем заключается в том, что первые поддерживают параллельные процессы.
Если говорить кратко, то диаграмма деятельности помогает нам описать логику поведения системы. Можно построить несколько диаграмм деятельности для одной и той же системы, причем каждая из них будет фокусироваться на разных аспектах системы, показывать различные действия, выполняющиеся внутри нее.
Именно на диаграмме деятельности представлены переходы от одной деятельности к другой. Это, по сути, разновидность диаграммы состояний, где все или большая часть состояний являются некоторыми активностями, а все или большая часть переходов срабатывают при завершении определенной деятельности и позволяют перейти к выполнению следующей.
Смысл диаграммы вполне понятен. На ней показана работа с веб-приложением, которое решает некую задачу в удаленной базе данных. Обратите внимание на расположение активностей на этой диаграмме: они как бы разбросаны по трем колонкам, каждая из которых соответствует поведению одного из трех объектов — клиента, веб-сервера и сервера баз данных. Благодаря этому легко определить, каким из объектов выполняется каждая из деятельностей.
Подробнее о диаграмме деятельности можно прочитать здесь.
Заключение
Надеюсь, что после этой статьи вы по-другому посмотрите на UML. Теперь при прочтении литературы или сайтов, посвященных данной теме, вам будет проще понять, какую цель преследует UML, и найти возможности для его применения. Попробуйте начать применять его и вы почувствуете всю силу и мощь, скрываемую за набором стрелок и квадратиков.
Оставьте комментарий, если вы думаете (или знаете), что что-то не так или могло быть описано лучше.
Чем не является uml
UML предназначен для моделирования. Сами авторы UML определяют свое детище следующим образом.
Мы полностью согласны с этим определением, и не только одобряем выбор ключевых слов, но придаем большое значение порядку, в котором они перечислены.
1.2.1. Спецификация
В типичных случаях в процессе разработки приложений участвуют по меньше мере два действующих лица: заказчик (конкретный человек или группа лиц, или организация) и разработчик (это может быть программист-одиночка, временная команда проекта или целая организация, специализирующаяся на разработке программного обеспечения). Из-за того, что действующих лиц двое, очень многое зависит от степени их взаимопонимания.
Одним из ключевых этапов разработки приложения является определение того, каким требованиям должно удовлетворять разрабатываемое приложение. В результате этого этапа появляется формальный или неформальный документ (артефакт), который называют по-разному, имея в виду примерно одно и то же: постановка задачи, требования, техническое задание, внешние спецификации и др.
Аналогичные по назначению, но, может быть, отличные по форме и содержанию артефакты появляются и на других этапах разработки, особенно если в разработку включено много действующих лиц. Для них также используются различные названия: функциональные спецификации, архитектура приложения и др. Мы будем все такие артефакты называть спецификациями.
Спецификация ‒ это декларативное описание того, как нечто устроено или работает.
Необходимо принимать во внимание три толкования спецификаций.
Эти три трактовки спецификаций могут не совпадать, и, к сожалению, как показывает практика, сплошь и рядом не совпадают, причем значительно. Заказчик может не осознавать своих объективных потребностей, или неверно их интерпретировать, или заблуждаться относительно природы своих затруднений, пытаясь с помощью заказного офисного приложения лечить симптомы, а не причину болезни своего бизнеса. Разработчик может не разбираться в предметной области заказчика и интерпретировать формулировки спецификаций совершенно превратным образом. Если же в формулировке спецификаций участвует разработчик, то злоупотребление технической терминологией может совершенно дезориентировать заказчика.
Основное назначение UML ‒ предоставить, с одной стороны, достаточно формальное, с другой стороны, достаточно удобное, и, с третьей стороны, достаточно универсальное средство, позволяющее до некоторой степени снизить риск расхождений в толковании спецификаций.
1.2.2. Визуализация
Рис. Жизненный цикл работника на предприятии
Разве что-нибудь непонятно?
Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми. Разумеется, наглядность визуализации моделей UML имеет значение, только если они должны составляться или восприниматься человеком ‒ это назначение UML не имеет отношения к компьютерам.
Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.
1.2.3. Проектирование
В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином «проектирование». Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код. Другими словами, одним из назначений UML является, например, создание таких моделей, для которых возможна автоматическая генерация программного кода (или фрагментов кода) соответствующих приложений. Более того, природа моделей UML такова, что возможен и обратный процесс: автоматическое построение модели по коду готового приложения.
По-английски автоматическое построение модели по коду готового приложения называется reverse engineering и обычно переводится на русский как «обратное проектирование». Нам этот перевод категорически не нравится: какое же это проектирование и почему оно обратное? Есть неплохой альтернативный вариант: «инженерный анализ программ», но он не получил пока распространения.
Сказанное в предыдущем абзаце требует оговорок «до некоторой степени», «в известной мере» буквально после каждого утверждения. Самое досадное, что в данный момент точно указать «степень» и «меру» не представляется возможным. Причина не в том, что никто не удосужился этим заняться, а в том, что это очень трудная задача, но не безнадежная. Инструменты, поддерживающие UML, все время совершенствуются, так что в перспективе третье предназначение UML может выйти и на первое место.
Некоторым уставшим от бесконечной отладки разработчикам может показаться, что стоит изучить UML, и все проблемы программирования будут решены. К сожалению, это не так.
1.2.4. Документирование
XMI (XML Metadata Interchange) ‒ внешний формат данных, основанный на языке XML (схема и набор правил использования тэгов), предназначенное для сериализации моделей и обмена ими.
Поясним последнюю фразу предыдущего абзаца. Стандарт требует, чтобы во внутреннем представлении модели для каждого элемента моделирования было отведено место, где можно хранить неформальное текстовое описание этого элемента. Большинство инструментов это требование выполняют: буквально для каждой линии или фигуры на диаграмме можно ввести текст, который поясняет смысл и назначение именно этой линии или фигуры. Более того, многие инструменты умеют из этих текстовых описаний собирать цельные, вполне осмысленные и хорошо отформатированные текстовые документы, которые можно использовать именно как привычные текстовые описания моделируемой системы. К сожалению, это замечательная возможность на практике используется меньше, чем она того заслуживает. Дело в том, что так же, как программисты не любят и ленятся писать осмысленные комментарии к программному коду, так и архитекторы не любят и ленятся писать текстовые пояснения к своим диаграммам.
1.2.5. Чем НЕ является UML
Не следует думать, что UML ‒ это панацея от всех детских ∇ болезней программирования. Для ясного понимания назначения и области применения UML полезно сопоставить UML с другими родственными явлениями.
∇ Информационным технологиям от силы полвека ‒ это еще младенческий возраст для новой области человеческой деятельности.
Во-первых, UML не является языком программирования (хотя генерация кода не возбраняется, см. параграф 1.2.3). Дело не в том, что UML язык графический, а подавляющее большинство практических языков программирования являются текстовыми языками. Гораздо важнее то, что для моделей UML не определена операционная семантика, то есть, не определен способ выполнения моделей на компьютере. Это сделано вполне сознательно, в противном случае UML оказался бы зависимым от некоторой модели вычислимости, уровень абстрактности его концепций пришлось бы существенно снизить, и он не отвечал бы своему основному назначению: служить средством спецификации приложений и других систем на любом уровне абстракции и в различных предметных областях.
Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Magic Draw, Rational Rose Enterprise, Visual Paradigm, Enterprise Architect, StarUML и др.). Сам язык никоим образом не навязывает то, как его нужно поддерживать инструментальными средствами. Решение всех вопросов, связанных с реализацией UML на компьютере полностью отдано на откуп разработчикам инструментов.
В-третьих, UML не является моделью процесса разработки приложений (хотя модель процесса разработки необходима и имеется множество различных моделей, предложенных разными авторами). Конечно, у авторов UML есть собственная модель процесса ‒ Rational Unified Process (RUP), которую они не могли не иметь в голове, разрабатывая язык, но, тем не менее, ими сделано все для того, чтобы устранить прямое влияние RUP на UML и сделать UML пригодным для использования в любой модели процесса или даже без оной.
У авторов этой книги тоже есть собственное мнение о взаимосвязи UML с моделью процесса разработки программного обеспечения (см. раздел 5.2), которое не может не сказываться на описании прагматики языка, но везде, где такое влияние замечено, сделаны соответствующие оговорки.
1.2.6. Способы использования UML
Из сказанного выше видно, что UML предназначен для решения различных задач, соответственно он может быть использован и практически используется по-разному. Далее мы перечисляем различные способы использования UML.
Рисование картинок. Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе.
Обмен информацией. Сообщество людей, применяющих и понимающих UML, стремительно растет. Если вы будете использовать UML, то вас будут понимать другие, и вы будете понимать других «с полувзгляда».
Спецификация систем. Это важнейший способ использования UML. И хотя не во всех случаях UML оказывается абсолютно адекватным средством спецификации, мы надеемся, что по мере развития языка все меньше будет оставаться таких исключений, где UML неприменим.
Повторное использование архитектурных решений. Повторное использование ранее разработанных решений ‒ ключ к повышению эффективности. Наше мнение по этому поводу изложено в разделе 5.2. К сожалению, модели UML пока что повторно используются в весьма ограниченных масштабах.
Генерация кода. В параграфе 1.2.3 данный вопрос достаточно освещен. Генерировать код нужно и можно, но возможности имеющихся инструментов не стоит переоценивать.
Имитационное моделирование. Возможности построения моделей UML, из которых путем вычислительных экспериментов можно было бы извлекать информацию о моделируемом объекте, пока что уступают возможностям специализированных систем, сконструированных для этих целей.
Верификация моделей. Было бы замечательно, если бы по модели можно было бы делать формальные заключения об ее свойствах: модель непротиворечива, согласована, эффективна и т.п. Кое-что UML позволяет проверить, но, конечно, очень мало. Здесь уместно привести аналогию с традиционными системами программирования: они позволяют быстро и надежно избавиться от синтаксических ошибок, но с логическими ошибками дело обстоит гораздо хуже. Может быть, в будущем.
1.2.7. Инструментальная поддержка
Рассмотрим, как соотносится сегодняшняя практика использования UML с декларированным выше назначением языка.
Проводя в жизнь принцип обучения на примерах, для иллюстрации вышесказанного обратимся к одной из диаграмм UML ‒ диаграмме использования (подробное описание данного типа диаграмм приведено в разделе 2.2).
По мнению авторов, можно выделить три основных варианта использования UML.
Рис. Инструментальная поддержка
Вариант использования drawing («Рисование диаграмм») подразумевает изображение диаграмм UML с целью обдумывания, обмена идеями между людьми, документирования и тому подобного. Значимым для пользователя User результатом в этом случае является само изображение диаграмм. Вообще говоря, в этом варианте использования языка поддерживающий инструмент не очень нужен. Иногда рисование диаграмм от руки фломастером с последующим фотографированием цифровым аппаратом может оказаться практичнее.
Вариант использования development («Разработка приложений») подразумевает детальное моделирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя Developer результатом в этом случае является работающее приложение, которое может быть скомпилировано в язык, поддерживаемый конкретной системой программирования Programming System или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.
Современные инструменты поддерживают указанные варианты использования далеко не в равной степени. Все инструменты умеют (плохо или хорошо) визуализировать все типы диаграмм UML, некоторые инструменты позволяют построить модель, допускающую какое-то дальнейшее использование, но только немногие инструменты могут генерировать исполняемый код и то, отнюдь, не для всех диаграмм. Имеется множество практических и организационных причин, по которым указанные выше варианты использования неравноправны и в разной степени поддержаны в современных инструментах. Некоторые из этих причин мы рассматриваем в последующих главах.
«UML. Взгляд со стороны» или «Как UML удерживает аналитиков в прошлом»
Изображение с www.uml.org
И как следствие: Аналитики используют концепцию описания программных систем, которая была заложена более 20 лет назад. Сама концепция хорошая, но нужно соотносить ее с местом и контекстом применения.
Если дальше продолжить этот анализ применения UML, а также соотнести его с требованиями текущего времени, то выводы такие:
Аспекты представления
Что делает аналитик, когда пытается увязать все диаграммы в одну модель? Он начинает строить гибридные диаграммы и таблицы связей. В результате получается не единая модель, а множество диаграмм, к которому добавились еще диаграммы и таблицы.
Уровни представления
Допустим бизнес-аналитик описал предметную область с помощью диаграмм UML. И теперь системному аналитику или тому же самому аналитику требуется сформировать модель программной системы. Если аналитик ориентирован на UML, то начнет создавать представления соответствующие сделанным ранее, но уже в рамках системы. Это будет выглядеть опять в виде аналогичных диаграмм.
А что будет делать аналитик, когда захочет сопоставить описание предметной области и модели системы?
Он опять начинает строить гибридные диаграммы, таблицы связей и трассировки.
В результате опять получается множество диаграмм и таблиц.
Тут еще нужно заметить, UML старый язык и для него имеется огромное количество книг и старых примеров. В которых в основном описываются случаи перехода от неавтоматизированного бизнеса к автоматизированному. И аналитики учатся на этих примерах. Но ведь на сегодняшний день информационные технологии проникли повсюду. Подход «Бизнес отдельно, ИТ отдельно» неприемлем.
Сервис-ориентированный подход
UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции. Например, сервис-ориентированную. В стандартном профиле UML нет понятия «Сервис», но есть профиль SoaML, который преподносится как язык моделирования сервис-ориентированной архитектуры.
Коротко расскажу про сервис-ориентированный подход, чтобы далее было понятно почему SoaML не подходит для его моделирования. За основу возьмем интерпретацию определений из TOGAF.
Человек и Магазин
Задача: Описать модель покупки товара в магазине.
Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий Use Case и его детализацию в виде диаграммы деятельности или диаграммы последовательности.
Человек выступает не как пользователь, а как одна из сторон взаимодействия.
Теперь решим данную задачу с помощью SoaML, строго в соответствии со спецификацией.
На этой диаграмме определяем сообщество взаимодействующих, это Магазин и Человек.
Определяем действующий между ними бизнес-процесс «Продажа товара», в котором Магазин выступает как «продавец», а Человек как «покупатель».
На основе бизнес-процесса мы теперь можем идентифицировать следующий бизнес-сервис, в SoaML для этого используется классификатор ServiceContract.
В рамках данного сервиса: Продавец выступает как provider, а Покупатель как consumer.
Продавец как поставщик предоставляет одну операцию «продать». Бизнес-анализ закончен, переходим на уровень системы.
Нам нужно смоделировать на уровне системы обновленную версию нашего бизнес-процесса по продаже товара. Для этого я выбрал диаграмму последовательности, можно использовать любую другую поведенческую диаграмму.
Из обновленного бизнес-процесса можно выделить одну операцию «продать», оформим ее в базовый интерфейс «Умеющий продавать».
Далее нам нужно описать сервисные интерфейсы, которые будут использованы для реализации сервиса.
Теперь можно представить модель целевого сервиса в виде диаграммы композитной структуры.
Сравним результаты объектно-ориентированного моделирования на UML и сервис-ориентированного моделирования на SoaML.
Визуально вся разница вот в этих маленьких квадратиках на границе компонентов. Я отметил их красным цветом.Неужели это вся разницы?
Разница между объектно-ориентированным и сервис-ориентированным моделирование на самом деле есть, просто SoaML свел всё к объектам. Но об этом позже.
А сейчас закончим рассмотрение SoaML на более сложном случае, тогда получаться у нас будут примерно следующие схемы.
Что же не так, по моему мнению, с SoaML.
Во-первых: Опять проблемы с целостностью языка и связью между уровнем бизнеса и уровнем приложений, вы сами видели как сложно всё соотносится друг с другом.
Во-вторых: Сервис описывается как объект структуры, это нехорошо. В русской речи распространена фраза «Поставщик представляет сервис», вот это компонент-ориентированный подход, который реализован в SoaML. Но в случае с сервис-ориентированной парадигмой правильнее говорить «Поставщик оказывает сервис». А если по другому перевести «Сервис» на русский язык, то всё сразу встает на свои места: «Поставщик оказывает услугу». С этой точки зрения «Сервис» это не «Объект», это «Поведение».
В-третьих: На слайде о сервис-ориентированной архитектуре я рассказал о двух абстракциях: Процесс и Сервис. Рассматривать и описывать их через призму объектно-ориентированного подхода является, мягко говоря, напряженной задачей.
Парадигмы
Вернемся к UML. UML посредством своей парадигмы пытается описать другие парадигмы.
И если с компонент-ориентированной парадигмой всё получается, она может быть представлена как логическое продолжение объектно-ориентированной. То с сервис-ориентированной получилось нехорошо.
В данном случае выражать одну парадигму через другую неудачная идея.
Использование такой концепции я продемонстрировал с SoaML на примере задачи «Человек и Магазин».
Относится к парадигмам лучше как обозначено ниже.
Продемонстрирую, чем отличается сервис-ориентированное моделирование, от объектно-ориентированного.
Человек и Собака
Задача: Описать модель взаимодействия – Человек гуляет с Собакой.
Данную задачу не задумываясь, наверное, решит любой студент технического факультета. В школах и универах на соответствующих специальностях объектно-ориентированное программирование является обязательным. Объектно-ориентированный подход представлен ниже.
А как будет выглядеть модель с сервис-ориентированным подходом? Не знаю, ответит ли такой вопрос студент.
Нужно понимать, что это простая задача и это простая модель. Но она отражает суть сервис-ориентированного подхода. Человек предоставляет (оказывает) для Собаки сервис (услугу) «Гулять».
Можно вспомнить историю объектно-ориентированного программирования. Как к нему скептически относились в начале его появления даже очень авторитетные люди, такие как Эдсгер Дейкстра и Никлаус Вирт. И до сих пор некоторые люди считают ООП недостойным внимания.
Ну так вот, данная модель тоже может вызвать усмешки. Дело в том что сервис-ориентированная парадигма не имеет достаточной поддержки на начальном уровне программирования и проектирования. Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring. Думаю, что программисты добираются до них с головой, уже отформатированной под объектно-ориентированный подход.
Аналитики строят свое представление о сервис-ориентированной архитектуре и проектирование по статьям в интернете, которые по-разному понимают, что это такое, а некоторые статьи без глубокого погружения в специфику и технические детали вообще малопонятны. В результате аналитики возвращаются к общепринятым Use Case между системой и пользователями. Распространено также, что архитектура системы и ее компонентный состав уже зафиксированы архитектором или обусловлены выбранной платформой. И тогда аналитики опять просто описывают Use Case между системой и пользователями.
Сравните объектно-ориентированный подход и эту, казалось бы, смешную, где Человек оказывает Собаке услугу «Гулять». Когда она перестанет быть для вас смешной, а будет смешным казаться объектно-ориентированный подход, где Человек реализует метод «гулять», на вход которому подается Собака. Вот тогда к вам пришло понимание сервис-ориентированной парадигмы.
Нужно заметить, что эти парадигмы вполне совместимы. Человек по-прежнему может выполнять свойственные ему действия: спать и танцевать, а Собака лаять.
Еще один момент: В этом примере я ввел новое понятие «Сервис». При этом я пока четко не определил правила его использования, но оно отличается от того что в SoaML. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.