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

Размещено на http://www.allbest.ru/

Харьковский национальный университет радиоэлектроники

МОДЕЛЬ АРХИТЕКТУРНОГО ФРЕЙМВОРКА УСКОРЕННОЙ РАЗРАБОТКИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

В.М. Левыкин, М.В. Евланов

Аннотация

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

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

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

Введение

В настоящее время ключевым понятием, задающим особенности анализа и синтеза информационных систем (ИС), моделей их жизненных циклов и других аспектов существования является понятие «системная архитектура» или, точнее, «архитектура системы». Принятый в 2010 г. стандарт ISO/IEC/IEEE 42010 «Systems and Software Engineering - Architecture Description» дает следующее определение данного понятия: «Архитектура [системы]: фундаментальные понятия и свойства системы в окружающей ее среде, воплощенные в ее элементах, отношениях, а также в принципах ее проектирования и развития» [1]. Данное определение учитывает основные проблемы, возникающие при попытках прикладного использования понятия «Архитектура» стандарта IEEE 1471:2000, и, по замыслу создателей, является максимально общим определением, пригодным для описания архитектур практически любых систем. Принципы проектирования и развития системы теоретически могут быть выделены архитектором путем реверс-инжиниринга из существующей системы или даже открыты в природе - в зависимости от исследуемой системы. Хотя в созданных человеком системах архитектура часто воспринимается как интенциональная позиция, такая интенциональность не является частью рассматриваемого определения.

В архитектуре широко используются два механизма: архитектурный фреймворк и языки описания архитектуры. Стандарт ISO/IEC/IEEE 42010 дает следующее определение понятия «архитектурный фреймворк» (АФ): «Архитектурный фреймворк: конвенции, принципы и методы описания архитектуры, установленные в конкретной области применения и/или сообществом заинтересованных сторон» [1]. АФ соответствует международным стандартам IS, если он обозначает:

- информацию, идентифицирующую фреймворк;

- одну или несколько проблем;

- одну или несколько заинтересованных сторон, у которых есть указанные выше проблемы;

- одну или несколько архитектурных точек зрения (и их технические спецификации, соответствующие IS);

- правила соответствий, интегрирующие точки зрения;

- условия применимости;

- согласованность фреймворка с положениями концептуальной модели стандарта ISO/IEC/IEEE 42010.

В целом АФ устанавливает общие практики создания, интерпретации, анализа и использования описаний архитектуры в рамках конкретной области применения или сообщества заинтересованных сторон. Можно указать следующие примеры АФ: MODAF, TOGAF, Kruchten's 4+1 View Model, RM-ODP [2-5]. Эти, а также множество других АФ были учтены при разработке АФ стандарта ISO/IEC/IEEE 42010, концептуальная модель которого приведена на рис. 1 [1].

Рис. 1 Диаграмма классов, описывающая концептуальную модель архитектурного фреймворка стандарта ISO/IEC/IEEE 42010

1. Постановка задачи исследования

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

Решением этой задачи в общем случае будет являться АФ, определяющий особенности описания ИС, ее элементов и архитектуры, а также особенности решения задач интеграции ИС из отдельных элементов на различных уровнях представления. Модель такого АФ должна отражать тот набор методологических положений, знаний, видов моделей и методов, правил и практик, которые могут быть использованы в процессах создания ИС. Место АФ в процессах создания конкретной ИС показано на рис. 2.

Рис. 2 Место архитектурного фреймворка в процессах создания информационной системы

2. Основной материал и результаты исследования

2.1 Обобщенная модель формальной части архитектурного фреймворка

