Неожиданно про UML… История и проблемы

Мадорская Ю.М.

Любая проблема — это поле для поиска решений. Чаще всего, чем искусственнее проблема, тем больше групп занимаются поиском решений. Особенно сложны «исторически сложившиеся проблемы» созданные людьми. При анализе проблем Природы исследователи, углубляясь, все чаще и чаще видят фрактальность структуры — повторяемость закономерностей на разных уровнях. Продвижение вперед в этой области связано как правило с «усилением зрения», когда удается охватить картину либо на более низком уровне (микроскопы), либо на более высоком (телескопы). (Особенно меня волнует в этом плане открытие С. Шноля).

При поиске решений для исторически сложенных проблем, также наблюдается фрактальность, но не в самих решениях, а в  процессе поиска решений. Решения в этой области как правило связаны с «закрытием глаз» на что-либо.  Продвижение вперед  в этом случае связано с нахождением тех или иных временных заплаток, порождающих новые искусственно созданные проблемы, при нежелании пересмотра нижележащих концепций. Это поведение демонстрировалось людьми, наверное, при всех значимых открытиях. Если от некоторого неправильного решения в прошлом зависит большая группа людей, то шансов на быстрый и полный пересмотр концепций, который мог бы остановить этот порочный процесс очень мало. 

На мой взгляд именно это и происходит с UML. 

История создания UML, которую можно почерпнуть в различных научных и практических публикациях, подтверждает, что UML не создавался как единое методологическое решение, он был создан как объединение существовавших и конкурирующих между собой нотаций.

Например, (цитирую)

1. «Большая тройка:

Object-oriented Analysis & Design (OOAD) – Grady Booch, The Object Modeling Technique (OMT) – Jim Rumbaugh. The Object-oriented Software Engineering method (OOSE) – Ivar Jacobson. Каждый из методов имел сильные и слабые стороны.  
Booch (OOAD) — очень сложный,  язык моделирования содержал угрожающее количество диаграмм и результирующих символом. Позволял эффективно выполнять низкоуровневое проектирование и такая детализация была даже полезна для документирования кода. Был хорош для объектно-ориентированного проектирования, слаб для объектно-ориентированного анализа. 

Rumbaugh (OMT) -  более простой язык моделирования, гораздо лучше для высокоуровневого проектирования, чем метод Буча. Соответственно хорош для объектно-ориентированного анализа и слаб для объектно-ориентированного проектирования.

Jacobson (OOSE) - основной особенностью были «use classes». Классы использования (Use classes) моделировали как система должна взаимодействовать с пользователями. Рассмотрение системы с точки зрения пользователя определяло процесс проектирования. Это очень хорошо подходило для верхнеуровневого проектирования. 

Казалось, что методы  Booch и Rumbaugh развиваются в схожем направлении. В 1994 году они объединили усилия, чтобы объединить два метода. Оказалось, что объединить все три метода очень сложно. В тоже время сообщество разработчиков ПО  хотела эффективный и стандартизованный язык моделирования. Тогда тройка сфокусировала свои усилия на унификации этих трех методов.« [1]

2. «В начале 90х объектно-ориентированные методы  Grady Booch и James Rumbaugh использовались довольно широко.  В октябре 1994, the Rational Software Corporation начала создание унифицированного языка моделирования. Во-первых, они пришли к соглашению о стандартизации нотации (языка), так как это казалось менее сложным, чем стандартизация методов» [2].

Unify, unfying — унифицировать, унифицированный, единый, объединенный.

Первый шаг унификации  — это введение единых обозначений, использование общего словаря для решения какой-либо задачи.  Успех данного этапа зависит от того, возможно ли обеспечить не только общие наименования, но и одинаковое понимание конструкций, построенных с их использованием.  Что, кстати, является одной из основных претензий к UML: «Сложно спорить, что UML отражает некоторый лучших опыт моделирования и что он объединяет нотации, полезность которых была подтверждена практикой. В то же время UML не ушел далеко в решении проблем недостатка точности, формальности. … Метамодели UML могут обеспечивать точное описание нотации и потому полезны для реализации редакторов, но они не обеспечивают точного описания смысла конструкций UML» [3].

Пояснения. Представьте, что при общении с Заказчиком, вы используете термин «Клиент», а Заказчик обозначает это как «Абонент». Отлично, вы договариваетесь называть это общим словом «Заказчик услуг«, однако разве вы продвинулись в понимании того, что стоит за понятием «Заказчик услуг«? Какими элементами он описывается, как «Заказчик услуг» связан с понятием «Юридическое лицо«? Для этого необходимо дополнительное исследование. От глубины этого исследования будет зависит качество построения архитектуры системы. В случае UML   — архитектуры языка.

Второй шаг (подход к)  унификации  —  использование единого метода решения задачи, в противовес разрозненному набору методик, связи между которыми определены плохо. Единый метод строится на единой системе однозначно определенных понятий. Система понятий метода выверяется на согласованность, непротиворечивость, неизбыточность, достаточность для решения задачи.  Также решается ряд других важных задач, обеспечивающих возможность получения значимого, однозначно интерпретируемого результата с использованием данного метода.

