Быстрые методы для объектных баз данных s-networks : Мероприятия

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

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

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

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

технологическое несоответствие объектной технологии, на которой, в основном, базируется быстрая разработка, и технологияТехнология (от греч. — искусство, мастерство, умение; др.-греч. — мысль, причина; методика, способ производства)— комплекс организационных мер, операций и приемов, направленных на изготовление, обслуживание, ремонт и/или эксплуатацию изделия с номинальным качеством и оптимальными затратами, и обусловленных текущим уровнем развития науки, техники и общества в целом. реляционных баз данных;
культурное несоответствиеМногозначная функция — обобщение понятия функции, допускающее наличие нескольких значений функции для одного аргумента. объектных разработчиков и специалистов, называемых автором “профессионалами в области данных”;
отсутствие инструментальной поддержки быстрых методов применительно к реляционным базам данных.

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

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

Свой третий тезис автор сам расценивает не очень серьезно. Действительно, откуда бы взялись инструменты быстрой разработки реляционных баз данных, если “профессионалы в области данных” быстрой разработкой пользоваться не хотят (или не могут). И в связи с этим, я вижу некоторое противоречие с замечанием автора, что сообщество open sourceValve Source Engine, сокращенно Source («источник»)— игровой движок, разработанный корпорацией Valve. Его особенностями считаются модульная основа и гибкость, синхронизация движения губ с речью, технология выражения эмоций и система физики, работающая по сети. Использует общий для продуктов Valve формат моделей движка .mdl. Физическая часть движка Source включает в себя часть переработанного кода физического движка Havok и принципы физики «тряпичной куклы». Движок может работать с видеокартой, поддерживающей DirectX 8-11. озабочено отсутствие средств быстрой разработки баз данных и стремится закрыть эту брешь. Кто же будет пользоваться этими средствами? Или в этом случае для проектирования реляционных баз данных профессионалы уже не потребуются?

В конце статьи, наконец, выясняется, к чему ведет автор. Около года тому назад компания 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 в серверной части. К сожалению, по причинам наличия несоответствия между объектной и реляционной парадигмами и отсутствия в настоящее время соответствующего инструментария, возможности применения быстрых методов здесь ограничены. Как вы увидите, гораздо легче применять быстрый подход при использовании технологии объектных систем управления базами данных (ОСУБД).

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

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

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

РефакторингРефакторинг (англ.refactoring)— процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости. (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 описывается на странице .

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

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

Чтобы безопасно изменять существующее программное обеспечение с целью рефакторинга или добавления новых функций, требуется возможность проверки, не было ли что-нибудь повреждено в процессе внесения изменений. Другими словами, требуется возможность пропуска на системе полного регрессионного теста. При обнаружении какого-либо повреждения необходимо либо его исправить, либо откатить изменения. В сообществе быстрой разработки среди программистов все более принято разрабатывать полный тестовый набор в параллель с разработкой приложения, а в действительности приверженцы быстрого подхода (агилисты, agilest) предпочитают писать код тестов до написания «настоящего» кода. Не следует ли тестировать и базу данных подобно тому, как тестируется исходный тест приложения? Внутри базы данных реализуется важная бизнес-логика в форме хранимых процедур, правил проверки корректности данных и правил ссылочной целостности (referential integrityINTEGRITY— операционная система реального времени, разработанная калифорнийской компанией Green Hills Software. Сертифицирована на соответствие POSIX. Ориентирована на однопроцессорные встраиваемые системы, в центральном процессоре которых есть блок управления памятью (архитектуры ARM, XScale, Blackfin, Freescale ColdFire, MIPS, PowerPC, x86). Система основана на микроядре velOSity. Главная особенность системы— отказоустойчивость (если произойдет отказ в какой-либо программе запущенной в этой ОС, система будет продолжать работать в штатном режиме)., 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) для создания схемы базы данных
Скрипты загрузки/извлечения данных
Файлы моделей данных
Метаданные объектно-реляционного отображения
Эталонные данные
Определения хранимых процедур и триггеров
Определения представлений
Ограничения ссылочной целостности
Тестовые данныеДанные (калька от лат.data) — это представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе.
Скрипты генерации тестовых данных
Тестовые скрипты

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

«ПесочницаПесочница— один из объектов на детской площадке: особое место, предназначенное для игр с песком при использовании игрушек. Обычно песочница огорожена бортиками, чаще всего сделанными из дерева, причём бортики зачастую имеют плоскую поверхность, чтобы на ней можно было лепить куличики. Часто в центре песочницы стоит «грибок», который защищает играющих детей от дождя и солнца.» – это полностью функционирующая среда, в которой систему можно построить, оттестировать и/или запустить. По причинам безопасности может захотеться поддерживать различные отдельные песочницы – у разработчиков должна иметься возможностьВозможность — направление развития, присутствующее в каждом явлении жизни; выступает и в качестве предстоящего, и вполне объяснимо рациональным путем: в каждой возможности присутствует вероятная невозможность, «возможность невозможного». Возможность не определяется познанием того, что может быть. Познание вероятностей, возможностей не всегда влияет на нашу возможность. На изучении возможности основывается, главным образом, исследование бытия и события. работать в своей собственной песочнице без опасения навредить другим работам, у группы поддержки качества и тестирования должна иметься возможность безопасного запуска их тестов системной интеграции, а у конечных пользователей должна иметься возможность запуска своих систем без опасения того, что разработчики повредят их исходные данные и/или функциональность системы.

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

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

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

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

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

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

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

Быстрые методыМетод (от греч. — «способ»)— систематизированная совокупность шагов, действий, которые необходимо предпринять, чтобы решить определенную задачу или достичь определенной цели. В отличие от области знаний или исследований, является авторским, то есть созданным конкретной персоной или группой персон, научной или практической школой. В силу своей ограниченности рамками действия и результата, методы имеют тенденцию морально устаревать, преобразовываясь в другие методы, развиваясь в соответствии с временем, достижениями технической и научной мысли, потребностями общества. Совокупность однородных методов принято называть подходом. Развитие методов является естественным следствием развития научной мысли. с использованием неагрессивной объектной базы данных db4o

Основная идея состоит в том, что чем менее агрессивной является стратегия персистентности, тем проще будет разрабатывать, развивать и сопровождать приложения. ОСУБД с открытым кодом db4objects, доступная под лицензией GPL на сайте , является хорошим примером неагрессивной стратегией персистентности для платформ 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.

Ambler, S.W. (2003). Agile Database Techniques: Effective Strategies for the Agile SoftwareПрограммное обеспечение (допустимо также произношение обеспечение), ПО— совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ (ГОСТ 19781-90). Developer. New York: John Wiley & Sons.

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

Ambler, S.W. and Sadalage, P. (2006). Database Refactoring: Evolutionary Database Design. Boston: Prentice Hall PTR.

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Генри Уид Фаулер (англ.Henry Weed Fowler; 23 марта 1878, Филадельфия, Пенсильвания — 21 июня 1965) — американский зоолог., 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.