Предисловие переводчика

Скотт Амблер – известный, судя по Internet, специалист в области методологий разработки программного обеспечения. Его даже называют “гуру” быстрых (agile) методов разработки. Сам он ассоциирует себя с двумя компаниями – Ambisoft и Robin International – и называет себя старшим консультантом в обеих компаниях. Судя по фотографиям, Амблер достаточно молодой человек, а судя по числу написанных и изданных им книг, а также объему подготовленных им материалов, размещенных на www.ambysoft.com, исключительно активный. Статью, перевод которой мы вам предлагаем, Амблер написал специально для портала www.odbms.org (хотя, похоже, что в этом его стимулировала компания db4objects, о которой мы еще поговорим).

Название статьи не совсем соответствует ее содержанию. Про разработку объектных баз данных в ней почти ничего не говорится. Большая часть статьи содержит обзор быстрых методов разработки, и в этой части нет каких-либо откровений, хотя она дает возможность в целом понять, что представляет из себя быстрый подход к разработке программного обеспечения. По нашему мнению, некоторой оригинальностью отличается только шестой раздел статьи (“Быстрый подход с применением объектных баз данных”), хотя и его название не совсем соответствует содержанию. Почти весь раздел посвящен трудностям, с которыми сталкиваются быстрые разработчики (автор вводит новый термин для обозначения этой категории разработчиков – агилисты) при потребности использовать реляционные базы данных. По нашему мнению, этот раздел заслуживает отдельного комментария.

Автор выдвигает три тезиса:

1. технологическое несоответствие объектной технологии, на которой, в основном, базируется быстрая разработка, и технология реляционных баз данных;

2. культурное несоответствие объектных разработчиков и специалистов, называемых автором “профессионалами в области данных”;

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

Что касается первого тезиса (technology impedance mismatch), то именно он лежал в основе Манифеста объектно-ориентированных баз данных, опубликованного в конце 1990-х и способствовавшего в то время развитию технологии объектно-ориентированных баз данных. Тогда под несоответствием понималось, главным образом, серьезное различие в системах типов, поддерживаемых в языках программирования и реляционных (SQL-ориентированных) СУБД. С той поры прошло уже много лет, и в современном стандарте языка SQL (и основных реализациях РСУБД) поддерживается очень развитая система типов (во многом схожая с системой типов языка Java). Поэтому об этой разновидности технологического несоответствия говорить уже не приходится, и автор напирает на несоответствие по причине потребности в “объектно-реляционном” отображения, если разработка ведется в объектной технологии, а базы данных используются реляционные. Но и об этом нужно говорить более точно и аккуратно. У языка SQL имеется своя объектная модель, и SQL-ориентированную базу данных (по крайней мере, если использовать IBM DB2 или Oracle) можно спроектировать и использовать в объектном стиле. Так что, похоже, что в действительности речь идет о том, что при использовании в быстрых методах языка SQL нужно хорошо знать этот язык, а быстро узнать его у агилистов не получается.

Со вторым тезисом до сих пор мне сталкиваться не приходилось. По-видимому, “профессионалами в области данных” автор называет специалистов, которые умеют производить логическое и физическое проектирование баз данных. Мне всегда казалось, что при создании приложения, для которого создается собственная база данных, должен вестись единый проект, поскольку особенности конструкции базы данных должны соответствовать общим требованиям к приложению. Какой подход выбирается для реализации всего проекта – это вопрос предпочтений проектной группы. И вот выясняется, что в группе, выполняющей проект быстрыми методами, проектировщики реляционной базы данных не вписываются в коллектив разработчиков. Очень может быть, что автор руководствуется своим личным опытом, но приводимые им доводы не очень убедительны. Фактически он утверждает, что “профессионалы в области данных” не хотят (или не могут) пользоваться быстрыми методами и поэтому нужно отказаться от реляционных баз данных и перейти на использование объектных баз данных (для разработки которых, по всей видимости, профессионалы не требуются). Мне кажется, что этот тезис открывает простор для дискуссии (и это одна из причин, по которой мы решили опубликовать перевод статьи Амблера).

