АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
7.2. Языки описания архитектуры Наблюдаемое на современном этапе развития многократное увеличение сложности ИС приводит к невозможности требуемые уровни качества ИС, такие как надежность, возможность повторного использования, сопровождаемость. Это приводит к появлению новых подходов к проектированию ИС, в частности, архитектурного подхода, который предполагает анализ структуры и поведения ИС с глобальных позиций. Использование архитектурного подхода само по себе предполагает наличие языка или языков архитектурного описания (architectural description languages ADL), которые позволяют описывать архитектуру и выполнять определенные преобразование. В течение многих лет ведутся работы по разработке таких языков. В данном параграфе приведено краткое описание некоторых ADL. Следует отметить, что это далеко не полный список известных ADL, кроме того, постоянно предлагаются новые языки. В настоящее время отсутствует общепринятое определение ADL. На неформальном уровне ADL можно определить как специализированный машинно-ориентированный язык, предназначенный для описании программной или системной архитектуры на требуемом уровне. Если использовать данное определение в качестве рабочего, то под него подпадают 2 группы ADL. К первой группе можно отнести языки, которые условно можно назвать языками моделирования системы на архитектурном уровне. Эти языки базируются на определении архитектуры как системы фундаментальных концепций или свойств системы, воплощенная в элементах системы, их взаимосвязях, а также в принципах проектирования и развития. На первый план при этом элементы системы и их взаимосвязи. При использовании данного подхода система, чаще всего, описывается как набор, объектов, обладающих интерфейсами и соединенных между собой с помощью коннекторов. К этой группе относится большинство ранних ADL. Динамика функционирования может описываться в терминах изменения состояние элементов. Фактически ADL рассматривается как язык описания концептуальной модели. Второй подход основывается на том, что ADL – это, прежде всего, средства архитектурного описания в смысле [6], которое использует такие понятия как заинтересованные стороны, архитектурные виды, точки зрения, а сопровождающие ADL инструментальные средства – это инструмент, позволяющий составлять и анализировать архитектурные описания. Крайне желательно, чтобы имелась возможность перехода от архитектурного описания к программному коду или его каркасу. К этой группе можно отнести UML, SysML [111, 112]. Инструментальные средства в этом случае рассматриваются как средства разработки архитектурного описания с последующим переходам от архитектурного описания к коду. Можно сформулировать основные требования, предъявляемые к ADL: ADL должен описывать систему с точки зрения всех заинтересованных сторон; ADL должен быть ориентирован на решения задач создания, архитектуры, ее уточнения и проверки на корректность (валидации); ADL должен обеспечивать возможность генерации описаний более низкого уровня, от которых можно переходить к реализации: ADL должен поддерживать различные архитектурные стили; ADL должен позволять получать архитектурные метрики получаемых архитектур или обеспечивать возможность оперативно генерировать прототипы создаваемых систем. Перечисленные выше требования относятся к «идеальному» ADL, и далеко не все реальные ADL соответствуют им. Классификация ADL. Работы по разработке и внедрению ADL в практику проектирования ИС ведутся уже не один десяток лет. За это время были разработаны, по крайней мере, десятки ADL, если не сотни языков, в основу которых были положены разные подходы. Укрупненная классификация ADL приведена на рис. 7.8.  Рис. 7.8. Классификация ADL ADL можно классифицировать по следующим основным признакам: назначение, подход к реализации, тип архитектуры, используемая нотация. С точки зрения назначения, можно выделить ADL, ориентированные только на документирование архитектурных решений, ориентированные на генерацию кода архитектурному описанию, проверку архитектурных решений на корректность и генерацию кода на языке описания аппаратуры. Можно выделить 2 основных подхода к построению ADL. Первый подход предполагает, что в основу ADL положена формальная теория, например алгебра процессов. Второй подход не предполагает использования формального аппарата и опирается на опыт разработчиков. Обычно ADL в той или иной степени ориентированы на описание определенных классов архитектур. Это могут быть корпоративные, системные, программные, аппаратно-программные или аппаратные архитектуры. ADL могут использовать различные способы описания архитектур (нотации): графическую, обычную текстовую (строковую), возможно использования XML описаний. Ниже приводится описание некоторых ADL. Список ADL выбран таким образом, чтобы показать разнообразие используемых подходов для построения ADL. ACME и AADL. The Architectural Based Language and Environment (ACME) – это компактный и относительно несложный в изучении ADL. В нем используются такие понятия как система, компонент, коннектор, порт, роль, представление и др. Система рассматривается как совокупность компонентов, соединенных коннекторами. Порты рассматриваются как конечные точки коннекторов. Например, на языке ACME описание конвейера команд UNIX выглядит следующим образом: Component pipe = { Port in; Port out; Property implementation: String = “while (!in.eof) {in.read; compute; out.write; }”; Из приведенного примера видно, что синтаксис этого языка очень напоминает синтаксис языка С. ACME фактически является подмножеством более сложного языка Architecture Analysis & Design Language (AADL) [113] AADL, который первоначально использовался в авионике и его название расшифровывалось как Avionics Architecture Description Language. В настоящее время используется для моделирования аппаратно-программных встроенных систем, работающих в РМВ. Разработанная архитектурная модель может использоваться либо как архитектурное описание, либо для генерации кода. WRIGHT. ADL WRIGHT был предложен еще в 1997 году [114] В основу этого языка положены формализм CSP (Communication Sequential Processes), предложенный Хоаром. CSP – это формальный язык, предназначенный для описания механизмов взаимодействия параллельных процессов. В основе его лежит математическая теория параллельности, известная как алгебра процессов или исчисление процессов. В качестве структурного языка WRIGHT базируется на формальном описании поведения компонентов и коннекторов. WRIGHT позволяет описывать поведение систем на уровне архитектурных стилей и выполнять анализ и валидацию системных конфигураций в рамках CSP-модели [115]. xADL – это ADL, разработанный Калифорнийским университетом, Ирвин для моделирования программных систем [116]. xArch предоставляет пользователю XML нотацию - ядро, которое может быть использовано для описания и моделирования архитектур ИС, либо может быть использовано в качестве отправной точки для создания собственной архитектурной нотации. В терминах xArch можно описать другие языки ADL, например ACME или Rapide. В этом плане xArch можно рассматривать как мета язык. Этот язык, по существу, представляет собой набор XML схем, использование которых позволяет описывать разные архитектурные виды, используя свой собственный язык. Это исключительно гибкий язык, который поддерживается многими разработчиками инструментальных средств. xADL представляет собой расширяемый ADL, который можно использовать для описания отдельных архитектурных видов с помощью языка XML. Такой подход позволяет решить традиционную для всех ADL проблему – обычно ADL может описать только один архитектурный вид. Как известно на базе XML можно определить произвольное множество языков, то предлагается для каждого вида использовать свой собственный язык. Сам по себе xADL простой и компактный язык. Например некоторый коннектор можно описать следующим образом: shows an example description of connector. < connector id = "conn1" > < interface id-- "1conn. in"> < direction> in < interface id: "1conn. out" > Switch Channel Interface (out) < direction> out <\interface> < \ connector> Основное достоинство этого языка состоит в возможности его расширения посредством разработки новых XML схем, например в [117], описывается расширение xADL для описания сервисно-ориентированных архитектур. UML как ADL. UML (Unified Modeling Language). UML — это формальный графический язык, являющийся de facto промышленным стандартом. Первоначально он создавался как графический язык для поддержки объектно-ориентированной парадигмы проектирования программного обеспечения. Позже в него были добавлены возможности моделирования бизнес-процессов, системного проектирования и отображения организационных структур. В настоящее время UML — это UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели ИС. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода. UML имеет хорошо определенный формальный синтаксис и семантику, что позволяет реализовывать процесс машинной обработки UML-моделей. Строго говоря, UML нельзя отнести к формальным языкам, поскольку за ним не стоит математический аппарат. Обычно UML определяют как язык, который определен полуформально. Несмотря на то, что классический UML входит в состав инструментария современного архитектора, как правило, его часто не относят к семейству ADL. Следует отметить, что по своим выразительным возможностям UML превосходит большинство современных ADL, в частности, позволяет строить архитектурные модели ИС. Если принять во внимание возможность создания в рамках UML профилей, то последние версии UML, начиная с 2.0, можно рассматривать UML в качестве ADL, поскольку он удовлетворяет большинству из перечисленных требований, предъявляемых к ADL. Особо следует отметить, что все версии UML, начиная с ранних, успешно использовались и продолжают использоваться для составления архитектурных описаний. Таким образом, UML можно рассматривать как один из наиболее часто используемых архитектором языков, поэтому имеет смысл рассмотреть более подробно состав UML. В основу построения UML положена обобщенная архитектура моделей и представлений ИС которая показана на рис. 7.9. Эта модель известна как модель Кратчена (Kruchten) [118]. Модели подразделяются на статические и динамические, а также на концептуальные и детальные. Каждому из квадратов можно поставить одну или несколько точек зрения в соответствии со стандартом [6]. В соответствии с этим подходом, процесс создания моделей представляется поуровневый спуск от общих моделей и представлений концептуального уровня к частным и детальным представлениям логического и физического уровня. На каждом этапе разрабатываемые модели дополняются и уточняются, для построения моделей использует преимущественно графические нотации. На момент написания данного учебника последняя версия UML 2.5 от июня 2015 года. Используемые диаграммы разбиты на 3 группы: структурные диаграммы, диаграммы поведения и диаграммы взаимодействия (рис. 7.10). Следует заметить, что в новых версиях UML появляются новые диаграммы.  Рис. 7.9. Архитектура моделей В основу построения UML положена обобщенная архитектура моделей и представлений ИС которая показана на рис. 7.9. Эта модель известна как модель Кратчена (Kruchten) [118]. Модели подразделяются на статические и динамические, а также на концептуальные и детальные. Каждому из квадратов можно поставить одну или несколько точек зрения в соответствии со стандартом [6]. В соответствии с этим подходом, процесс создания моделей представляется поуровневый спуск от общих моделей и представлений концептуального уровня к частным и детальным представлениям логического и физического уровня. На каждом этапе разрабатываемые модели дополняются и уточняются, для построения моделей использует преимущественно графические нотации. На момент написания данного учебника последняя версия UML 2.5 от июня 2015 года. Используемые диаграммы разбиты на 3 группы: структурные диаграммы, диаграммы поведения и диаграммы взаимодействия (рис. 7.10). Следует заметить, что в новых версиях UML появляются новые диаграммы.  Рис. 7.10. Диаграммы UML Структурные диаграммы Structure Diagrams): диаграмма классов (Class diagram), диаграмма композитных структур (Composite Structure diagram), диаграмма пакетов (Package diagram), диаграмма объектов (Object Diagram), диаграмма компонентов (Component diagram), диаграмма развертывания (Deployment Diagram), диаграмма профилей (Profile diagram). Диаграммы поведения (Behavior Diagrams): диаграмма вариантов использования (Use Case diagram), диаграмма деятельности (Activity diagram), диаграмма конечного автомата (State Machine diagram). Диаграммы взаимодействия (Interaction Diagrams): диаграмма последовательности (Sequence Diagram), диаграмма коммуникации (Communication Diagram), диаграмма обзора взаимодействия (Interaction Overview Diagram), временная диаграмма (Timing Diagram). Диаграмма классов — это статическая структурная диаграмма, описывает структуру системы в терминах классов, их атрибутов, методов и зависимостей между классами. Диаграмма композитной структуры — статическая структурная диаграмма, которая демонстрирует внутреннюю структуру классов и взаимодействие элементов внутренней структуры класса. Подвидом диаграмм композитной структуры являются диаграммы кооперации, которые показывают роли и взаимодействие классов в рамках кооперации. Диаграмма пакетов — это структурная диаграмма, на которой отображаются пакеты и связи ними. Диаграммы пакетов предназначены для организации элементов в группы по с целью упрощения анализируемой структуры. Диаграмма объектов — это полный или частичный снимок моделируемой системы в некоторый момент времени. На диаграмме объектов представлены экземпляры классов ИС и указываются текущие значений их атрибутов и связи между объектами. Диаграмма компонентов — это статическая структурная диаграмма, показывающая разбиение программной системы на структурные компоненты и зависимости между компонентами. В качестве компонентов выступают пакеты, модули, библиотеки файлы и т. п. Диаграмма профилей (появилась в новых версиях) описывает использование профилей. Диаграмма развёртывания — используется для моделирования работающих узлов и артефактов, развёрнутых на них. Диаграмма вариантов использования (диаграмма прецедентов) — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования. Диаграмма деятельности — это диаграмма, показывающая разложение деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий соединённых между собой потоками, которые идут от выходов одного узла к входам другого. Диаграмма конечного автомата — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями. Диаграмма последовательности — это диаграмма, которая описывает взаимодействия элементов модели в форме последовательности сообщений и соответствующих событий на линиях жизни объектов Диаграмма коммуникации — диаграмма, которая описывает взаимодействия между линиями жизни объектов в форме элементов внутренней структуры системы и передаваемых между ними сообщений Диаграмма обзора взаимодействия — служит для представления только взаимодействия потока управления. Временная диаграмма — явным образом показывающая изменения состояния на линии жизни с заданной шкалой времени, что может быть полезно в приложениях реального времени [63]. SysML как ADL. SysML – это язык моделирования общего назначения, имеющий графический интерфейс пользователя. Этот язык используется для спецификации, анализа, проектирования и верификации сложных технических систем, которые могут включать аппаратные средства, программные средства, информационные ресурсы, персонал и т.д. С помощью SysML, используя графические нотации, можно моделировать требования, структуру, поведение систем, выполнять инженерный анализ систем. SysML очень тесно связан с UML. Эти языки, по существу, используют один и тот же подход к проектированию систем на основе моделей. Разница состоит в сфере применения. UML ориентирован на проектирование программных систем, а SysML на проектирование аппаратно-программных и человеко-машинных систем. В этом смысле UML можно рассматривать как подмножество SysML. Однако, с точки зрения числа используемых диаграмм, UML богаче SysML. В этом плане, SysML можно рассматривать как подмножество UML. Соотношение между SysML и UML 2 показано на рис. 7.11.  Рис. 7.11. Соотношение между SysML и UML SysML определяет 2 группы диаграмм (рис. 7.12): структурные диаграммы (Structure Diagram) и поведенческие диаграммы (Behavior Diagram) и диаграмму требований (Requirement Diagramm). К структурным относягся 4 типа диаграмм: диаграмма определения блоков (Block Definition Diagram), диаграмма внутренних блоков (Internal Block Diagram), пакетная диаграмма (Package Diagram) и параметрическая диаграмма (Parametric Diagram). К группе поведенческих диаграмм относят 4 типа диаграмм: диаграмму вариантов использования (Use Case Diagram), диаграмму последовательностей (Sequence Diagram), диаграмму активностей (Activity Diagram) и диаграмма конечного автомата (State Machine Diagram).  Рис. 7.12. Диаграммы SysML Основным понятием для SysML является «блок», в качестве блока может выступать любой элемент, программная компонента, аппаратный блок, персонал и т.п. Структуру системы можно описать в терминах диаграмма определения блоков, которая описывает систему в терминах система-подсистема. Диаграмма внутренних блоков описывает систему в терминах частей, портов и коннекторов. Пакетная диаграмма используется для упрощения модели и по своему назначению совпадает с аналогичной UML диаграммой. Параметрическая диаграмма позволяет описывать систему ограничений, налагаемых на систему (по производительности, надежности, массе, габаритам и т.п.). Поведенческие диаграммы описывают динамику (поведение) системы. Диаграмма вариантов использования позволяет на достаточно высоком уровне описать функциональность системы. Эта диаграмма идентична соответствующей диаграмме в UML. Диаграмма активностей позволяет описать поток данных и управления между активностями. Диаграмма последовательностей описывает взаимодействие между различными подсистемами. Диаграмма конечного автомата (Машина состояний) позволяет описывать систему в терминах состояний и переходов между состояниями при возникновении событий. Диаграмма требований позволяет описать требования, предъявляемые к системе в графической форме. Если сравнивать состав моделей UML и SysML, то видно, что в SysML появляются только 2 новые модели - это модель требований и параметрическая модель. Три диаграммы: диаграмма вариантов использования, диаграмма последовательностей и машина состояний идентичны соответствующим диаграммам UML. Прочие диаграммы можно рассматривать как модификации соответствующих диаграмм UML [112]. ArchiMate. ArchiMate ориентирован, прежде всего, на описание и моделирование корпоративных ИС. Он описывает организацию в терминах организационной структуры, бизнес процессов и информационных потоков. ArchiMate – стандарт языка моделирования архитектуры предприятия с открытым исходным кодом, разрабатываемый консорциумом Open Group. Язык ArchiMate поддерживается инструментальными средствами различных производителей. Он полностью согласован с моделью архитектуры предприятия TOGAF, которая будет рассмотрена ниже, также поддерживаемой консорциумом Open Group. ArchiMate поддерживает описание, анализ и визуализацию архитектуры предприятия. Базовыми для ArchiMate являются понятия «элемент» и «отношение», на основе которых строятся модели организации и ее отдельных частей. Элементы в ArchiMate классифицируются по трем признакам. Элемент может быть структурным или поведенческим, внешним или внутренним, индивидуальным или коллективным. В качестве основных выделяются 3 типа элементов: активный структурный элемент, пассивный структурный элемент и элемент поведения. Активный структурный элемент (active structure element) – это элемент, который может выполнять определенные действия. Примерами активных структурных элементов могут быть бизнес-исполнители, компоненты приложений или устройства, которые реально исполняют те или иные действия. Пассивный структурный элемент (passive structure element) – это объект, на котором выполняются действия. Как правило, это либо иформационные объекты либо объекты данных, это могут быть также физические объекты, над которыми выполняются те или иные действия. Элемент поведения (behavior element) – это некоторое действие, выполняемое одним или несколькими активными структурными элементами. В качестве элементов поведения могут выступать процессы, функции, сервисы и события, которые назначаются активным структурным элементам, с целью определить, кто или что производит те или иные действия. Таким образом имеем классическую тройку {Субъект, Объект, Отношение}. ArchiMate различает внешний и внутренний взгляды на систему. На этой основе определяются понятия «сервис» и «интерфейс». Сервис определяется как элементарная функциональность, предоставляемая системой своему окружению, реализация при этом скрывается. Сервис представляет собой внешне видимое поведение системы с точки зрения внешних систем, использующих данный сервис. Для внешних систем значимыми являются только его функциональные и нефункциональные характеристики, такие как качество сервиса, стоимость. Интерфейс определяется как точка доступа, к сервису и рассматривается как активный структурный элемент. В ArchiMate для описания организации в языке определяются три слоя: бизнес-слой, слой приложений и технологический слой. Для каждого из слоев определяется собственный набор элементов, которые представляют специализацию базовых понятий, то есть их конкретизацию применительно к рамкам того или иного слоя. Для каждого слоя определяются свои исполнители работ, свои работы и свои объекты работ. Бизнес-слой описывает деятельность и развитие организации и ее окружение, Кроме того, описываются продукты и сервисы, доступные для внешних потребителей, основные бизнес-процессы и сервисы, бизнес-исполнители и бизнес-роли, выполняющие эти процессы, а также используемая информация. Слой приложений описывает приложения, их функциональность и отношения между ними. Кроме того, описываются сервисы приложений, доступные бизнес-слою, и основные объекты данных, используемые приложениями. Технологический слой описывает вычислительное и коммуникационное оборудование и системное программное обеспечение, которые используются для выполнения приложений, А также инфраструктурные сервисы. Описания, относящиеся к разным слоям имеют похожую структуру, однако набор элементов и понятия различны. В каждом слое используется общая концепция элементов языка и отношений, что позволяет выделить в слоях несколько доменов, описывающих различные предметные области в рамках слоя. Взаимодействие между слоями определяется отношениями типа «использование» и «реализация». Первое отношение показывает, как верхний слой использует сервисы нижнего слоя, а второе – как элементы нижнего слоя реализуют элементы более высоких слоев. Язык предоставляет средства по расширению множества понятий, входящих в его ядро. Это можно сделать, используя механизмы профилирования и механизм специализации. Первый предполагает добавление дополнительных атрибутов к существующим понятиям, а второй - определение новых понятий на основе уже существующих. ArchiMate самым тесным образом связан с фреймворком TOGAF, который будет рассмотрен ниже. Как TOGAF, так и ArchiMate являются стандартами The Open Group и относятся к разработке архитектуры предприятия. Однако TOGAF и ArchiMate имеются свои собственные спецификации, и они могут использоваться по отдельности [119]. 7.3. Архитектуры, управляемые моделями Архитектура, управляемая моделями (Model Driven Architecture, MDA) — это подход к проектированию приложений, основанный на широком использовании моделей, в частности платформенно-независимых моделей. Под платформенно-независимой моделью (Platform Independent Model, PIM) понимается такое представление системы, в котором внимание концентрирует на общей архитектуре системы, а детали реализации, относящиеся к конкретной платформе, скрываются. PIM представляет только часть полной спецификации системы, которая не изменяется при переходе с одной платформы на другую. В соответствии с концепцией MDA, разработка ИС начинается с создания PIM-модели, которая определяет состав, структуру и поведение будущей ИС. PIM представляет совокупность архитектурных элементов проектируемой ИС и связей между ними, но без привязки к конкретным языкам программирования и ОС. На последующих этапах разработки ИС на базе PIM строится одна или несколько платформенно-зависимых моделей (Platform Specific Model, PSM), которые уже учитывают специфику конкретной платформы и технологии реализации программных компонентов. Описание архитектурных моделей. Наиболее эффективным и повсеместно используемым подходом к описанию архитектурных моделей является методология Model-Driven Engineering (MDE), основанная на построении иерархии моделей. Для описания моделей применяются специализированные доменно-ориентированные языки (domain-specific modeling languages – DSMLs), которые используются для построения моделей систем в соответствии с семантикой и ограничениями, определенными в метамодели. Составной частью MDE является набор утилит для генерации разного рода артефактов, таких как исходный код, диаграммы размещения и преобразования моделей. Ключевыми для MDE являются следующие концепции: модель (model – M), метамодель (metamodel – MM), связывание моделей (model weaving – MW), преобразование моделей (model transformation – MT), метаметамодель (MMM). Модели, используемые в рамках MDE-подхода, образуют стек (рис. 7.13), который содержит четыре уровня М0–М3. Уровень М0 представляет собой саму моделируемую систему; уровень М1 соответствует модели системы. Уровень М2 – это уровень метамоделей. Каждая модель должна соответствовать определенной метамодели, которая определяет семантику и элементы модели. Можно говорить, что метамодель определяет ключевые сущности, отношения и ограничения языка моделирования. Уровень М3 определяется как уровень метамоделей для метамоделей, которые называются метаметамоделями. Поскольку уровень метаметамоделей – это самый высокий уровень, то метаметамодели должны соответствовать только сами себе.
Рис. 7.13. Стек моделей Модели стека понимаются в соответствии с определением модели, предложенным в [120]. При построении моделей должны выполняться следующие требования: во-первых, модель должна содержать только значимые для решения конкретных задач анализа элементы, т. е. она не должна быть излишне сложной, во-вторых, модель должна соответствовать определенной точке зрения и, в-третьих, модель должна быть полезной, т. е. отвечать на конкретные вопросы. Модели трансформации. Представление набора моделей в виде стека требует определения процедуры перехода от модели верхнего уровня к моделям нижнего уровня. Преобразование моделей – это процесс, который определяет, каким образом можно получить целевую модель из нескольких исходных моделей. Процесс преобразования моделей (modelware) можно определить следующим образом (рис. 7.14). Пусть модель Ма, соответствующая метамодели ММa, трансформируется в модель Mb, которая соответствует метамодели MMb. Само преобразование можно определить как MT, также представляющую собой модель, которая соответствует метамодели MMT. В свою очередь, MMT является моделью и должна соответствовать метаметамодели, например MOF-модели.  Рис. 7.14. Преобразования моделей Модели могут трансформироваться либо «по горизонтали», либо «по вертикали». В первом случае трансформируемая модель преобразовывается в модель, которая принадлежит одному с ней уровню. Во втором случае трансформируемая модель является моделью более высокого уровня. С точки зрения типов трансформируемых моделей можно выделить следующие основные варианты [121]: 1) трансформация типа «формальная модель–формальная модель»; 2) XML-описание – формальная модель; 3) текстовое описание – XML-описание; 4) текстовое описание – формальная модель; 5) формальная модель – код. В классической работе [122] определяются следующие базовые механизмы трансформации моделей: прямое преобразование (Direct manipulation), структурное преобразование (Structure Driven), операционное (Operational), преобразование с использованием шаблонов (Template-based), реляционное (Relational), преобразование графа (Graph Transformation), XSLT-преобразование (XSLT-based), гибридное (Hybrid). Модели связывания – это специальный тип моделей, предназначенный для связывания моделей разных типов. Данные модели также могут быть представлены в рамках 4-уровнего стека моделей. Основное назначение этих моделей состоит в установлении соответствия между отдельными элементами моделей (низкоуровневое связывание). Модель связывания может быть использована для связывания любых элементов разных метамоделей, таких как метаклассы, атрибуты, ссылки, типы данных. На рис. 7.15 модель связывания WM используется для установления соответствия между элементами метамоделей MMa и MMb. При этом сама WM должна соответствовать метамодели связывания WMM.  Рис. 7.15. Соответствия между элементами метамоделей Мегамоделирование (Megamodeling). При необходимости использования для описания архитектуры системы множества метаметамоделей, их свойств и отношений между их элементами вводится понятие более высокого уровня, в качестве которого выступает понятие мегамодели [123]. Мегамодель можно рассматривать как метамодель MDE, которая позволяет определять отношения между моделями и метамоделями, а также их свойства. С использованием мегамоделей определяются отношения между отдельными элементами, в частности моделями, которые фактически являются метамоделями, видами и точками зрения. Следует заметить, что такой подход в полной мере соответствует стандарту ISO/IEC/IEEE 42010, который предлагает считать, что каждый вид должен соответствовать точке зрения, а каждая модель должна соответствовать типу модели. В [124] предложена структура фреймворка, ориентированная на мегамоделирование. Фреймворк определяет следующие типы моделей: 1) терминальные модели (Terminal Models), которым соответствуют реальные системы и которые соответствуют некоторым метамоделям; 2) метамодели (MetaModels), которые определяют доменно-ориентированные концепции и соответствуют метамоделям; 3) метаметамодели (MetaMetamodels), которые описывают концепции верхнего уровня и соответствуют сами себе. Метамодели и метаметамодели иногда называют эталонными моделями (Reference Models), поскольку они представляют своего рода эталон для моделей, которые должны им соответствовать. Терминальные модели подразделяются на три группы: трансформации (Transformation Models), связывания (Weaving Models) и мегамодели (MegaModels). Модели трансформации определяют процессы преобразования моделей, модели связывания определяют отношения между моделями, а мегамодели предназначены для поддержки процесса мегамоделирования. Следует отметить, что терминальная модель не является абстрактным метаклассом и может использоваться для порождения конкретных экземпляров и поэтому должна соответствовать одной метамодели. На рис. 7.16 представлена диаграмма отношений между артефактами рассматриваемого фреймворка. Корневым элементом (метаклассом) является элемент Entity (сущность). Сущность представляет произвольную концепцию, которая может существовать в рамках метамодели. Отношение может быть либо направленным (DirectedRelationship), либо двунаправленным (Bidirectional). Рассмотренная модель может быть расширена произвольным образом.  Рис. 7.16. Диаграмма отношений между артефактами Иерархия фреймворков. Фреймворки могут быть организованы в виде иерархии (рис. 7.17). На верхнем уровне располагается мегафреймворк (MMF), на следующем за ним уровне располагаются доменные метафреймворки (DF). Домен фреймворков делится на два поддомена: проблемно-ориентированный (домен задач) и поддомен решений. Фреймворки, относящиеся к первой группе можно определить как проблемно-ориентированные метафреймворки (ПОМФ) и задачно-ориентированные метафреймворки (ЗОМФ). ПОМФ ориентированы на решение задач, конкретной предметной области и в явном виде не накладывают ограничений на используемые архитектурные решения. ЗОМФ, напротив, ориентированы на использование определенных платформ и в явном виде не ограничивают области применения. Следует заметить, что как ПОМФ, так и ЗОМФ являются метафреймворками и предназначены для генерации не конкретных архитектур, а частных фреймворков (ЧФ). Можно выделить два типа ЧФ: фреймворки, предназначенные для порождения архитектур линеек (семейств) продуктов (FL), и простые частные метафреймворки (F). Использование метафреймворков не является обязательным. Если MF-метафреймворки используются, то они могут использоваться как для порождения архитектур линеек (семейств) продуктов, так и выступать в качестве метафреймворков для прождения частных фреймворков F-типа. Каждая архитектура соответствует ровно одному фреймворку F. Каждый фреймворк типа FL или F может строиться на базе нескольких DF, наследуя разные архитектурные элементы (интересы, точки зрения, модели). Если фреймворк F-типа строится на базе FL-фреймворка, то каждый фреймворк F-типа соответствует одному FL-фреймворку, а каждому FL-фреймворку может соответствовать произвольное число F-фреймворков.  Рис. 7.17. Иерархия фреймворковПредлагаемый фреймворк, ориентированный на разработку и проектирование систем обработки и анализа, относится к проблемно-ориентированному поддомену. Разрабатываемый фреймворк представляет собой иерархию фреймворков, включающую фреймворки MF, ML и F. Фреймворки обеспечивают формирование моделей уровней M1, M2 и M3, определяемых методологией MDE. Архитектурные метрики. В основу построения системы архитектурных метрик положены следующие принципы: 1. Метрики являются атрибутами архитектурной модели. 2. Каждая из архитектурных моделей может иметь произвольное число метрик в диапазоне от 1 до N. 3. Метрика должна быть востребована, по крайней мере, одной заинтересованной стороной. 4. Метрики снимаются по запросу одной или нескольких заинтересованных сторон. 5. Мера востребованности метрики является метаметрикой. 6. В качестве потребителей (заинтересованных сторон) метрик могут выступать как люди, так и технические системы. Требования к архитектурным метрикам. Метрики должны удовлетворять следующим основным требованиям: 1. Система метрик должна быть функционально полной, но не избыточной. 2. Метрики должны быть представлены в форме, воспринимаемой заинтересованной стороной, т. е. в терминах модели, которой принадлежит данная метрика. 3. Стоимость метрики должна удовлетворять системным ограничениям. Стоимость метрики может выражаться разными способами, в частности, в денежном исчислении, в терминах уменьшения производительности контролируемой системы и т. п. |
