Feature driven development методология: Feature driven development — Википедия – TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development / Habr

Feature driven development — Википедия

Материал из Википедии — свободной энциклопедии

Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 3 января 2018;
проверки требует 1 правка.
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 3 января 2018;
проверки требует 1 правка.

Feature driven development (FDD, разработка, управляемая функциональностью) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.

FDD была изначально предложена Джеффом Де Люкой (англ. Jeff De Luca) для проекта (рассчитанного на 15 месяцев и 50 человек) по разработке программного обеспечения для одного крупного сингапурского банка в 1997 году. Де Люка выделил набор из пяти процессов, охватывающий как разработку общей модели, так и ведение списка, планирование, проектирование и реализацию элементов функциональности (англ. feature).

Первое описание FDD появилось в 1999 году в главе 6 книги Java Modeling in Color with UML^[1]. В книге A Practical Guide to Feature-Driven Development^[2] (2002 год) описание FDD было обобщено, и в частности избавлено от привязок к конкретному языку программирования.

FDD включает в себя пять базовых видов деятельности:

1. разработка общей модели;
2. составление списка необходимых функций системы;
3. планирование работы над каждой функцией;
4. проектирование функции;
5. реализация функции.

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

Разработка общей модели[править | править код]

Разработка начинается с высокоуровневого сквозного анализа широты решаемого круга задач и контекста системы. Далее для каждой моделируемой области делается более детальный сквозной анализ. Сквозные описания составляются в небольших группах и выносятся на дальнейшее обсуждение и экспертную оценку. Одна из предлагаемых моделей или их объединение становится моделью для конкретной области. Модели каждой области задач объединяются в общую итоговую модель, которая изменяется в ходе работы.

Составление списка возможностей (функций)[править | править код]

Информация, собранная при построении общей модели, используется для составления списка функций. Это осуществляется разбиением областей (англ. domain) на подобласти (предметные области, англ. subject areas) с точки зрения функциональности. Каждая отдельная подобласть соответствует какому-либо бизнес-процессу, шаги которого становятся списком функций (свойств). В данном случае функции — это маленькие части понимаемых пользователем функций, представленных в виде «<действие> <результат> <объект>», например, «проверка пароля пользователя». Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо разбить на несколько подзадач, каждая из которых сможет быть завершена за установленный двухнедельный срок.

План по свойствам (функциям)[править | править код]

После составления списка основных функций, наступает черёд составления плана разработки программного обеспечения. Владение классами распределяется среди ведущих программистов путём упорядочивания и организации свойств (или наборов свойств) в классы.

Проектирование функций[править | править код]

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

Реализация функции[править | править код]

После успешного рассмотрения дизайна данная видимая клиенту функциональность реализуется до состояния готовности. Для каждого класса пишется программный код. После модульного тестирования каждого блока и проверки кода завершенная функция включается в основной проект (англ. build).

Так как функции малы, то их разработка — относительно легкая задача. Для мониторинга проекта по разработке ПО и предоставления точных данных о развитии проекта необходимо протоколировать разработку каждого свойства (функции). FDD выделяет шесть последовательных этапов для каждой функции (свойства). Первые три полностью завершаются в процессе проектирования, последние три — в процессе реализации. Для удобства контроля за выполнением работ на каждом этапе показывается процент его готовности (выполнения). В таблице ниже приведены основные этапы. Функция, которая всё ещё находится в разработке, завершена на 44 % (Анализ области 1 % + Дизайн 40 % + Проверка дизайна 3 % = 44 %)

Таблица 1. Основные этапы

Анализ области	Дизайн	Проверка дизайна	Код	Проверка кода	Включение в сборку
1 %	40 %	3 %	45 %	10 %	1 %

FDD построен на основе набора передового опыта (набора наилучших практик), признанного в отрасли и полученного из инженерии программного обеспечения. Эти практические методы строятся с точки зрения важного для клиента функционала. Ниже дано краткое описание каждого метода:

• Объектное моделирование области. Объектное моделирование состоит из исследования и выяснения рамок предметной области решаемой задачи. Результатом является общий каркас, который можно в дальнейшем дополнять функциями.
• Разработка по функции. Любая функция, которая слишком сложна для разработки в течение двух недель, разбивается на меньшие подфункции до тех пор, пока каждая подзадача не может быть названа свойством (то есть, быть реализована за 2 недели). Это облегчает создание корректно работающих функций, расширение и модификацию системы.
• Индивидуальное владение классом (кодом). Означает, что каждый блок кода закреплён за конкретным владельцем-разработчиком. Владелец ответственен за согласованность, производительность и концептуальную целостность своих классов.
• Команда по разработке функций (свойств). Команда по разработке функций (свойств) — маленькая, динамически формируемая команда разработчиков, занимающаяся небольшой подзадачей. Позволяет нескольким разработчикам участвовать в дизайне свойства, а также оценивать дизайнерские решения перед выбором наилучшего.




• Проверка кода (англ. code review) Проверки обеспечивают хорошее качество кода, в первую очередь путём выявления ошибок.
• Конфигурационное управление. Помогает с идентификацией исходного кода для всех функций (свойств), разработка которых завершена на текущий момент, и с протоколированием изменений, сделанных разработчиками классов.
• Регулярная сборка. Регулярная сборка гарантирует, что всегда есть продукт (система), которая может быть представлена заказчику, и помогает находить ошибки при объединении частей исходного кода на ранних этапах.
• Обозримость хода работ и результатов. Частые и точные отчёты о ходе выполнения работ на всех уровнях внутри и за пределами проекта о выполненной работе помогают менеджерам правильно руководить проектом.