Свой третий тезис автор сам расценивает не очень серьезно. Действительно, откуда бы взялись инструменты быстрой разработки реляционных баз данных, если “профессионалы в области данных” быстрой разработкой пользоваться не хотят (или не могут). И в связи с этим, я вижу некоторое противоречие с замечанием автора, что сообщество open source озабочено отсутствие средств быстрой разработки баз данных и стремится закрыть эту брешь. Кто же будет пользоваться этими средствами? Или в этом случае для проектирования реляционных баз данных профессионалы уже не потребуются?

В конце статьи, наконец, выясняется, к чему ведет автор. Около года тому назад компания db4objects объявила о выходе своей объектно-ориентированной СУБД db4o, доступной с исходными кодами (система написана на языке Java) по лицензии GPL. Вернее, компания придерживается подхода двойного лицензирования: для клиентов, желающих использовать систему для построения коммерческих приложений, обеспечивается специальная коммерческая лицензия. По этому поводу (как и в случае MySQL) разработка системы ведется исключительно силами сотрудников компании. Суть последнего раздела статьи Амблера в этом контексте сводится к тому, что использование db4o при быстрой разработке приложений баз данных снимает все противоречия и делает жизнь агилистов счастливой. Дай Бог, чтобы это так и было! Но только у меня имеются сомнения.

Я не слишком глубоко познакомился с техническим устройством db4o, но у меня уже создалось впечатление, что серьезных технологических новшеств в этой системе нет. Подобно тому, как когда то разработчики одной из самых успешных объектно-ориентированных СУБД Object Store начинали свой проект с полной привязки с среде языка C++, разработчики db4o ориентируются на среды Java и .NET. Как и раньше, основными козырями системы объявляется возможность сохранения в базе данных объектов произвольно сложной структуры, с которыми можно работать так же, как если бы они создавались в соответствующей программной среде во время выполнения приложения. Почему-то в качестве особого достоинства системы объявляется поддержка ACID-транзакций, хотя, вроде бы, это является обязательной характеристикой любой современной СУБД.

Интересно, что компания db4objects (пока) даже и не претендует на конкуренцию с реляционными системами в наиболее доходном секторе рынка – секторе корпоративных информационных систем. Подобно многим известным ранее начинающим компаниям, db4objects претендует на соответствие возможностей своего продукта потребностям встроенных систем, в которых база данных является неотъемлемой принадлежностью приложения и не требует внешнего админитстрирования. Мне кажется, что в этой области у db4o шансы действительно имеются, если СУБД работает достаточно устойчиво. И, скорее всего, быстрые методы Скотта Амблера в совокупностью с технологией db4o здесь смогут принести успех.

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

Современные процессы разработки программного обеспечения, такие как Rational Unified Process (RUP), Extreme Programming (XP) и Scrum, являются эволюционными по своей природе, и многие из них – быстрые (agile). При применении эволюционного подхода вы работаете одновременно в итерационной и инкрементальном режимах; быстрый подход сочетает эволюционность с высоким уровнем сотрудничества. Работая в итерационном режиме, вы в каждый момент времени немного моделируете, немного тестируете, немного кодируете и немного развертываете, потом еще немного, и еще немного, и т.д. При использовании инкрементального подхода вы организуете свою систему в виде последовательности выпусков, а не одного большого выпуска. Когда группа разработчиков прибегает к коллаборативному подходу, ее участники активно стараются найти способы эффективной совместной работы; следует даже добиваться того, чтобы инициаторы проекта (заказчики системы) являлись активными членами группы.

В этой статье приводится обзор набора быстрых методов для разработки программного обеспечения, ориентированного на работу с данными. В большинстве работ, посвященных этому предмету, в частности, в моих книгах Agile Database Techniques (John Wiley Publishing, 2003) и Database Refactoring (Prentice Hall PTR, January 2006), предполагается использование объектной технологии, например, Java или C# в клиентской части приложения и технологии реляционных баз данных, например, Oracle или DB2 в серверной части. К сожалению, по причинам наличия несоответствия между объектной и реляционной парадигмами и отсутствия в настоящее время соответствующего инструментария, возможности применения быстрых методов здесь ограничены. Как вы увидите, гораздо легче применять быстрый подход при использовании технологии объектных систем управления базами данных (ОСУБД).

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

1. Рефакторинг
2. Быстрое моделирование
3. Постоянное регрессионное тестирование
4. Конфигурационное управление
5. «Песочницы» (sandbox) разработчиков

1. Рефакторинг

