Не корысти RADи

23 декабрь, 2005 - 00:00Андрей Зубинский

Лет двадцать с лишним назад, когда компьютеры были большими, программ было немного, они были дорогими и разрабатывать их было удовольствием (разве не удовольствие – интересная неутомительная высокооплачиваемая работа?). Сейчас же все наоборот: программ просто море и потребители стараются «выудить» из него то, что подешевле и покачественнее. Программирование как занятие, по сути, становится оброком, который крепостные информационного века отрабатывают вовсе не корысти ради. Это, конечно, не всерьез, но все же...

«Без сомнения» говорят всегда именно в тех случаях, когда сомнения не дают покоя, а потому на эту тему нужно будет поразмыслить особо.
В. Клемперер

Начиная любую беседу, всегда полезно убедиться, что понятийный аппарат, который вы собираетесь использовать, будет понятен (красивая нетавтология) всем ее участникам. Иначе беседа превратится в монолог, причем в чрезвычайно утомляющий. А вот это уже чревато малоприятными последствиями – многие люди не выдерживают длительных непонятных монологов в стиле «скучно о неинтересном» и стремятся компенсировать особенности этого стиля скандалом. От которого, естественно, сразу становится интересно и весело потому, что скандал позволяет изящно перейти от малопонятных технических и невнятных псевдотехнических терминов к вещам куда более приземленным. Например, к личностям участников скандала. Впрочем, активно вовлеченные в интернет-общение читатели хорошо знают, о чем идет речь. Именно поэтому мы сразу приступим к самому главному – к обсуждению собственно термина «быстрая разработка приложений» или RAD (Rapid Application Development).

Из огромного количества определений RAD автором статьи были выбраны наиболее, если так можно выразиться, представительные, вариации которых встречаются в изобилии. Вот жесткое и лаконичное определение RAD, полностью соответствующее точке зрения «ультралевых» (т. е. не связанных никакими корпоративными приверженностями специалистов; на самом деле это вовсе не означает их объективности – многие «ультралевые» добровольно надели такие шоры технологических пристрастий, какие не может навязать самая суровая корпоративная культура):

«RAD – процесс разработки программного обеспечения, который в середине 90-х годов был более маркетинговым приемом, чем действительно хорошо определенным проектным процессом».

«Ультралевые» с сайта tunes.org в данном случае правы. Но, как это обычно бывает, – правы всего лишь частично. Не менее категоричны в суждениях и сторонники механистических определений, ставящие во главу угла технико-инструментальный характер чего бы то ни было. Так, типичный пример нечеткого механистического определения дает словарь сайта www.bitpipe.com:

«RAD – это система для быстрого построения прикладного программного обеспечения».

Если здесь еще есть нечеткость, заключенная в многозначности слова «система», то в определении с сайта www.webopedia.com механицизм доведен до совершенства:

«RAD – это программная система, позволяющая программисту быстро создавать рабочие программы. В общем, RAD-системы дают в распоряжение программиста определенный набор инструментов, помогающих эффективно разрабатывать графический пользовательский интерфейс, требующий больших затрат труда. Две наиболее популярных RAD-системы для ОС Windows – это Visual Basic и Delphi... в настоящее время граница, отделяющая RAD-системы и среды разработки, размывается».

Не корысти RADи
Во многих востребованных программных системах класса RAD находится применение и совершенно консервативным техникам. Например, в весьма специфической среде разработки для C-программистов швейцарской компании RistanCASE применяются не UML-диаграммы, а традиционные блок-схемы и знаменитые диаграммы Насси-Шнайдермана

Очень удобное определение для недобросовестного компьютерного журналиста, пишущего о RAD – можно привести его в слегка усеченной форме (до многоточия) и ограничиться указанными двумя наиболее популярными RAD-системами. И между тем говорить о нем как о совсем неправильном тоже нельзя. Сокращение времени разработки за счет использования программ класса «построители интерфейса» (GUI builders) в свое время действительно совершило революцию именно в области ускорения производства прикладного ПО. К слову, эта революция в промышленных масштабах начиналась вовсе не во времена персональных компьютеров (или, если хотите, во времена Visual Basic и Delphi), а в эпоху рабочих станций, и если вы внимательно посмотрите на рынок труда, то выясните, что специалисты по применению GUI builders для безбожно устаревшего набора виджетов Motif до сих пор в цене.