Гибкая методология разработки

• ↑ Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X)
• ↑ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (ISBN 0-13-067615-2)
• Alan S. Koch. Agile Software Development: Evaluating the Methods for Your Organization. — Artech House, 2004. — 280 с. — ISBN 978-1580538428. (Appendix F)

Feature Driven Development для веб-разработчиков / Habr

Лет 10 назад веб-проекты по большей части были статическими, а технологический процесс порой — прост до безобразия. Теперь грань между веб-приложениями и настольными приложениями стирается, функциональная сложность веб-проектов растет. Это диктует новые требования к веб-разработке. Обычная ситуация нынче, в эпоху «удиви меня 2.0», — когда проект долгосрочный, в нем задействовано множество специалистов (и не специалистов также), щедро орошающих многострадальный product backlog новыми идеями и целями, как до начала разработки, так и после. Как вы понимаете, цели и истории мутируют, а вместе с ними и задачи. Предварительная оценка по времени теряет свою целесообразность. И т.д. и т.п. Очевидно, нужна специальная методология разработки. Можно попробовать приобщиться к

Rational Unified Process (RUP) или Process Mentor. Однако, не стоит. Среди столь популярных ныне Agile методик имеется то, что нам надо — Feature Driven Development (FDD).

В общих чертах подход можно описать следующей последовательностью:

• Разработка общей модели
• Создание списка свойств
• Планирование по свойствам
• По каждому свойству – технический дизайн и реализация.

В идеале на выходе мы получаем платформу, постепенно обрастающую свойствами. Звучит как-то подозрительно просто. Давайте все же посмотрим, что это такое.

