По интернетам несколько месяцев бродит в оригинале и переводах статья Ernesto Garbarino Has UML Died Without Anyone Noticing? Слушатели предстоящего вебинара Грамматика системных моделей попросили меня поделиться собственным мнением о том, что же произошло с UML. Я решил разобрать статью целиком и сделаю это по переводу UML умер, а никто и не заметил?
Описание архитектуры ИТ-решения не самая простая практика. И уж точно не следует приступать к её освоению с заполнения шаблона описания архитектуры. Тем не менее, такого рода шаблоны существуют и кто-либо из представителей заказчика информационной системы не редко требует описать архитектуру. Обычно, такого рода запрос поступает от персонажа, именуемого главным архитектором, и потому я возьму на себя смелость дать несколько рекомендаций о том, как это следует делать. Обычно, в качестве шаблона используются производные от RUP-овского Software Architecture Document скачать который можно, например, здесь. Существенно реже можно встретить TOGAF-овский Architecture Definition Document и уж вряд ли вам попадется ISO-шный Architecture description. Поэтому ориентироваться будем на первый шаблон. Читать далее О заполнении шаблона описания архитектуры решения
Я не перестаю удивляться энтузиазму, мастерству и целеустремленности архитекторов, с которым они предлагают свои подходы к моделированию информационных систем. Совсем недавно на InfoQ появилась статья Саймона Брауна (Simon Brown) Agile Software Architecture Sketches and NoUML. Саймон автор книги Software Architecture for Developers и сайта coding{the}architecture. В принципе, слайды и материалы с сайта достаточно полно описывают идеи автора. Но для тех, кому будет лениво их просматривать, я изложу краткую версию, немного дополнив её своими комментариями
Перелистываю фундаментальную книжку «троих друзей» (Jacobson, Booch, Rumbaugh) об унифицированном процессе разработки ПО 1999 года выпуска (перевод на русский в 2002) и с сожалением осознаю, что наиболее ценные идеи RUP и UML не нашли своего воплощения в корпоративной среде. Сплошь и рядом игнорируются три основные свойства унифицированного процесса:
Процесс развития корпоративной информационной управляется deadline-ами (К кому-то на Новый год приходит Дед Мороз, а к кому-то – дед лайн). В лучшем случае, под такую интерацию подкладываются требования в виде списка фич. Причем, элементы такого списка могут описывать структуры данных, элементы поведения, нефункциональные требования и вообще все что угодно. Что означает доступность сервиса 99,9% редко кого волнует. А ведь большинство современных сервисов включают множество вариантов использования: подключение(подписка), предоставление, настройка, разрешение проблем и пр. Какой из этих сценариев должен успешно завершаться в 999 случаях из тысячи и что такое успешное завершение – решительно не понятно. Далее, в отличие от требований, варианты использования четко описывают, для какой группы пользователей предоставляет требуемый функционал и, что даже более важно, зачем он им предоставляется. В требованиях никогда такого не было. Обычная формулировка требования: у объекта X должно быть свойство Y. На вопросы, кто и в какой момент задает значение этого свойства, кто и когда использует это значение, кому разрешено данное значение переопределить, требования не дают ответов. Унифицированный процесс предлагает построить все активности вокруг сценариев: определение состава проекта(итерации), проектирование, разработку и тестирование, развертывание компонент, планирование capacity и т.д.
Сделать это правда, можно только с использованием архитектуры. Основная идея ИТ архитектуры заключается в том, что для получения качественного решения следует рассматривать продукт с нескольких точек зрения. Недостаточно определить структуры данных и операции. Декомпозиция решения на модули позволяет четко определить зоны ответственности различных команд. Описание взаимодействий – собирает отдельные модули в единую работающую систему. Варианты использования привязывают цели пользователей к взаимодействиям между системами и компонентами, что позволяет планировать характеристики продукта (емкость, доступность, время отклика). Планирование развертывания, с одной стороны, дает возможность независимо от процесса разработки готовить инфраструктуру, а с другой стороны помогает не запутаться при согласовании настроек различных сред и приложений.
И все эти активности происходят в ходе всего проекта, т.е. решение разрабатывается инкрементально, от простого к сложному. Как известно, сложную систему невозможно заставить работать(«включить»). Её можно «вырастить» из простой работающей системы. Точно так же с первого раза невозможно сделать хорошую архитектуру, хорошую документацию, хорошие тесты. И именно поэтому в процессе нужна социальная составляющая. Люди должны общаться, ругаться, договариваться, причем делать все это не «на пальцах» а при помощи моделей и прототипов системы. Весь agile, пришедший вслед за унифицированным процессом построен на этом. Не ИТ разрабатывает систему для бизнес-заказчика, а заказчик разрабатывает себе систему при помощи ИТ. Иначе получится как всегда.
На протяжении последних десяти лет ИТ архитектура и управление ИТ-сервисами(ITSM) следуют параллельными курсами. Не то чтоб они не пересекаются, пересекаются они на каждом шагу, я бы даже сказал, не пересекаются, а скорее сталкиваются, высекают друг из друга искры и снова расходятся на безопасное расстояние. При этом оба обозначенных направления изначально не являлись целостными и крайне друг в друге нуждаются. Проблема ИТ архитектуры заключается в её статичности. Архитектурные модели, вырванные из процессов ИТ, не актуализируются и довольно быстро устаревают. Архитекторам, зачастую приходится заниматься тем, что Гради Буч назвал software archeology, раскопками утраченных знаний о том, что представляет собой ИТ система и как она работает. В свою очередь, ИТ процессам очень не хватает четкой классификации объектов и отношений между ними. Определяемые ITIL понятия ИТ-сервис и конфигурационная единица(КЕ) не особо конкретны. Любое существительное можно назвать КЕ, однако сколь либо стандартизированных классификаторов КЕ не существует и организациям их приходится придумывать самостоятельно. С ИТ-сервисом ситуация не лучше. Про него по большому счету известно то, что он предоставляется и то, что он обладает(или должен обладать) соглашением об уровне сервиса (SLA). Попробуем «подружить» архитектуру информационных систем и управление ИТ-сервисами Читать далее Почему ИТ-сервисы должны базироваться на архитектуре
В предыдущей заметке я позволил себе назвать появление UML основным событием в современной архитектуре информационных систем. Сегодня я подробней коснусь реализующих UML инструментов. Вернее, не существующих на сегодняшний день инструментов, а инструментов какими они должны быть.
Почему-то архитекторам свойственно напускать много сиреневого тумана на свою деятельность: и определения что такое архитектура единого нет; и книжки про архитектуру все почему-то довольно толстые. Даже великий Буч, как мне кажется, больше написал о том, чем не является архитектура, а не о том, чем же она является. Мне хочется сделать простой и по возможности краткий обзор того, что же такое архитектура. Может начальникам как-нибудь расскажу. Обзор будет субъективный, потому сразу прошу – тапками в меня не кидайтесь.