АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
ГЛАВА 9. ФРЕЙМВОРКИ 9.1. Понятие фреймворка. Типы фреймворков Понятие фреймворка. Термин фреймворк происходит от английского framework (каркас, структура). Достаточно часто вместо термина фреймворк используют термин каркас и говорят о каркасном подходе к проектированию. Каркасный подход к проектированию или подход к проектированию на основе фреймворков получил самое широкое распространение в среде разработчиков ИС. Основная идея данного подхода состоит в том, что предлагается использовать некоторые типовые проверенные практикой решения, т.е. термин фреймворк можно определить как лучшая практика. Фреймворки могут использоваться для решения самых разных задач, относящихся к проектированию ИС, таких как решение конкретных программистских задач, проектирование архитектуры ИС, проектирование и сопровождение корпоративной ИС. Термин фреймворк или каркас является достаточно популярным в среде разработчиков ИС и может обозначать разные понятия. В настоящее время нет общепринятого определения термина фреймворк. Чаще всего, фреймворк определяют как набор типовых решений, методик проектирования и классов, которые могут быть использованы при решении множества сходных задач. В самом широком смысле под фреймворком понимают общепринятые архитектурно-структурные решения и (или) подходы к проектированию ИС. Применительно к программным системам фреймворк или каркас представляет собой набор классов или структур, которые описывают решение некоторого класса задач. Для решения конкретной задачи разработчик выполняет настройки соответствующих компонентов, собирает отдельные компоненты в систему и генерирует исполняемый код. Различия между паттернами и фреймворками. Фреймворки и паттерны имеют много общего и, в первую очередь, это то, что паттерны и фреймворки - это подходы к повторному использованию кода. Различие между паттернами и фреймворками состоит в следующем. Фреймворк можно рассматривать как реализацию системы паттернов проектирования (поведенческих паттернов). В то время как фреймворк – это исполняемая программа, а паттерн – это знание и опыт как решать конкретную задачу. Еще одно отличие паттерна от фреймворка состоит в том, что фреймворк представляет собой скелетное решение достаточно крупной задачи и обычно включает в себя достаточно большое количество как паттернов, так и компонентов. Кроме того, фреймворки могут использовать подклассы и другие механизмы. Фреймворки можно классифицировать: по месту применения в ИС, по способу использования и по масштабу применения [128]. Схема классификации фреймворков показана на рис. 9.1  Рис. 9.1. Классификация фреймворков По месту применения фреймворки можно разделить на 3 типа: инфраструктурные фреймворки (System Infrastructure Frameworks); фреймворки уровня промежуточного ПО (Middleware Frameworks); фреймворки, ориентированные на разработку приложений(Application Frameworks), это могут быть либо фреймворки общего назначения, либо фреймворки, относящиеся к конкретному предметному домену. Использование инфраструктурных фреймворков упрощает разработку инфрастуктурных элементов, таких как, например, операционные системы. Обычно такие фреймворки используются внутри организации и не поступают в продажу. Фреймворки уровня промежуточного ПО используются для интеграции распределенных приложений и компонентов. Фреймворки, ориентированные на приложения, используются, в первую очередь, для поддержки процесса разработки систем, ориентированных на конечного пользователя и принадлежащих некоторому конкретному предметному домену. Можно выделить два типовых подхода к использованию фреймворков: использование фреймворка по принципу «белого ящика»; использование фреймворка по принципу «черного ящика». Кроме того, возможно использование гибридных подходов, которые называют «серым ящиком». Фреймворки, используемые по принципу белого ящика, называют также архитектурными фреймворками (architecture-driving framework). Эти фреймворки используют наследование и динамическое связывание для формирования скелета приложения. Фреймворк, работающий по принципу белого ящика, определяется через интерфейсы объектов, которые разработчик может добавлять в систему. Основным недостатком данного подхода является то, что для того, чтобы работать с фреймворками, необходимо иметь подробную информацию о классах, которые будут расширяться. Фреймворки, используемые по принципу черного ящика, называют также фреймворками, управляемыми данными. При использовании фреймворков данного типа в качестве основных механизмов формирования приложения выступают композиция компонентов и параметризация. При этом требуемая функциональность достигается посредством добавление в фреймворк дополнительных компонентов. В общем случае, работать с фреймворками, использующими принцип черного ящика, проще, чем с фреймворками, реализуюшими принцип белого ящика, но их разработка является более сложной. Большинство реальных фреймворков используют комбинацию рассмотренных выше подходов и их называют фреймворками, используемыми по принципу серого ящика (grey-box). По масштабу применения фреймворки можно разделить на три группы: фреймворки уровня приложений, фреймворки уровня домена, вспомогательные фреймворки. Фреймворки уровня приложения (аpplication frameworks) обеспечивают полный набор функций, которые реализуются типовым приложениями. Обычно сюда входят GUI, базы данных, документация. Примером таких фреймворков могут служить MFC (Microsoft Foundation Classes), которые используются для создания приложений для работы в среде MS Windows и JFC (Java Foundation Classes). Фреймворки уровня домена (Domain frameworks) используются для создания приложений, относящихся к определенному предметному домену. В качестве домена может выступать как ИС, включающая несколько взаимодействующих между собой приложений, например, системы сбора и обработки телеметрической информации, поступающих от сложной технической системы, так и целой организации, в качестве которой могут выступать, например промышленные корпорации, органы государственной власти, правительственные ведомствам и т.п. В последнем случае речь идет о фреймворках уровня организации (enterprise). Под термином «организация» понимается в самом широком смысле и включает коммерческие и некоммерческие организации, целые корпорации и их подразделения, различного рода ассоциации типа совместных предприятий и т.д. Следует особо отметить, что термин «организация» включает в себя такие элементы как людей, собственно бизнес, информацию, технологии, а не только информационная система. Вспомогательные фреймворки (Support frameworks) ориентированы на решение частных задач, таких как управление памятью или файловой системой. Фреймворки уровня домена. Международный стандарт ISO/IEC 42010 определяет архитектурный фреймворк как «совокупность соглашений, принципов и практик, используемых для описаний архитектур и принятых применительно к некоторому предметному домену и (или) в сообществе специалистов (заинтересованных лиц)» [6]. Типовой архитектурный фреймворк включает следующие основные элементы: типовые для домена заинтересованные лица; типовые для домена проблемы; архитектурные точки зрения; правила интеграции различных точек зрения. Кроме того, фреймворки могут включать методы и инструменты. Фреймворки уровня домена можно классифицировать по следующим признакам (рис. 9.2: назначение; принцип построения; гибкость при использовании; условия реализации. С точки зрения назначения, фреймворки можно разделить на фреймворки общего назначения и фреймворки, ориентированные на конкретные предметные области, такие как правительственные организации и оборонные ведомства. Возможны различные концептуальные подходы к построению фреймворков, в частности: ключевым элементом фреймворка может быть онтология; в основу фреймворка может быть положен тот или иной процесс разработки; фреймворк может быть ориентирован на данные (данноцентрический подход); фреймворк может быть ориентирован на эффективную поддержку сетевых взаимодействий.  Рис. 9.2. Классификация фреймворков уровня доменаФреймворки могут распространяться на коммерческой основе, либо быть бесплатными для некоммерческого использования. Кроме того, фреймворк может быть ориентирован на использование внутри организации. С точки зрения возможности реконфигурирования и возможности настройки на конкретное применение фреймворки можно разделить на «жесткие» и «гибкие». Жесткие фреймворки не предусматривают возможности настройки, а гибкие – разрешают настраивать фреймворк для решения конкретной задачи. Жесткие фреймворки могут требовать использовать конкретный инструментарий и конкретную методологию проектированию. На данный момент существуют, по крайней мере, десятки различных фреймворков разного уровня и назначения. Ниже в качестве примеров рассмотрены некоторые из них. Это достаточно широко известные и активно используемые фреймворки, для построения которых использованы разные подходы. Примеры подобраны таким образом, чтобы показать разнообразие существующих фреймворков. 9.2. Фреймворки уровня приложения Фреймворки уровня приложения (аpplication frameworks) обеспечивают широкий набор функций, которые используются для построения типовых приложений. Фреймворки уровня приложения наряду с фреймворками, ориентированными на разработку GUI, можно отнести к самым старым фреймворкам. Наиболее широко известными фреймворками данного типа являются . NET и JEE фреймворки, хотя термин фреймворки применительно к этим продуктам используется не часто, но фактически это фреймворки [128]. Java как фреймворк. Изначально Java разрабатывалась как язык для программирования встроенных систем. Однако за почти двадцать лет своего существования в развитый язык программирования общего назначения. Наиболее продвинутой его частью следует считать Java Platform, Enterprise Edition (JEE), которая представляет собой набор спецификаций и соответствующей документации, описывающей архитектуру серверной платформы для задач средней и большой сложности. JEE может позиционироваться как промышленная технология, ориентированная на использование в крупномасштабных проектах, в которых требуется надежность, масштабируемость, гибкость. Популярности JEE способствует то, что предлагается бесплатный комплект разработки, позволяющий предприятиям разрабатывать свои системы, не тратя больших средств. Имеются бесплатные инструментальные средства разработки. JEE представляет собой законченный фреймворк, позволяющий выполнять работы связанные с проектированием, кодированием, отладкой, сборкой многоуровневых распределенных приложений, написанных на Java. Структура JEE показана на рис. 9.3.  Рис. 9.3. Структура JEE JEE представляет собой совокупность 4 контейнеров: контейнер для апплетов (Applet Container), клиентский контейнер (Client Container), Веб контейнер (Web Container), EJB контейнер (Enterprise JavaBeans (EJB) Container). Клиентский контейнер – это контейнер, в котором функционирует клиентская часть JEE приложения. Веб контейнер предназначен для поддержки функционирования серверных компонентов 2 типов: сервлетов (servlets) и Java Server Pages. EJB контейнер предназначен для поддержки функционирования компонентов EJB, которые будут рассмотрены ниже. Контейнер для апплетов – предназначен для поддержки функционирования Java апплетов. Обычно это Web браузер. JEE платформа ориентирована на поддержку разработки многослойных распределенных клиент-серверных приложений. В рамках данной платформы определяются следующие слои: клиентский слой (client tier), слой бизнес-логики (business logic tier) и back-end слой (back-end tier). Клиентский слой ориентирован на работу различных типов клиентов. В слое бизнес-логики размещается код, который реализует требуемую функциональность (бизнес-логику). Этот слой может быть представлен в виде нескольких подслоев. Back-end слой обычно представлен базами данных. JEE платформа не накладывает ограничений на размещения слоев. Они могут быть размещены на одном или разных компьютерах, размещенных в сети. Центральный слой, в котором реализуется бизнес-логика приложения, использует EJB контейнеры, которые предоставляют сервисы, находящимся в них EJB компонентам. Все обращения к компонентам осуществляются через контейнер. Контейнер поддерживает взаимодействие с back-end слоем. Для этого обычно используются решения, основанные на Java Data Base Connectivity (JDBC), которая представляет собой набор драйверов для доступа к реляционным базам данных. Для установки компонентов в контейнеры используются XML дескрипторы. Клиентская часть приложения может быть реализована разными способами, это может быть Web-клиент, апплет или обычное Java приложение. Взаимодействие со средним слоем также может реализовываться разными способами: с помощью http (https) протокола, с использованием XML или других протоколов. Такой гибкий подход позволяет создавать достаточно эффективные приложения. Клиент может быть реализован с использованием JavaBeans или апплета. Для доступа к бизнес-логике часто используют сервлеты. Клиентская часть часто реализуется с помощью апплета, который может быть загружен через Интернет в браузер пользователя. Одним из преимуществ работы с апплетом состоит в том, что конечный пользователь может быть уверен, что он работает с последней версией приложения, при этом от него не требуется выполнять никаких действий по установке клиентской части приложения на своем компьютере. Бизнес-логика чаще всего реализуется в промежуточном слое, Для этого обычно используется EJB технологии. EJB компоненты помещаются в EJB контейнеры, что позволяет строить надежные и масштабируемые системы. С точки зрения JEE платформы КИС находятся в back-end слое, при этом имеются достаточно богатые библиотеки API для взаимодействия с ними, основными из которых являются следующие: JDBC API, который может использоваться для доступа к реляционным базам данных; Java Transaction API (JTA), который может использоваться для работы с транзакциями, Java Naming and Directory Interface (JNDI) может использоваться для работы с корпоративными службами каталогов; Java Message Service (JMS) может использоваться в качестве корпоративной системы обмена сообщениями; JavaMail API могут использоваться для работы с почтовыми сообщениями; Java APIs for XML может использоваться для интеграции вновь создаваемых систем с уже существующими системами. В качестве основных достоинств JEE платформы обычно указывают относительную простоту, хорошую масштабируемость приложений, легкость портирования, возможность повторного использования кода на уровне EJB компонентов, возможность интеграции с не-Java приложениями [129]. Полную информацию по данному фреймворку можно найти на официальном сайте [130]. .NET фреймворк от фирмы Майкрософт. .NET Framework — это программная платформа, выпущенная компанией Microsoft в 2002 году. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR), функциональные возможности которой доступны в любых языках программирования, использующих эту среду. При разработке .NET были учтены, с одной стороны, опыт использования COM/DCOM и ActiveX, а, с другой стороны, принято считать, что платформа .NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (в настоящее время принадлежит компании Oracle), которая основана на использовании виртуальной машины. По замыслу разработчиков, платформа .NET должна была предоставить возможности пользователям работать с Интернет как со стационарных компьютеров, так и с использованием беспроводных устройств. Следует отметить, что .NET платформа может использоваться не только на компьютерах, но и на любых Windows совместимых устройствах. .NET в полном объеме поддерживает XML, который является стандартом de facto для обмена информацией. Основная идея NET фреймворка состоит в том, чтобы программа, написанная на любом поддерживаемом платформой ЯВУ, сначала переводится компилятором промежуточный байт-код (Common Intermediate Language, CIL), который затем либо исполняется виртуальной машиной (Common Language Runtime, CLR), либо транслируется в исполняемый код для конкретного целевого процессора. Использование виртуальной машины избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR встроенный в неё JIT-компилятор «на лету» (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Однако потери производительности неизбежны. Этот подход во многом копирует подход, который ранее использовался разработчиками Java в части использования виртуальной машины. Отличие состоит в том, что в .NET использование виртуальной машины рассматривается не только как средство скрыть от пользователя специфику используемой аппаратной платформы, но и скрыть специфику используемого языка программирования. Обобщенная структура .NET фреймворка показана на рис. 9.4. В рамках .NET фреймворка имеются следующие слои (уровни): CLR слой, набор базовых классов платформы, слой классов данных и классов для работы с XML, библиотека классов .NET фреймворка. .NET является надстройкой над операционной системой, в качестве которой может выступать версия Windows. Принципиально возможно использование и любых других ОС, однако эта практика до сих пор не получила распространения.  Рис. 9.4.Обобщенная структура .NET фреймворка Ядром .NET является CLR, предоставляющая среду выполнения программы. Ее основная функция состоит в том, чтобы обнаруживать и загружать типы .NET и производить управление ими в соответствии с полученными командами. CLR включает в себя виртуальную машину. На верхнем уровне среда активизирует объекты, производит проверку безопасности, размещает объекты в памяти, выполняет их. В состав CLR также входит сборщик мусора. Под сборкой мусора понимается автоматическое уничтожение объектов, которые более не используются в дальнейшей работе приложения с целью освобождения памяти. На следующем над CLR уровне располагается слой базовых классов .NET (Framework Class Library, FCL), которая открывает доступ к системным функциям, включая и те, что прежде были доступны только через API Windows. Набор базовых классов платформы образуют нижний уровень FCL, который поддерживает такие низкоуровневые операции как файловый ввод/вывод, обработка графики и взаимодействие с оборудованием компьютера. Кроме того, он включает функции, ориентированные на поддержку низкоуровневых сервисов, таких как, управление нитями (вычислительными потоками), работу с сетевыми соединениями и др. Далее следует слой классов для работы с данными и XML. Классы данных позволяют реализовать управление информацией, хранящейся в серверных базах данных. В эту группу входят классы SQL. Кроме того, имеется набор классов, называемый ADO.NET, который ориентирован на работу с постоянными данными. Кроме того, имеется набор классов для работы с XML, использование которых позволяет осуществлять поиск и преобразования XML. Базовые классы, классы данных и XML расширяются классами, предназначенными для построения приложений на основе трех различных технологий: Windows-формы (Windows Forms). Web-формы (Web Forms) и Web-сервисы (Web Services). Всего разработчики получают в свое распоряжение более 4000 классов, которые могут быть использованы в процессе разработки настольных, клиент-серверных и других приложений, а также приложений основанных на использовании Web-сервисов. В качестве основных (официальных) языков, в число которых входят: С#, VB.NET, Managed C++ (управляемый C++) и JScript .NET поддерживается большое количество других ЯВУ. Более подробную информацию о .NET можно найти, например, в [131, 132]. 9.3. Фреймворк Захмана Это один из самых старых архитектурных фреймворков. Он назван по фамилии его создателя Джона Захмана (John Zachman), который разработал данный подход еще в 80-х годах прошлого века работая в IBM. С момента его создания появилось несколько вариантов данного фреймворка. На данный момент последней была версия 2 Framework for Enterprise Architecture, которая была разработана компанией Zachman International в 2008 году. До 1992 года этот фреймворк назывался Фрейворк для Архитектуры ИС (A Framework for Information Systems Architecture). Это один из первых фреймворков, которые предлагают рассматривать организацию и ее ИС с многих точек зрения. Этот фреймворк является достаточно универсальным. В первую очередь он ориентируется на корпоративные ИС. Он может использоваться для решения для анализа и моделирования текущей структуры организации и возможных изменений ее структуры в ответ на изменения во внешнем мире. Фреймворк Захмана также достаточно часто используется аналитиками и архитекторами крупных ИС. При этом сам автор, определяя область применения фреймворка, указывал, что область его применения не ограничивается архитектурами ИС, а может расширяться применительно к решению задач уровня КИС. Фреймворк Захмана разрабатывается и распространяется организацией ZIFA (Zachman Institute for Framework Advancement). Сам фреймворк не является стандартом, однако он послужил основой для разработки ряда других фреймворков, которые стали отраслевыми стандартами, таких как Federal Enterprise Architecture Framework (FEAF), The Open Group Architecture Framework (TOGAF), and the Department of Defence Architecture Framework (DoDAF), некоторые из которых будут рассмотрены ниже В основе данного фреймворка лежит классификация (таксономия) артефактов, в состав которых входят такие категории как данные и функциональность, а также модели, спецификации и документы. Фактически, фреймворк Захмана в современном виде представляет собой онтологию верхнего уровня, которую разработчик конкретной ИС может расширять и уточнять, получая в результате онтологию, описывающую конкретную систему. В основе предложенной таксономии лежит идея, состоящая в том, что функционирование организации можно описать в терминах ответа на 6 простых вопросов: что, как, где, кто, когда, почему: используемые данные (что?); процессы и функции (как?); места выполнения процессов (где?); организации и персонал (кто?); управляющие события (когда?); цели и ограничения, определяющие работу системы (зачем?). Ответы на эти вопросы можно давать с использованием различных понятий, т.е. с разной степенью детализации. При этом выделяется 6 уровней: уровень контекста; уровень бизнес-описаний; системный уровень; технологический уровень; технический уровень; уровень реальной системы. Таким способом формируется матрицы размером 6х6, каждой клетке которой ставятся в соответствие модели и артефакты (рис. 9.5). Обозначенные 6 вопросов определяют шесть аспектов рассмотрения с точки зрения разных заинтересованных сторон, в число которых входят: аналитики; менеджеры; архитекторы; разработчики; системные администраторы; пользователи.
Рис. 9.5. Матричное представление Фреймворка Захмана В рамках рассматриваемого фреймворка определены следующие правила заполнения ячеек. колонки можно менять местами, но нельзя добавлять новые колонки и удалять имеющиеся; каждой колонке соответствует собственная модель; каждая из моделей, соответствующих столбцам должна быть уникальна; каждая строка представляет собой описание системы с точки зрения пользователя или группы пользователей, т.е. представляет собой отдельный вид; каждая из ячеек уникальна; каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или текстового документа; заполнение клеток должно проводиться последовательно "сверху вниз". Первая строка (контекст) соответствует уровню планирования бизнеса в целом с учетом внешних факторов. На этом уровне вводятся общие понятия, определяющие функционирование организации, определяются ключевые бизнес-процессы (например, закупка сырья, сбыт продукции), описывается место нахождение объектов, например бизнеса, определяются организации, с которыми осуществляются взаимодействие (партнеры, конкуренты, вышестоящие организации, собственные подразделения и т.д.), определяется список событий, которые оказывают влияние на функционирование организации, а также формулируется бизнес-стратегия. Фактически, данная строка определяет контекст всех последующих строк и отражает самый общий взгляд на организацию и отражает точку зрения бизнес-аналитика. Вторая строка (бизнес-модель) предназначена для описания функционирования организации в бизнес терминах. Этот уровень отражает видение организации менеджерами верхнего уровня. Здесь, в частности, используются описания реализуемых в организации бизнес-процессов. Третий уровень (системная модель) соответствует видению организации системным архитектором. На этом уровне бизнес-процессы описываются уже в терминах ИТ-систем, включая определение типов данных, правила их преобразования и обработки для реализации функциональности, определенной на уровне 2. На четвертом уровне (технологическая модель) выполняется привязка данных и операций над ними к определенным программным и аппаратным платформам и инструментальным средствам. Четвертый уровень отражает взгляд на ИС с точки зрения разработчиков программных и аппаратных средств. Пятый уровень (детальное описание), включает описания конкретных моделей оборудования, топологию сети, средства разработки и собственно готовый программный код. Этот уровень отражает видения системы с точки зрения администраторов (системный администратор, администратор баз данных и т.п.). Шестой уровень (функционирующая организация) описывает функционирующую систему и представляет собой видение ИС конечным пользователем. На данном уровне присутствуют такие элементы как руководство пользователя, фактические базы данных и т.п. Если перемещаться по ячейкам таблицы по строкам сверху вниз, то можно проследить каким образом осуществляется детализация отдельных аспектов описания системы. Так, первая колонка определяет используемые в системе данные и отвечает на вопрос "ЧТО?". На верхнем уровне имеем простое перечисление основных сущностей. На втором уровне данные сущности используются для построения семантической модели, которая обычно описываются в виде ER-диаграммы. На третьем уровне полученная модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе, либо в случае использования объектно-ориентированного подхода иерархию классов. Пятый уровень включает описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. На последнем уровне описываются фактические наборы данных, размеры реально занимаемого дискового пространства, статистику обращений и т.д. Колонка процессы и функции, отвечающая на вопрос "КАК?", содержит описания последовательной детализации процесса перехода от миссии организации к описанию отдельных операций. В частности, первому уровню соответствует простое перечисление ключевых бизнес-процессов. Второй уровень содержит описания бизнес-процессов, которые затем детализируется и представляются в виде множества операций над данными и архитектуры приложений (уровень 3), методов классов (уровень 4), программного кода (уровень 5) и исполняемых модулей (уровень 6). Начиная с 4-го уровня, рассмотрение ведется уже не в рамках организации целом, а по отдельным приложениям. Колонка, которая называется место выполнения процесса, отвечающая на вопрос "ГДЕ?", определяет пространственное распределение компонент системы и сетевую инфраструктуру. На уровне планирования бизнеса оказывается достаточным определить расположение всех основных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие ними. На третьем уровне осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения и промежуточного ПО. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Шестой уровень описывает функционирование реализованной сети. Колонка таблицы организации и персоналии, отвечающая на вопрос "КТО?", определяет участников процесса. На первом уровне планирования бизнеса определяется список организаций-партнеров, подразделений организации и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли, требования к пользовательским интерфейсам пользователя, правила доступа к отдельным объектам, физическая их реализация на уровне кода. Колонка, которая называется Управляющие события и отвечает на вопрос "КОГДА?", определяет временные параметры бизнес-процессов и работы системы. Детализация осуществляется сверху вниз, начиная от списка значимых для функционирования системы событий (уровень 1) и базового графика работ (уровень 2). На третьем уровне определяются модели работы с событиями. На следующем уровне определяются алгоритмы обработки событий. Пятый уровень определяет программную реализацию процесса обработки событий, а на 6-м уровне – история функционирования системы, представленная, например, в форме записей в лог-файлах. Последняя колонка, определяющая Цели и ограничения, отвечает на вопрос "ПОЧЕМУ?", описывает мотивации и задает порядок перехода от задач бизнеса к требованиям, вторые предъявляются к отдельным элементам системы. Исходной точкой является бизнес-стратегия, которая последовательно транслируется в дерево целей и бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию. Рассматриваемый фреймворк в явном виде не позволяет описывать поведение системы в динамике, поскольку каждый элемент таблицы не может содержать как описание существующего состояния ("как есть"), так и целевого, а также всех промежуточных состояний, при этом модель не содержит средств для четкого разделения этих различных "временных срезов". Однако этот недостаток достаточно просто можно устранить, если перейти от одномерной к двухмерной модели в виде куба, содержащего множество временных срезов. Более серьезный недостаток данного фреймворка состоит в отсутствии встроенного механизма распространения изменений между элементами таблицы, приводит к необходимости вручную отслеживать изменения всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально "затрагиваемых" ячейках. Данный фреймворк не накладывает ограничений на использование тех или иных аппаратных и программных платформ и инструментальных средств разработки. Несомненными достоинствами фреймворка Захмана являются простота для понимания как техническими, так и нетехническими специалистами, возможность поддержки обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий, нейтральность, относительно инструментальных средств. Фреймворк Захмана распространяется на коммерческой основе [133]. 9.4. Фреймворк DODAF Архитектурный фреймворк министерства обороны США (Department of Defense Architecture Framework, DoDAF) представляет собой фреймворк разработанный для нужд министерства обороны США. Первая версия этого документа была разработана в 1996 году в качестве реакции на появление известного акта Клингера-Коэна (Clinger-Cohen Act). (Закон США, который определял каким образом федеральное правительство должно закупать, использовать информационные технологии, в частности для военных применений. В рамках данного фреймворка различаются 2 типа архитектур: корпоративная архитектура (Enterprise-level architecture) и архитектура решений (Solution Architecture). Под корпоративной архитектурой (архитектурой организации) понимается стратегическая информация, которая определяет миссию, информация необходимая для выполнения миссии, технологии, необходимые для выполнения миссии, процессы, которые необходимо реализовать в случае изменения миссии, процессы, которые необходимо реализовать для внедрения новых технологий. Корпоративная архитектура должна содержать описание текущей архитектуры, описание целевой (желаемой) архитектуры и план перехода от существующей к желаемой архитектуре. Под архитектурой решения понимается фреймворк или структура, описывающая элементы и их взаимосвязи, использование которых позволяет организации выполнять свою миссию [134]. Архитектура решений не является предметом рассмотрения DoDAF. В рамках DoDAF рассматривается только архитектура организации. DoDAF ориентирован, прежде всего, на формирования требований к очень сложным системам, которые иногда называют системой систем (System of Systems, SoS), поскольку в качестве элементов систем выступают другие системы. Основной целью создания данного фреймворка являлось создание методологии, которая ориентирована на использование аналитиками, формулирующими требования к подсистема ИС максимальной сложности. Все вооружения и информационные системы, закупаемые министерством обороны США, должны документироваться в соответствии с данным фреймворком. Несмотря на то, что данный фреймворк ориентирован на системы военного назначения, он является полностью открытым и свободно распространяемым. Всю информацию по данному фреймворку можно найти на сайте МО США [134]. Первая версия DoDAF появилась в 2003 году, а на данный момент последней версией DoDAF была версия 2.02. Отличительной особенностью DoDAF является ориентация на данные, авторы позиционируют данный фреймворк как datacentric, т.е., по мнения авторов, самым главным элементом ИС являются данные, а обрабатывающие их приложения являются производными, а при создании семейств продуктов наиболее важным является сохранения данных для повторного использования. Интересно отметить, что в предыдущая версия DoDAF (версия 1.5) определяла данный фреймворк как ориентированный на сетевое взаимодействие (netcentric). Ориентация на данные определяет класс систем, на проектирование которых ориентирован DoDAF – это, прежде всего, системы сбора хранения и обработки данных с целью их использования в процессе принятия решений. Основными элементами архитектурного описания являются модели (models), виды (view) и точки зрения (viewpoints). Модель определяется как шаблон (template) для сбора данных, при этом выделяются следующие типы моделей: таблицы, данные в которых представлены в виде строк и столбцов; графические изображения, описывающие структурные аспекты архитектурного решения; графические изображения, описывающие поведенческие аспекты архитектурного решения; отображения, описывающие взаимосвязь между двумя типами информации в форме матрицы; онтологии, являющиеся расширением онтологии, определенной в DoDAF; картинки в свободном формате; разного рода временные диаграммы. Вид определяется как способ представления связанного набора данных в понятном пользователю виде. Это могут быть документы, таблицы, графики и т. п. Точка зрения описывает данные, поступающие от одного или нескольких источников, которые организованы таким образом, чтобы были полезны при принятии решений и может включать несколько видов. Точка зрение представляет собой упорядоченное множество видов. Архитектурное описание в рамках DoDAF определяется как множество видов, используемых для документирования архитектуры. В рамках DoDAF V2.0 определяются восемь точек зрения (рис. 9.6):  Рис. 9.6. Структура фрймворка DoDAF обобщенная точка зрения (All Viewpoint (AV), которая интегрирует все точки зрения и образует архитектурный контекст для других точек зрения; точка зрения, определяющая потенциальные возможности (Capability Viewpoint, CV), использующая такие понятия как, например сроки поставки оборудования, обучения персонала и т.д.); точка зрения данные и информация (Data and Information Viewpoint, DIV), рассматривает структуры данных и способы их представления для разных целей; операционная точка зрения (Operational Viewpoint, OV), рассматривает систему с точки зрения сценариев работы, активностей; проектная точка зрения (Project Viewpoint PV), которая рассматривает систему с точки зрения требуемых характеристик и возможностей, а также с точки зрения процесса проектирования и других реализуемых проектов (эта точка зрения активно используется при реализации процесса закупок систем для нужд МО); сервисная точка зрения (Services Viewpoint, SvcV) рассматривает систему как совокупность взаимодействующих сервисов; точка зрения, учитывающая стандарты (Standards Viewpoint, StdV), в частности, действующие технические стандарты, методики, руководства, ограничения и т.п.; системная точка зрения (Systems Viewpoint, SV) рассматривает систему как совокупность взаимодействующих подсистем, рассматривает способы взаимодействия подсистем и используется преимущественно при необходимости работать с унаследованными системами. DoDAF служит также руководством по разработке интегрированных архитектур, которые определяются как архитектура которая включает в себя множество видов, однако не требует использовать именно предлагаемую методологию проектирования в процессе разработки архитектуры. Термин интегрированная архитектура означает, что данные могут использоваться для формирования более чем одного архитектурного вида. Данные могут собираться, организовываться и храниться с использованием различных программных продуктов и инструментов, в частности, коммерческих. Предлагаемая методика построения архитектурного описания включает 6 шагов. 1. Определение назначения архитектурного описания. 2. Определение требуемого уровня детализации разрабатываемого описания. 3. Определение того, какие данные необходимы для построения архитектурного описания. 4. Сбор и обработка требуемых данных. Построение описания. 5. Анализ архитектуры на соответствие требованиям. 6. Документирование архитектуры и представление результатов в виде, удобном для практического применения в системах поддержки принятия решений. Визуализация видов используется исключительно в иллюстративных целях. Для успешного использования DoDAF пользователям предлагается руководствоваться 8 принципами, которые представляют собой концепции достаточно высокого уровня. 1. Архитектурное описание должно быть четко ориентировано на провозглашенные цели. 2. Архитектурное описание должно быть по возможности простым и понятным, но не упрощенным. 3. Архитектурное описание должно облегчать, а не затруднять процесс принятия решений. 4. Архитектурное описание должно быть составлено таким образом, чтобы его можно было использовать для сравнения различных архитектур. 5. При составлении архитектурного описания должны в максимальной степени использоваться стандартные типы данных. 6. Архитектурное описание должно выполняться в терминах самих данных, а не инструментальных средств работы с данными. 7. Архитектурные данные должны быть организованы в виде, удобном для групповой работы. 8. Архитектурное описание должно быть построено таким образом, чтобы его можно было использовать в сетевой среде, т.е. должно быть сетецентричным. Мета модель данных. В рамках DoDAF используется мета модель данных, которая называется Data Meta-Model (DM2), которая является онтологией и имеет несколько уровней, каждый из которых отражает тот уровень представления информации, который важен для конкретной группы пользователей. Пользователь может расширять данную модель в соответствии со своими нуждами. В рамках DM2 определены 3 верхних уровня: концептуальная модель данных (Conceptual Data Model (CDM); логическая модель данных (Logical Data Model, LDM); спецификация обмена данными на физическом уровне (Physical Exchange Specification, PES). Данные модели являются составной частью рассматриваемого фреймворка. Концептуальная модель дает возможность строить архитектурное описание в нетехнических терминах, которое понятно не только ИТ-специалистам. Логическая модель является расширением концептуальной модели за счет добавления атрибутов к понятиям, определенным на концептуальном уровне. Спецификация обмена данными представляет собой платформенно независимое средство, которое обеспечивать обмен данными между разными моделями. Данная спецификация основана на использовании XML и XSD. Для каждой из моделей, входящей в состав DoDAF, имеется собственное XSD-описание. Семантически близкие понятия сгруппированы в кластеры, основными из которых являются следующие: цели; средства достижения целей (что нужно предпринять в тех или иных обстоятельствах для достижения желаемого эффекта); активности (работы которые выполняют некоторые преобразования или изменяют состояние); исполнители (То, что реализует активности, в частности, системы, персонал, организации); сервисы (бизнес-сервисы или программные сервисы); материальные потоки (описывают процессы взаимодействия между активностями); информация и данные; проекты (все формы планируемых активностей); трейнинги/квалификация/образование описания требований с точки зрения квалификации персонала); правила (правила типа «как», стандарты, соглашения, ограничения, относящиеся к архитектуре); метрики (все виды измерений, которые применимы к архитектуре); местоположение (все виды размещения, включая точки, линии, фигуры, место нахождения конкретного оборудования, URL и т.д. Если сравнивать DoDAF с рассмотренными ранее фреймворками Захмана и TOGAF, который будет рассмотрен ниже, то следует отметить, что он существенно отличается по назначению, поскольку ориентирован не на разработку всей системы, а, прежде всего, на разработку архитектурного описания системы, с целью формирования задания на разработку с учетом ранее выполненных разработок и разработок, выполняющихся одновременно. В качестве конечного результата выступает не ИС, а только ее задокументированное архитектурное описание. Кроме того, DoDAF дает пользователя значительно большую свободу выбора инструменальных средств и моделей для решения конкретной задачи и активно предлагает пользователю выбирать только те модели, которые ему действительно нужны. На базе DoDAF был создан целый ряд других фреймворков, к числу которых относятся фреймворк НАТО (NATO Architecture Framework, NAF) и фреймворк МО Великобритании (Ministry of Defence (United Kingdom) Architecture Framework (MODAF). DoDAF имеет много общих черт с TOGAF, в частности, одним из ключевых элементов как TOGAF, так и DoDAF является репозитарий, содержимое которого доступно всем заинтересованным сторонам. 9.5. TOGAF фреймворк Open Group Architecture Framework (TOGAF) является одним из наиболее широко известных и часто используемых архитектурных фреймворков, который ориентирован на решения задач, связанных с проектированием, планированием, реализацией и управлением корпоративной архитектурой и представляет собой набор инструментов, использование которых позволяет разрабатывать широкий спектр архитектур различного назначения. Он позволяет описывать ИС как совокупность строительных блоков (модулей), определять способы их соединения с помощью прилагаемого инструментария, включает список рекомендованных к применению стандартов и платформ, которые могут быть использованы при реализации ИС. Разработчика TOGAF ведется в рамках Архитектурного Форума (Architecture Forum) который функционирует в составе известной организации The Open Group, которая распространяет данный фреймворк бесплатно для некоммерческого использования. Разработка проводится начиная с середины 90-х годов. На данный момент последней является версия 9, которая появилась в начале 2009 года. С последними версиями можно ознакомиться на официальном сайте [135]. Следует отметить, что TOGAF дает собственное определение архитектуры, в соответствии с которым архитектура ИС определяется как «формальное описание системы, или детальный план системы на уровне компонентов и методология их реализации» или как «структура компонентов, их взаимосвязи, принципы их реализации и эволюции». В то время как в соответствии с общепринятым определением (стандарт ANSI/IEEE 42010-2011) архитектура определяется как «описание организации системы в терминах компонентов их взаимосвязей между собой и с окружающей средой и принципы управлением их разработкой и развитием». В рамках TOGAF определяются четыре архитектурных домена (рис. 9.7): бизнес-архитектура (архитектура бизнес-процессов), которая определяет бизнес-стратегию, систему управления организацией и ключевые бизнес процессы; архитектура уровня приложений, которая определяет интерфейсы отдельных приложений и способы их использования в процессе реализации бизнес-процессов в терминах бизнес-сервисов; архитектура данных, которая описывает логическую и физическую организацию корпоративных данных; технологическая (техническая) архитектура, которая описывает аппаратную, программную и сетевую инфраструктуру.
Рис. 9.7. Структура фреймворка TOGAF Основными компонентами TOGAF являются (рис. 9.8): методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры; руководства и методики проектирования, используемые в рамках ADM; фреймворк архитектурного описания (Architecture Content Framework), который представляет собой детальную модель результатов разработки архитектуры, в терминах артифактов и архитектурные блоки; архитектурный континиум организации (Enterprise Continuum), который представляет собой репозитарий архитектурных артефактов и артефактов реализации; эталонные модели TOGAF (TOGAF Reference Models), включающая в себя техническую эталонную модель (Technical Reference Model, TRM) и интегрированную модель информационной инфраструктуры (The Integrated Information Infrastructure Model, III-RM); фреймворк, описывающий организацию (Architecture Capability Framework), описывающий структуру организации, персонал, роли и ответственности.
Рис. 9.8. Основные компоненты TOGAF | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||