Введение

Доброго, солнечного периода года, Уважаемые коллеги!

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

• ТРИЗ;
• BABOK;
• Процессах анализа и управления рисками;

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

Настало время выйти из тени и начать

О чем эта серия

Данная серия статей посвящена рассмотрению дисциплины «Архитектурное проектирование программного обеспечения» Целью является систематизация имеющейся разнородной и скуднопредставленной в РФ литературе, относящейся к данному направлению активности, и разработка инновационных подходов к созданию и документированию архитектуры программного обеспечения.

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

На сегодняшний день, в области архитектурного проектирования, уже сложилась определенная структура данной активности и библиотека «best practiсe», пополняемая регулярно на основе успешного опыта и сопутствующих научных исследованиях в данной активности домена информационных технологий.

Именно эти практики мы и обсудим

А эта статья вот о чем

Первая является вводной и базисной для этой серии.

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

О Архитектуре и архитектурном проектировании

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

В основе рассматриваемой деятельности лежат понятия, которые являются двумя разными сторонами одной и той же «медали»:

• Архитектура – как результат;
• Проектирование – как средство достижения поставленного результата.

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

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

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

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

Проектирование - это вид активности направленный на создание уникального продукта (услуги), последовательность этапов реализации которого, будет определяться «внешними» факторами, и определять его конечные преимущества и недостатки.

Область проектирования получила широкое распространение в виде современной и эффективной формы деятельности – проект.

Архитектурное проектирование - это вид активности, который своей целью ставит создание архитектуры в процессе выполнения проекта.

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

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

• Частично или полностью автоматизирует выполнение рутинных операций, которые, как правило, являются наиболее ресурснозатратными;
• Предоставляет уникальные возможности, связанные с «online» обменом и преобразованием информации в разных целях;
• Оптимизирует не только использование человеческого капитала, но и затраты, связанные с содержанием недвижимого имущества;
• И т.д.

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

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

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

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

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

В трудах классика сферы информационных технологий - Фредерика Брукса, можно найти следующее отличие программы от программного продукта:

• Максимально обобщённый диапазон и виды входных данных;
• Тщательное тестирование;
• Наличие подробной документации;
• Программный продукт требует в 3 раза больших временных затрат;

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

Именно качественные (или не очень) программные продукты формируют электронный мир программного обеспечения, который не только окружает каждого современного жителя планеты Земля, но формирует его сознание и образ поведения в нем.

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

Программное обеспечение, лежащее в основе мира будущего, должно обеспечивать необходимые качественные характеристики, такие как:

• Функциональность;
• Производительность;
• Надежность;
• Безопасность;
• И др.

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

Немного о истории и о сегодняшнем дне

Начиная с середины 50-х годов 20 века понятие архитектуры программного обеспечения стало очень широко и бурно обсуждаться в профессиональном сообществе ИТ специалистов. Связано это было с тем, что архитектура, в её первоначальном способе применения, рассматривали только в виде необходимого базиса создаваемых информационных систем.

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

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

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

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

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

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

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

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

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

Так же надо отметить, что архитектура это 100% продукт «человеческой мысли», что предъявляет особые дополнительные требования к ключевым аспектам исследования данной профессиональной области.

Результат подобного отношения к архитектурному проектированию характеризует данную активность еще и как социальный объект.

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

Рамки и ограничения этой серии

Здесь мы не претендуем на открытие «terra incognita» в области проектирования компьютерных программ. Одной из наших основных задач было и есть - синтезировать набор имеющихся мировых «best practice» рассматриваемого нами домена, переработать его, дополнить малоизвестной, но важной информацией, обогатить полученную «суть» практическими подходами к работе и методологиями, учитывающими реалии деятельности сотрудников в сфере информационных технологий и ситуацию на рынке разработки информационных программ Российской Федерации.

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

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

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

Мы осветим следующие «высокоуровневые» аспекты, связанные с архитектурным проектированием программного обеспечения:

1. Необходимые характеристики архитектуры программного обеспечения;
   • Будут приведены функциональные и нефункциональные/качественные характеристики архитектур, которые, в итоге, являются катализаторами в формировании основных преимуществ и недостатков разрабатываемого программного обеспечения;
2. Требования, формирующие архитектуру программного обеспечения;
   • Будут изложены основные требования, после тщательного анализа которых следует этап проектирования. В ходе этого этапа вырабатываются основные характеристики будущего программного продукта (см.п.1);
3. Объекты архитектуры программного обеспечения и связи между ними:
   • Будут перечислены объекты, объединение которых в единую систему, позволит добиться результатов, ожидаемых от использования проектируемых программных продуктов;
4. «Внешнее» окружение процесса архитектурного проектирования:
   • Обзорно освятим факторы, которые будут оказывать влияние на процесс архитектурного проектирования и дальнейшего использования соответствующих программ;
5. Процесс архитектурного проектирования:
   • Опишем то, как должна выглядеть активность, в которой должны быть учтены наиболее эффективные, на сегодняшний день, методологии организации процессов архитектурного проектирования;
6. «Пакет» документации на архитектуру ПО:
   • Приведем список документов, необходимых и достаточных для последующего развития и сопровождения создаваемого программного обеспечения;
7. Риски, связанные с архитектурой и архитектурным проектированием;
   • Изложим наиболее популярные риски, которые встречаются в тех случаях, когда применение созданной архитектуры не соответствует первоначально заданным задачам и условиям её использования;
8. Уровни архитектуры ПО;
   • Приведем те представления архитектуры программного обеспечения, без которых не будет возможным её разработка и последующее использование;
9. Подходы к созданию архитектуры ПО;
   • Изложим наиболее эффективные современные методологии и принципы архитектурного проектирования программных продуктов, их преимущества и недостатки;
