Разработка, управляемая моделями (Model Driven Development, MDD) – одна из наиболее модных сегодня технологий у производителей инструментальных средств создания ПО. По сути, разработка, управляемая моделями, – это стиль создания программ, когда главными артефактами процесса разработки являются модели, по которым генерируется код, и другие прикладные артефакты (например, документация). Разумеется, использование MDD не означает, что весь код разрабатываемого ПО генерируется по модели, но имеется в виду, что объем такого кода довольно велик. Среди достоинств этого метода обычно называются скорость разработки, отлаженность кода, архитектурная целостность системы и простота ее сопровождения, что на первый взгляд более чем достаточно для того, чтобы технология MDD стала если не единственной, то по крайней мере основной, однако это не так.
Не последнюю роль среди проблем MDD играет то, что речь идет не о локальном улучшении, а о полном изменении всей парадигмы разработки. Сегодня модели применяются главным образом как наброски, которые передают какие-то аспекты системы, или как чертежи, подробно описывающие дизайн изделия, эскиз которого был сделан вручную. Применение моделей в качестве документации и спецификации весьма эффективно, но требует соблюдения строгой дисциплины для обеспечения непрерывного соответствия моделей разрабатываемому ПО. Использование MDD также оказывает влияние на состав команды, планирование проекта, анализ, проектирование и разработку приложения, на передачу знаний между участниками проекта, управление версиями и изменениями, а также тестирование. Кроме того, использование MDD оказывает существенное влияние на взаимодействие с заказчиком, позволяя быстро предоставить ему работающий прототип, но относительно медленно после этого доводить те его части, которые не предполагают автоматической генерации.
Применение MDD провоцирует на возможность время от времени говорить заказчику, что существенное с точки зрения потребительских качеств системы изменение может быть выполнено в течение одного дня, поскольку требует всего лишь перестановки нескольких галочек в модели и перегенерации кода, а для гораздо менее значительного с точки зрения заказчика изменения понадобятся недели, поскольку придется вручную писать значительный объем кода. Это может приводить к недоверию между разработчиком и заказчиком.
Вместе с тем, как показывает опыт, выполнение проектов с помощью MDD – интересное мероприятие, и, начав использовать методы и приемы MDD в своих проектах, вы, скорее всего, уже не откажитесь от них. Однако прежде надо учесть ряд особенностей MDD, которые не всегда очевидны заранее или сложны для освоения.
Типичные заблуждения
Иногда приходится слышать, что метод MDD приспособлен только для технических систем, а для информационных непригоден, однако мой опыт разработки на основе MDD различных систем, включая ERP/CRM-систему для малого и среднего бизнеса, тиражируемую гостиничную Web-систему, систему обнаружения мошенничества для телекоммуникационных компаний, серию систем документооборота для крупного банка и ряд других, позволяет утверждать, что бизнес-системы – это вполне благодатная область для разработки, управляемой моделями.
И наоборот, для технических систем хорошо продуманная библиотека типовых функций нередко оказывается эффективнее, чем MDD. Эффективное использование MDD возможно прежде всего при наличии различных объектов с различающимися наборами атрибутов, для которых необходимо реализовать сходную функциональность. Это могут быть всевозможные справочники, для которых реализуется типовая функциональность типа CRUD (создать, прочитать, изменить, удалить), бизнес-объекты, связанные с определенными наборами документов, или что-то еще. Встречаемые автором системы отличались малым количеством различных объектов и существенным разнообразием функциональности, требуемой для каждого из объектов, что часто делало применение MDD нецелесообразным. Однако при обработке различных объектов нередко приходилось выполнять одни и те же типовые действия: пересчет координат объектов, пересчет матриц ковариации и т.п., где выявление типовых действий и создание библиотеки типовых функций для их реализации позволило существенно ускорить разработку и отладку программного обеспечения.
Таким образом, MDD, приводящая к автоматической генерации значительных объемов кода, применима для разработки далеко не всех технических систем. Другое заблуждение – использование MDD требует применения «патентованных» средств моделирования и генерации кода, таких как мощные CASE-средства от крупнейших производителей. Это не так. С одной стороны, встроенных средств генерации, даже в самых «продвинутых» инструментах, не хватает для автоматизации генерации значительного объема кода в конкретной системе, с другой – модель, требуемая для генерации, часто оказывается много проще (ведь она предназначена для описания достаточно узкого класса объектов), чем универсальная модель в CASE-средстве. При этом набор атрибутов, как правило, существенно отличается от стандартного. Любое CASE-средство потребует доработок и настроек, вполне сравнимых по трудоемкости с разработкой простого интерфейса для ввода необходимых параметров модели и ориентированного на конкретные проекты генератора кода.
Модель для генерации кода может быть существенно компактнее, чем, например, традиционные модели, заложенные в CASE-средства. Это связано с тем, что многие атрибуты, используемые при разработке, оговариваются заранее и не меняются в ходе разработки.
Выбор проекта
Предметная область и используемые технологии не ограничивают сферу применения MDD, однако определенные ограничения на проекты существуют. В наибольшей мере подход MDD раскрывается при выполнении нескольких однотипных проектов. На одиночном проекте небольшого масштаба затраты на разработку средств автоматизации могут оказаться гораздо выше, чем на непосредственное программирование требуемой функциональности. Однако, если проект достаточно масштабен и при этом однороден по функциональности (например, система, предоставляющая массу отчетов со сходной функциональностью), то можно успешно использовать MDD и в нем.
Помимо выбора проекта, немаловажным является и выбор момента, когда принимается решение о разработке с использованием MDD. Как показывает опыт, наибольший эффект MDD дает в проектах, изначально ориентированных на ее применение. В этом случае архитектура системы изначально строится с учетом предполагаемой автоматизации генерации кода и не требует дополнительной переработки. Переход на MDD по ходу выполнения проекта может создавать напряжение в команде из-за потерь времени на разработку модели и генераторов, а также у заказчика (чем это они занимаются за мои деньги?). Кроме того, наличие нескольких выполненных «вручную» систем, код которых наверняка отличается от того, который будет генерироваться автоматически в последующих системах, может затруднить последующее сопровождение всего пула реализованных и внедренных систем и не позволит добиться ожидаемого снижения стоимости.
Подбор команды
Опыт применения MDD пока еще не слишком распространен, а готовых учебников и учебных курсов сегодня почти нет. Единственная известная автору общедоступная книга по MDD из серии RedBooks (Building SOA Solutions Using the Rational SDP, ibm.com/redbooks), хотя и содержит детальное описание технологии, представляет собой всего лишь общий разбор единственного примера разработки системы с использованием MDD. Поэтому при подборе команды важно обращать внимание не только на квалификацию кандидата, но и на готовность осваивать новую технологию.
Наибольшие сложности могут возникнуть также при выделении членов команды из штата компании. В этом случае выбрать людей, которые готовы увлеченно создавать новую технологию и обладают достаточной квалификаций, значительно сложнее. Ведь, как правило, это «звезды», которые уже заняты в наиболее критических для компании проектах. Однако именно эти люди хранят в своих головах опыт предыдущих разработок и могут быть очень полезны при разработке архитектуры и шаблонов нового проекта.
Какие именно специалисты нужны для проекта? Практически те же, что и для любого другого. Единственная новая роль – разработчик генератора кода, хотя разработка генератора – не самая сложная работа, но у человека должен быть опыт генерации текста в зависимости от параметров, например опыт разработки Web-приложений с использованием Java Server Pages (JSP) или скриптовых языков типа perl и Tcl/Tk. С другой стороны, практически у всех ролей (специалистов) появляются дополнительные задачи или несколько изменяется приоритет и объем задач, которыми они занимаются. В наибольшей степени это касается пары «аналитик – архитектор», которые должны включить в круг своих обязанностей анализ требований и поиск архитектурных решений для шаблонов генерации кода. Чтобы успешно справиться с новой задачей, эта пара должна быть достаточной креативной, способной эффективно работать в тесном контакте. Аналитик должен хорошо понимать возможности генерации кода, чтобы оценить его соответствие требованиям заказчика к разрабатываемым системам, а архитектор должен ориентироваться в типовых требованиях заказчика к функциональности систем, чтобы выбрать подходящую архитектуру связки генератор–система. Архитектор, как правило, либо сам осуществляет разработку типового кода (того кода, который будет в дальнейшем автоматически генерироваться), либо привлекает к этому наиболее квалифицированных разработчиков.
Управление изменениями и версиями
Это один из наиболее сложных аспектов выполнения проектов в технологии MDD. Вместо одного объекта для управления изменениями – программного кода проекта – появляется три со своими специфическими особенностями: код проекта, как написанный вручную, так и сгенерированный; генератор, включая, возможно, интерфейс пользователя для этого генератора; модель проекта. Без любого из этих трех компонентов нельзя «вернуться в прошлое» к той версии генератора, с помощью которого на основе той версии модели была получена та версия кода.
Модель проекта часто оказывается наиболее проблемным компонентом данной триады. Мало того, что она не всегда ведется в открытом формате (XML-файл, описанная структура СУБД), она еще имеет тенденцию менять свою структуру. Например, в нее могут быть добавлены новые атрибуты, которые оказались необходимы для генерации кода в последнем проекте для нового заказчика. Если с первой проблемой, как правило, удается справиться за счет имеющихся в большинстве CASE-средств утилит импорта/экспорта данных в открытые форматы, то со второй сложнее. Особенно если вы ведете несколько ветвей модели и генератора и пытаетесь перенести изменения из одной ветви в другую. Дело в том, что изменения структуры не всегда сводятся к элементарному добавлению нового атрибута. Иногда происходит как бы «расщепление» атрибута, при котором один старый атрибут заменяется на два новых. И, чтобы вернуться к старому составу атрибутов, необходимо описать правила его вычисления по паре новых. В таких ситуациях приходится очень тщательно анализировать изменения, прежде чем понять, могут ли они быть перенесены автоматически. И это, пожалуй, одна из наиболее существенных технических сложностей использования MDD.
Передача знаний и дисциплина
Традиционно, если разработчики используют какие-либо инструментальные средства, даже предназначенные для MDD, предполагается, что они хорошо знают эти средства еще до начала проекта. Если же инструментарий создается и совершенствуется практически одновременно с его использованием в проекте, обучиться ему заранее невозможно. Значит, необходимо наладить постоянное взаимодействие тех, кто разрабатывает генераторы/трансформации, и тех, кто их использует. Если это удастся, то разработчики инструментария будут в курсе всех претензий со стороны пользователей, которыми в данном случае оказываются разработчики проектов.
Еще одна особенность таких проектов, на которую следует обратить внимание, – более долгий срок ввода в проект дополнительных разработчиков или замены выбывших. Вновь включаемого в проект разработчика необходимо обучить пользованию самодельными инструментальными средствами, и на это требуется определенное время. К счастью, оно обычно не превышает недели, но в экстренных ситуациях и это долго. Чтобы избежать подобных проблем, желательно иметь в резерве обученных специалистов. Одним из наиболее эффективных со многих точек зрения способов подготовки таких людей является привлечение разработчиков, занятых одновременно в двух и более проектах, по крайней мере один из которых является MDD-проектом. Кстати, это помогает решать и определенные психологические проблемы, которые могут возникать при использовании MDD-технологий, – участники такого проекта не превращаются в «закрытую касту», что уменьшает разговоры о необходимости использования тех или иных процедур MDD.
Помимо собственно передачи знаний, от участников MDD-проекта требуется обязательное использование этих знаний. Какой смысл в поиске типовых решений и их автоматизации, если разработчик говорит, что ему это не нравится, и начинает изобретать собственный велосипед? Соблюдение технологической дисциплины – одна из принципиальных для российских разработчиков проблем. Разработчик должен создавать порученный ему код посредством указанного инструментария, что актуально не только при использовании MDD. Встречается ситуация, когда одинаковые по функциональности фрагменты кода, выполненные в одном проекте разными разработчиками, различаются во всем. В случае использования MDD проблема соблюдения технологической дисциплины становится ключевой, и получить реальный эффект можно только при условии достаточно жесткого ее соблюдения.
Особенности тестирования
При использовании MDD нужно различать тестирование шаблонов, генератора, превращающего эти шаблоны в код, и тестирование полученного кода. Первая задача тестировщиков – тестирование генератора и шаблонов, во время которого надо проверить, что код генерируется в соответствии с моделью и действительно обеспечивает требуемую функциональность. Чтобы обеспечить такое тестирование как на начальной стадии проекта, так и при последующих изменениях генератора и шаблонов, на генератор и шаблоны должна разрабатываться и вестись типовая проектная документация, например ТЗ или спецификация. Эта документация также может упростить упомянутые проблемы передачи знаний между участниками проекта.
Наличие качественной документации на генератор и шаблоны может быть весьма полезным и в том случае, когда один и тот же генератор используется при выполнении заказов для различных клиентов. В этом случае спецификация генератора и шаблонов позволяет продемонстрировать заказчику рамки, за пределами которых разработка ПО будет требовать существенно больших ресурсов.
Тестирование генератора и шаблонов фактически сводится к тестированию полученного с их помощью кода. При этом должны проверяться не только те наборы атрибутов и шаблоны, которые предполагается непосредственно использовать в ближайшем проекте, но и все, допускаемые спецификацией. К тестированию обязательно должны привлекаться аналитик и архитектор проекта. Они в данном случае являются одновременно и разработчиками и заказчиками и должны оценить возможность получения с помощью генератора кода с требуемой функциональностью, а также качество этого кода. Эти задачи, как правило, выходят за стандартные навыки тестировщиков.
Тестирование генератора и шаблонов может доставить немало работы тестировщикам. Зато после этого базовая функциональность проекта (реализуемая с помощью автоматической генерации кода) потребует лишь минимального регрессионного тестирования, а несколько больший объем тестирования понадобится только в случае внесения изменений непосредственно в шаблоны или генератор. В этом случае, как правило, можно обойтись относительно небольшим объемом тестирования лишь изменяемых функций.
Основное внимание на последующих стадиях проекта тестировщики должны уделять функциональности, которая была реализована вручную. Помимо всего прочего это требует налаженного информирования тестировщиков относительно того, как реализуется та или иная функциональность.
При выполнении серии однотипных проектов разработка и тестирование генератора и шаблонов проводится однократно, но в ходе каждого проекта, как правило, производится кастомизация генератора и шаблонов. Сгенерированный с помощью обновленных шаблонов код, а чаще – пользовательские интерфейсы демонстрируются заказчику. В случае наличия у заказчика замечаний может выполняться дополнительная кастомизация шаблонов.
Если ничего не получается
Иногда по результатам анализа вы убеждаетесь, что проект плохо подходит для использования MDD. Например, та функциональность, которую вы считали типовой, при ближайшем рассмотрении оказалась уникальной для разных типов объектов. В итоге объем кода, который можно сгенерировать, не переусложняя генератор, оказывается слишком мал для того, чтобы оправдать разработку генератора и шаблонов. Иногда приходится отказываться от использования MDD по ходу выполнения проекта или серии проектов по другим причинам. Например, сменился руководитель со стороны разработчика или заказчика, а новый не принимает такой подход в принципе.
В любом случае попытка использования MDD, как правило, оказывает положительное влияние на проект. Если вы обратили внимание на MDD, значит, занялись углубленным архитектурным анализом системы, выделили какую-то типовую функциональность и даже задумались о том, как ее лучше реализовать.
Алексей Закис (azakis@mail.ru) – независимый автор (Москва).
MDD на практике
Реальная гостиничная система предполагает ведение десятков тарифов, правил начисления скидок, бонусов и т.п., что делает управление такой системой невозможным без применения справочников различной структуры, не говоря уже об очевидных справочниках номерного фонда, включая типы комнат и возможные виды из окна. Каждый по отдельности такой справочник достаточно прост, но их количество означало большой объем работ, который был эффективно выполнен с использованием MDD.
Системы банковского документооборота, с которыми пришлось столкнуться автору, предназначались для работы с документами, связанными с банковскими бизнес-объектами: контрагентами или клиентами, займами, залогами и т.п. Как правило, системы позволяли найти тот или иной объект и/или связанные с ним документы (например, описания строений, под которые выдавался залог) и далее выполнять типовой набор базисных действий с документами (создание нового документа или его версии, перепривязка документа от одного объекта к другому и т.п.). Основное отличие между системами было в наборе атрибутов бизнес-объекта и связанных с ним документов. Кроме того, в ряде систем была несколько расширена функциональность, позволявшая выполнять какие-то действия, специфические для данного бизнес-объекта. Разработанный генератор кода позволял генерировать пользовательский интерфейс и типовую функциональность для бизнес-объектов и документов с произвольным (описанным в модели) набором атрибутов. Ручной доработки требовала только специфическая функциональность для отдельных бизнес объектов.
Система обнаружения мошенничества включала в себя подсистему сбора исходной статистики и ее первоначальной обработки (агрегирование), а также подсистему, предназначенную для операторов, осуществляющих анализ этих данных. Еще одна подсистема предоставляла пользователям доступ к определенным отчетам, которые строились по подготовленной статистике. По функциональности она была близка к системам бизнес-анализа и позволяла выбрать данные для демонстрации по указанным критериям и осуществить их сортировку, фильтрацию и анализ вглубь (drill down). Поскольку заказчиком не предполагалось использование в проекте готовых средств бизнес-анализа, одним из возможных подходов было создание генератора, который по описанию набора данных в отчете (состав полей, возможность анализа вглубь по определенному полю и т.п.) формировал бы более сотни экранных форм для работы с данными..
Фундамент метамоделирования
С той поры как люди начали пользоваться компьютерами, исследователи занимаются повышением уровня абстракции, на котором программисты пишут коды. Метод разработки на базе моделей стал естественным продолжением традиции абстрагирования от первых компиляторов до объектно-ориентированных языков и далее, позволяя программистам справляться с задачами, о решении которых раньше можно было только мечтать.
http://www.osp.ru/os/2003/12/183688
Модели должны работать
Стив Меллор, один из создателей концепции разработки на базе моделей, рассказывает о преимуществах модельного программирования.