Несмотря на четкое перечисление того, что является RAD, механицисты все-таки оставили некоторую степень неопределенности. Она кроется в прилагательном «быстро». В проектных процессах «быстро» – очень эластичная оценка. Обычно ее можно растягивать до тех пор, пока не лопнет терпение заказчика или не прекратится финансирование усилий по растяжению этого самого «быстро». Этот «пробел» в терминологической неразберихе устранили определения, авторов которых можно условно отнести к «нормировщикам» (потому что находить точный ответ на вопрос: «Насколько быстро сделана работа?» – обязанность нормировщика). «Нормировщики», помогавшие создавать энциклопедический словарь терминов журналу PC Magazine, дали RAD такое определение:

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

Автор признается, что определение нормировщиков приведено в сокращенном виде – не для введения читателя в заблуждение, а исключительно с целью демонстрации его специфического «нормировочного» характера. Недостающие детали будут непременно восстановлены далее, в других определениях. «Нормировщики», как им и полагается, уточнили сроки – «все, что обеспечивает выход работоспособных версий раз в три-четыре месяца» («все» – это и организация проектного процесса, и инструментальная его составляющая), т. е. RAD. Потому что раз в три-четыре месяца – это быстро (в аббревиатуре – rapid).

Итак, к этому моменту неразбериха в определениях достигла апогея – то ли RAD – это действительно всего лишь что-то вроде современной интегрированной среды разработки (IDE, Integrated Development Environment), то ли это некая система, позволяющая как-то быстро проектировать программы, и так далее. Такая неразбериха, безусловно, говорит об одном – что «ультралевые», навесив на этот термин ярлык «маркетингового приема», не так уж были и не правы.

И все-таки, RAD – это...

Не корысти RADи
RAD заменяет последовательность проектных действий, отделяющую во времени заказчика ПО от готового продукта, итерациями, в начале которых заказчик непосредственно взаимодействует с разработчиком и уточняет требования к ПО

Упомянутый в определении «нормировщиков» итеративный процесс проектирования ПО действительно является основой RAD. Вот только это замечательное уточнение не намного проясняет ситуацию, ведь теперь надо давать определение этому самому «итеративному процессу». К счастью, о нем и его истории известно довольно многое. Точное название процесса – IID (Iterative and Incremental Development). К нему прибегали еще в середине далеких 50-х годов прошлого столетия в исследовательских организациях Министерства обороны США (в дальнейшем – просто DOD). Список создателей IID возглавляет сам Фред Брукс (знаменитый автор книги «Мифический человеко-месяц»). Первая сохранившаяся публикация об IID датируется 1968 годом (авторы – Б. Рэндделл и Ф. Цюрхер из исследовательского центра IBM). К слову, примечательно, что именно эта публикация 1968 г. фактически без изменений стала основой «нового» подхода к проектированию ПО – SCRUM, появившегося в 1993 г. (опять же, – для окончательной путаницы следует заметить, что RAD и SCRUM как методики принципиально отличаются оценками скорости: если RAD – разработка «быстрая», rapid, то SCRUM – «шустрая», agile). Несмотря на ограниченный объем журнальной статьи давайте все же дадим право голоса системным архитекторам седой компьютерной старины (все-таки почти 40 лет – огромный срок):

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

В этом определении отражены и итеративность процесса (формирование последовательности моделей), и инкрементный его характер (увеличение числа функций модели и уточнение реализаций этих функций в каждой итерации). В начале 80-х годов, когда стали появляться высокоуровневые средства, автоматизирующие решение различных задач разработки ПО, Джеймс Мартин добавил к определению IID одно уточнение и назвал получившееся «быстрой разработкой приложений». Некогда один из ведущих аналитиков IBM, невероятно продуктивный автор, написавший 101 (!) книгу, Мартин заслуживает краткого отступления. Он писал не просто книги-однодневки, изобилие которых оправдывается бурным ростом IT, а создавал фундаментальные труды, на которых выросло несколько поколений специалистов, в том числе и в СССР, где в середине 70-х выпущенные издательством «Мир» манускрипты по базам данных его авторства стали бестселлерами. Ему также принадлежат идеи CASE – автоматизированных средств решения задач системного анализа и проектирования, языков сверхвысокого уровня (так называемых языков четвертого поколения, 4GL) и киберкорпораций.

Уточнение Мартина добавляет к определению IID соответствующую времени долю механицизма: «с использованием автоматизированных средств решения задач системного анализа и проектирования – CASE». В первоначальном варианте, до написания очередной фундаментальной книги, в заглавии которой впервые появилась аббревиатура RAD, модифицированную методологию Джеймс Мартин назвал «быстрым итеративным прототипированием производственного характера» (Rapid Iterative Production Prototyping, RIPP). Естественно, Мартин в свое время постулировал принципы RAD как методологии и более детально. В частности, им были выделены несколько основных компонентов, скрытых за лаконичностью общего определения.