Как выразился автор методологии Джеф Делюка (Jeff Deluca — http://www.jeffdeluca.com), общая модель – больше набросок или очертание, нежели детальное содержание. Однако чтобы получить эту модель, недостаточно просто требований к проекту. Модель – это видение проекта, основанное на результатах предварительных исследований. Спасибо Луису Розенфельду (Louis Rosenfeld — http://louisrosenfeld.com) – мы знаем, насколько важна роль информационной архитектуры при веб-разработке. На этапе общей модели у нас должны быть – анализ целевой аудитории, анализ контента и контекста его использования, структура контента, включая метаданные и тезаурус. Должен быть документ, описывающий принципы пользовательского интерфейса, список используемых UX-компонентов, описание их свойств и поведения.

Рис.1. Пирамида информационной архитектуры

В данном подходе подразумевается, чтомы приступаем кразработке, имея лишь наброски системы, которыепо мере разработки обрастают деталями. Таким образом, детальные каркасы (wireframes) будут разработаны входе создания соответствующих свойств (features) или, другими словами, частей проекта. Однако на стадии общей модели таки потребуются «сырые» каркасы основных интерфейсов и предварительная карта сайта.

Все выше описанное –сопутствующие документы. Основной результат этапа–модель домена (Domain model). Это статическая UML диаграмма, включающая все определенные к данному моменту логические объекты проекта и их взаимодействие (объект является частью другого объекта, объект расширяет другой объект и т.д.).

Не думаю, что здесь мне стоит вдаваться вподробности. Большинствоиз вас использует методику SCRUM, а список свойств в FDD – то же самое, что и product backlog в SCRUM. Разве что стоит еще раз напомнить: при создании списка следует оперировать именно целями и подцелями, но не задачами.
Все бы хорошо, но как же оценить время разработки свойств проекта, когда детали туманны. Связанные задачи для разработчиков будут предельно ясны только тогда, когда будут выполнены все предварительные работы по данному свойству. Как же планировать? И тут на помощь приходит Story Point Estimation. Мы оцениваем свойства не в человеко-днях, а в абстрактных баллах по мере сложности свойства. Из всего списка предлагается выбрать свойство минимальной сложности и присвоить ему 2 балла сложности. Рекомендуется использовать экспоненциальную шкалу, например: 1, 2, 3, 5, 8. Тогда спрашивается, почему мы не назначили 1 самому пустяковому свойству. На всякий случай. Список свойств огромный и с первого взгляда маловероятно, что вы будете максимально точны в оценке.
В оценке принимают участие все члены команды. Т.е., каждое свойство обсуждается с позиций всех этапов разработки до тех пор, пока команда не приходит к единой оценке сложности. Достаточно утомительно, я вам скажу, но – продуктивно.
Итак, приоритеты определены, выбрано свойство для реализации. Самое время описать требования. Для этого создается модель прецедентов (Use Cases) относительно выбранного свойства. Данный документ хорошо бы снабдить диаграммой активности (Activity Diagram) для визуализации логики сопряженных сценариев использования. Сами прецеденты можно отразить в соответствующей UML диаграмме (Use Case diagram). В ходе обзора (review) документа, опять же, принимают участие все члены команды.

Рис.2. Модель прецедентов привносит детали в документы общей модели

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

Технический дизайн предполагает UML-диаграмму с сущностями модели домена, список и диаграмму классов (где это уместно), сопряженных со свойством моделей, DAO, контроллеров, сервисов, декораторов (возможно хелперов). Там же представлена архитектура БД, покрывающая свойство в виде модели «сущность-связь» (ER Diagram). Если свойство затрагивает какие-либо внешние системы (например, профайлер пользовательских предпочтений), это должно быть также отражено в техническом дизайне, скажем, в виде диаграммы последовательностей (Sequence diagram).

Помимо прочего следует подготовить варианты тестирования (Test Cases), что позволит QA-специалистам полноценно оценить качество реализации свойства.

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

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

В то время как визуальный дизайнер будет трудиться над пользовательским интерфейсом, программисты могут создать описанные в техническом дизайне компоненты в виде прототипа. Таким образом, после обзора визуального дизайна и прототипа свойства, производится xHTML-верстка и модификация декораторов (views). Наверняка творческий гений визуального дизайнера потребует от вас также дополнительного программирования на клиентской стороне (JS). Когда свойство готово, оно передается в QA-отдел для тестирования.
После того, как свойство протестировано и ушло в продукт, берем следующее по приоритетам свойство, повторяем цикл дизайна/реализации.

Feature driven development — это… Что такое Feature driven development?

Feature driven development (FDD, разработка, управляемая функциональностью) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в поставленные сроки.

История

FDD была изначально предложена Джеффом Де Люкой (англ. Jeff De Luca) для проекта (рассчитанного на 15 месяцев и 50 человек) по разработке программного обеспечения для одного крупного Сингапурского банка в 1997 году. Де Люка выделил набор из пяти процессов, охватывающий как разработку общей модели, так и ведение списка, планирование, проектирование и реализацию элементов функциональности (англ. feature).

Первое описание FDD появилось в 1996 году в главе 6 книги Java Modeling in Color with UML^*. В книге A Practical Guide to Feature-Driven Development^* (2002 год) описание FDD было обобщено, и в частности избавлено от привязок к конкретному языку программирования.

Обзор

FDD включает в себя пять базовых видов деятельности:

1. разработка общей модели;
2. составление списка необходимых функций системы;
3. планирование работы над каждой функцией;
4. проектирование функции;
5. реализация функции.

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

Разработка общей модели

Разработка начинается с высокоуровневого сквозного анализа широты решаемого круга задач и контекста системы. Далее для каждой моделируемой области делается более детальный сквозной анализ. Сквозные описания составляются в небольших группах и выносятся на дальнейшее обсуждение и экспертную оценку. Одна из предлагаемых моделей или их объединение становится моделью для конкретной области. Модели каждой области задач объединяются в общую итоговую модель, которая изменяется в ходе работы.

Составление списка возможностей (функций)

Информация, собранная при построении общей модели, используется для составления списка функций. Это осуществляется разбиением областей (англ. domain) на подобласти (предметные области, англ. subject areas) с точки зрения функциональности. Каждая отдельная подобласть соответствует какому-либо бизнес-процессу, шаги которого становятся списком функций (свойств). В данном случае функции — это маленькие части понимаемых пользователем функций, представленных в виде «<действие> <результат> <объект>», например, «проверка пароля пользователя». Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо разбить на несколько подзадач, каждая их которых сможет быть завершена за установленный двухнедельный срок.

План по свойствам (функциям)

После составления списка основных функций, наступает черёд составления плана разработки программного обеспечения. Владение классами распределяется среди ведущих программистов путем упорядочивания и организации свойств (или наборов свойств) в классы.

Проектирование функций

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

Реализация функции

После успешного рассмотрения дизайна, данная видимая клиенту функциональность реализуется до состояния готовности. Для каждого класса пишется программный код. После модульного тестирования каждого блока и проверки кода, завершенная функция включается в основной проект (англ. build).

Этапы

Так как функции малы, то их разработка — относительно легкая задача. Для мониторинга проекта по разработке ПО и предоставления точных данных о развитии проекта необходимо протоколировать разработку каждого свойства (функции). FDD выделяет шесть последовательных этапов для каждой функции (свойства). Первые три полностью завершаются в процессе проектирования, последние три — в процессе реализации. Для удобства контроля за выполнением работ на каждом этапе показывается процент его готовности (выполнения). В таблице ниже приведены основные этапы. Функция, которая все ещё находится в разработке, завершена на 44 % (Анализ области 1 % + Дизайн 40 % + Проверка дизайна 3 % = 44 %)

Таблица 1. Основные этапы

Анализ области	Дизайн	Проверка дизайна	Код	Проверка кода	Включение в сборку
1 %	40 %	3 %	45 %	10 %	1 %

Передовой опыт

FDD построен на основе набора передового опыта (набора наилучших практик), признанного в отрасли и полученного из инженерии программного обеспечения. Эти практические методы строятся с точки зрения важного для клиента функционала. Ниже дано краткое описание каждого метода:

• Объектное моделирование области. Объектное моделирование состоит из исследования и выяснения рамок предметной области решаемой задачи. Результатом является общий каркас, который можно в дальнейшем дополнять функциями.

• Разработка по функции. Любая функция, которая слишком сложна для разработки в течение двух недель, разбивается на меньшие подфункции до тех пор, пока каждая подзадача не может быть названа свойством (то есть, быть реализована за 2 недели). Это облегчает создание корректно работающих функций, расширение и модификацию системы.

• Индивидуальное владение классом (кодом). Означает, что каждый блок кода закреплён за конкретным владельцем-разработчиком. Владелец ответственен за согласованность, производительность и концептуальную целостность своих классов.

• Команда по разработке функций (свойств). Команда по разработке функций (свойств) — маленькая, динамически формируемая команда разработчиков, занимающаяся небольшой подзадачей. Позволяет нескольким разработчикам участвовать в дизайне свойства, а также оценивать дизайнерские решения перед выбором наилучшего.

• Проверка кода (англ. code review) Проверки обеспечивают хорошее качество кода, в первую очередь путём выявления ошибок.

• Конфигурационное управление. Помогает с идентификацией исходного кода для всех функций (свойств), разработка которых завершена на текущий момент, и с протоколированием изменений, сделанных разработчиками классов.

• Регулярная сборка. Регулярная сборка гарантирует, что всегда есть продукт (система), которая может быть представлена заказчику, и помогает находить ошибки при объединении частей исходного кода на ранних этапах.

• Обозримость хода работ и результатов. Частые и точные отчёты о ходе выполнения работ на всех уровнях внутри и за пределами проекта о выполненной работе помогают менеджерам правильно руководить проектом.

См. также

Гибкая методология разработки

Примечания

Литература

• ↑ Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X)
• ↑ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (ISBN 0-13-067615-2)
• Alan S. Koch Agile Software Development: Evaluating the Methods for Your Organization. — Artech House, 2004. — 280 с. — ISBN 978-1580538428 (Appendix F)

