Подходы к документированию архитектуры программного обеспечения

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

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

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

Введение

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

• масштабируемость
• сложность

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

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

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

Описанию того:

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

будет посвящена наша сегодняшняя лекция.

Уровни архитектуры программного обеспечения

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

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

Для цельного понимания понятия архитектуры программного продукта следует выделить следующие уровни:

• Уровень приложения;
• Уровень данных;
• Уровень информации;
• Интеграционный уровень;
• Уровень безопасности;
• Сетевой уровень;
• Уровень платформы;
• Уровень системы.

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

• Управление доступными ресурсами/активами;
• Управление изменениями;
• Управление событиями;
• Поддержка пользователей;
• Обеспечение уровня предоставления сервиса для бизнес процессов.

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

К примеру, уровень управления данными состоит из следующих дисциплин:

• СУБД;
• Файловые системы;
• Конкретные реализации модели данных;
• И т.д.

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

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

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

• SQL Server;
• ERWin;
• И т.д.

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

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

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

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

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

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

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

• Бизнес-архитектура

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

  В этом виде архитектуры рассматривается аспект данных (локальные справочники, мастер справочники и т.д.), используемые организациями, их представление, взаимозависимости и взаимовлияние не только друг на друга, но и на функционал конкретного программного продукта.
• Технологическая архитектура

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

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

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

• Функциональный признак - страхование /бухгалтерский учет/интеграционное взаимодействие и т.д.;
• Тематический признак - услуги гражданам/внутренние процессы и т.д.;

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

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

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