Первый и наиболее важный из них, естественно, команда разработчиков. Она должна быть малочисленной, состоять из опытных, разносторонне подготовленных специалистов, способных не только выполнять свои конкретные обязанности, но и при необходимости свободно заменять друг друга.

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

Не корысти RADи
Те, кто думает, что область применения RAD ограничивается исключительно «ускоренной сборкой» приложений бизнес-класса из UML-диаграмм, – глубоко заблуждаются. Во многом благодаря RAD-проектированию ПО сложных систем управления с помощью пакетов класса Matlab Simulink и VisSim ваш цифровой фотоаппарат с его множественными датчиками и приводами стоит вполне разумных денег

Третий компонент – использование техники прототипирования в начале каждой итерации. В RAD под прототипированием понимается любой возможный ускоренный (лучше – «реактивно быстрый») способ построения работоспособного приложения, отвечающего пользовательским требованиям, действительным на начало текущей итерации. Быстро разработанный прототип позволяет предъявить его пользователям и уточнить их требования, т. е., получить необходимую информацию для начала следующей итерации проектного процесса. К слову, термин «итерация проектного процесса» (ему уже фактически дано определение ранее и только что оно было уточнено) также является компонентом RAD-методологии.

В связи с тем что RAD–методология не усложнена излишним теоретизированием и прошла испытание временем, ее особенности достаточно хорошо известны. К ее достоинствам следует отнести ускорение проектного процесса с одновременным повышением качества ПО. Как ни странно, но это признанная оценка RAD. Надо только учитывать, что в терминах RAD «качество ПО» – это фактически отношение оценки соответствия программной системы требованиям к ней (будь то пользовательским или заказчика) к стоимости владения этой системой. То есть, чем более ПО соответствует требованиям и ниже стоимость владения этим ПО, тем выше его качество. Недостатки RAD весьма специфичны и в большей мере являются не идеологически обусловленными, а, если так можно сказать, обусловленными технологическими особенностями.

RAD-методологию часто обвиняют в создании предпосылок к построению ПО, непригодного к расширению функциональности во время его эксплуатации. Логика обвинителей проста и обвинение во многом законно: так как в соответствии с RAD завершенный программный продукт фактически получается методом «выращивания» его из прототипа постоянными модификациями последнего, для изменения функциональности завершенного продукта требуются дополнительные итерации полноценного проектного процесса, обычно недоступные тем, кто использует ПО. Еще одно обвинение также не голословно – в связи с тем, что при разработке по RAD-методологии на каждую итерацию выделяется мало времени (чем меньше, тем лучше), функциональная насыщенность созданного ПО может оказаться минимально достаточной.

Итак, мы добрались до той точки повествования, когда уже можно утверждать, что хотя бы со значением обсуждаемого термина мы почти разобрались, естественно, игнорируя значительную часть деталей (которых не просто много – в книге Дж. Мартина «Rapid Application Development», вышедшей в 1991 г., ни много ни мало, – 788 страниц). Но рассказ о RAD будет неполным, если не упомянуть о новой, современной модификации обкатанной методологии – ARAD. По сути, это та же самая IID с механистической поправкой, отражающей в первой букве аббревиатуры (за которой скрывается непереводимое на русский язык слово Architected) очередное изменение средств разработки. Architected RAD, или ARAD, – термин, введенный в оборот в IT-мире аналитиком известной компании Gartner М. Блечером (M. Blechar). По идее, ARAD должна одновременно и устранять два указанных выше недостатка RAD, и увеличивать скорость разработки за счет применения в проектном процессе шаблонов проектирования (design patterns) и предварительно созданных инфраструктур (frameworks), «настроенных» на потребности прикладной области. Кроме того, основа ARAD – уже не CASE-средства в их классическом понимании, а механизмы генерации кода (в дальнейшем мы уделим им достойное внимание). ARAD – самая молодая в цепочке IID – RIPP – RAD – ARAD методология, но уже успевшая себя зарекомендовать. Если доверять результатам многочисленных оценок разных ARAD проектных процессов (в том числе и оценок, проведенных сторонними по отношению к заинтересованной в ARAD Gartner специалистами), то главным преимуществом методологии можно считать высокий возврат инвестиций (ROI, Return Of Investments) в программные проекты.