Рефакторинг (Fowler 1999) – это дисциплинированный способ внесения небольших изменений в исходный код для совершенствования его конструкции, упрощения работы с ним. Важным аспектом рефакторинга является то, что он сохраняет неизменной поведенческую семантику кода – в процессе рефакторинга никогда ничего не добавляется и не удаляется, только совершенствуется качество кода. Примером рефакторинга могло бы быть переименование операции getPersons() в getPeople(). Для реализации этого рефакторинга необходимо изменить определение операции, а затем поменять каждый вызов этой операции в коде приложения. Процесс рефакторинга не завершается до тех пор, пока код снова не заработает так, как раньше.

Аналогично, рефакторинг баз данных (Ambler 2003, Ambler & Sadalage 2006) – это простое изменение схемы реляционной базы данных, которое улучшает ее конструкцию, оставляя неизменной ее поведенческую и информационную семантику. Рефакторингу можно подвергать либо структурные аспекты схемы базы данных, например, определения таблиц и представлений, либо функциональные аспекты, например, хранимые процедуры и триггеры. В процессе рефакторинга схемы базы данных требуется переработать не только саму схему, но и внешние программы (бизнес-приложения или программы извлечения данных), связанные с этой схемой. Очевидно, что рефакторинг баз данных реализуется сложнее рефакторинга кода, потому что не допускается разрушение ни данных, ни функциональных возможностей, поэтому здесь требуется осторожность.

2. Быстрое моделирование

Независимо от того, что вы могли слышать раньше, эволюционные и быстрые методы не являются просто новым названием «кодирования и устранения ошибок». По-прежнему требуется анализировать требования и продумывать архитектуру и конструкцию системы до ее построения, и один из хороших подходов состоит в моделировании до кодирования. На рис. 1 изображен жизненный цикл Быстрой Разработки под Управлением Модели (Agile Model Driven Development, AMDD) (Ambler 2004). При использовании AMDD в начале проекта создаются начальные высокоуровневые модели, которые обеспечивают общее представление проблемной области, которую вы затрагиваете, а также потенциальной архитектуры будущей системы. Одной из моделей, которые обычно создаются, является «тонкая» («slim») концептуальная/прикладная модель, описывающая основные бизнес-объекты и связи между ними. Вашей целью является продумывание основных проблем в начале проекта без немедленного погружения в пока еще ненужные детали – детали можно проработать позже, когда это понадобится (just-in-time, JIT), путем мозгового штурма модели. Более подробно метод AMDD описывается на странице http://www.agilemodeling.com/essays/amdd.htm.

Рис. 1. Жизненный цикл AMDD

3. Постоянное регрессионное тестирование

Чтобы безопасно изменять существующее программное обеспечение с целью рефакторинга или добавления новых функций, требуется возможность проверки, не было ли что-нибудь повреждено в процессе внесения изменений. Другими словами, требуется возможность пропуска на системе полного регрессионного теста. При обнаружении какого-либо повреждения необходимо либо его исправить, либо откатить изменения. В сообществе быстрой разработки среди программистов все более принято разрабатывать полный тестовый набор в параллель с разработкой приложения, а в действительности приверженцы быстрого подхода (агилисты, agilest) предпочитают писать код тестов до написания «настоящего» кода. Не следует ли тестировать и базу данных подобно тому, как тестируется исходный тест приложения? Внутри базы данных реализуется важная бизнес-логика в форме хранимых процедур, правил проверки корректности данных и правил ссылочной целостности (referential integrity, RI). Очевидно, что эту бизнес-логику следует тщательно тестировать.

Метод разработки, начинающийся с создания тестов (test-first development, TFD), называемый также программированием, начинающимся с создания тестов (test-first programming), является эволюционным подходом, при котором до написания нового функционального кода вы должны написать тест, который не проходит на существующем коде. Шаги TFD изображены на рис. 2 в виде диаграммы активностей UML. Разработка под управлением тестов (tеst-driven development, TDD) (Astels 2003; Beck 2003) – это комбинация TFD и рефакторинга. Сначала вы пишите код, применяя подход TFD, а когда он работает, вы обеспечиваете высокое качество разработки путем применения рефакторинга. После рефакторинга требуется снова пропустить регрессионные тесты для проверки того, что ничего не повреждено.

