Архитектура информационных систем. Часть 1. Учебное пособие

7.3. Фреймворки

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

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

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

фреймворк Захмана;

фреймворк TOGAF;

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

17Одним из первых коммерческих фреймворков приложений стал MacApp, разработанный компанией Apple для платформы Macintosh. Изначально он был создан на объектно-ориентированной версии языка Паскаль, а впоследствии – переписан на C++.

71

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

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

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

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

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

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

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

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

18 ER-модель – модель сущность-связь (от англ. entity-relationship model, ERM) –

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

75

описания фактических данных с учётом их реальных размеров, и т.п.

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

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

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

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

76

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

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

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

простота восприятия как техническими специалистами, так и специалистами нетехнического профиля;

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

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

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

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

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

но зависимых ячейках.

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

77

Контрольные вопросы

1.Дайте понятие паттерна проектирования.

2.Поясните сущность основных видов системных паттернов.

3.Поясните сущность основных видов структурных паттернов.

4.Поясните сущность основных видов поведенческих паттернов.

5.Поясните сущность основных видов производящих паттернов.

6.Поясните сущность основных видов паттернов параллельного программирования.

7.Дайте понятие антипаттерна проектирования.

8.Поясните сущность основных видов антипаттернов в управлении разработкой ПО.

9.Поясните сущность основных видов антипаттернов в разработке ПО.

10.Охарактеризуйте основные виды антипаттернов в объектноориентированном программирование.

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

12.Поясните сущность основных видов методологических антипаттернов.

13.Поясните сущность основных видов организационных антипаттернов.

14.Дайте понятие фреймворка.

15.Какие аспекты и уровни описания используются во фреймворке Захмана?

16.Охарактеризуйте уровни контекста, бизнес-модели и системной модели фреймворка Захмана.

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

18.Поясните сущность следующих аспектов фреймворка Захмана: ″используемые данные″, ″процессы и функции″, ″места выполнения процессов″.

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

78

Технология RPC обеспечивает возможность вызова удалённой процедуры по возможности точно так же, как и процедуры локальной. При этом если вызываемая процедура является удалённой, то вместо локальной процедуры в библиотеку помещается специальная версия процедуры, называемая стабом клиента (англ. stub – заглушка). Стаб запускается аналогично локальной процедуре, но его выполнение сводится только к формированию сообщения для отправки ядру удалённого компьютера.

8.1.2. Схема выполнения RPC

Порядок взаимодействия программных компонентов при осуществлении удалённого вызова процедуры поясняется схемой, приведенной на рис. 24.

компьютер-клиент компьютер-сервер

сообщение-вызов

Рис. 24. Схема выполнения удалённого вызова процедуры

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

Ядро клиента:

осуществляет переключение на контекст ядра с сохранением содержимого регистров и карты памяти;

80