Ссылки

Гибкая методология разработки — wiki студи Клондайк

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Экстремальное программирование

Одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Основные приёмы XP

• Короткий цикл обратной связи (Fine-scale feedback)

1. Разработка через тестирование (Test-driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Whole team, Onsite customer)
4. Парное программирование (Pair programming)

Непрерывный, а не пакетный процесс

1. Непрерывная интеграция (Continuous integration)
2. Рефакторинг (Design improvement, Refactoring)
3. Частые небольшие релизы (Small releases)

Понимание, разделяемое всеми

1. Простота (Simple design)
2. Метафора системы (System metaphor)
3. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
4. Стандарт кодирования (Coding standard or Coding conventions)

Социальная защищённость программиста (Programmer welfare):

1. 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

DSDM

Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) — это главным образом методика разработки программного обеспечения, основанная на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007 году DSDM стал основным подходом к управлению проектом и разработки приложений[источник не указан 635 дней].

Принципы

Существует 9 принципов, состоящих из 4 основных и 5 начальных точек.

• Вовлечение пользователя — это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными.
• Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством.
• Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше — это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей.
• Главный критерий — как можно более быстрая поставка программного обеспечения, которое удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важна, чем решение критических проблем в функционале продукта.
• Разработка — итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения.
• Любые изменения во время разработки — обратимы.
• Требования устанавливаются на высоком уровне прежде, чем начнётся проект.
• Тестирование интегрировано в жизненный цикл разработки.
• Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности.

Scrum

Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки.

FDD

Feature driven development (FDD, функционально-ориентированная разработка) — итеративная методология разработки программного обеспечения, одна из гибких методологий разработки (agile). FDD представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Используемое в FDD понятие функции или свойства (англ. feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.

Feature Driven Development | Alexey Kiselev

Эта методология (кратко именуемая FDD) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). Как и остальные адаптивные методологии, она делает основной упор на коротких итерациях, каждая из которых служит для проработки определенной части функциональности системы. Согласно FDD, одна итерация длится две недели. FDD насчитывает пять процессов. Первые три из них относятся к началу проекта.

1. Разработка общей модели
2. Составление списка требуемых свойств системы
3. Планирование работы над каждым свойством
4. Проектирование каждого свойства
5. Конструирование каждого свойства

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

Наиболее полное описание методологии FDD можно найти в книге Питера Коада со товарищи, под названием “UML in Color” . Его компания, “TogetherSoft”, также занимается консалтингом и обучением FDD.

Текст выше взят отсюда. Перевел последовательность действий:

Разработка общей модели

Проект начинается с многоуровневого определения границ системы и её контекста (как я понимаю, доменной модели). Далее,  детализированная модель создается для каждой области моделирования. Для удобства поддержки, они делятся на маленькие группы, объединяющиеся по областям. Эти доменные модели областей, в итоге, объединятся в общую модель системы.

Составление списка требуемых свойств системы

Знания при создании модели используются для построения списка фич (свойств системы). Это сделано при помощи функциональной декомпозиции домена по предметным областям. Они содержать бизнес-активности, а так же описание, какая из бизнес-активностей формирует какой список фич. Фичи являются малыми составляющими клиентский функций, например: “посчитать количество продаж”. Фичи должны быть реализованы не более чем за 2 недели, иначе их следует делить на меньшие части.

Планирование работы над каждым свойством

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

Проектирование каждого свойства

Под дизайном здесь не понимается дизайн интерфейса. Уточняется диаграмма последовательности по группе фич, которые можно реализовать за 2 недели.

Конструирование каждого свойства

Разработка.

Тут мне была интересна только декомпозиция.

Не очень мне тут понятно, когда у нас идет дизайн интерфейса и описываются конкретные поля… Мы же, по идее, должны протрассировать фичи на элементы интрефейса..

Правильно ли я перевел рисунок отсюда..?

 

Комментарий пользователя Shur с uml2.ru:

В тексте приводится определение “Фича – небольшая часть функции в форме <действие> <результат> <объект>, с результатом, имеющим ценность с точки зрения клиента. Например – “рассчитать суммарный объем продаж” или “проверить пароль пользователя”.

В смысле этого определения фича может иметь вид “заполнить <название поля> интерфейсной формы значением <название показателя>”.

Из текста раздела Buid feature list следует, что система декомпозируется по иерархии:
автоматизируемая область (домен) -> предметные области (subject areas) -> виды деятельности (business activities) -> список фич.
Причем каждой фиче соответствует действие (по крайней мере) одного из видов деятельности (activity).

Like this:

Like Loading…

Разработка через тестирование — Википедия

Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (англ. inspires confidence)^[1].

В 1999 году при своём появлении разработка через тестирование была тесно связана с концепцией «сначала тест» (англ. test-first), применяемой в экстремальном программировании^[2], однако позже выделилась как независимая методология.^[3].

Тест — это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Когда программист проверяет работоспособность разработанного им кода, он выполняет тестирование вручную.

