Архитектура управляемая моделями mda реферат

Обновлено: 02.07.2024

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

Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры ( Service -oriented architecture SOA ) и о реализации архитектуры, "управляемой моделями" (модельная архитектура . Model-driven architecture MDA ).

Что такое сервис-ориентированная архитектура и как она связана с вопросами бизнес-архитектуры и архитектуры информационных технологий предприятия?

Хотя концепция сервис-ориентированной архитектуры была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес-функции организации и начинаются информационные технологии , их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft [4.42] и IBM [4.43], развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис-ориентированная архитектура будет ведущим принципом проектирования новых критически-важных прикладных систем и бизнес-процессов в ближайшем будущем.

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

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

Под сервис-ориентированной архитектурой понимается подход к проектированию прикладных информационных систем, который руководствуется следующими принципами [4.44]:

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

В целом, SOA представляет собой модель взаимодействия компонент , которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Заметим, что одним из известных интеграционных шаблонов как раз и является "Сервис". Интерфейсы сами по себе не зависят от используемых аппаратных платформ, операционных систем или языков программирования, используемых для разработки этих приложений. Это позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным, но в то же время универсальным способом. Такая особенность использования интерфейса, независимого от окружения и платформы, получила название модели "слабой связи". Ее очевидным преимуществом является повышенная гибкость и адаптируемость, поскольку замена или модернизация одной из компонент системы не сказывается на остальных. Достаточно интересное введение в эту проблематику и обсуждение связи терминов SOА и web -cервисов можно найти, например, в [4.45].

С учетом отмеченных выше существующих тенденций перехода к бизнесу "реального времени" и создания систем так называемого "расширенного предприятия", объединяющих само предприятие, его поставщиков, партнеров и клиентов в единую систему, становится очевидно, что технологии web -cервисов найдут свое применение на всех уровнях корпоративных информационных систем. Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием такого механизма, так что достаточно критическими становятся вопросы согласованной работы этих сервисов. Для описания такой работы были предложены даже специальные термины – "хореография" и "оркестровка" (очевидно, по аналогии с управлением оркестром из различных инструментов или ансамблем разных исполнителей). При этом, если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.

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

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

Аббревиатура MDA расшифровывается как Model Driven Architecture архитектура, управляемая моделью. MDA это архитектура, описывающая новый способ разработки программного обеспечения. Название говорит само за себя очевидно, что в рамках этой архитектуры создание приложений базируется на разработке модели приложения.

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

Основные понятия

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

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

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

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

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

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

Вычислительно-независимая модель модель, скрывающая любые детали реализации и процессов системы; описывает только требования к системе и ее окружению.

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

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

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

Преобразование модели процесс преобразования одной модели системы в другую модель той же системы.

Архитектура разработки приложений на основе моделей

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

Типы моделей

Вычислительно-независимая модель (Computation Independent Model, CIM) описывает общие требования к системе, словарь используемых понятий и условия функционирования (окружение). Модель не должна содержать никаких сведений технического характера, описаний структуры и функционала системы. CIM максимально общая и независимая от реализации системы модель. Спецификация MDA подчеркивает, что CIM должна быть построена так, чтобы ее можно было преобразовать в платформенно-независимую модель. Поэтому CIM рекомендуется выполнять с использованием унифицированного языка моделирования UML.

Платформенно-независимая модель (Platform Independent Model, PIM) описывает состав, структуру, функционал системы. Модель может содержать сколь угодно подробные сведения, но они не должны касаться вопросов реализации системы на конкретных платформах. Модель PIM создается на основе CIM. Для создания модели используется унифицированный язык моделирования UML.

Платформенно-зависимая модель (Platform Specific Model, PSM) описывает состав, структуру, функционал системы применительно к вопросам ее реализации на конкретной платформе. В зависимости от назначения модель может быть более или менее детализированной. Модель создается на основе двух моделей. Модель PIM служит основой модели PSM. Модель платформы используется для доработки PSM в соответствии с требованиями платформы.

Модель платформы описывает технические характеристики, интерфейсы, функции платформы. Зачастую модель платформы представлена в виде технических описаний и руководств. Модель платформы используется при преобразовании модели PIM в модель PSM. Для целей MDA описание модели платформы должно быть представлено на унифицированном языке моделирования UML.

Уровни модели

