Паттерны в АИС. Паттерны и фреймворки ч2. Паттерны и фреймворки в архитектуре ис часть 2 Курс Архитектура информационных систем
 Скачать 449.97 Kb.
|
|
Паттерны и фреймворки в архитектуре ИС часть 2 Курс «Архитектура информационных систем» Фреймворки Фреймворк определяют, как набор типовых решений, методик проектирования и классов, которые могут быть использованы при решении множества сходных задач. В широком смысле под фреймворком понимают общепринятые архитектурно-структурные решения и (или) подходы к проектированию ИС. Применительно к программным системам фреймворк, или каркас, представляет собой набор классов или структур, которые описывают решение некоторого класса задач. Для решения конкретной задачи разработчик выполняет настройки соответствующих компонентов, собирает отдельные компоненты в систему и генерирует исполняемый код. Общность и различие Сходство: фреймворки и паттерны имеют общие подходы к повторному использованию кода Различие: Фреймворк можно рассматривать как реализацию системы паттернов проектирования, т.е. Фреймворк — это исполняемая программа Паттерн — это знание и опыт как решать конкретную задачу Фреймворк представляет собой скелетное решение достаточно крупной задачи и обычно включает в себя большое количество как паттернов, так и компонентов. Фреймворки могут использовать подклассы и другие механизмы. Классификация фреймворков Подходы к использованию фреймворков по принципу белого ящика по принципу черного ящика возможно использование гибридных подходов («серый ящик») Фреймворки. Принцип белого ящика Фреймворки, используемые по принципу белого ящика называют архитектурными фреймворками (architecture-driving framework). Применяют наследование и динамическое связывание для формирования скелета приложения. Определяется через интерфейсы объектов, которые разработчик может добавлять в систему. Недостаток: необходимо иметь подробную информацию о классах, которые будут расширяться. Фреймворки. Принцип черного ящика Фреймворки, используемые по принципу черного ящика называют фреймворками, управляемыми данными. В качестве основных механизмов формирования приложения выступают композиция компонентов и параметризация. Требуемая функциональность достигается посредством добавления в фреймворк дополнительных компонентов. Работать с фреймворками, использующими принцип черного ящика, проще, чем с фреймворками, реализующими принцип белого ящика, но их разработка является более сложной. Классификация по масштабу применения фреймворки уровня приложений фреймворки уровня домена (организации) вспомогательные фреймворки Фреймворки уровня приложения (application frameworks) Обеспечивают полный набор функций, которые реализуются типовыми приложениями: GUI базы данных документация Примером таких фреймворков могут быть MFC (Microsoft Foundation Classes), которые служат для создания приложений, ориентированных на работу в среде MS Windows. Фреймворки уровня домена (Domain frameworks) Используются для создания приложений, относящихся к определенному предметному домену. В качестве домена может выступать как информационная система, включающая несколько взаимодействующих между собой приложений, так и целой организации (фреймворки уровня организации (enterprise). Термин «организация» включает коммерческие и некоммерческие организации, целые корпорации и их подразделения, различного рода ассоциации типа совместных предприятий и т.д. Термин «организация» включает в себя такие элементы, как людей, собственно бизнес, информацию, технологии, а не только информационную систему. Классификация фреймворков уровня домена Примеры фреймворков фреймворк Захмана фреймворк TOGAF фреймворк министерства обороны США Фреймворк Захмана В 1980-х гг. Джон Захман (John Zachman) разработал данный подход, работая в IBM. Появилось несколько вариантов данного фреймворка. Фреймворк Захмана (версия 2) Framework for Enterprise Architecture — был разработан компанией Zachman International в 2008 г. и анонсировался авторами как отраслевой стандарт. В основе данного фреймворка лежит классификация (таксономия) артефактов, в состав которых входят такие категории, как: данные и функциональность модели, спецификации и документы. Фреймворк Захмана представляет собой онтологию верхнего уровня, которую разработчик конкретной ИС может расширять и уточнять, получая в результате онтологию, описывающую конкретную систему. Фреймворк Захмана Онтоло́гия (в информатике) — это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Фреймворк Захмана В основе предложенной классификации (таксономии) лежит идея, состоящая в том, что функционирование организации можно описать в терминах ответа на шесть простых вопросов: что, как, где, кто, когда, почему: используемые данные (что?); процессы и функции (как?); места выполнения процессов (где?); организации и персоналии (кто?); управляющие события (когда?); цели и ограничения, определяющие работу системы (почему?). Фреймворк Захмана Уровни детализации: уровень контекста; уровень бизнес-описаний; системный уровень; технологический уровень; технический уровень; уровень реальной системы. Уровни детализации Правила заполнения ячеек колонки можно менять местами, но нельзя добавлять новые колонки и удалять имеющиеся; каждой колонке соответствует собственная модель; каждая из моделей, соответствующих столбцам, должна быть уникальна; каждая строка (уровень) представляет собой описание системы с точки зрения пользователя или группы пользователей, т. е. представляет собой отдельный вид; каждая из ячеек уникальна; каждая клетка содержит описание аспекта реализации системы в виде определенной модели или текстового документа; заполнение клеток должно проводиться последовательно «сверху вниз». Недостаток фреймворка Захмана не позволяет описывать поведение системы в динамике, поскольку каждый элемент таблицы не может содержать как описание существующего состояния («как есть»), так и целевого, а также всех промежуточных состояний; модель не содержит средств для четкого разделения этих различных «временных срезов»; отсутствие встроенного механизма распространения изменений между элементами таблицы, что приводит к необходимости вручную отслеживать изменения всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально «затрагиваемых» ячейках; не накладывает ограничений на использование тех или иных аппаратных и программных платформ и инструментальных средств разработки. Достоинства фреймворка Захмана простота для понимания как техническими, так и нетехническими специалистами; возможность поддержки обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий; нейтральность относительно инструментальных средств. Фреймворк Захмана распространяется на коммерческой основе. Фреймворк TOGAF Фреймворк TOGAF ориентирован на решения задач проектирования, планирования, реализации и управления корпоративной архитектурой . Фреймворк TOGAF позволяет : описывать ИС как совокупность строительных блоков (модулей); определять способы их соединения с помощью прилагаемого инструментария, включает список рекомендованных к применению стандартов и платформ, которые могут быть использованы при реализации ИС. Архитектурные домены TOGAF бизнес-архитектура (архитектура бизнес-процессов) определяет бизнес-стратегию, систему управления организацией и ключевые бизнес-процессы; архитектура уровня приложений определяет интерфейсы отдельных приложений и способы их использования в процессе реализации бизнес-процессов в терминах бизнес-сервисов; архитектура уровня данных, описывает логическую и физическую организацию корпоративных данных; технологическая (техническая) архитектура описывает аппаратную, программную и сетевую инфраструктуру. Основные компоненты TOGAF методика 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), описывающий структуру организации, персонал, роли и ответственности. Методика ADM ADM реализует итерационный процесс проектирования на двух уровнях: на верхнем уровне для каждой итерации повторяются действия, определенные на каждой из фаз; на нижнем уровне реализуются итерации внутри отдельных фаз. Все решения принимаются исходя из текущих требований бизнеса и имеющихся решений Особенности фреймворка TOGAF крупные организации: оборона, финансы, здравоохранение В состав TOGAF, в частности, входит отдельный документ, поясняющий соответствие между понятиями TOGAF и фреймворком Захмана. Различия TOGAF от фреймворка Захмана: фреймворк Захмана ориентирован на описание некоторой конкретной архитектуры и в его основе лежит таксономия; в основе TOGAF лежит понятие архитектурного континиума, т. е. архитектура постоянно находится в процессе изменения, отслеживая изменения бизнес-требований, поэтому на первый план выходит ADM. Архитектурный фреймворк министерства обороны США Department of Defense Architecture Framework (DoDAF). Фреймворк для министерства обороны США включает в себя набор точек зрения (viewpoints), отражающих взгляды на систему со стороны различных заинтересованных сторон. Фреймворк ориентирован на системы военного назначения. Всю информацию по данному фреймворку можно найти на сайте МО США Особенность DoDAF ориентация на данные; предыдущая версия DoDAF (версия 1.5) определяла данный фреймворк как ориентированный на сетевое взаимодействие (net centric) ориентация на данные определяет класс систем, на проектирование которых ориентирован DoDAF — это прежде всего системы сбора, хранения и обработки данных в целях их использования в процессе принятия решений модели (models); виды (view); точки зрения (viewpoints). Модель определяется как шаблон (template) для сбора данных. Типы моделей: таблицы, данные в которых представлены в виде строк и столбцов; графические изображения, описывающие структурные аспекты архитектурного решения; графические изображения, описывающие поведенческие аспекты архитектурного решения; отображения, описывающие взаимосвязь между двумя типами информации в форме матрицы; онтологии, являющиеся расширением онтологии, определенной в DoDAF; картинки в свободном формате; разного рода временные диаграммы. Вид определяется как способ представления связанного набора данных в понятном пользователю виде (документы, таблицы, графики) Точка зрения описывает данные, поступающие от одного или нескольких источников. Представляет собой упорядоченное множество видов. Архитектурное описание в рамках DoDAF определяется как множество видов, используемых для документирования архитектуры. В рамках DoDAF V2.0 определяются восемь точек зрения: обобщенная точка зрения (All Viewpoint (AV), которая интегрирует все точки зрения и образует архитектурный контекст для других точек зрения; точка зрения, определяющая потенциальные возможности (Capability Viewpoint, СV), использующая такие понятия как, например, сроки поставки оборудования, обучения персонала и т.д.); точка зрения, определяющая данные и информацию (Data and Information Viewpoint, DIV), рассматривает структуры данных и способы их представления для разных целей; операционная точка зрения (Operational Viewpoint, OV) рассматривает систему с точки зрения сценариев работы, активностей; проектная точка зрения (Project Viewpoint PV), которая рассматривает систему с точки зрения требуемых характеристик и возможностей, а также с точки зрения процесса проектирования и других реализуемых проектов (эта точка зрения активно используется при реализации процесса закупок систем для нужд МО); сервисная точка зрения (Services Viewpoint, SvcV) рассматривает систему как совокупность взаимодействующих сервисов; точка зрения, учитывающая стандарты (Standards Viewpoint, StdV), в частности, действующие технические стандарты, методики, руководства, ограничения и т.п.; системная точка зрения (Systems Viewpoint, SV) рассматривает систему как совокупность взаимодействующих подсистем, рассматривает способы взаимодействия подсистем и используется преимущественно при необходимости работать с унаследованными системами. Уровни DM2 1. концептуальная модель данных (Conceptual Data Model (CDM) 2. логическая модель данных (Logical Data Model, LDM) 3. спецификация обмена данными на физическом уровне (Physical Exchange Specification, PES) Данные модели являются составной частью рассматриваемого фреймворка. Уровни DM2 Концептуальная модель дает возможность строить архитектурное описание в нетехнических терминах, которое понятно не только ИТ- специалистам. Логическая модель является расширением концептуальной модели за счет добавления атрибутов к понятиям, определенным на концептуальном уровне. Спецификация обмена данными представляет собой платформенно независимое средство, обеспечивающее обмен данными между разными моделями. Данная спецификция основана на использовании XML и XSD. Для каждой из моделей, входящей в состав DoDAF, имеется собственное XSD-описание. Особенности DoDAF ориентирован не на разработку всей системы, а прежде всего на разработку архитектурного описания системы, в целях формирования задания на разработку с учетом ранее выполненных разработок и разработок, выполняющихся одновременно. в качестве конечного результата выступает не ИС, а только ее документированное архитектурное описание. дает пользователю значительно большую свободу выбора инструментальных средств и моделей для решения конкретной задачи и активно предлагает ему выбирать только нужные модели. |