Разработка через тестирование требует от разработчика создания автоматизированных модульных тестов, определяющих требования к коду непосредственно перед написанием самого кода. Тест содержит проверки условий, которые могут либо выполняться, либо нет. Когда они выполняются, говорят, что тест пройден. Прохождение теста подтверждает поведение, предполагаемое программистом. Разработчики часто пользуются библиотеками для тестирования (англ. testing frameworks) для создания и автоматизации запуска наборов тестов. На практике модульные тесты покрывают критические и нетривиальные участки кода. Это может быть код, который подвержен частым изменениям, код, от работы которого зависит работоспособность большого количества другого кода, или код с большим количеством зависимостей.

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

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

Разумеется, к тестам применяются те же требования стандартов кодирования, что и к основному коду.

Графическое представление цикла разработки, в виде блок-схемы

Приведенная последовательность действий основана на книге Кента Бека «Разработка через тестирование: на примере» (англ. Test Driven Development: By Example).^[1]

Добавление теста[править | править код]

При разработке через тестирование, добавление каждой новой функциональности (англ. feature) в программу начинается с написания теста. Неизбежно этот тест не будет проходить, поскольку соответствующий код ещё не написан. (Если же написанный тест прошёл, это означает, что либо предложенная «новая» функциональность уже существует, либо тест имеет недостатки.) Чтобы написать тест, разработчик должен чётко понимать предъявляемые к новой возможности требования. Для этого рассматриваются возможные сценарии использования и пользовательские истории. Новые требования могут также повлечь изменение существующих тестов. Это отличает разработку через тестирование от техник, когда тесты пишутся после того, как код уже написан: она заставляет разработчика сфокусироваться на требованиях до написания кода — тонкое, но важное отличие.

Запуск всех тестов: убедиться, что новые тесты не проходят[править | править код]

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

Написать код[править | править код]

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

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

Запуск всех тестов: убедиться, что все тесты проходят[править | править код]

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

Рефакторинг[править | править код]

Когда достигнута требуемая функциональность, на этом этапе код может быть почищен. Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы, устранить дублирование кода, облегчить внесение изменений в ближайшем будущем.

Повторить цикл[править | править код]

Описанный цикл повторяется, реализуя всё новую и новую функциональность. Шаги следует делать небольшими, от 1 до 10 изменений между запусками тестов. Если новый код не удовлетворяет новым тестам или старые тесты перестают проходить, программист должен вернуться к отладке. При использовании сторонних библиотек не следует делать настолько небольшие изменения, которые буквально тестируют саму стороннюю библиотеку^[3], а не код, её использующий, если только нет подозрений, что библиотека содержит ошибки.

Разработка через тестирование тесно связана с такими принципами как «делай проще, дурачок» (англ. keep it simple, stupid, KISS) и «вам это не понадобится» (англ. you ain’t gonna need it, YAGNI). Дизайн может быть чище и яснее, при написании лишь того кода, который необходим для прохождения теста.^[1] Кент Бек также предлагает принцип «подделай, пока не сделаешь» (англ. fake it till you make it).
Тесты должны писаться для тестируемой функциональности. Считается, что это имеет два преимущества. Это помогает убедиться, что приложение пригодно для тестирования, поскольку разработчику придется с самого начала обдумать то, как приложение будет тестироваться. Это также способствует тому, что тестами будет покрыта вся функциональность. Когда функциональность пишется до тестов, разработчики и организации склонны переходить к реализации следующей функциональности, не протестировав существующую.

Идея проверять, что вновь написанный тест не проходит, помогает убедиться, что тест реально что-то проверяет. Только после этой проверки следует приступать к реализации новой функциональности. Этот приём, известный как «красный/зелёный/рефакторинг», называют «мантрой разработки через тестирование». Под красным здесь понимают не прошедшие тесты, а под зелёным — прошедшие.

Отработанные практики разработки через тестирование привели к созданию техники «разработка через приёмочное тестирование» (англ. Acceptance Test-driven development, ATDD), в котором критерии, описанные заказчиком, автоматизируются в приёмочные тесты, используемые потом в обычном процессе разработки через модульное тестирование (англ. unit test-driven development, UTDD).^[4] Этот процесс позволяет гарантировать, что приложение удовлетворяет сформулированным требованиям. При разработке через приёмочное тестирование, команда разработчиков сконцентрирована на чёткой задаче: удовлетворить приёмочные тесты, которые отражают соответствующие требования пользователя.

Приёмочные (функциональные) тесты (англ. customer tests, acceptance tests) — тесты, проверяющие функциональность приложения на соответствие требованиям заказчика. Приёмочные тесты проходят на стороне заказчика. Это помогает ему быть уверенным в том, что он получит всю необходимую функциональность.

Исследование 2005 года показало, что использование разработки через тестирование предполагает написание большего количества тестов, в свою очередь, программисты, пишущие больше тестов, склонны быть более продуктивными.^[5] Гипотезы, связывающие качество кода с TDD, были неубедительны.^[6]

Программисты, использующие TDD на новых проектах, отмечают, что они реже ощущают необходимость использовать отладчик. Если некоторые из тестов неожиданно перестают проходить, откат к последней версии, которая проходит все тесты, может быть более продуктивным, нежели отладка.^[7]

Разработка через тестирование предлагает больше, чем просто проверку корректности, она также влияет на дизайн программы. Изначально сфокусировавшись на тестах, проще представить, какая функциональность необходима пользователю. Таким образом, разработчик продумывает детали интерфейса до реализации. Тесты заставляют делать свой код более приспособленным для тестирования. Например, отказываться от глобальных переменных, одиночек (singletons), делать классы менее связанными и легкими для использования. Сильно связанный код или код, который требует сложной инициализации, будет значительно труднее протестировать. Модульное тестирование способствует формированию четких и небольших интерфейсов. Каждый класс будет выполнять определенную роль, как правило, небольшую. Как следствие, зависимости между классами будут снижаться, а зацепление повышаться.
Контрактное программирование (англ. design by contract) дополняет тестирование, формируя необходимые требования через утверждения (англ. assertions).

Несмотря на то, что при разработке через тестирование требуется написать большее количество кода, общее время, затраченное на разработку, обычно оказывается меньше. Тесты защищают от ошибок. Поэтому время, затрачиваемое на отладку, снижается многократно.^[8] Большое количество тестов помогает уменьшить количество ошибок в коде. Устранение дефектов на более раннем этапе разработки, препятствует появлению хронических и дорогостоящих ошибок, приводящих к длительной и утомительной отладке в дальнейшем.

Тесты позволяют производить рефакторинг кода без риска его испортить. При внесении изменений в хорошо протестированный код риск появления новых ошибок значительно ниже. Если новая функциональность приводит к ошибкам, тесты, если они, конечно, есть, сразу же это покажут. При работе с кодом, на который нет тестов, ошибку можно обнаружить спустя значительное время, когда с кодом работать будет намного сложнее. Хорошо протестированный код легко переносит рефакторинг. Уверенность в том, что изменения не нарушат существующую функциональность, придает уверенность разработчикам и увеличивает эффективность их работы. Если существующий код хорошо покрыт тестами, разработчики будут чувствовать себя намного свободнее при внесении архитектурных решений, которые призваны улучшить дизайн кода.

Разработка через тестирование способствует более модульному, гибкому и расширяемому коду. Это связано с тем, что при этой методологии разработчику необходимо думать о программе как о множестве небольших модулей, которые написаны и протестированы независимо и лишь потом соединены вместе. Это приводит к меньшим, более специализированным классам, уменьшению связанности и более чистым интерфейсам. Использование mock-объектов также вносит вклад в модуляризацию кода, поскольку требует наличия простого механизма для переключения между mock- и обычными классами.

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

Тесты могут использоваться в качестве документации. Хороший код расскажет о том, как он работает, лучше любой документации. Документация и комментарии в коде могут устаревать. Это может сбивать с толку разработчиков, изучающих код. А так как документация, в отличие от тестов, не может сказать, что она устарела, такие ситуации, когда документация не соответствует действительности — не редкость.

• Существуют задачи, которые невозможно (по крайней мере, на текущий момент) решить только при помощи тестов. В частности, TDD не позволяет механически продемонстрировать адекватность разработанного кода в области безопасности данных и взаимодействия между процессами. Безусловно, безопасность основана на коде, в котором не должно быть дефектов, однако она основана также на участии человека в процедурах защиты данных. Тонкие проблемы, возникающие в области взаимодействия между процессами, невозможно с уверенностью воспроизвести, просто запустив некоторый код.
• Разработку через тестирование сложно применять в тех случаях, когда для тестирования необходимо прохождение функциональных тестов. Примерами может быть: разработка интерфейсов пользователя, программ, работающих с базами данных, а также того, что зависит от специфической конфигурации сети. Разработка через тестирование не предполагает большого объёма работы по тестированию такого рода вещей. Она сосредотачивается на тестировании отдельно взятых модулей, используя mock-объекты для представления внешнего мира.
• Требуется больше времени на разработку и поддержку, а одобрение со стороны руководства очень важно. Если у организации нет уверенности в том, что разработка через тестирование улучшит качество продукта, то время, потраченное на написание тестов, может рассматриваться как потраченное впустую.^[9]
• Модульные тесты, создаваемые при разработке через тестирование, обычно пишутся теми же, кто пишет тестируемый код. Если разработчик неправильно истолковал требования к приложению, и тест, и тестируемый модуль будут содержать ошибку.
• Большое количество используемых тестов может создать ложное ощущение надежности, приводящее к меньшему количеству действий по контролю качества.
• Тесты сами по себе являются источником накладных расходов. Плохо написанные тесты, например, содержат жёстко вшитые строки с сообщениями об ошибках или подвержены ошибкам, дороги при поддержке. Чтобы упростить поддержку тестов, следует повторно использовать сообщения об ошибках из тестируемого кода.
• Уровень покрытия тестами, получаемый в результате разработки через тестирование, не может быть легко получен впоследствии. Исходные тесты становятся всё более ценными с течением времени. Если неудачные архитектура, дизайн или стратегия тестирования приводят к большому количеству непройденных тестов, важно их все исправить в индивидуальном порядке. Простое удаление, отключение или поспешное изменение их может привести к необнаруживаемым пробелам в покрытии тестами.

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

Из кода теста может не быть доступа к приватным (англ. private) полям и методам. Поэтому при модульном тестировании может потребоваться дополнительная работа. В Java разработчик может использовать отражение (англ. reflection), чтобы обращаться к полям, помеченными как приватные.^[10] Модульные тесты можно реализовать во внутренних классах, чтобы они имели доступ к членам внешнего класса. В .NET Framework могут применяться разделяемые классы (англ. partial classes) для доступа из теста к приватным полям и методам.

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

