Опубликован: 03.02.2016 | Доступ: свободный | Студентов: 1608 / 339 | Длительность: 07:40:00
Лекция 4:

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

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >

Обзор существующих подходов к созданию и документированию архитектуры

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

Трудозатраты группы проектирования можно представить следующим образом:

  • 20% трудозатрат – создание модели архитектуры и функциональности программного продукта;
  • 70% трудозатрат – воплощение разработанной модели;
  • 10% трудозатрат – прочее.

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

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

  • Модель Захмана;
  • Модель "4+1";
  • Стратегическая модель архитектуры SAM;
  • Архитектурные концепции и методики Microsoft;
  • Прочие.

Модель Захмана

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

  • General motors;
  • Bank of America;
  • Федеральное правительство США (Архитектура FEAF).

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

  • Методика описания архитектуры Open Group (TOGAF)

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

  • Методика описания архитектуры министерства обороны США (DoDAF)

    DoDAF методология построения архитектуры предприятий, созданная по заказу Министерства обороны США (DoD). DoD неоднократно являлось инициатором создания стандартов в области бизнес-моделирования процессов и программных продуктов. Рассматриваемая нами ранее нотация IDEF также создана при непосредственном участии Министерства обороны США. Специфика DoDAF определяется спецификой создания программных продуктов по заказу DoD. DoD – один из крупнейших заказчиков и разработчиков сложных программных продуктов. В предприятиях по созданию таких систем участвуют тысячи подрядчиков, от слаженной работы которых зависит достижение поставленных результатов. Компании, которые стремятся взаимодействовать с DoD на коммерческой основе, должны выполнять DoDAF. Это обстоятельство послужило толчком к началу распространению DoDAF.

Модель Захмана базируется на дисциплине классической, строительной архитектуры, которую мы уже неоднократно упоминали. В первоначальной работе Захман определил архитектуру, как "набор описательных представлений (моделей), которые применимы для описания программного продукта в согласовании с требованиями руководства, которые могут развиваться в течение определенного периода". В соответствии с поставленными целями, была предложена модель архитектуры компании (Zachman Framework for Enterprise Architecture). Модель предлагает решение двух основных архитектурных задач:

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

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

  • Анализ;
  • Планирование;
  • Проектирование;
  • Разработка;
  • Тестирование;
  • Внедрение;
  • Промышленная эксплуатация.

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

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

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

Подобная модель рассмотрения архитектуры представлена в модели Захмана, которая по сути отображена в виде таблицы, имеющей 5 строк/уровней и 6 столбцов/колонок.

В строках отражена следующая информация:

  • Пара верхних строчек/уровней описывает наиболее общие представления и ожидания от архитектуры программного продукта. На этих уровнях представлена ситуация, которая соответствует интересам менеджеров функциональных процессов, реализуемых в программном продукте ;
  • Последующий уровень "логической модели" архитектуры, который более определен, по сравнению с верхними соседствующими уровнями, но при этом еще довольно абстрактен. На этом уровне менеджеры и аналитики, отвечающие за программный продукт, должны работать совместно, коммуницируя на едином языковом пространстве;
  • Уровни с 4-ого и далее отражают детали, которые необходимы для участников построения архитектуры. Значимая деталь построения этих уровней заключается в том, что каждый участник, в соответствии со своей ролью, в создании архитектуры и программном продукте, получает/формирует картину в соответствии с необходимым для него уровнем абстракции и детализации;

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

  • Что?

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

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

  • Как?

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

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

  • Где?

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

  • Кто?

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

  • Когда?

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

  • Для чего?

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

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

При заполнении модели таблицы следует соблюдать следующие правила:

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

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

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

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

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

В модели Захмана подобное отношение к архитектуре программных продуктов является недопустимым.

Модель Захмана (пример)

увеличить изображение
Рис. 1. Модель Захмана (пример)

Подводя итог обсуждения модели Захмана нужно вывести следующие преимущества:

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

Модель "4+1"

Следующим рассматриваемым подходом к созданию и документированию архитектуры программного продукта будет Модель "4+1". Она сыграла важную роль в области развития направления архитектурного проектирования. Основоположником этой модели, созданной в 1995 году, является Филипп Кратчен. Методика "4+1" позиционируется в качестве простого и понятного инструмента описания программной архитектуры.

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

Первые четыре:

  • Логическое представление

    Данное представление играет роль модели проектирования разрабатываемой информационной системы. Может различаться в зависимости от выбранной технологии реализации программного обеспечения. Цель логического представления методики "4+1" - фиксация функциональных требований к программному продукту.

  • Процессное представление

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

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

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

  • Представление уровня разработки

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

Связующим артефактом разрабатываемой архитектуры программного продукта ("+1"), в представленной модели "4+1", являются специализированные сценарии использования (use cases). На основе ключевых сценариев использования во многом происходит формирование конечного вида программного продукта. Ключевые сценарии объединяют представления в единую и неделимую систему, описывающую последовательность взаимодействия объектов и процессов. При описании акцент сделан на наиболее важных требованиях, формирующих конечный результат процессов архитектурного проектирования и разработки программного продукта. Сценарии использования должны удовлетворять следующим требованиям:

  • Полностью идентифицировать значимые объекты архитектуры;
  • Контролировать и демонстрировать полноту и работоспособность архитектуры.

Стратегическая модель архитектуры "SAM"

Современная методика "Стратегическая модель архитектуры" (Strategic Architecture Model) представляет собой инструмент анализа и документирования архитектуры программного продукта и связанных с ним предметных бизнес доменов. Данная методика получила широкое распространение по причине активного внедрения компанией Microsoft в свои внутренние и внешние проекты. Но, несмотря на такого авторитетного покровителя, ее авторство принадлежит английской консалтинговой компании Systems Advisers Ltd.

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

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

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

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

Наиболее приоритетны следующие сферы:

  • Бизнес цели и обеспечивающие их задачи, достижение которых обеспечивает эволюционное развитие компании и продвижение на рынке;
  • Бизнес-процессы, составляющие конкурентное преимущество компании в соответствующей бизнес-ниши рынка товаров и услуг;
  • Бизнес-компоненты, которые определяют движение бизнес-процессов;
  • Прикладные системы, автоматизирующие работу бизнес-процессов и бизнес-компонентов;
  • Задействованные в организации программные и аппаратные технологии;
  • Проекты, в ходе которых выполняется автоматизация бизнес-процессов и компонентов и достижение бизнес-целей;
  • Используемые данные;
  • Организационная структура;
  • Технологическая инфраструктура.

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

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

  • Cервис-ориентированную архитектуру SOA;
  • Архитектуру MDA, основанную на управлении моделями.

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

  • Статичные

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

  • Подвижные

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

  • Динамичные

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

Приведенная классификация позволяет:

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

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

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >