Об авторе: Шалыто Анатолий Абрамович, докт. техн. наук, профессор, заведующий кафедрой «Технологии программирования» СПбГУ ИТМО. shalyto@mail.ifmo.ru
Прошло уже более года, как PC Week/RE опубликовал статью о движении за открытую проектную документацию для программного обеспечения [1]. Тогда она вызвала определенный резонанс в ИT-сообществе. Сначала статья была перепечатана рядом изданий (в частности, еженедельной методической газетой для учителей «Информатика») и опубликована на нескольких сайтах (например, http://www.silicontaiga.ru). Затем последовала реакция прессы: «Может быть, вместо открытой проектной документации лучше иметь качественную?»[2] или: «Что взять с профессора — он теоретик и жизни не знает» [3].
«Волны» от появления этой статьи затихли после ее публикации и весьма активного обсуждения на сайте ZDNet.ru (http://zdnet.ru/?ID=427760), в ходе которого идею, изложенную в статье, поддержало только несколько человек, а большинство опять говорило о том, что вряд ли автор разбирается в практической деятельности — ведь он же профессор. Из этой дискуссии я также узнал, что несчастным являюсь не только я, но и все, кто поддерживает идею Open Source, включая и Линуса Торвальдса [4]. Я всегда буду помнить слова одного уверенного в себе человека, который в этой дискуссии назвал Линуса типичным неудачником. Наверное, и корпорация IBM, по мнению этого человека и его единомышленников, также неудачница, так как поддерживает идею открытых кодов, а кто для этих людей служит образцом для подражания, можно легко догадаться.
За прошедший год в рассматриваемом вопросе мало что изменилось. Я на сайте http://is.ifmo.ru продолжаю выкладывать студенческие проекты, выделив отдельно такую область программирования, как визуализаторы алгоритмов. Как я и предполагал в работе [1], последователей у движения, видимо, из-за большой трудоемкости создания проектной документации (даже один студенческий проект у меня занимает 12-15 ч, а у студента — не менее 100) не появилось. Однако из этого не следует, что вопрос о проектной документации на программы, в том числе и открытой, не актуален. Ниже делается попытка обосновать это на основе материалов, появившихся с момента публикации работы [1].
При использовании открытых кодов в большинстве случаев документация не разрабатывается — коды открыты, что еще надо? То, что в подобных «проектах» весьма трудно разбираться другим людям, мало заботит их создателей — это не их проблема.
Считается, что такой известный Интернет-ресурс, как http://sourceforge.net, содержит десятки тысяч проектов. Однако, с инженерной точки зрения их на этом ресурсе на порядки меньше, так как большинство из них не содержит проектной документации. Отметим также, что в инженерной практике (в отличие от программирования) проектов без проектной документации не бывает.
Можно ли себе представить проекты серийного автомобиля или здания, на которые не выпущена документация? Ответ однозначен — нет. А вот относительно «цифрового дома», созданием которого сейчас озабочены ведущие ИT-фирмы мира, ответ не столь очевиден. При этом все, что связано со словом «дом», предполагает проектную документацию, а все, что связано со словом «цифровой», делится на две части: аппаратную, которую без проектной документации не создать, и программную — она обычно разрабатывается и без такой документации. На то, что проектная документация на программное обеспечение необходима на других этапах его жизненного цикла, в погоне за прибылью зачастую продолжают не замечать. Однако, как будет показано ниже, признаки «потепления» в этом вопросе налицо.
Я думаю, что сегодняшняя ситуация с проектной документацией — временная, ведь люди строят дома очень давно, а программируют сравнительно недавно. Можно себе представить, как выглядела «документация» на колесо через пятьдесят лет после его изобретения. Сейчас она выглядит явно иначе.
Близкий по своей сути взгляд на этот вопрос высказан в работе [5]:
«Программирование, несомненно, относится к точным наукам, однако принято не доказывать правильность программ, а тестировать их. Автор программы обычно действует по некоторому алгоритму (или без оного) и после прогона ряда тестов считает, что она правильная. Затем он отправляет программу на бета-тестирование, предлагая ее посмотреть „всему миру“. Вот и все доказательства.
Если „мир“ широк, как, например, у корпорации Microsoft, то многие ошибки, скорее всего, будут обнаружены. Для более узкого „мира“ — так и умрем или с ошибками, или от них, если, например, проектируем программное обеспечение (ПО) для самолета, на котором полетим. Очень часто при разработке программного обеспечения, как и в математике, правдоподобие принимают за правильность.
Математики, решая подобную проблему в течение полутора тысяч лет, придумали такой методологический прием, как доказательство. У нас нет тысячи лет, так как огромное число микропроцессоров уже проникло в различные бытовые устройства и „бунта“ стиральных машин [6] и других составляющих „цифрового дома“, в которые загружены недостаточно проверенные программы, можно ожидать каждый день. Хорошая проектная документация повышает достоверность и понятность программы. Попробуйте объяснить конструктору, что чертеж является достаточно полным решением задачи — вам не поверят. Так почему же вам верят, когда вы предоставляете программу без документации, без объяснений не только того, как, но и почему (каким образом) она работает?»
Осознавая это, в последнее время все большее значение стали придавать программной инженерии [7-9], для которой проектная документация должна являться краеугольным камнем. Ее наличие особенно важно при создании ПО для ответственных систем.
«В Лаборатории реактивного движения NASA предпринимаются попытки внедрить среди разработчиков дисциплину создания программного обеспечения. Сейчас лаборатория инвестирует 4 млн. долл. в год в реализацию инициативы, направленной на обеспечение качества ПО, которая призвана дать разработчикам возможность систематизировать и использовать набор „лучших“ практических решений. При этом считается, что инициатива будет успешной лишь в том случае, если разработчиков удастся убедить в необходимости документировать свои решения.
Для рассматриваемых объектов, если пропустить срок, определяемый законами небесной механики, полет придется отложить надолго, и поэтому за точное выполнение сроков запуска приходится дорого платить, как, например, это было при создании аппарата, успешно опустившегося на поверхность Марса в 1997 году, когда ПО для него в значительной степени осталось без документации» [10].
«Последние несколько лет компьютерная общественность с замиранием сердца следит за сводками о ходе боев в единой Европе против патентования компьютерных изобретений. Схватка происходит между общественными организациями, которые защищают свободу творчества, и корпорациями, которые защищают свои доходы.
При этом стоит подумать, что делать, если патентование в области программного обеспечения станет суровой реальностью» [11]. Можно не делать ничего, если и другие корпорации окажутся такими же добрыми, как SUN и IBM, и захотят раскрыть тысячи патентов и коды ряда своих программ. Однако, кажется, что так поступят по разным причинам далеко не все.
«Чтобы защитить свободные/открытые программы от патентования заложенных в них решений, достаточно будет опубликовать их описания. Такая публикация сделает использованные решения непатентоспособными во всем мире. Кроме того, описание принципа действия таких программ — фактически наличие проектной документации [1].» [11].
Наличие открытой проектной документации может помочь и в решении проблемы повторного использования открытых кодов. Вот что по этому поводу говорит президент Bell Labs по исследованиям Джеффри Яффе [12]: «Самые серьезные трудности связаны с тестированием. Применение свободно распространяемых решений означает, что большая часть компонентов уже есть в отрасли, и вам нет необходимости создавать их самим.
Но когда код — достояние отрасли, причем технологические процессы его создания не ясны, возникает вопрос, насколько тщательно этот код протестирован. И когда вы объединяете подобные компоненты, вам остается только надеяться, что все это вместе будет работать. Так что непонятно, насколько действительно в данном случае можно говорить о серьезной экономии.
Предложить новые процессы и технологии, причем так, чтобы довести свободно распространяемые решения до уровня, который вы запланировали и которого добились сами, — весьма нетривиальная проблема в сфере методов разработки программного обеспечения».
Примерно о том же самом сказано в работе [13]: «Изучение того, как используются программы с открытым кодом в крупных корпорациях, помогло определить, почему так медленно распространяются все технологии с открытыми кодами за исключением Linux.
У предприятий возникает немало проблем с интеграцией таких компонентов. К тому же пользователи говорят, что им самим приходится проводить тщательное тестирование подобных разработок.
Еще одна проблема в этой области — отсутствие коммерческих структур, которые помогли бы решить все возникающие вопросы. Лицензия — это еще не все.
За рамки Linux потребитель выйдет лишь после того, как убедится в уровне технической поддержки других продуктов с открытым кодом».
Несмотря на то, что здесь проектная документация не упоминается, несомненно, что ее наличие может резко повысить степень доверия к программам с открытым кодом.
Со словами о необходимости разработки проектной документации обратился к своим последователям Линус Торвальдс: «Во избежание повторения еще через десять лет неприятностей, аналогичных имевшим место с SCO, я предлагаю ввести процесс явного документирования не только источников отдельных фрагментов …, но и того, каким путем они шли» [14].
О документации в рамках движения Free Software Foundation заговорил его основатель Ричард Столлман: «Наиболее дефицитной составляющей свободных операционных систем является не программное обеспечение, а хорошие свободные руководства, которые могут включаться в их состав. Многие из наших важнейших программ не полностью документированы. Документация представляет собой неотъемлемую часть любого программного пакета. Когда важный свободный программный продукт ее не имеет, в этом его основной недостаток. На сегодня мы имеем много подобных прорех… Будут ли у разработчиков свободного программного обеспечения достаточные знания и решимость, чтобы выпустить полный комплект документации?» [15].
Изложенное, видимо, явилось основанием для того, что на конференции LinuxSummit-2004 в Хельсинки доклад о движении за открытую проектную документацию [16] следовал непосредственно за докладом о движении за свободное программное обеспечение [17].
Начали появляться книги (пока только на русском языке), в которых подтверждается целесообразность предложенного движения. Так в книге [18] сказано: «Интересно проделать следующий мысленный эксперимент: а что было бы, если бы математики работали примерно в таких же условиях, как программисты?
Ясно, что если бы математик, опубликовавший теорему, брал деньги (а тем более требовал бы их заранее) за каждое ее использование, то переиспользование (повторное использование) сразу бы сильно сократилось. Даже если бы он не брал деньги за теорему саму по себе, но секретил бы ее доказательство и угрожал бы уголовным преследованием всякому, кто осмелится понять (дизассемблировать) написанный им текст, то ситуация пришла бы к тому же мертвому концу (здесь эта калька английского слова лучше русского словечка „тупик“). Видимо, достаточно было бы, всего-навсего оплачивать труд математиков на повременной основе, проверяя обоснованность отчетов о затраченном времени по числу строк написанного доказательного текста.
Это, может быть, не убило бы переиспользование полностью, но любой математик (а не только жулики) при каждом удобном случае переписывал бы чужие доказательства своими терминами и с маленькими изменениями. Здесь к тупику пришли бы медленнее, но столь же неизбежно. Мы пришли к важному социальному и практичному выводу: единственным шансом на излечение нынешних подростковых болезней программирования является работа сообществ открытого программного обеспечения и открытой проектной документации [1]». В другой книге [19] также отмечено место движения за открытую проектную документацию в области создания свободного программного обеспечения: «В указанном направлении мы видим три основных этапа.
Идея открытой проектной документации возникала неоднократно. Она звучала еще в концепции грамотного программирования, предложенной Дональдом Кнутом [20], в соответствии с которой программа пишется как некий текст на естественном языке со вставками исходного кода. Достаточно давно возникло понимание того, что ценность документации (например, описания архитектуры и интерфейсов) может значительно превышать ценность самих исходных текстов. Удачные примеры открытой проектной документации можно найти на сайте кафедры «Технологии программирования» СПбГУ ИТМО (http://is.ifmo.ru, разделы «Проекты» и «Визуализаторы»)«.
В рамках «Движения за открытую проектную документацию» основное внимание уделяется формализации описания поведения программных систем, что чрезвычайно важно, если оно является сложным, так как этот вопрос не рассматривался в должной мере. В настоящее время все чаще обсуждается проблема применения моделей при создании программных систем [21, 22], в том числе исполняемых моделей. Это приводит к тому, что использование таких моделей в проектной документации упрощается и становится естественным.
Среди инструментальных средств, предназначенных для создания моделей, описывающих поведение программных систем, следует отметить свободно распространяемый пакет UniMod (http://unimod.sourceforge.net), который поддерживает SWITCH-технологию (автоматный подход к написанию программ) [23], используя при этом язык моделирования UML [24] и свободно распространяемую среду разработки Eclipse [25].
Из изложенного следует, что несмотря на все трудности есть основания надеяться, на то, что со временем программы и проектная документация на них будут представлять единое целое. При этом, если программы будут открытыми, то, естественно, что и документация, описывающая процесс их создания, должна быть открытой.
Об авторе: Шалыто Анатолий Абрамович, докт. техн. наук, профессор, заведующий кафедрой «Технологии программирования» СПбГУ ИТМО. shalyto@mail.ifmo.ru