Не существует единого мнения среди программистов, применяющих разработку через тестирование, о том, насколько осмысленно тестировать приватные, защищённые(англ. protected) методы, а также данные. Одни убеждены, что достаточно протестировать любой класс только через его публичный интерфейс, поскольку приватные переменные — это всего лишь деталь реализации, которая может меняться, и её изменения не должны отражаться на наборе тестов. Другие утверждают, что важные аспекты функциональности могут быть реализованы в приватных методах и тестирование их неявно через публичный интерфейс лишь усложнит ситуацию: модульное тестирование предполагает тестирование наименьших возможных модулей функциональности.^[11][12]

Fake-, mock-объекты и интеграционные тесты[править | править код]

Модульные тесты тестируют каждый модуль по отдельности. Неважно, содержит ли модуль сотни тестов или только пять. Тесты, используемые при разработке через тестирование, не должны пересекать границы процесса, использовать сетевые соединения. В противном случае прохождение тестов будет занимать большое время, и разработчики будут реже запускать набор тестов целиком. Введение зависимости от внешних модулей или данных также превращает модульные тесты в интеграционные. При этом если один модуль в цепочке ведет себя неправильно, может быть не сразу понятно какой именно^{[источник не указан 2780 дней]}.

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

1. Везде, где требуется доступ к внешним ресурсам, должен быть объявлен интерфейс, через который этот доступ будет осуществляться. См. принцип инверсии зависимостей (англ. dependency inversion) для обсуждения преимуществ этого подхода независимо от TDD.
2. Интерфейс должен иметь две реализации. Первая, собственно предоставляющая доступ к ресурсу, и вторая, являющаяся fake- или mock-объектом. Всё, что делают fake-объекты, это добавляют сообщения вида «Объект person сохранен» в лог, чтобы потом проверить правильность поведения. Mock-объекты отличаются от fake- тем, что сами содержат утверждения (англ. assertion), проверяющие поведение тестируемого кода. Методы fake- и mock-объектов, возвращающие данные, можно настроить так, чтобы они возвращали при тестировании одни и те же правдоподобные данные. Они могут эмулировать ошибки так, чтобы код обработки ошибок мог быть тщательно протестирован. Другими примерами fake-служб, полезными при разработке через тестирование, могут быть: служба кодирования, которая не кодирует данные, генератор случайных чисел, который всегда выдает единицу. Fake- или mock-реализации являются примерами внедрения зависимости (англ. dependency injection).

Использование fake- и mock-объектов для представления внешнего мира приводит к тому, что настоящая база данных и другой внешний код не будут протестированы в результате процесса разработки через тестирование. Чтобы избежать ошибок, необходимы тесты реальных реализаций интерфейсов, описанных выше. Эти тесты могут быть отделены от остальных модульных тестов и реально являются интеграционными тестами. Их необходимо меньше, чем модульных, и они могут запускаться реже. Тем не менее, чаще всего они реализуются используя те же библиотеки для тестирования (англ. testing framework), что и модульные тесты.

Интеграционные тесты, которые изменяют данные в базе данных, должны откатывать состоянии базы данных к тому, которое было до запуска теста, даже если тест не прошёл. Для этого часто применяются следующие техники:

• Метод TearDown, присутствующий в большинстве библиотек для тестирования.
• try...catch...finally структуры обработки исключений, там где они доступны.
• Транзакции баз данных.
• Создание снимка (англ. snapshot) базы данных перед запуском тестов и откат к нему после окончания тестирования.
• Сброс базы данных в чистое состояние перед тестом, а не после них. Это может быть удобно, если интересно посмотреть состояние базы данных, оставшееся после не прошедшего теста.

Существуют библиотеки Moq, jMock, NMock, EasyMock, Typemock, jMockit, Unitils, Mockito, Mockachino, PowerMock или Rhino Mocks, а также sinon для JavaScript предназначенные упростить процесс создания mock-объектов.

1. ↑ ^{1 2 3} Beck, K. Test-Driven Development by Example, Addison Wesley, 2003
2. ↑ Lee Copeland. Extreme Programming (неопр.). Computerworld (December 2001). Дата обращения 11 января 2011. Архивировано 27 августа 2011 года.
3. ↑ ^{1 2} Newkirk, JW and Vorontsov, AA. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004
4. ↑ Koskela, L. «Test Driven: TDD and Acceptance TDD for Java Developers», Manning Publications, 2007
5. ↑ Erdogmus, Hakan; Morisio, Torchiano. On the Effectiveness of Test-first Approach to Programming (неопр.) (недоступная ссылка). Proceedings of the IEEE Transactions on Software Engineering, 31(1). January 2005. (NRC 47445). — «We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive.». Дата обращения 14 января 2008. Архивировано 27 августа 2011 года.
6. ↑ Proffitt, Jacob TDD Proven Effective! Or is it? (неопр.) (недоступная ссылка). — «So TDD’s relationship to quality is problematic at best. Its relationship to productivity is more interesting. I hope there’s a follow-up study because the productivity numbers simply don’t add up very well to me. There is an undeniable correlation between productivity and the number of tests, but that correlation is actually stronger in the non-TDD group (which had a single outlier compared to roughly half of the TDD group being outside the 95% band).». Дата обращения 21 февраля 2008. Архивировано 27 августа 2011 года.
7. ↑ Llopis, Noel Stepping Through the Looking Glass: Test-Driven Game Development (Part 1) (неопр.) (недоступная ссылка). Games from Within (20 February 2005). — «Comparing [TDD] to the non-test-driven development approach, you’re replacing all the mental checking and debugger stepping with code that verifies that your program does exactly what you intended it to do.». Дата обращения 1 ноября 2007. Архивировано 22 февраля 2005 года.
8. ↑ Müller, Matthias M.; Padberg, Frank. About the Return on Investment of Test-Driven Development (неопр.) (PDF) (недоступная ссылка) 6. Universität Karlsruhe, Germany. Дата обращения 1 ноября 2007. Архивировано 27 августа 2011 года.
9. ↑ Loughran, Steve Testing (неопр.) (PDF). HP Laboratories (November 6th, 2006). Дата обращения 12 августа 2009. Архивировано 27 августа 2011 года.
10. ↑ Burton, Ross Subverting Java Access Protection for Unit Testing (неопр.). O’Reilly Media, Inc. (11/12/2003). Дата обращения 12 августа 2009. Архивировано 27 августа 2011 года.
11. ↑ Newkirk, James Testing Private Methods/Member Variables — Should you or shouldn’t you (неопр.). Microsoft Corporation (7 June 2004). Дата обращения 12 августа 2009. Архивировано 27 августа 2011 года.
12. ↑ Stall, Tim How to Test Private and Protected methods in .NET (неопр.). CodeProject (1 Mar 2005). Дата обращения 12 августа 2009. Архивировано 27 августа 2011 года.

• Кент Бек. Экстремальное программирование: разработка через тестирование = Test-driven Development. — Питер, 2003. — 224 с. — ISBN 5-8046-0051-6, 0-321-14653-0.
• Лайза Криспин, Джанет Грегори. Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М.: «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 экз. — ISBN 978-5-8459-1625-9.

Предметно-ориентированное проектирование — Википедия

Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. Domain-driven design, DDD) — это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.

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

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

Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»^[1].

• Область (англ. domain, домен) — предметная область, к которой применяется разрабатываемое программное обеспечение.
• Модель (англ. model) — описывает отдельные аспекты области и может быть использована для решения проблемы.
• Язык описания — используется для единого стиля описания домена и модели.

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

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

Ограниченные связи[править | править код]

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

Решение: Точно определить контекст, в котором используется модель. Определить границы использования данной модели и её характеристики.

Целостность[править | править код]

Когда над проектом работает большое количество людей, то есть тенденция дробить модель на несколько более мелких фрагментов. Чем больше людей, тем более значительна данная проблема. В конечном итоге теряется целостность проекта.

Решение: Постоянное объединение кусков кода от различных разработчиков и проверка работоспособности посредством тестирования. Это позволяет держаться всем разработчикам в одной большой концепции.

Взаимосвязь[править | править код]

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

Решение: На этапе проектирования точно обозначьте, что именно выполняет каждая модель и как она взаимосвязана с другими моделями. В конечном итоге у вас должна получиться карта взаимосвязей моделей.

При проектировании на основе предметно-ориентированного подхода используются следующие понятия:

Ограниченный контекст[править | править код]

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

Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают архитектурный стиль, который имеет красноречивое название «Большой ком грязи» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).^[2]

Сутью предметно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках.

Сущность[править | править код]

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

Объект-значение[править | править код]

Объект-значение — это свойства, важные в той предметной области, которую вы моделируете. У них, в отличие от сущностей, нет обозначения; они просто описывают конкретные сущности, которые уже имеют обозначения. Полезность объектов-значений состоит в том, что они описывают свойства сущностей гораздо более изящным и объявляющим намерения способом. Стоит всегда помнить, что значение объекта никогда не изменяется на протяжении выполнения всего программного кода. После их создания, внесение поправок невозможно.

Агрегат[править | править код]

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

Службы предметных областей[править | править код]

Иногда в предметной области есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой класс, не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести многослойную архитектуру, так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.^[3]

Взаимосвязь с подходами программирования[править | править код]

Хотя по концепции предметно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике используются сильные стороны объектно-ориентированного программирования. Это использование наследования, инкапсуляции, представления в виде методов и классов. Нужно помнить, что объектно-ориентированный подход может быть применен не только к ООП языкам, таким как Java, C# или C++, но так же и к функциональным — F#, Erlang. Особенно удобны языки, поддерживающие создание и использование собственных предметно-ориентированных языков, такие как Scala (см. также ЯОП).

1. ↑ Evans, Eric (англ.)русск.. Domain-Driven Design: Tackling Complexity in the Heart of Software (англ.). — Addison-Wesley, 2004. — ISBN 978-032-112521-7. в русском переводе Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем
2. ↑ Brian Foote and Joseph Yoder, Big Ball of Mud, 1999, Urbana, IL 61801 USA
3. ↑ Haywood, D., Domain-Driven Design using Naked Objects, 2009, Pragmatic Programmers

• Вон Вернон. Реализация методов предметно-ориентированного проектирования = Implementing Domain: Driven Design. — М.: «Вильямс», 2016. — 688 с. — ISBN 978-0-321-83457-7.

• Эрик Эванс. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем = Domain-Driven Design: Tackling Complexity in the Heart of Software. — М.: «Вильямс», 2011. — 448 с. — ISBN 978-5-8459-1597-9.
• Нильссон Д. Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET = Applying Domain-Driven Design and Patterns with Examples in C# and .NET. — М.: «Вильямс», 2008. — 549 с. — ISBN 978-5-8459-1296-1.
• Evans E. Domain-Driven Design — Tackling Complexity in the Heart of Software. — Addison-Wesley, 2004. — 529 с. — ISBN 978-0-3211-2521-7.

• Brian F., Joseph Y. Big Ball of Mud. — Urbana, IL 61801 USA, 1999. — 41 с.
• Nick Tune, Scott Millett. Patterns, Principles And Practices Of Domain-driven Design. — 1-е изд. — «John Wiley & Sons», 2015. — 792 с. — ISBN 978-1118714706. — ISBN 1118714709.

Видео