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

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

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

Архитектурные концепции и методики Microsoft

Лидеры рынка информационных технологий, компании, которые во многом определяют и формируют архитектуры современных программных продуктов (Microsoft, IBM, SAP и пр.), занимаются созданием собственных методик разработки архитектуры информационных систем. Во многом это является не просто дорогой прихотью, а их обязанностью. Это следует из того, что "линейка" информационных продуктов, предлагаемых обозначенными компаниями-гигантами, покрывает подавляющую часть комплексной архитектуры предприятия. Поэтому компаниям, которые склоняются в сторону выбора решений предлагаемых технологий, необходимы адекватные практические рекомендации, подкрепленные на практике успешным опытом использования.

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

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

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

  • Архитектура информации

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

  • Программные продукты

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

  • Технологическая архитектура

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

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

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

  • Microsoft Solutions Framework (MSF)

    Как создавать программные продукты?

  • Microsoft Operations Framework (MOF)

    Как эксплуатировать технологическую инфраструктуру?

  • Microsoft Systems Architecture (MSA)

    Как правильно создавать технологическую инфраструктуру?

  • Microsoft Solutions for Management (MSM)

    Как правильно создавать процессы управления технологической инфраструктурой?

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

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

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

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

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

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

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

Другие архитектурные методики

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

TEAF

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

RM-ODP

В основе справочной модели открытых распределенных вычислений (RM-ODP – Reference model of open distributed processing), находятся принципы анализа информационной системы под углом зрения на разные представления реализации системы и объектно-ориентированная парадигма разработки программных продуктов. Эта методика применяется при описании архитектуры электронного правительства Германии.

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

Модель определяет пять основных представлений:

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

Кроме представлений, RM-ODP содержит описание следующих функций:

  • Управление

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

  • Координация

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

  • Репозиторий

    Функция репозитория описывает, как информация организована и хранится.

  • Безопасность

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

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

В архитектурной модели RM-ODP выделено девять средств обеспечения прозрачности:

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

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

CAFCR

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

Аббревиатура СAFCR образована из названий пяти основных представлений данной модели;

  • Customer objectives – Задачи заказчика;
  • Application – Приложения;
  • Functional – Функциональность;
  • Conceptual – Концепция;
  • Realization – Реализация.

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

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

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

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

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