Еще несколько слов о проектировании

designerВ предыдущем сообщении Квинтэссенция проектирования я сделал небольшой обзор взгляда Роберта Гласса на проектирование информационных систем. Согласно ему проектирование – это процесс создания в уме действующих моделей информационной системы, которую можно использовать для проведения тестовых прогонов. Гласс ссылается на работы Билла Кертиса (Bill Curtis) Эллиота Соловей (Elliot Soloway), правда не приводит конкретных ссылок. Мне не удалось найти первоисточников, поэтому цитирую по книжке Гласса. Эти исследователи использовали метод «анализ протоколов» чтоб определить, как осуществляется проектирование информационных систем. Сначала у них получилось примерно следующее. Проектируя приложение, архитектор осуществляет следующие активности:

  • Осмысление задачи
  • Декомпозиция задачи на цели и объекты
  • Выбор и составление планов решения задачи
  • Реализацию планов
  • Раздумья над продуктом и процессом

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

  1. Строят умозрительную модель предлагаемого решения
  2. Проверяют в уме работу модели – по сути, занимаются симуляцией на модели, чтобы посмотреть, позволяет ли она решить задачу.
  3. Обнаружив, что не позволяет, выявляют условия, с которыми модель не справляется, и корректируют её
  4. Повторяют шаги 1-3 до тех пор, пока не получат модель, которая, как им кажется, позволяет решить задачу.

Из этих замечаний можно сделать несколько интересных выводов.

Во-первых, цель тестового прогона не в том, чтобы убедиться, что анализируемый подход позволяет решить задачу, а как раз, наоборот, в том, чтоб в этом разубедиться. Проще говоря, хороший тест выявляет ошибку. Именно поэтому архитекторы, обычно, могут рассказать, почему то или иное решение не подходит. Проектирование – итерационный процесс, все предыдущие итерации которого закончились неудачей. Из-за этого вопрос: «Когда же вы, наконец, закончите проект решения?» выглядит довольно странно. Можем закончить хоть сейчас, отложив все проблемы на этап развертывания, интеграционного тестирования и эксплуатации. Вообще говоря, разница в мышлении проектировщиков и «обычных людей» более чем существенна. Люди привыкли искать, и разумеется, находить подтверждения своим мыслям, архитекторам больше свойственно сомневаться

Во-вторых, проектирование невозможно без детального понимания работы уже существующих компонент. Золотой век одиноко стоящих персональных компьютеров давно прошел. Когда-то можно было не только быстро придумать решение, но и за полчаса изготовить работающий прототип. Среда разработки и все необходимые для этого библиотеки были под рукой, на персональном компьютере архитектора. Развитие приложений в архитектуре клиент-сервер лишили нас этой возможности. Ни документация, ни эмуляторы или тестовые среды не позволяют гарантировать работу прототипа при переносе в продуктивную среду. Мне не нравится идея разделения сред на продуктивные, тестовые, среды для разработчиков и т.д. К счастью, современные сетевые сервисы отходят от этой традиции. Web API предоставляют возможность работать, как минимум, с аутентичным ПО, а зачастую и с реальными данными.

В третьих, предложенная схема процесса проектирования объясняет удачные находки методологий (прототипирование, непрерывная интеграция) и средств разработки ПО. Когда-то очень и очень давно придумав программу её записывали на бумаге (вернее на специальных формулярах). Затем специальные люди набивали их на перфокартах. Другие люди загружали колоду карт в ЭВМ. Третьи – раздавали распечатки с выявленными компилятором ошибками… С появлением IDE все это ушло в прошлое. Появились разработчики, которые вообще опускают этап создания в уме моделей программы, действуя по принципу «кодим и фиксим». Но сейчас не об этом. Изложенная модель проектирования показывает, в каком направлении думали разработчики ПО и для других видов проектирования.  Возьмем, например, системы управления бизнес-процессами. BPM –  попытка, кстати довольно наивная, создать интегрированную среду разработки для проектировщика бизнес-процессов. Выглядит это так. Сидит за компьютером бизнес-аналитик и придумывает процесс. Придумал, накидал несколько квадратиков и стрелочек в BPMN и запустил. С другой стороны экрана запустился бизнес-процесс, в исполнителей полетели задачи и те ринулись их исполнять. Если что-то пошло не так, архитектор бизнес-процесса его чуть-чуть подкрутил и сотрудники вновь зашуршали бумажными и электронными документами. Вот такая идея. Но как-то пока не сбылось! Впрочем, как и model driven development и многое другое. Ну, посмотрим, может еще и случится. Пока существует OMG нас, безусловно, ждет еще множество забавных идей.

Подводя итог, не могу не заметить, что всё это очень похоже на цикл adaptive case management, представленный на картинке в заметке 2012: Design by Doing, Standard+Case, Smart Process Apps

Еще несколько слов о проектировании: 5 комментариев

  1. Максим, про ACM – это Вы ловко 🙂 Цикл похож на цикл – не подкопаешься 🙂
    Но как таковой процесс проектирования описан верно, хоть, тоже, слишком общО. Основной методологический вопрос к проектировщикам звучит, как правило, так: “как у вас получается выполнить пункт 1?” 🙂 Ведь, когда есть синтезированная модель (хоть в уме, хоть на картинке, хоть на стенде) – с ней уже можно много разных вещей делать: обсуждать, проверять, раскрашивать – это уже во многом рутинная деятельность. Главное – чтобы модель откуда-то взялась.

    1. Так ведь в реализации п.1 и заключается сходство с циклом ACM. Только case worker перебирает шаблоны процессов из каталога, пока не найдет нужный, а архитектор шаблоны архитектур из головы

      1. Ну вот я и говорю, что сходство уж очень общее предложено – перебор “чего-то” из каталога. Идеальный ACM замахивается на более сложную задачу – подобрать из каталога шаблон организационно-деятельностной структуры, применимой для данной задачи. То есть в случае с ACM архитектура решаемой бизнес-задачи содержит в себе, в т.ч., и последовательность действий по ее решению – и средства применения этой последовательности к окружающему миру – средства раздачи заданий, контроля результатов, анализа информации и т.д. Достал проект из каталога, нажал кнопку, все побежали в нужные стороны 🙂

Добавить комментарий для Максим Смирнов Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *