Персональные инструменты
 

Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск


Аннотация

Докладчик
Максим Цепков

Итеративная разработка в agile ставит проблему: как создавать и поддерживать архитектуру системы. Можно работать без нее, но в сложных проектах не получаются. DDD предлагает строить каркас как доменную модель. Это — лучше, но доменная модель описывает не все аспекты системы. Мы хотим поделиться своим опытом описания архитектуры.

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

Из чего состоит модель? Наша компания занимается заказной разработкой учетно-аналитических систем, и мы выработали достаточно устойчивый шаблон, использованный в десятках проектов, который мы называем Учетной машиной. Модель состоит из трех частей: доменная модель, модель документооборота и модель учета. Первая представляется диаграммой классов. Мы используем rich domain model, это позволяет использовать диаграмму не только для общения разработчиков, но и для согласования постановок с экспертами заказчика. Диаграмма классов возникает в самом начале проекта, представляя на этом этапе только основные классы и их связи, а по мере проработки очередного фрагмента — конкретизируется. Для представления учета стандартных диаграмм нет, и нам пришлось разработать свои Диаграммы учета, отражающие потоки ресурсов (денег, товаров) между учетными счетами. В докладе они будут разобраны подробнее. Она также появляется в начале проекта и постепенно уточняется. А для представления документооборота мы используем диаграмму состояний UML, отражающую переходы документа. Эти диаграммы обычно возникают только при проработке очередного фрагмента системы. Все части модели связаны: переходы документов реализуются методами, и приводят к движению ресурсов.

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

Видео


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация

Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011).pdf


Примечания и отзывы

Докладчик
Максим Цепков
Компания
CustIS
Презентация
Документ на slideshare.net

Доклад Макса был первым после обеда во второй день конференции. Увы, в программе ошибочно был указан доклад Владимира Бахова, поэтому начальные условия выступления перед аудиторией оказались неблагоприятными для докладчика.

С интересом прослушал доклад. Заинтересовала идея про поиск метафоры системы и проекции системы в виде

  • диаграммы классов;
  • диаграммы учета;
  • диаграммы состояний.

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

Интересный познавательный доклад с яркими образами для иллюстрации мыслей.

ИМХО, хорошо пошло. Про учетную машину, про диаграммы, про DDD — концентрированный опыт компании кАстис. Только лучшее, только звёзды. Максим даже в отведенное время уложился (жалко, не осталось времени на вопросы). Народу было не особо много, но и не мало, несколько человек очень заинтересовались, после доклада подходили. Тема интересная, не избитая и, вроде как, подходит к тематике конференции.

Что, на мой взгляд, можно улучшить. Местами всё-таки аудитория заметно «подвисала», размышляя над сложными речевыми оборотами. Те, кто поумнее и выспался, всё поняли, конечно, но можно работать над переводом части слов в образы, упрощением речи и т. д. Когда последний тормоз в зале проснётся и всё поймет — успех и мировая известность обеспечены.

Максим Цепков

  • Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)

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

Основные моменты (лучше смотреть видео/презентацию):

  • Макс упомянул о такое практике XP как «метафора системы», понятие хорошо раскрыто и проиллюстрировано в докладе
  • Нужно использовать разные диаграммы/иллюстрации/взгляды для разных систем и разных случаев. Нотация не так важна как понятность.
  • Стандартные диаграммы (проекции) используемые в ЗИС:
    • диаграмма классов (скорее, на мой взгляд, сущностей)
    • диаграмма учета
    • диаграмма состояний документов
  • Некоторые правила
    • Для простоты и гибкости приходится отказываться от case-средства
    • нельзя использовать технические коды на диаграммах
    • активно использовать цветовое кодирование
    • детализация только там, где необходимо




Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».