Рис. 2. Метод разработки, начинающийся с создания тестов

4. Конфигурационное управление

Иногда изменение в системе оказывается очень плохой идеей, и нужно откатить систему в состояние до внесения этого изменения. Например, переименование столбца Customer.Fname в Customer.FirstName может нарушить работоспособность 50 внешних программ, и стоимость их модификации может оказаться слишком высокой. Подобно тому, как разработчики помещают свое имущество (исходные коды и модели разработки) под охрану конфигурационного управления, профессионалам следует аналогично поступать со следующими предметами:

• Скрипты DLL (data definition language) для создания схемы базы данных
• Скрипты загрузки/извлечения данных
• Файлы моделей данных
• Метаданные объектно-реляционного отображения
• Эталонные данные
• Определения хранимых процедур и триггеров
• Определения представлений
• Ограничения ссылочной целостности
• Тестовые данные
• Скрипты генерации тестовых данных
• Тестовые скрипты

5. Песочницы разработчиков

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

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

Разработчики нуждаются в своих собственных физических песочницах для работы в них, в копии исходного кода для его развития и в копии базы данных для работы с ней и ее развития. При наличии собственной среды они могут безопасно вносить изменения, тестировать их и либо принимать их, либо отбрасывать. Если разработчик считает изменение жизнеспособным, он продвигает его в совместно используемую среду проекта, тестирует его и заносит под контроль CM, чтобы другие члены группы могли его взять. В конце концов группа продвигает свою работу в какую либо тестовую демо-среду и/или среду подготовки. Это продвижение часто происходит один раз на весь цикл разработки, хотя может происходить более или менее часто в зависимости от особенностей среды (чем более часто продвигается система, тем больше шансы получить значительную обратную связь). Наконец, когда система проходит приемку и системное тестирование, она внедряется в производство.

Рис. 3. Логические песочницы для обеспечения безопасности разработчиков

6. Быстрый подход с применением объектных баз данных

Я полагаю, что быстрым быть проще при использовании технологии объектных баз данных (ОСУБД), чем технологии РСУБД, на основе трех соображений:

1. Несоответствие технологий. Объектная и реляционная технологии основываются на разных парадигмах, в результате между ними имеется “потеря соответствия” (“ impedance mismatch”), которую необходимо преодолевать. На рис. 4 показаны стеки приложений при использовании технологий РСУБД и ОСУБД. Как можно видеть, при использовании технологии РСУБД на уровне персистентности требуется реализовывать объектно-релляционное отображение между объектной схемой и схемой данных, в то время как при использовании технологии ОСУБД эта проблема отсутствует. При использовании технологии РСУБД приходится выполнять больше работы, приходится определять объектную схему и схему данных и отображения между ними, а затем все это необходимо развивать по мере появления новых требований к приложению. При использовании технологии ОСУБД нужно всего лишь определить и развивать объектную схему приложения.
2. Несоответствие культур. Под несоответствием культур мы понимаем разницу в культуре объектных разработчиков и пррофессионалов в области данных. Объектные разработчики, включая тех, которые используют технологию ОСУБД, годами работают в эволюционной манере и легко переходят к быстрым методологиям. Профессионалы в области данных, с другой стороны, тяготеют к традиционному подходу, который обычно является по своей природе последовательным и часто предписывающим (т.е. бюрократическим). Еще хуже то, что, как показывает таб. 1, сообщество данных в основном избегает новых методов разработки, таких как AMDD и TDD, в то время как объектные разработчики охотно их принимают. Эти культурные различия часто проявляются в дискуссиях относительно способа выполнения работы, излишних совещаниях, дополнительной работе части профессионалов в области данных, которые всего лишь должны делать свое дело по своим правилам, и даже двойной работе, поскольку и в объектной группе, и в группе данных возникает свое видение концептуальной и проектной схем. Более подробное обсуждение этой темы см. на www.agiledata.org.
3. Поддержка инструментальных средств. В настоящее отсутствует инструментальная поддержка рефакторинга схем РСУБД и, в меньшей степени, автономного тестирования РСУБД. Инструментальные средства рефакторинга и автономного тестирования для объектной технологии являются достаточно зрелыми, что повышает производительность труда объектных разработчиков. Я очень надеюсь, что в течение нескольких следующих лет инструментальная поддержка быстрой разработки РСУБД улучшится, но в настоящее время ситуация не является блестящей.

