Фреймворки. 
Архитектура информационных систем

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

В области программирования под фреймворком понимают множество классов и способов их взаимодействия^[1].

Одними из наиболее широко известных и активно используемых фреймворков, относящихся к определённым предметным областям, являются следующие:

• • фреймворк Захмана;
• • фреймворк TOGAF;
• • фреймворк министерства обороны США.

Фреймворк Захмана

Фреймворк Захмана является одним из первых архитектурных фреймворков, и назван по фамилии его разработчика Джона Захмана (John Zachman). Данный фреймворк был разработан им в компании IBM в 80-х гг. прошлого столетия. Последняя версия (версия 2) фреймворка была представлена компанией Zachman International в 2008 г. [13].

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

• • «что?» — данные;
• • «как?» — функции и процессы;
• • «где?» — места расположения системы;
• • «кто?» — организации и сотрудники;
• • «когда?» — расписание событий;
• • «почему?» — мотивы, определяющая функционирование системы.

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

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

Если аспекты системы использовать в качестве столбцов, а уровни описания — в качестве строк, то может быть сформирована таблица размером 6×6 (рис. 23). Каждая ячейка таблицы содержит соответствующий ему фрагмент описания системы. На каждом уровне описания могут быть выделены соответствующие заинтересованные лица, а именно:

Рис. 23. Табличное представление фреймворка Захмана.

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

Для фреймворка Захмана определены следующие правила заполнения ячеек:

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

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

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

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

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

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

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

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

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

Аспект " данные" на верхнем уровне представлен перечнем важнейших для бизнеса объектов и понятий. Далее на их основе выделяются основные сущности, выявляется взаимодействие между ними, т. е. строится семантическая модель, которая описывается, например, в виде ER-диаграммы^[2]. На уровне 3 полученная модель данных нормализуется, уточняются все атрибуты и ключи. На следующем уровне строится физическая модель данных системы либо иерархия классов, (при использовании объектно-ориентированной подхода). За ним следуют разработанные библиотеки классов, табличные пространства СУБД. Последнему уровню соответствуют описания фактических данных с учётом их реальных размеров, и т. п.

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

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

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

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

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

Достоинствами фреймворка Захмана являются:

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

Недостатками фреймворка Захмана являются:

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

Фреймворк Захмана распространяется и используется на коммерческой основе.

• [1] Одним из первых коммерческих фреймворков приложений стал МасАрр, разработанный компанией Apple для платформы Macintosh. Изначально он был создан наобъектно-ориентированной версии языка Паскаль, а впоследствии — переписан на C++.
• [2] lli ER-модель — модель сущность-связь (от англ, entity-relationship model, ERM) -модель данных, позволяющая описывать концептуальные схемы предметной области.