Из рис. 2 следует, что основная точка зрения участников процессов создания ИС на АФ представляет его как своеобразный фильтр, выделяющий и формирующий из всего множества концептуальных положений, видов моделей, методов, знаний, правил и практик создания ИС внутренне непротиворечивое подмножество, элементы которого необходимы для создания конкретной ИС. Под внутренней непротиворечивостью здесь следует понимать существование отображений, связывающих концептуальные положения, виды моделей, методы, знания, правила и практики создания ИС в единую целостную систему. При этом такие отображения, как правило, направлены «от теории к практике» - так, например, используемый в АФ вид модели ИС может стать началом отображения, концом которого будет являться множество практик применения моделей данного вида в процессах создания ИС, однако обратное неверно. При этом слова «обратное неверно» характерны только для отображений в рамках самого АФ - так, вполне реальна ситуация, когда по результатам применения практик создания ИС (например, аналогичных изложенным в стандартах ISO), решаются задачи Data Mining или Process Mining, в результате чего формируются новые теоретические знания или модели АФ.

Основываясь на данном представлении, любой АФ можно разделить на две части. К первой части - формальной - относятся поддающиеся формальному описанию виды моделей, методы, декларативные знания, процедурные правила и алгоритмы, которые могут быть использованы при решении задач, возникающих в процессах создания ИС. Ко второй части - неформальной - относятся неформальные или слабо формализуемые концептуальные положения, стандарты, знания, правила и практики, которые могут быть использованы конкретными представителями Поставщика и Потребителя для успешного выполнения процессов создания ИС. Такое разделение позволяет рассматривать формальную часть АФ в виде своеобразного банка видов моделей, методов, знаний, правил и алгоритмов, элементы которого используются для осуществления преобразований описаний создаваемой ИС и ее элементов в соответствии с любой из возможных методологий создания ИС.

Простейшими моделями такого банка являются модели, выполненные с использованием математического аппарата теории графов. Однако такие модели будут излишне упрощенными. Поэтому целесообразно описать формальную часть АФ в виде следующей модели:

, (1)

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

Из модели (1) следует, что основным элементом любого АФ создаваемой ИС следует считать набор видов моделей, используемых конкретным АФ в процессах создания ИС с соответствующей архитектурой. Поэтому основное внимание следует сосредоточить на детализации описаний элементов модели и особенностях практической реализации этих описаний. Описания элементов других категорий и функторов модели (1) требуют специальных исследований и здесь не рассматриваются.

2.2 Модель формальной части архитектурного фреймворка ускоренной разработки информационной системы

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

Одной из наиболее важных проблем, возникающих при попытках описать требования к ИС формальными способами, является изначальная неполнота требований. Эта неполнота вызвана, прежде всего, стремлением Потребителя получить только те ИT-услуги и реализующие их ИТ-сервисы [6], эксплуатация которых обеспечит скорейшее появление прибыли от автоматизируемого процесса. При этом Потребитель не задумывается о необходимости дополнительных ИT-услуг и соответствующих ИТ-сервисов, необходимых для обеспечения эффективной согласованной работы основных ИT-услуг. Не стоит сбрасывать со счетов и «забывчивость» Потребителя, возможность слабой ориентации Потребителя в предложениях Поставщика, а также плохое знание Поставщиком особенностей предметной области Потребителя. Кроме того, следует помнить о возможности изменений автоматизируемого процесса с течением времени (например, в результате реинжиниринга или постепенного улучшения).

Сказанное выше определяет концепцию представления требований к ИС как набор следующих положений [7, 8]:

а) отказ от рассмотрения только множества сформулированных требований к ИС и изначальное представление требований к ИС как элементов универсума, включающего в себя как известные, так и неизвестные Поставщику, Потребителю или им обоим требования к ИС, а также методы формирования этих требований;

б) изначальное многообразие представлений требований к ИС в виде данных, информации и знаний;

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

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

Изложенная концепция определяет основные особенности формализованного описания групп требований к ИС и отдельных требований, их моделей различного вида, методов и средств формирования, анализа и управления этими требованиями, а также возможных моделей и методов синтеза описания проектируемой архитектуры ИС на различных уровнях представления. Поэтому становится возможным говорить о существовании архитектурного фреймворка, основанного на положениях сервисного подхода и предложенной концепции представления требований к ИС, Такой архитектурный фреймворк в дальнейшем будем называть архитектурным фреймворком ускоренной разработки ИС (АФУР ИС). В соответствии с приведенным выше описанием понятия «АФ» модель АФУР ИС должна установить общие особенности и ограничения создания, анализа, интерпретации и использования архитектурных описаний ИС на основе требований к ИС, применяемых в указанных выше процессах создания ИС.