В зависимости от уровня детализации платформы, модели (кроме модели платформы) могут содержать сведения о различных функциональных частях системы. В этом случае говорят об уровнях модели. Обычно различают следующие основные уровни модели.

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

Уровень пользовательского интерфейса описывает возможности приложения по взаимодействию с пользователями, а также состав форм приложения, функционал элементов управления (например, контроль ввода данных). Легкость автоматизации этого уровня зависит от того, насколько унифицированы пользовательские операции. Если удается создать типовые шаблоны элементов управления для основных операций, появляется возможность автоматической генерации форм и их содержимого при создании приложения из модели.

Этапы разработки

Процесс разработки разбивается на три этапа. На первом этапе разрабатывается вычислительно-независимая модель (CIM). Часто модель, создаваемую на этом этапе, также называют доменной или бизнес-моделью. Цель данного этапа разработка общих требований к системе, создание общего словаря понятий, описание окружения, в котором система будет функционировать. Сущности, описываемые в модели CIM этого этапа, должны тщательно анализироваться и отрабатываться. Право на включение в модель должны иметь только те элементы, которые будут использованы и развиты на последующих этапах разработки. Для создания модели CIM на данном этапе можно использовать любые средства. Однако для совместимости с последующими этапами весьма желательно иметь описание модели на языке UML. Следует учитывать, что модель CIM первого этапа представляет собой скорее общую концепцию системы и не является насущно необходимой для процесса разработки приложения. При создании небольших программных систем этот этап можно опустить, однако при работе со сложными проектами он становится почти обязательным. К примеру, разработка текстового технического задания, казалось бы, никак не помогает собственно процессу программирования, зато, существенно способствует пониманию задачи в целом и позволяет избежать грубых ошибок проектирования в дальнейшем. На втором этапе разрабатывается платформенно-независимая модель (PIM). Она может разрабатываться с нуля в случае отсутствия модели первого этапа или основываться на CIM. Преобразование CIM в PIM осуществляется на основе описания на зыке UML, созданного на первом этапе. Здесь в него добавляются элементы, описывающие бизнес-логику, общую структуру системы, состав и взаимодействие подсистем, распределение функционала по элементам, общее описание и требования к пользовательскому интерфейсу. Модель PIM этого этапа обязательно включается во все автоматизированные среды разработки приложений на основе MDA.


На третьем этапе создаются платформенно-зависимые модели (PSM). Их число соответствует числу программных платформ, на которых будет функционировать приложение. Кроме этого, возможны случаи, когда приложение (или его составные части) должны работать на нескольких платформах одновременно. Модель PSM создается путем преобразования модели PIM с учетом требований модели платформы. Процесс преобразования описывается ниже. На этапе создания модели PSM разработка приложения согласно архитектуре MDA заканчивается. Считается, что правильно построенная PSM содержит техническую информацию, достаточную для генерации исходного кода (там, где это возможно) и необходимых ресурсов приложения. Здесь эстафетную палочку должна подхватить среда разработки, реализующая MDA. В нашем случае Delphi 9 обеспечивает генерацию кода и компиляцию приложений ECO. С формальной точки зрения это уже не относится к компетенции MDA, но для разработчика преобразование PSM в исполняемый код приложения непосредственное продолжение процесса разработки. Однако, архитектура MDA описывает еще один вариант прохождения третьего этапа, который называется прямым преобразованием в код. Спецификация MDA для этого случая сообщает, что могут существовать инструментарии, напрямую преобразующие модель PIM в исполняемый код приложения. Модель PSM при этом может создаваться как контрольное описание, позволяющее проверить результат прямого преобразования.

Преобразование моделей PIM PSM

  • Разработка схемы преобразования (mapping)
  • Маркирование (marking)
  • Собственно преобразование (transformation)


  • Ручной
  • С использованием профилей
  • С настроенной схемой преобразования
  • Автоматический

Многоплатформенные модели

Архитектура MDA учитывает возможность разработки приложений, одновременно функционирующих на нескольких платформах. Для этого марки схемы преобразования моделей PIM PSM устанавливаются в соответствии с распределением функционала приложения по платформам. Затем генерируется несколько платформенно-зависимых частей приложения. Проблема взаимодействия частей такого гетерогенного приложения решается на уровне бизнес-логики приложения на этапе разработки. Для обмена данными могут использоваться специально разработанные подсистемы, использующие для организации обмена заранее согласованные механизмы, форматы данных, интерфейсы. Более того, разработка механизмов межплатформенного взаимодействия хорошо поддается автоматизации. Инструментарии MDA могут содержать функционал для создания таких механизмов.

