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

Это один из самых старых архитектурных фреймворков. Он назван по фамилии его создателя Джона Захмана, который разработал данный подход еще в 1980-х гг., работая в IВМ. С момента его создания появилось несколько вариантов данного фреймворка. Последний фреймворк Захмана (версия 2) Framework for Enterprise Architecture — был разработан компанией Zachman International в 2008 г. и анонсировался авторами как отраслевой стандарт. В основе данного фреймворка лежит классификация (таксономия) артефактов, в состав которых входят такие категории, как данные и функциональность, а также модели, спецификации и документы. Фактически фреймворк Захмана в современном виде представляет собой онтологию верхнего уровня, которую разработчик конкретной ИС может расширять и уточнять, получая в результате онтологию, описывающую конкретную систему.

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

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

• используемые данные (что?);

• процессы и функции (как?);

• места выполнения процессов (где?);

• организации и персоналии (кто?);

• управляющие события (когда?);

• цели и ограничения, определяющие работу системы (почему?).

Ответы на вопросы даются с разной степенью детализации на 6 уровнях:

1. уровень контекста, 2. уровень бизнес-описаний, 3. системный уровень, 4. технологический уровень, 5. технический уровень, 6. уровень реальной системы

Выделяют также 6 групп, которые отвечают на данные вопросы:

1. аналитики, 2. топ-менеджеры, 3. Архитекторы, 4. Разработчики, 5. Администраторы, 6. пользователи

Правило заполнения ячеек:

1. Колонки можно менять местами, но нельзя добавлять новые или удалять имеющиеся.

2. Каждой колонке соответствует собственная модель

3. Каждая из моделей, соответствующих столбцам, должна быть уникальна

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

5. Каждая из ячеек уникальна.

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

7. Заполнение клеток проводится последовательно сверху вниз.

38. Основные типы взаимодействия в ис

Гадасин рассказывал, что ИС могут совместно использовать данные, время ( типо 1 тик на одну прогу, второй тик на другую) и ресурсы ( например вычислительные ресурсы процессора)

Взаимодействие на уровне данных

Одной из главных проблем интеграции данных является обилие форматов и типов. Компоновка информации из различных информационных систем (ИС), установки ее однозначного соответствия в разных системах (таблиц, полей), синхронизация одинаковых информационных объектов в различных ИС.

В настоящее время обычно используют стандартные интерфейсы и протоколы, например, SQL и JDBC/ODBC, применяют различные инструменты реляционных баз данных (Relational Database — RD), и современных хранилищ и фабрик данных (Data Warehouse, Data Factory — DW, DF). Такие технологии создают удобную для пользователя единую среду для хранения и использования данных.

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

цель– объединить разрозненные программные приложения,

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

Интеграция на уровне  приложений

Интеграция на уровне приложений (Enterprise Application Integration — EAI,) подразумевает совместное использование исполняемого кода, а не только внутренних данных интегрируемых приложений. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО. При таком подходе из этих компонентов создается универсальное программное ядро или платформа, с помощью которых используют все приложения. Для каждого приложения создается только один интерфейс для связи с этим ядром, что существенно облегчает задачу интеграции.