Подводя итог, приведем оригинальное определение RAD Дж. Мартина, данное им в 1991 г.: «Быстрая разработка приложений (RAD) – это жизненный цикл проектного процесса, созданный специально для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. RAD создан так, чтобы можно было получить максимальные выгоды от использования мощных средств разработки, которые в настоящее время быстро развиваются эволюционным путем».

Инструменты RAD

Столь обширное обсуждение используемых терминов дает основание с должной степенью определенности говорить о том, что за продолжительный период существования методологии в ней неустойчивым, изменчивым, оказался механистический компонент, а именно, – используемый инструментарий. Кроме того, мы уже располагаем достаточными знаниями, позволяющими сформулировать основные требования к этому инструментарию. Ну а эти требования могут, в свою очередь, стать основой для некоторой классификации, дающей возможность более-менее определенно относить тот или иной инструмент к классу RAD. Это на самом деле немаловажно хотя бы потому, что никто не пытается оспорить утверждение, что термином RAD очень любят злоупотреблять в маркетинговых целях, и для правильного выбора RAD-инструментария надо уметь отделять зерна от плевел.

Не корысти RADи
Настоящий венец RAD – пакет кросс-разработки встраиваемых приложений Nucleus компании Mentor Graphics. Практически полная виртуализация построения прототипов ПО, генерация кода, мощный набор компонентов (вплоть до собственной операционной системы). Здесь все подчинено достижению одной цели – проектируемый мобильный телефон или mp3-плейер должен быть готов к производству тогда, когда рынок готов к его потреблению, а не когда конструкторы наконец-то справились с решением задач

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

Второе фундаментальное требование опять же основывается на особенности первого компонента RAD. Причем на очевидной особенности – когда речь идет о «команде», работающей над одним проектом, совершенно ясно, что инструментарий, ею используемый, должен поддерживать режим коллективной разработки.

Высокая скорость разработки работоспособных прототипов ПО в каждой итерации RAD-процесса требует применения высокоуровневых инструментов. В первую очередь, – максимальной их приспособленности к использованию готовых компонентов, в том числе и созданных третьей (по отношению к RAD-разработчику и поставщику инструмента) стороной. Наличие рынка таких готовых компонентов для инструментария определенного класса только приветствуется и является серьезным аргументом в пользу его выбора – ведь практически всегда купить готовый компонент дешевле и быстрее, чем разрабатывать его аналог «с нуля».

Оставшихся требований к RAD-инструментам немного, но они крайне важны. Настоящий инструмент RAD-класса должен, естественно, обеспечивать минимальный путь от требований к прототипу до самого работающего прототипа. Следует учитывать, что формирование перечня требований по RAD-методологии предусматривает задействование в этом процессе пользователя (или заказчика) – это настолько важный момент, что в терминологии RAD для него предусмотрена специальная аббревиатура JRP (Joint Requirements Planning) – «совместное планирование требований». Соответственно, средства формирования требований не должны отпугивать своей сложностью пользователя. И, наконец, самое главное. По-настоящему хороший RAD-инструмент должен в идеале решать одну-единственную целевую задачу RAD как методологии – быстро получить качественное ПО. Мы уже ранее говорили о понятии «качества ПО» в терминах RAD, и теперь просто констатируем следующее: по-настоящему хороший RAD-инструмент может не быть лучшим в частностях процесса проектирования (например, в описании логических моделей баз данных), но обязан быть таковым в реализации перечня пользовательских требований к ПО.

И вот мы располагаем практически всем необходимым для краткого ознакомления с основными классами инструментального ПО, отвечающими перечисленным выше требованиям. Естественно, ни о каком детальном разборе возможностей каждого инструментального пакета и речи быть не может: во-первых, все перечисленные ниже программные продукты – настоящие гиганты, во-вторых, обо всех из них написано огромное количество учебников, позволяющих узнать необходимое самостоятельно. Мы же будем говорить именно о RAD-специфике упомянутых программ – благо есть соответствующие многочисленные и довольно незаангажированные их оценки.