* Консорциум OMG создан сообществом IT-компаний, специализирующихся на разработке программного и аппаратного обеспечения. Основной задачей консорциума является стандартизация и спецификация в сфере информационных технологий. При этом деятельность консорциума в значительной степени ориентирована на разработку перспективных стандартов. Программистам известны такие разработки OMG, как OMA, CORBA, UML.

Содержание

  • Введение
  • 1. Цель и ядро MDA
  • 2. Жизненный цикл разработки
  • 3. Типы моделей
  • Заключение
  • Список использованных источников

Архитектура, управляемая моделью MDA (текущее состояние, примеры проектов) ( реферат , курсовая , диплом , контрольная )

UML является примером такого языка. Необходимость в двух различных моделях возникает в том случае, если структурные и динамические аспекты не могут быть описаны в одной модели, т.к. используемый язык не в состоянии отразить оба аспекта. Важно заметить, что обе модели связаны, т. е. они описывают одну и ту же систему. Рисунок 7 отображает ситуацию, при которой две различных модели, которые описывают одну и ту же систему, записаны на различных языках. Таким образом, аспект, который описывается в диаграмме или модели, не обязательно связан с типом модели. Язык выступает важной характеристикой модели. Некоторые языки являются более выразительными, чем другие и более подходящими для того, чтобы представить определенные аспекты системы[6]. Платформо-независимые и зависимые модели Имеется ряд определений PIMи PSMмоделей.

Согласно документации OMG данные модели имеют значительные различия. Модель может быть либо PIM, либо PSM. В реальности очень сложно провести черту, которая разделяют два типа моделей. При этом можно заключить наибольшую зависимость каждой из них от платформы.

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

Даже в этом случае должна быть возможность преобразовать UML-модель в ER-модель, сохраняя структурные характеристики системы[9]. Инструмент преобразования необходим для того, чтобы выполнить преобразование исходной модели, основываясь на описании преобразования. С точки зрения разработчика самыми важными элементами являются PIMи PSM. Разработчик фокусируется на создании PIM, описывая систему на высоком уровне абстракции. На следующем этапе выбирается инструмент преобразования, способный провести трансформацию разработанной PIM согласно какому-либо описанию преобразования. В результате получается PSM, которая в дальнейшем может быть преобразована в код.Рис.

10.На рисунке выше изображена только одна PSM, но в то же время из одной PIMможно получить несколько PSMс готовыми мостами между ними. В зависимости от уровня детализации платформы, модели (кроме модели платформы) могут содержать сведения о различных функциональных частях системы. В этом случае говорят об уровнях модели. Обычно различают следующие основные уровни модели[11].

Заключение

Архитектура MDAвозникла не на пустом месте. Само ее появление и возможность реализации обусловило наличие ряда стандартов и технологий, на практике доказавших свою полезность. Концептуальной основой появления MDAстали спецификации OMA, ORB, CORBA. Перевести замысел в практическую плоскость позволили технологии объектно-ориентированного программирования (ООП), стандарт CWM, языки UML, XML, MOF [20, "https://referat-bank.ru"].

Работами по созданию новой архитектуры программирования занялся консорциум OMG (ObjectManagementGroup). По мнению создателей, архитектура MDA является новым витком эволюции технологий программирования, так как описывает процесс разработки в целом. Новизна MDA заключается в том, что описание процесса разработки в ней выполнено с использованием современных средств представления и позволяет автоматизировать создание приложений. И весьма вероятно, что через некоторое время архитектура MDA станет общим промышленным стандартом в разработке программного обеспечения [2]. На данном этапе эта методология находится больше в области академических исследований, чем практического применения. Хотя множество деталей еще требуют уточнений и разработки и потребуются еще годы работы перед тем, как мы увидим практические применения MDA, общее видение и направление развития уже достаточно хорошо определены. Тем не менее, многие считают идею генерации работающих систем автоматически из моделей утопической [5].

Список использованных источников