Использование рассмотренной концепции представления требований к ИС позволяет уточнить взаимосвязи основных элементов термина «описание архитектуры системы на основе сервисного подхода с точки зрения требований к системе». Концептуальная модель данного термина показана на рис. 3.

Создание ИС с применением АФУР ИС, основанное на предложенной контекстной диаграмме классов, подразумевает разработку и интеграцию описаний архитектуры на трех основных уровнях представления: общесистемном уровне, уровне ИT-услуг и уровне ИT-сервисов [7]. При этом процесс проектирования архитектуры ИС, который может осуществляться как сверху вниз, так и снизу вверх, предполагает обязательную интеграцию описаний элементов ИС, выполненных на разных уровнях представления. Так, например, описание архитектуры ИT-сервиса должно включать описание взаимосвязанных функциональных операций, в совокупности обеспечивающих физическую реализацию функциональности сервиса; описание архитектуры ИT-услуги - описание ИТ-сервисов, в совокупности обеспечивающих реализацию данной ИТ-услуги; описание архитектуры ИС - описания взаимосвязанных ИТ-услуг. Другими словами, архитектура ИС (как и ее описания) на всех уровнях представления рассматривается как набор автономных модулей, обеспечивающих реализацию конкретного варианта конфигурации функциональной структуры ИС. Каждый такой модуль любого уровня представления характеризуется набором входных данных, необходимых для получения информации извне, и выходных данных, необходимых для отображения результатов выполнения ИТ-услуги ИС, а также интерфейсов, обеспечивающих взаимодействие модуля с внешней средой. При этом внешней средой могут являться другие модули этой же ИС, внешние системы, или пользователи ИС, взаимодействующие с модулем через пользовательский интерфейс.

Рис. 3 Концептуальная модель термина «описание архитектуры системы на основе сервисного подхода с точки зрения требований к системе»

Такая точка зрения на АФУР ИС определяет как наиболее предпочтительный способ проектирования архитектуры ИС методом «снизу вверх». Это обусловлено наличием библиотеки готовых элементов ИС (ИТ-услуг и отдельных ИТ-сервисов), эффект от повторного использования которых увеличивается при оперировании описанием элементов ИС, выполненным на уровне отдельных ИТ-услуг и особенно отдельных ИТ-сервисов. Данный уровень представления позволяет обеспечить повторное использование ИТ-сервисов, даже в том случае, когда не востребована полная функциональность созданных ранее ИT-услуг, реализацию которых обеспечивают данные ИТ-сервисы. В этом случае такие ИT-сервисы становятся элементами новой ИT-услуги.

Поэтому процесс проектирования архитектуры системы в рамках АФУР ИС следует рассматривать как процесс синтеза варианта конфигурации функциональной структуры ИС из отдельных ИТ-услуг. При этом предполагается, что повторное использование требований к ИС позволит идентифицировать те ИТ-услуги, которые находятся в библиотеке готовых решений, доступной Поставщику в ходе процессов создания конкретной ИС. Процессы, непосредственно работающие с требованиями к ИС, в этом случае целесообразно рассматривать как процессы идентификации требований к системе в целом, функциональных и нефункциональных требований к ИТ-услугам, образующим функциональную структуру ИС.

Сказанное выше позволяет рассматривать модель АФУР ИС как частный случай модели (1), в которой компонент определяется как совокупность паттернов проектирования описаний ИС и ее элементов. Тогда модель АФУР ИС будет иметь следующий вид:

, (2)