Первый важный класс RAD-специфических программ, естественно, отвечает за инструментальную поддержку самого важного этапа каждой итерации – сбор (или формирование) информации о требованиях пользователя. Так как в общем случае эти требования неформализуемы, то в принципе в качестве программ данного класса может выступать что угодно – в частности любой текстовый редактор. К слову, такой подход реализован во многих специализированных пакетах, ориентированных исключительно на решение задачи формирования требований – например, система IBM Rational RequisitePro фактически представляет собой среду для коллективной работы над представленными в текстовом виде требованиями, интегрированную с популярным текстовым процессором Microsoft Word. Однако если вспомнить о многофункциональности, в этом классе RAD-инструментов следует отдать предпочтение все-таки развитым программным системам, обеспечивающим поддержку универсальных средств. К последним прежде всего следует отнести графический язык моделирования UML – в силу его стандартности, пригодности к описанию самых разных аспектов функционирования ПО, в том числе и требований пользователей (еще один довод «за UML», но мы о нем поговорим чуть позже). Перечень доступных программных пакетов, поддерживающих работу с UML, весьма обширен – его начинает универсальная «офисного характера» (обманчивая, к слову, характеристика) система Microsoft Visio и продолжает весьма специализированное ПО, например, Enterprise Architect австралийской компании Sparx System и Rational Rose корпорации IBM. Известны и кросс-платформенные легально бесплатные, распространяемые с открытыми исходными текстами, разработки с пригодной для формирования требований функциональностью, например программа UML-моделирования ArgoUML и ряд встраиваемых расширений (плагинов) к ней. В принципе, никаких особо строгих требований к продуктам этого класса не предъявляется, и неудивительно, что наибольшей популярностью, по оценкам специалистов компании Automated Architecture, в среде RAD-разработчиков пользуются самые универсальные системы (Visio и Rational Rose).

Интегрированные среды разработки (IDE) – второй важнейший инструментальный класс RAD-методологии. Две наиболее популярные IDE кратко рассмотрены в отдельной статье этого номера, здесь же целесообразно сослаться на несколько устаревшую, но исключительно информативную оценку RAD-соответствия пяти IDE (Microsoft Visual Studio.NET 2003, Sun Java Studio Creator, BEA Web Logic Workshop, Borland C# Builder и IBM WebSphere Studio), выполненную Дэвидом МакАмисом. Найти этот материал легче всего по первой же ссылке в результатах поиска Google по следующему запросу: «+David +McAmis +zdnet +RAD». Это очень добросовестная работа, заключительная часть которой достойна цитирования: «Если вы собираетесь выбрать одну из перечисленных IDE, наилучшим образом соответствующую принципам RAD, вам придется непросто. Каждая из интегрированных сред обладает своими уникальными достоинствами... К примеру, если в вашем RAD-проекте предусмотрена необходимость быстро создавать прототипы командой разработчиков, пишущих на разных языках из перечня поддерживаемых в CLR, Visual Studio будет наилучшим выбором. С другой стороны, – если вам нужен инструментарий, обеспечивающий интеграцию .NET и J2EE компонентов в рамках одной языковой среды, – то лучшим выбором будет C# Builder... Серьезным достоинством WebSphere Studio является отличная интеграция IDE с высокоуровневыми инструментами Rational Rose».

Третий класс систем, де-факто обязательно используемых в проектах, основанных на RAD-методологии, – так называемые системы интеграции данных, или, в терминах RAD, – «инструменты быстрой интеграции», RIT (Rapid Integration Tools). Сам термин «интеграция» в этом названии и программные системы этого класса настолько многогранны, что заслуживают не одной отдельной статьи. В обсуждаемом же контексте важнее всего то, что существует фундаментальный доступный отчет о результатах сравнения одиннадцати ведущих систем RIT-класса, проведенного специалистами Института инженерии разработки ПО Карнеги-Миллона и что полученных в данной статье сведений в принципе достаточно, чтобы при необходимости с ним разобраться самостоятельно.

Отдельных слов заслуживает важнейший класс приложений, отвечающих за «ускорение» процессов разработки кода в RAD-проектах. Речь идет о генераторах кода, в первую очередь, о трансляторах UML-моделей непосредственно в исполняемый код. В этом случае максимально сокращается дистанция между высокоуровневым прототипом и его исполняемым овеществлением. Именно мощные кодогенераторы стали ключевой технологической основой ARAD-методологии. На сегодняшний день их имеется великое множество (достаточно посетить сайт www.codegeneration.net, чтобы в этом убедиться), в том числе есть немало хороших легально бесплатных кодогенераторов (например, AndroMDA). В современных RAD-проектах кроме готовых генераторов кода часто применяются создаваемые «под проект» специфические генераторы, обычно разрабатываемые с помощью соответствующих механизмов инфраструктуры моделирования Eclipse (Eclipse Modeling Framework, EMF).

Не ставя точку

Тему RAD можно смело назвать «неподъемной» не только для еженедельного журнала, но и для специализированного академического издания. Однако «заезженность» используемых в RAD-методологии терминов и постепенная подмена их смысла маркетинговыми суррогатами буквально требовали появления такого материала, который стал бы одновременно и достаточным для общего ознакомления с предметом, и отправной точкой для его более детального изучения.