CC BY
21
Сайт 2
V \
\е r \ Сервис 2- '
Механизм управления пользователями *
щА
Механизм Механизм безопасности индексирования и поиска
Ядро системы
Вспомогательные 1 классы и механизмы >
Сайт 1
У.. 'f
'■--■-г'
С \ Сеоаис )
Рис. 1. Архитектура системы ißortal
Физически законченное приложение представляет собой SAR или EAR-архив, объединяющий в себе необходимый набор компонентов. Так, например, для системы управления новостями этот архив будет включать новостной модуль и фабрику для управления хранением и доступом к новостям.
Как видно из приведённой выше архитектуры ¡.Portal, при разработке законченного решения необходимо создать достаточно большое число программных артефактов, начиная от собственно реализации компонентов на языке Java и заканчивая дескрипторами развёртывания. Множество из этих артефактов имеют регулярную структуру, что даёт возможность автоматизировать процесс их создания.
Исходными данными для создания каркаса приложения в ¡.Portal MSE является набор UML-диаграмм. Таким образом, первый этап создания приложения заключается в формализации требований к программному продукту на основе моделей. При этом формируется общее представление о предметной области и готовятся данные для формирования структуры каркаса.
Большинство программных продуктов, особенно в области управления бизнес-данными, требуют хранения огромного числа вспомогательных данных. Как правило, эти данные хранятся 8 виде справочников, структура которых в большинстве случаев известна ещё на начальном этапе проектирования системы и не подвержена изменениям во время всего жизненного цикла приложения. Структуры данных такого рода чаще всего наиболее подходят для автоматической генерации на основе моделей.
Ещё одна важная особенность первого этапа ¡.Portal MSE - документирование программной реализации. Несмотря на широкое распространение Agile-методик разработки [4,5], заказчик программного продукта, как правило, хочет увидеть формализованное описание системы в виде технического задания. Созданные на первом этапе модели позволяют найти общий язык с заказчиком и более чётко сформулировать требования к системе,
На втором этапе в ¡.Portal MSE происходит генерация программного кода на основе преобразования Model-to-text. При этом формируются основные структуры для работы с данными: фабрики и модули. Широко известен факт, что объектную модель приложения можно достаточно легко преобразовать в реляционную модель базы данных. На этом принципе основаны многие ORM-framework, такие как Hibernate и TopLink. 8 программной реализации классов поддержки ¡.Portal MSE предусмотрена эталонная реализация преобразования модели в SQL-скрипт для генерации базы на СУБД FireBird.
Также на этом этапе генерируются необходимые дескрипторы развёртывания и интерфейсные шаблоны для обеспечения базовой возможности управления данными приложения. Таким образом, на втором этапе создаётся работоспособный каркас приложения, служащий основой для последующей разработки. Также создаётся набор тестов для контроля его функционирования.
На третьем этапе происходит доработка созданного каркаса с учётом требований бизнес-логики и дизайнеров интерфейса. Данный этап требует полного использования одной из Agile-методик разработки. Автором в данном случае рекомендуется использование ХР-programming (экстремальное программирование).
Модель разработки ¡.Portal MSE включает три уровня. В данной статье подробно рассматривается лишь нижний уровень, этапы которого описаны выше. Всю же модель можно увидеть на рис. 2.
Рис. 2. Уровни ¡Portal MSE
В предыдущем разделе было указано, что второй этап ¡.Portal MSE включает генерацию каркаса приложения с использованием Model-to-text преобразования. Это одна из концепции MDA (Model driven architecture), позволяющая формировать на базе набора моделей реализацию программной системы с использованием конкретных технологий.
В качестве основы для разработки при данном подходе выступают модели, несущие в себе всю структурную информацию будущего программного продукта ¡.Portal MSE - диаграммы классов.
ВЕСТНИК ИрГТУ №1 (29) 2007
7
[®] Кафедра молодых
От программистов часто приходится слышать, что разработка моделей бессмысленна, Рассмотрим основные доводы, приводимые в этом случае:
• Разработка моделей - очень длительный и неинтересный процесс. Однако графические модели в ¡.Portal MSE служат основой для генерации каркаса приложения. Написание вручную большого числа вспомогательных артефактов системы приводит к большому объёму механической работы, при которой допускается множество ошибок.
• Модели нужны лишь для документирования, они не имеют реальной ценности для программиста, так как Java-код сам по себе является моделью данных. При такой точке зрения не учитываются два важных аспекта. Во-первых, графические модели гораздо более наглядны для ключевых пользователей заказчика, чем словесное описание и уж, тем более, программный код. Это позволяет общаться с представителями заказчика на «одном языке» и как следствие выявить большинство особенностей и требований системы на этапе проектирования. Во-вторых, программный код является удобной для чтения моделью лишь в случае, когда используются достаточно простые шаблоны работы с данными. В случае использования сложных многоуровневых моделей разработки не всегда достаточно легко представить модель данных из кода системы.
• Модель является упрощением реальной ситуации, невозможно сгенерировать из модели реальное приложение. В какой-то мере этот довод является верным. Однако в ¡.Portal MSE предполагается лишь генерация каркаса приложения с последующей его доработкой командой разработчиков. Кроме того, в реальной жизни большая часть функционала программного продукта имеет достаточно регулярную структуру. Так, в частности, рассмотренный выше пример с управлением справочниками подразумевает использование стандартных элементов управления, ручное создание которых потребовало бы много механической работы по кодированию.
Главным преимуществом, которое вносит в разработку веб-приложений второй этап ¡.Portal MSE, является использование во всех приложениях типовых шаблонов проектирования и реализация программных компонентов. Ни для кого не является секретом, что сопровождение разработанных программных решений требует от их владельца значительных инвестиций. Использование типовых шаблонов управления данными позволяет уменьшить время, требуемое на изменение программного кода в соответствии с новыми бизнес-требованиями.
Test-Driven Development (TDD) [6] - одна из наиболее популярных концепций, используемых в настоящее время при разработке приложений. Основа такой популярности TDD - широкое распространение Agile-методик разработки и значительный рост их популярности.
Как было отмечено ранее, при генерации каркаса приложения в ¡.Portal MSE создаётся набор тестов для модульного тестирования приложения [7]. Например, при
создании фабрики для управления жизненным циклом новостей генерируются реализации стандартных методов класса SimpleLifeCycleDactorySupport:
• public abstract Item createlfem(Dn parentDn, Item item);
• public abstract Item deleteltem(ltem item);
• public abstract Item editltem(ltem item).
Эти методы отвечают за создание, изменение и удаление объектов из хранилища данных. Так как это public методы фабрики - в соответствии с TDD для них должны быть подготовлены модульные тесты. Такие тесты как раз и генерируются при создании каркаса приложения из модели. Данные тесты требуют специализированной среды исполнения в контексте сервера приложений JBoss, что как раз и учитывается при их генерации.
Почему ¡.Portal MSE включает в себя TDD?
Во-первых, третий этап описываемой технологии подразумевает использование Agile для реализации каркаса. А большинство Agile-техник требуют использования тестов для верификации программного кода.
Во-вторых, любое применение рефакторинга к программному коду требует наличия тестов для проверки его работоспособности [8]. Чем более полным является набор тестов для приложения, тем более «агрессивный» рефакторинг допустимо применять к программному коду. Например, все современные среды разработки позволяют применять шаблон рефакторинга «переименование метода». Однако это не всегда безопасно. Если этот метод вызывается через java reflection, то среда разработки не сможет установить этот факт и изменить исходный код. Соответственно в данной ситуации может возникнуть ошибка, которая достаточно легко может быть найдена на уровне модульного тестирования.
В-третьих, написание тестов по своей сути является одной из моделей документирования исходного кода. В данном случае под документацией понимается набор исполняемых файлов, представляющих собой исполняемую спецификацию продукта. Тем самым получается, что внесение изменений в программный продукт начинается с изменения тестов, что приводит к переходу в красную стадию разработки, когда некоторые из тестов не проходят. После исправления исходного кода переходят к зелёной стадии, когда все тесты проходят успешно. А уже далее применяют рефакторинг для повышения качества и читаемости кода приложения.
В-четвёртых, модульное тестирование позволяет снизить общее время отладки приложения за счёт сокращения времени на локализацию и исправление ошибок. Особенно это важно при внесении изменений в функционирующую систему.
В-пятых, тесты служат отличной основой для формирования многих метрик по проекту, Так, общее количество тестов характеризует объём реализуемого кода, Соотношение между числом public-методов и тестов характеризует степень покрытия тестами функционала системы, В соответствии с ¡.Portal MSE оно должно превышать
8
ВЕСТНИК ИрГТУ №1 (29) 2007