где - модель структурных паттернов проектирования описаний ИС и ее элементов; - модель поведенческих паттернов проектирования описаний ИС и ее элементов; - одноместный ковариантный функтор, устанавливающий связь между моделями и ; - одноместный ковариантный функтор, устанавливающий связь между моделями и ; - одноместный ковариантный функтор, устанавливающий связь между моделями и ; - одноместный ковариантный функтор, устанавливающий связь между моделями и ; - одноместный ковариантный функтор, устанавливающий связь между моделями и .

Следует отметить, что, как и для модели (1), основным элементом АФУР ИС следует считать набор структурных паттернов проектирования требований, устанавливающих допустимые для использования виды моделей и формализованных описаний различных групп требований к ИС.

Выводы

В соответствии с рассмотренным в начале статьи определением понятия «АФ» разработанная модель АФУР ИС обладает следующими особенностями:

а) данная модель установлена для процесса определения требований правообладателей, процесса анализа требований и процесса проектирования архитектуры системы в соответствии с положениями стандарта ISO/IEC 15288:2002;

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

в) данная модель однозначно идентифицирует факт принятия Поставщиком решения об использовании сервисного подхода в процессах создания ИС;

г) данная модель ограничена проблемой повторного использования требований к ИС при создании ИС различного назначения, а также проблемой синтеза архитектуры конкретной ИС на уровне ИТ-услуг в ходе создания данной ИС;

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

е) данная модель содержит элементы, устанавливающие правила соответствий, интегрирующие упоминаемые в п. д) архитектурные точки зрения на ИС и ее элементы;

ж) для данной модели определены условия ее применимости в процессах, указанных в п. а);

и) данная модель согласована с положениями концептуальной модели стандарта ISO/IEC/IEEE 42010.

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

В дальнейшем основное внимание следует уделять решению проблемы детализации описаний моделей структурных паттернов проектирования требований к ИС, используемых АФУР ИС.

Литература

1. Сайт ISO/IEC/IEEE 42010 Website [Электронный ресурс]. Режим доступа: http://www.iso-architecture.org/ieee-1471/index.html. Заголовок с экрана.

2. Bailey, I. Brief Introduction to MODAF with v1.2 Updates [Электронный ресурс] / I. Bailey // Сайт «modaf.com the website for MODAF users and implementers».Режим доступа: http://www.modaf.com/Documents/. Заголовок с экрана.

3. Welcome to TOGAF® Version 9.1, an Open Group Standard [Электронный ресурс] // Сайт «the Open group». Режим доступа: http://pubs.opengroup.org/architecture/togaf9-doc/arch/. Заголовок с экрана.

4. Kruchten Ph. Architectural Blueprints - The “4+1” View Model of Software Architecture [Текст] / Ph. Kruchten // IEEE Software. 1995. № 12 (6). pp. 42-50.

5. Linington P.F. Building Enterprise Systems with ODP. An Introduction to Open Distributed Processing [Текст] / P.F. Linington, Z. Milosevic, A. Tanaka, A. Vallecillo. Chapman & Hall/CRC Press, 2011. 284 p.

6. Евланов М.В. Глобальные цели поставщика и потребителя ИТ-услуг [Текст] / М.В. Евланов, О.Е. Неумывакина, А.Ю. Карамышева // Восточно-европейский журнал передовых технологий. 2012. № 5/2 (59). С. 12-17.

7. Евланов М.В. Концепция представления требований к информационной системе [Текст] / М.В. Евланов // Вісник національного технічного університету «ХПІ». Збірник наукових праць. Серія «Нові рішення в сучасних технологіях». 2012. № 68 (974). С. 32-40.

8. Евланов, М.В. Концепция представления требований к информационной системе [Текст] / М.В. Евланов // Информационные системы и технологии: материалы Междунар. науч.-техн. конф., Морское-Харьков, 22-29 сентября 2012 г.: тезисы докладов / [редкол.: А.Д. Тевяшев (отв. ред.) и др.]. Харьков: НТМТ, 2012. С. 34.

Размещено на Allbest.ru