Рис. 4. Сравнение стеков приложений при использовании РСУБД и ОСУБД

Быстрые методы с использованием неагрессивной объектной базы данных db4o

Основная идея состоит в том, что чем менее агрессивной является стратегия персистентности, тем проще будет разрабатывать, развивать и сопровождать приложения. ОСУБД с открытым кодом db4objects, доступная под лицензией GPL на сайте www.db4o.com, является хорошим примером неагрессивной стратегией персистентности для платформ Java и .NET. Запросы задаются на основе открытого API, который просто используется и развивается – доступ к данным производится через собственный исходный код, который можно подвергать рефакторингу и тестированию с использованием существующих средств разработки. Отсутствуют техническией и культурные несоответствия, которые нужно было бы преодолевать, и инструменты, требуемые для быстрого развития схемы, уже существуют.

Взгляд мельком: Применение быстрых методов с использованием двух технологий СУБД

Метод	При использовании технологии РСУБД	При использовании технологии ОСУБД
1. Рефакторинг	Средства рефакторинга баз данных пока не существуют Технология РСУБД не поддерживает простую эволюцию схемы, поскольку она часто основывается на предположении о последовательном подходе к разработке	Используются существующие инструментальные средства рефакторинга Технология ОСУБД поддерживает гораздо более простую эволюцию схемы, поскольку она часто основывается на предположении, что разработчики будут следовать эволюционному подходу
2. Быстрое моделирование	Требуется моделировать как объектную схему, так и схему данных, а затем организовывать их отображения Реально возникновение конфликтов, если это делается разными группами (как часто и бывает)	Нужно моделировать только объектную схему
3. Постоянное регрессионное тестирование	Средства тестирования РСУБД все еще развиваются, хотя сообщество open source быстро наверстывает упущенное Средства тестирования данных очень зрелые, но часто дорогие Для многих профессионалов в области данных TDD является новой идеей	Средства автономного тестирования для объектной технологии, такие как Junit и CSUnit, являются очень зрелыми. В сообществе быстрого программирования хорошо воспринимается TDD
4. Конфигурационное управление	Требуется поставить все артифакты разработки под контроль CM	Требуется поставить все артифакты разработки под контроль CM
5. Песочницы разработчиков	Требуются все средства разработки, объектный код и экземпляр базы данных	Требуются все средства разработки и объектный код

Таблица 1. Применение быстрых методов с использованием двух технологий

7. Резюме

Современные процессы разработки программного обеспечения являются по своей природе эволюционными и достаточно часто быстрыми. Если организация принимает быстрый подход, то ее IT-профессионалы должны принять на вооружение соответствующие методы, которые позволят им работать в быстрой манере. Эти методы включают рефакторинг, быстрое моделирование, постоянное регрессионное тестирование, конфигурационное управление всеми активами разработки и отдельные песочницы для работы разработчиков. Использование РСУБД усложняет применение этих методов по причинам технического несоответствия, культурного несоответствия и отсутствия в настоящее время инструментальной поддержки.

8. Литература

Ambler, S.W. (2002). Agile Modeling: Best Practices for the Unified Process and Extreme Programming. New York: John Wiley & Sons. www.ambysoft.com/agileModeling.html

Ambler, S.W. (2003). Agile Database Techniques: Effective Strategies for the Agile Software Developer. New York: John Wiley & Sons. www.ambysoft.com/agileDatabaseTechniques.html

Ambler, S.W. (2004). The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. New York: Cambridge University Press. www.ambysoft.com/theObjectPrimer.html

Ambler, S.W. and Sadalage, P. (2006). Database Refactoring: Evolutionary Database Design. Boston: Prentice Hall PTR. www.ambysoft.com/databaseRefactoring.html

Astels D. (2003). Test Driven Development: A Practical Guide. Upper Saddle River, NJ: Prentice Hall.

Beck, K. (2003). Test Driven Development: By Example. Boston, MA: Addison-Wesley.

Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Menlo Park, CA: Addison-Wesley Longman.

Примечание.
¹Часть этой статьи позаимствована с изменениями из книги S. Ambler и P. Sadalage «Database Refactoring: Evolutionary Database Design», выходящей в январе 2006 г. в издательстве Prentice Hall PTR.