Разница между подходами огромна. В первом случае мы имеем спектр кубиков для описания задачи, которые раскрашены понятными нам цветами. При этом многие кубики могут быть схожи и потому постоянно возникают проблемы — какой же цвет брать для этой задачи, а для этой…? Можно и так построить и так, споры не угасают. Во втором случае мы прорабатываем систему цветных кубиков таким образом, что она не обладает (как минимум) избыточностью и однозначно понятно какой цвет необходимо использовать для той или иной задачи и по какому принципу этот цвет выбирать. 

Из-за невозможности  реализовать второй подход для UML  (методической или организационной) был выбран первый подход к унификации — соглашение об обозначениях. Заметьте, в таком случае не идет речь о качестве самой системы понятий, входящих в общий словарь и утряске связей между ними, обеспечение однозначной интерпретации конструкций.

В публикациях часто упоминается «Война методов», царившая в то время. Необходимость визуального моделирования и несогласованная генерация одного языка моделирования за другим неизбежно привела к проблеме Вавилонской башни. И когда все равны по статусу, но все разные, то сложно договориться, кто лучше.  Хороший в этом случае выход — объединиться, создать «группировку». Дифференцированная группа в таком случае выиграет у одиночек. Но  это объединение на основе поверхностных договоренностей, а не на основе полного пересмотра концепций.  Объединение элементов, не всегда дает на выходе Систему.  Создание устойчивой, жизнеспособной системы — это очень сложный процесс, предполагающий разрушение ранее созданных связей, на которую разработчики скорее всего не были готовы, увидев самостоятельный коммерческий интерес уже в унификации обозначений  — создании унифицированной нотации.

Второй шаг унификации  так и не был ими сделан, однако существует много научных групп, занимающихся этой задачей, в том числе на базе нотации UML. 

Известные проблемы UML не означают, что его нельзя использовать «в повседневной жизни» . Польза от некоторой унификации обозначений очевидна и я полностью согласна с позицией Э. Галиаскарова (см. в конце статьи). Однако следует помнить, что UML не отделим от его разработчика, так же как для правильной интерпретации фразы друга-француза лучше расспросить его поподробнее, что же он имел ввиду, чтобы не попасть в просак.

Литература

  1. History of UML. www.cs.cofc.edu
  2. History of UML: Methods and Notations http://sourcemaking.com/uml/basic-principles-and-background/history-of-uml-methods-and-notations
  3. R Francea, A Evansb, K Lanoc, B Rumped. UML as a Formal Modelling notation http://dx.doi.org/10.1016/S0920-5489(98)00020-8
;-) Любое копирование и публикация материала допускается только с письменного разрешения автора.
Для ссылки в научной работе, в соответствии с ГОСТ Р 7.0.5-2008 «Библиографическая ссылка», правильно использовать:
Мадорская Ю.М. Неожиданно про UML… История и проблемы [Электронный ресурс] // ReqCenter.pro Согласованные знания для практического использования, 2013. URL: http://edu.reqcenter.pro/?p=3505 (дата обращения: 21.02.2013)
 
P.S. Хотелось бы процитировать дискуссию, которая привела к созданию данной статьи
В каких случаях UML вреден? http://www.uml2.ru/forum/index.php?topic=5318.0
Автор Эдуард Галиаскаров http://insectfinder.blogspot.ru/

Если считать UML французским языком, то наша задача в каких случаях вреден французский язык?

Ваши друзья не любят французский и каждый раз, когда вы пытаетесь его использовать, они бьют тебя по лбу. В таких случаях он крайне вреден для здоровья. Но если вы поехали на экскурсию в Париж, то всегда можете спросить у прохожего француза дорогу на Нотер-Дам 

Я думаю UML будет вреден, если вы попытаетесь описать процессы химической кинетики для демонстрации ваших выводов на научной конференции химиков.Хотя если вы будете формализовать требования к системе моделирования таких процессов, UML может быть довольно полезен. Буду доказывать в этом году со своим дипломником.

Мои комментарии:

Замечательный текст!! Вы меня вдохновляете. Добавлю.

Любой язык моделирования полезен уже тем, что заставляет задавать вопросы, причем _систематизированно_. (Эффект от этого часто потрясающий, особенно при условии, что в нем немного категорий). Далее, нужно смотреть, именно эта систематизация подходит для именно этой задачи или не подходит. Задача включает в себя весь контекст, в том числе и команду, которая над ней работает. 

Сложности начинаются тогда, 

1. когда используют не подходящую для задачи систематизацию или

2. когда используются две или более не сходящихся систематизации. 

Что значит не сходящихся? Между ними нет связи или она не однозначна, результаты одной систематизации сложно соотнести с другой. Т.е. общую интерпретацию не построить или она не однозначна. UML — это несколько систематизаций в одном флаконе (наборы диаграмм), построенные не по принципу «возьмем одну целую систематизацию и аккуратно разделим на части, не потеряв системные связи», а по принципу «соберем в одном месте те систематизации, которые были». Так исторически сложилось.  Чтобы проверить, хорошо ли это получилось, нужно посмотреть статьи по попыткам построить полную трассировку UML.

 

Разработка и  управление требованиями. Курсы.

Присоединиться в facebook или linkedin

Комментарии

комментарии

Комментарии закрыты.