Куриленко И.Е., Борисов А. В. Современные архитектурные подходы к построению программного обеспечения // Сб. тр. XVIII междунар. науч.-техн. конф. Информационные средства и технологии .-Т.

Модельно-управляемая архитектура (MDA) это разработка программного обеспечения подход к развитию программные системы. Он предоставляет набор руководящих принципов для структурирования спецификаций, которые выражаются как модели. Модельно-ориентированная архитектура - это своего рода доменная инженерия, и поддерживает модельно-ориентированная инженерия программных систем. Он был запущен Группа управления объектами (OMG) в 2001 году. [1]

Содержание

Обзор

Тогда, учитывая платформенная модель соответствующий CORBA, .СЕТЬ, Интернет и т. д., платформо-независимая модель (PIM) переводится в один или несколько модели для конкретных платформ (PSM), которые могут запускать компьютеры. Это требует сопоставлений и преобразований и тоже должно моделироваться.

Организация OMG предоставляет приблизительные спецификации, а не реализации, часто как ответы на Запросы предложений (RFP). Реализации поступают от частных компаний или групп с открытым исходным кодом.

Связанные стандарты

Исполняемый UML был профиль UML, который использовался при рождении MDA. Теперь OMG продвигает fUMLвместо этого. (Язык действий для fUML - ALF.)

Торговая марка

Темы об архитектуре, управляемой моделями

Подход MDA

OMG фокусирует управляемую на модели архитектуру на перспективном проектировании, то есть создании кода из абстрактных, созданных человеком диаграмм моделирования (например, диаграмм классов). [ нужна цитата ] . Группа OMG ADTF (Рабочая группа по анализу и проектированию) возглавляет эту работу. С некоторой долей юмора группа выбрала ADM (наоборот, MDA), чтобы назвать исследование обратным проектированием. ADM декодирует модернизацию на основе архитектуры. Задача ADM - разработать стандарты для модельного обратного проектирования унаследованных систем. [3] Метамодель открытия знаний (KDM) является наиболее продвинутым из этих направлений и описывает информационные системы с точки зрения различных активов (программ, спецификаций, данных, тестовых файлов, схем баз данных и т. Д.).

Поскольку концепции и технологии, используемые для реализации проектов, а также концепции и технологии, используемые для реализации архитектур, менялись в своем собственном темпе, их разделение позволяет разработчикам систем выбирать из лучших и наиболее подходящих в обеих областях. В дизайне учтены функциональные (вариант использования), в то время как архитектура обеспечивает инфраструктуру, через которую реализуются нефункциональные требования, такие как масштабируемость, надежность и производительность. MDA предполагает, что независимая от платформы модель (PIM), которая представляет собой концептуальный проект, реализующий функциональные требования, выдержит изменения в технологиях реализации и программные архитектуры.

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

Инструменты MDA

Организация OMG предоставляет приблизительные спецификации, а не реализации, часто как ответы на Запросы предложений (RFP). OMG документирует общий процесс в документе, который называется MDA Guide.

Инструмент MDA может быть инструментом, используемым для проверки моделей на полноту, несоответствие или условия ошибок и предупреждений. Также используется для расчета показателей модели. [5]

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

Спецификации OMG реализованы частными компаниями или Открытый исходный код группы. Одним из важных источников реализации спецификаций OMG является Фонд Затмения (EF). Многие реализации стандартов моделирования OMG можно найти в Среда моделирования Eclipse (ЭДС) или Платформа графического моделирования (GMF) фонд Eclipse также разрабатывает другие инструменты различного профиля, такие как GMT. Соответствие Eclipse спецификациям OMG часто не является строгим. Это верно, например, для стандарта OMG EMOF, который EMF аппроксимирует своей реализацией Ecore. Больше примеров можно найти в проекте M2M, реализующем стандарт QVT, или в проекте M2T, реализующем стандарт MOF2Text.

Обычно инструменты MDA фокусируются на элементарной спецификации архитектуры, хотя в некоторых случаях инструменты не зависят от архитектуры (или платформы).

Простые примеры спецификаций архитектуры включают:

Проблемы MDA

Споры о создании кода

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

Часто цитируемая критика заключается в том, что диаграммам UML просто не хватает деталей, которые необходимы для того, чтобы содержать ту же информацию, которая содержится в исходном коде программы. Некоторые разработчики даже заявляют, что «Код является дизайн". [15] [16]

Читайте также: