Пятнадцать лет назад один из классиков современной логики и информатики Г.С. Цейтин показал мне то, что сразу меня поразило: первую версию системы языков UML. Я привез копию ее стандарта в Ижевск и заразил этим нескольких своих учеников; в частности, они стали применять систему Rational Rose, фирменный диск с одной из первых ее версий до сих пор хранится у меня как исторический памятник. Мы предложили одному из известных питерских компьютерных издательств книгу по UML, но нам ответили, что вопрос не актуален. Через пару лет это издательство пыталось обратиться ко мне за написанием такой книги, но я тогда уже ушел далеко от того, чтобы писать учебник по системе, у которой я теперь знал не только достоинства, а умалчивать о недостатках и ограничениях не в моих принципах.
Поэтому я с радостью воспринял, что наконец-то выходит серьезная русская книга об UML, его применении и его роли. Поскольку эта система стала принципиальным прорывом во многих областях, остановимся на ее новациях, ее роли и ее ограничениях∇.
Прежде всего, авторы в первой главе долго обсуждают, является ли UML формальным языком. Конечно же, мне пришлось сразу же об этом задуматься, и я сразу увидел, что ни под определение формального, ни под определение естественного он не подходит. Когда мне довелось познакомиться еще с одним ярким примером из совершенно другой области (лингвистическая информатика∇), я понял, что это ‒ частный случай общего феномена, до сих пор упускавшегося в информатике. И название у примера из лингвистики созвучное: UNL (Unified Networking Language).
Результатом осмысления стала следующая классификация.
Искусственные языки. Формальные языки с точным синтаксисом и семантикой, дистанцирующиеся от человеческих языков. Четко охарактеризованы в данной книге.
Естественные языки. Ни формального синтаксиса, ни формальной семантики. Такой язык как-то развивается, и всем его знающим кажется, что они его понимают и могут на нем выразить свои мысли. Также четко охарактеризованы в данной книге.
Квазиестественные языки. Формальные языки с точным, хотя обычно исключительно утяжеленным, синтаксисом и точной, обычно исключительно примитивной, семантикой. Например, язык для генерации милицейских протоколов по формальному описанию происшествия, с которым пришлось мне столкнуться в своей работе. Отличие от искусственных в том, что внешне конструкции на них выглядят как тупой, бюрократический, но человеческий текст, и дополнительного изучения чего-то для поверхностного понимания этого текста не требуется.
Квазиискусственные языки. Внешне выглядят как искусственные, но формальные синтаксис и семантика являются лишь надстройкой над естественным содержимым. Таков, в частности, язык UNL, предназначавшийся для обмена в сети Интернет текстами на естественном языке, которые теряют многое при переводе на другой язык. Например, русские слова "жениться" и "изба" могут быть описаны на нем следующим образом:
marry[actor=male] cottage[material=wood, nation=Russian, place=village]
Есть модификаторы для обозначения взаимосвязей между словами, могут быть и модификаторы модификаторов. Тем самым в принципе можно даже поэтический текст разметить так, чтобы читателю на другом языке он был понятен со всеми обертонами "без перевода". Но этот язык, конечно же, не понятен без некоторого предварительного изучения и внешне выглядит как искусственный.
Первым квазиискусственным языком стал UML. Формальные диаграммы часто связывают в нем содержательные понятия. Именно поэтому UML явился принципиальным прорывом на фронте, более широком, чем собственно программирование, и даже таким прорывом, что многие его части уже принадлежат не собственно информатике, а являются пограничными между нею и другими областями.
Следующим концептуальным прорывом UML явилось то, что он неявно признал неформализуемость тех понятий, с которыми работают практические информационные системы. Известно, что феномен неформализуемости, открытый Н. В. Белякиным в 1978 г. и далее развитый в теорию неформализуемых понятий, практически игнорируется научным сообществом. На одном из сайтов, посвященных методологии программирования, моя цитата длительное время была переврана: вместо "формализация неформализуемых понятий" там написана сладенькая водичка: "формализация неформализованных".
Это связано с тем, что обыденное научное и околонаучное сознание вместо развития рационального мышления молится на него, как на идола. Дьявол обязательно подсовывает таким идолопоклонникам нечто, полностью обесценивающее то положительное, что содержалось в объекте их поклонения. Такой вот дьявольской приправой к общепринятой концепции рациональности является иллюзия всезнания. Она выражается тезисом о том, что в принципе все познаваемо. При этом как-то игнорируется, что в силу диагонального эффекта никто не может, в частности, познать сам себя. Англо-саксонское позитивное мышление просто не может смириться с отрицанием этой иллюзии и тем более с направленным использованием незнания как позитивного фактора∇. Тем не менее в силу своей прагматичности неявно носители такого сознания могут просовывать по кусочкам концепцию неформализуемости, что и сделано в UML.
А именно, в UML признается, что объект проектирования не может быть описан одним полуформальным описанием. Необходимо несколько, освещающих его с разных сторон. Поэтому в UML имеется около десяти классов различных моделей, объединенных общей графической формой и общим метасинтаксисом.
Тем не менее принципиальным ограничением UML является то, что он описывает лишь информационные аспекты конструирования искусственных объектов. Более того, я уверен, что попытки распространить его за это достаточно широкое и весьма почтенное поле деятельности приведут к уродствам. Это ограничение прекрасно осознавалось авторами языка и пока еще не нарушено за счет телячьего энтузиазма полузнающего сообщества.
Но есть другое ограничение, постепенно выявившееся за первое десятилетие работы с UML и настолько же неприятное для его авторов и его энтузиастов, насколько для Д. Гильберта было неприятно четко осознанное и четко высказанное им положение, что почти все объекты классической математики никакого отношения к реальной жизни не имеют∇.
Но в отличие от гигантской фигуры Д. Гильберта, имевшего смелость высказать столь неприятную для него вещь, я не нашел нигде признаков того, чтобы патриархи UML прямо говорили о втором его существенном ограничении. Хотя само по себе это ограничение таково, что относится не только к информатике, стоит высказать его на материале информатики, где оно может быть показано ярче всего.
Современное программирование четко делится на два направления, апологеты которых часто столь же пренебрежительно трактуют друг друга, как, скажем, "фрисофтеры" и Microsoft, не понимая, что они, точно так же, как НАТО и Россия, не могут жить друг без друга и что у них совершенно разные сферы влияния и роль в данном мире.
Это индустриальное программирование, где важнее форма, чем содержание, и экстремальное программирование, где на первом месте стоит содержание, а форма рассматривается лишь как адекватное вместилище для него.
Принципиальным моментом в выборе той или иной методологии программирования∇ является уровень заказчика. Если заказчик ‒ потребитель, то нужно пользоваться методологией индустриального программирования. Ему важно, как все это будет упаковано, как оно будет выглядеть, комфортно ли будет с ним играться (слово "работать" здесь как-то не лезет на язык). А уже во-вторых, нужно, чтобы оно еще кое-как "фурычило". Ему очень часто можно "впарить" (и это даже порою на самом деле будет так), что сие не есть ошибка, это новая "фича". В работе он может лишь помешать своими дурацкими требованиями, его нужно нейтрализовать, найти с ним общий язык и максимально эффективно и быстро выяснить в тех немногих областях, где он может быть полезен, чего же ему надо.
Если заказчик ‒ специалист, то он разбирается в нужной ему задаче гораздо лучше разных там "программеров"∇. Он ‒ полноправный участник работы. Зачастую только он может оценить, правильно ли сработала программа, и ему всего важнее именно эта правильность. Упаковка ‒ дело второе, ее можно будет довести тогда, когда уже почти все будет работать. А системы тестов и ежедневное полное тестирование, на которое молятся в руководствах по ХР и из-за которого многие хорошие и творческие программисты сбегают из таких проектов, ‒ лишь один из способов работать в такой обстановке.
Ошибка в оценке квалификации заказчика непременно приводит к провалу проекта.
Так вот, UML оказался идеальным инструментом для индустриального программирования. В экстремальном же он может играть лишь вспомогательную роль на второстепенных этапах и как поддержка (причем отнюдь не всегда адекватная) некоторых аспектов документации. Это наблюдение было основано на анализе работы громадной в 2000-2002 гг. новосибирской софтверной фирмы Новософт. Несколько проектов было завалено именно из-за того, что экстремальные по существу задачи решались методами ООАД.
Рассмотрим тот пример, где UML серьезно обогнал многие системы программирования. Это диаграммы автоматов. Известно, что автоматное программирование ‒ один из базовых стилей программирования, исключительно плохо совмещающийся со структурным, из-за чего он в свое время предавался анафеме и до сих пор изгнан из базовых курсов программирования. Но на своем месте он работает великолепно. Диаграммы UML поддерживают этот стиль на четверку с минусом. Уже это в большинстве случаев очень хорошо, но если об этом минусе на секундочку забыть и увлечься, то случится тот провал, который будет стоить большинства правильных решений.
А самое главное, что диаграммы часто могут быть средством самообмана, а то и обмана, поскольку так называемый "автоматический синтез" программы по ним и их по программе настолько безобразен, что может быть использован лишь для быстрого показа, как же будет работать программа в данном случае. А при переписывании вручную слишком часто возникают расхождения между документацией и реализацией.
Поэтому наличие UML не подменяет работ А.А. Шалыто и других энтузиастов автоматного программирования.
Я с удовольствием прочитал книгу Ф.А. Новикова и Д.Ю. Иванова о языке UML и увидел, что умалчивать о сложностях и недостатках не в их принципах тоже, а издательство, тем не менее, ее выпускает. Так что я рекомендую данную книгу для всех мыслящих читателей, имеющих отношение к программированию либо как деятелей, либо как педагогов, либо как заказчиков сложных проектов. Полезна она будет также специалистам в области сложных проектов с большой информационной составляющей и с заказчиком класса потребителя, но с большими амбициями и большими деньгами. Она показывает, как создать для этого типа заказчика такую упаковку, которая его удовлетворит, а уж ваше дело как специалиста вложить в нее приличное содержание. Тем более что даже отличное содержимое при невзрачной упаковке такой заказчик пренебрежительно забракует.
Не ищите в этой книге однозначных рекомендаций! Она четко показывает, как надо делать, и тут же показывает, что в несколько другом случае так делать не надо. Она вся пронизана русским негативным мышлением в самом высоком смысле этого слова. Из-за этого мышления наши специалисты столь высоко ценятся в ведущих центрах информатики, где англосаксонское позитивное мышление часто заводит в тупик.
С одним из авторов этой книги я знаком уже более тридцати лет и знаю его как прекрасного специалиста и, самое главное, как человека, уверенно стоящего на высокой ступени знаний и умений. Другой же известен как хороший педагог и очень хороший специалист.
Д. ф.-м. п., профессор Н.Н. Непейвода. 31.12.2009, Ижевск