Есть одна тема, которая, вероятно, является основной в деятельности архитектора информационных систем. Это тема проектирования. Тема о том, как люди придумывают те или иные решения. К сожалению, по этой теме нет каких-либо общепризнанных работ. Различные авторы затрагивают её порой в своих книгах, но не дают исчерпывающего подхода, позволяющего организовать такую деятельность. Я знаю, как в своей работе это делаем мы. Я много раз видел, как это делают другие люди. Но у меня нет рецептов описания этой «техники». Я не могу включить это в учебный курс и стараюсь обходить тему проектирования стороной. Но ведь людей, пришедших разбираться в архитектуре информационных систем, на самом деле, в основном и интересует вопрос как их проектировать.
Несколько замечаний от тех, кто пытался «раскопать» эту тему. Роберт Гласс «Программирование и конфликты» (Robert L. Glass «Software Conflict 2.0. The Art and Science of Software Engineering»):
Все это время, говоря о проектировании, мы ходили вокруг да около. Методологии это не проектирование; они представляют собой платформу, на которой мы объединяем и организуем наши проектные усилия. И языки (программирования) – это не проектирование; это способ записи готового по сути, проекта. Проектирование есть нечто такое, что происходит внутри головы, в мозгу, причем происходит быстрее молнии.
Т.е. ни методологии, ни языки программирования или другие средства разработки не дают ответа на вопрос, как человек проектирует информационные системы. Более того, далее Гласс ссылается на исследование трудностей, возникающих у людей при проектировании. И вероятной причиной таких трудностей является то, что люди строят в своей голове представления будущих программ, а не действующие модели. Представления: описания структур данных, компонентные диаграммы, разнообразные другие картинки не могут быть выполнены. Их нельзя подвергнуть тестовому прогону в уме. По крайней мере, они для этого не предназначены. Т.е. все, чему нас учат книжки по разработке архитектуры информационных систем, не очень помогает, а может даже и помешать этой деятельности.
От архитекторов постоянно требуют нарисовать картинку. Но никто не требует её исполнения. Когда к вам приходит архитектор с картинкой, вы не знаете, сколько тестовых прогонов данной архитектуры он произвел в своей голове. Возможно, ни одного. Определенную пользу приносят обсуждения. Но сначала вы должны потратить некоторое время, чтоб загрузить картинку в свою голову. Если угодно, задеплоить модули и классы на нейроны своего мозга и затем начать мысленно (или вслух) выполнять сценарии. В жизни обычно так и происходит. Когда кто-то хочет представить вам архитектуру он начинает рассказывать как те или иные объекты друг с другом взаимодействуют. Довольно быстро оперативная память слушателя или же самого рассказчика заканчивается и тогда он хватает карандаш или маркер и начинает рисовать что-то не очень внятное. Процесс нормального исполнения в этот момент прерывается. То же самое происходит, если на определенном шаге прервать рассказчика вопросом: «А что если…?». В обоих случаях шансов вернутся к основному сценарию совсем не много. В общем, довольно быстро все запутываются (теряют нить рассуждений) и возвращаются к началу сценария.
Что же делать?
Во-первых, не преувеличивать роль картинок. Картинка – это инфраструктура, если хотите аппаратное обеспечение, на котором будет разворачиваться сюжет. Реквизит, помогающий не сразу запутаться в ходе дальнейшего обсуждения.
Если вы хотите нарисовать на картинке направленные стрелочки, то нарисуйте. Но, по крайней мере, пронумеруйте их и снабдите описанием осуществляемых действий, чтоб читатель мог провести мысленный запуск проекта. При этом, не забывайте что человек по природе своей однозадачен и не может выполнять в уме несколько потоков параллельно. Двунаправленная стрелочка – это удар в мозг. В лучшем случае её проигнорируют.
Пишите сценарии. Это дает хоть какую-то гарантию того, что зарисованное решение было хотя бы однажды исполнено. Вообще, написание и проговаривание сценариев – это одна из основных практик проектирования решений. Рассказывайте сценарии. Всегда помните, где находится исполняемый в данный момент процесс. Хотя бы для того, чтобы знать, куда следует вернуться после обработки очередного исключения вызванного внезапным вопросом.
Программная архитектура возникла во времена структурного программирования Дейкстры, когда основной задачей разработки ПО было научить людей упорядочивать данные и исходники программ. Инструменты архитектуры изначально были статичны и останутся таковыми еще довольно длительное время. Сегодняшние информационные системы – это множество взаимодействующих друг с другом модулей, развернутых на различных узлах сети. Их очень непросто запустить и практически нельзя выключить (все и сразу). Современную нам архитектуру информационных систем Рой Филдинг назвал абстракцией времени выполнения (run-time abstraction). Она существует только в то время, в которое приложение выполняется и не существует ни до ни после того.
Изображение взято из заметки: «Нейросети для чайников» http://habrahabr.ru/post/143129/