10. Роль системного архитектора;
    • Опишем его роль в процессе архитектурного проектирования. Перечислим те навыки и профессиональные качества, которыми должен обладать архитектор информационных продуктов;
11. Процессы развития и сопровождения архитектуры ПО;
    • Расскажем о том, как должны быть выстроены данные процессы, чтобы архитектура программного обеспечения была эффективна в заданных условиях функционирования;

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

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

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

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

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

Перечень ограничений:

• Организационные аспекты создания, развития и сопровождения архитектуры и процессов её проектирования:
  • Мы сознательно не стали включать сюда аспекты, связанные с управленческими дисциплинами. Область менеджмент обширно и подробно изучена. Для рассмотрения конкретных, интересующих Вас вопросов, можно найти специализированную литературу, но определенные специфические моменты менеджмента, влияющие на архитектуру и архитектурное проектирование, мы обязательно рассмотрим;
• Процессы разработки кода архитектуры:
  • Процессы разработки «кода» архитектуры, это активности, которые должны следовать после того, как выполнено проектирование архитектуры. С одной стороны, учитывая реальное положение дел в области программной инженерии, нужно сказать о том, что в 60% проектов, связанных с созданием программного обеспечения, проектирование и разработка это процессы, которые выполняются параллельно, но, с другой стороны, такая практика работ является не лучшим «образчиком» создания программного обеспечения. Мы, в определенных частях последующих статей, будем учитывать этот аспект, но, «по умолчанию», абстрагируемся от его влияния. Такой принцип обучения является классическим. Это позволит нам изложить основные моменты, формирующие базисные понятия, наиболее эффективным образом. Таким образом, этап «кодирования» - это следующий, после архитектурного проектирования, этап. Он будет нами учтен, но описывать и излагать его мы не будем;
• Политические, социальные, экономические моменты, влияющие на образ созданного программного обеспечения:
  • Когда речь заходит о каком-то «внутреннем» процессе, а архитектурное проектирование (не архитектура) - это именно такой процесс, оказывающий влияние только на ограниченное число пользователей, то факторы «внешнего» влияния рассматриваются отдельно. Для анализа подобных факторов существует разнообразный инструментарий. В частности, можно привести в пример «PEST» анализ. При необходимости его можно изучить отдельно и использовать результаты проведенного анализа в своих исследованиях;
• «Человеческий» фактор:
  • Пожалуй, данный аспект наших ограничений - это основная причина самых потрясающих достижений и наиболее запоминающих провалов при проектировании архитектур программного обеспечения. «Человеческий фактор» и все его составляющие, такие как мотивация, эффективность и т.д. это части человеческой личности, рассмотрению которых сегодня уделяется большое количество внимания ученых и специалистов, при этом, нет предпосылок к тому, что эти тенденции будут ослабевать. Возможно, фокус внимания проводимых исследований сместиться в более антропогенно - техническое направление, но внимание к ним со временем будет только усиливаться. При желании, любой сможет найти достаточное количество материала из данной области.

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

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

Шаблоны архитектурного проектирования и стили по Алистеру Коберну

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

Мы сконцентрируемся на процессах проектирования, но очень важно иметь представление о смежных с ним процессах – это процессы сбора и анализа информации.

Для начала необходимо однозначно и ясно понять:

• Что требуется для разработки будущего программного продукта?
• Как имеющийся набор информации преобразовать в программный продукт?

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

Сделаем небольшое отступление и поясним коллегам, что тема сбора и анализа требований требует отдельного разговора (довольно длительного). В наших планах определена веха по созданию курса по этой тематике, поэтому здесь мы не будем заострять наше внимание на данной активности, и вернемся к ней позже. При наличии интереса мы рекомендуем ознакомиться с книгой «классика» данного направления программной инженерии К.Вигерса «Разработка и управление требованиями».

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

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

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

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

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

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

В данной области уже накоплен определенный, наиболее успешный опыт образцов архитектур и архитектурного проектирования, которые объединены в шаблоны проектирования (design patterns).

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

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

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

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

Несмотря на подобное «гуманитарное» содержание его работ, в них приведены 3 стиля применения шаблонов, которые являются общеупотребительными в процессах проектирования:

• Статическое использование шаблонов:
  • Разработка архитектуры происходит перед началом разработки «кода» будущего программного продукта. Данный шаблон реализуется от начала и до конца при разработке определенной функциональности программы;
  • При применении этого шаблона используется больше времени и ресурсов на ранних стадиях с тем, чтобы получить экономию при последующем сопровождении и доработке.
• Эволюционное использование шаблонов:
  • Использование этого шаблона направлено на равномерное распределение ресурсов по стадиям проекта разработки программы. В этом случае уменьшаются «вложения» в начале проекта, что способствуют получению более быстрых начальных результатов в виде функциональности, но требуются дополнительные инвестиции при внедрение шаблона на стадии сопровождения/доработки;
  • Такой подход приводит к тому, что позднее потребуются доработки архитектуры и исправление допущенных ошибок, возникновение которых неминуемо. Этот шаблон подразумевает применение процессов рефакторинга и реинжиниринга при сопровождении и развитии системы.
• Неиспользование шаблонов:
  • Использование данного шаблона оправдано только для небольшого числа проектов. Например, при работе над старым кодом, в случае крайне ограниченных ресурсов/сроков в сочетании с невысокими требованиями к качеству/сопровождаемости программного продукта.

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

Когда же речь заходит о практиках проектирования, ….

Итоги

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

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

До скорой встречи и не очень скучайте!

Авторы статьи

Иван Никитин

Михаил Цулая