Архитектура, управляемая моделью (MDA) (7. Архитектура, управляемая моделью (MDA)), страница 7
Описание файла
Файл "Архитектура, управляемая моделью (MDA)" внутри архива находится в следующих папках: 7. Архитектура, управляемая моделью (MDA), Дополнительные материалы. PDF-файл из архива "7. Архитектура, управляемая моделью (MDA)", который расположен в категории "". Всё это находится в предмете "распределённые ис и базы данных" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве НИУ «МЭИ» . Не смотря на прямую связь этого архива с НИУ «МЭИ» , его также можно найти и в других разделах. Архив можно найти в разделе "лекции и семинары", в предмете "распределённые ис и базы данных" в общих файлах.
Просмотр PDF-файла онлайн
Текст 7 страницы из PDF
Трансформация из PIM в PSMопускается. В этом случае исходный и результирующий язык, а такжеопределения трансформации встроены в инструмент, который опять жеработает по принципу «черного ящика».В качестве языка определения PIM обычно используется UML.Динамическая часть, не отражаемая средствами UML, обычно добавляется всгенерированный код вручную.Настраиваемые инструментыИнструментыпреобразования.должныОбычнопозволятьпараметризироватьневозможноподстроитьпроцессопределениятрансформации под свои требования, потому что доступ к ним закрыт.Лучшее на что можно рассчитывать – это правила преобразования,написанные на каком-либо внешнем скриптовом языке.
Чтобы внестиизменения в такой скрипт требуется много времени, потому что пока еще несоздано специализированного для написания таких определений языка.Большинство инструментов работают только с языком описания PIM,которым является UML. Хотя диаграммы UML используются для созданияPIM, на практике инструменты не используют определения языка UML,заменяя их своими интерпретациями. Из-за этого даже специалист в областиUML потратит много времени на изучение определений, вшитых винструменты, для написания своих определений трансформации.Инструменты задания правил преобразованияЭти инструменты обеспечивают создание и модификацию правилпреобразования.
Они нужны в случае, если разработчика не устраиваютимеющиеся правила преобразования, и ему требуется написать своисобственные. Как было сказано ранее, такими средствами могут являтьсяинструментально-специализированныескриптовыеязыки.Жесткаязависимость всей концепции MDA от определений трансформации делает44необходимым создание языка, способного четко описывать правилапреобразования, и инструментов, лучше справляющихся с этой задачей.Такие инструменты еще не созданы.Исходя из написанного, можно сделать вывод о том, что поскольку наданный момент не существует реальных инструментов моделированияправил преобразования, то и полезность всей концепции MDA оказываетсяпод вопросом.
На самом деле все не так плохо. Несмотря на то, что полныйпотенциалконцепцииещенеиспользуется,дажесуществующиеинструменты дают значительные приемущетсва.Другие инструментыХотя ядром MDA являются инструменты преобразования, нужны еще идругие инструменты. Кроме функциональности, приносимой инструментамипреобразования, требуется и другая.o Редакторкода:Developmentнаборфункций,Environment(IDE),представляемыхнапример,отладка,Interactiveкомпиляция,форматирование кода.o Файлы кода: хотя мы рассматривали код в качестве модели, обычно онхранится в текстовых файлах.
Это не тот формат, который может быть45понят остальными инструментами. Поэтому, требуются следующие двевещи:o Парсер файла кода: парсер, который преобразует текстовыйфайл с кодом в форму модели, которую могут использоватьдругие инстументы.o Генератор файлов кода: отражение парсера. Работает наоборот.Преобразует модель кода в текстовые файлы.o Репозиторий моделей: база данных моделей, где хранятся модели имогут быть получены, используя XMI, JMI или IDL.o Редактор моделей: инструмент для создания и редактированиямоделей.o Валидатор моделей: модели, на основе которых генерируются другиемодели, должны быть очень четко-определенными.
Валидаторпроверяет модели на соответствие некоторым правилам построениямоделей, для того, чтобы она была применима для трансформации.o Редактор определений трансформации: редактор для создания иредактирования опредеоений трансформации.o Репозиторий определений трансформации: хранилище созданныхопределений трансформации.Множесто инструментов на сегодняшний день в некоторой степенисовмещают несколько вышеописанных функций. Традиционные CASEинструменты предоставляют средства для редактирования и хранениямоделей (редактор и репозиторий).
Генератор кода, основанный наскриптовом языке и встроенный в CASE-инструмент, является инструментовтрансформации и редактором определений трансформации. В таком случае,репозиторием определений трансформации является система текстовыхфайлов.46Все функций могут идти в двух формах: применительно к языку или вобщем. Инструмент, рассчитанный на конкретный язык, может включать всебя редактор моделей для UML и генератор кода из UML модели в код C#.Общий редактор моделей позволяет пользователю редактировать любуюмодель.Выбор инструментовИзложеннаявышеинформацияпомогаетввыборенужныхинструментов для разработки по концепции MDA.
Для начала нужноопределиться с требованиями. Нужно ли привязываться к конкретному языкуилитребуетсяуниверсальныймеханизм?Нужноликомбинироватьразличные инструменты, используя различные стандартные интерфейсы, илиограничиться одним, который предоставляет весь нужный функционал?При выборе инструмента нужно выяснить, какие функции онподдерживает и на какой язык ориентирован. Так же необходимо проверить,работают ли функции на моделях, описанных с использованием стандартныхмеханизмов (XMI, JMI, IDL). После этих манипуляций можно составитьдовольно четкое впечатление о выбранном инструменте.
Не существуетсредств, предоставляющих полную функциональность в этой области.Поэтому следует быть готовыми комбинировать несколько различныхинструментов.Хотя процесс трансформации моделей является ключевым в MDA,нужно также озаботиться инструментами, выполняющими другие важныефункции. При комбинировании инструментов главное – это разобраться,какие функции поддерживает каждый из них [12].47Достоинства MDAMDA предоставляет архитектуру, которая обладает рядом ключевыхдостоинств:Переносимость, нарастающее повторное использование приложения,уменьшение стоимости и сложности разработки и управленияприложением в настоящее время и в будущем.Строгие методы гарантии того, что системы, базируемые на различныхтехнологиях реализации, соответствуют общей бизнес-логике итребованиям.Независимость от платформы, значительное сокращение времени,стоимости и сложности, связанной с переработкой приложений дляразличных платформ и сменой платформ.Настройка на предметную область посредством специфическихмоделей, которые позволяют быстро реализовывать новые приложения,используя стандартные для данной области компоненты.Возможность для разработчиков, дизайнеров и системныхадминистраторов использовать удобные им языки и концепции;бесшовное связывание и интегрирование фрагментов, разрабатываемыхразными командами.Пользуясь MDA, можно организовать не только переход от абстрактноймодели к детальной (от PIM к PSM, от PSM к коду системы), но и обратноепреобразование — повышение уровня абстракции.
Возможно созданиеинструментов, позволяющих осуществлять не только прямое, но и обратноепреобразование моделей на основе стандартных отображений. Благодаряэтому открывается возможность вести разработку, тестирование имодификацию одновременно платформно-независимой и платформнозависимой моделей; если возникает необходимость изменить логику работы48программы на абстрактном уровне (т.е.
изменить PIM), эти изменения могутбыть отображены в изменения PSM [3].Преимущества, которые дает архитектура MDA:Кардинальное повышение производительности разработки(устраняется этап «ручного» программирования).Документированность и легкость сопровождения.Централизация логики функционирования.Облегчение доступности и управляемости разработки (UML-диаграммы, представленные в графическом виде, являются достаточнонаглядными и по существу не требуют знания программирования илитеоретических основ разработки реляционных баз данных) [5].Рассмотримболееподробнопреимущества,предоставляемыеконцепцией MDA [12].ПроизводительностьВ MDA разработчик делает акцент на разработку PIM, посколькугенерация PSM происходит автоматически.
Конечно, все еще необходимоопределитьточноепреобразование,чтоявляетсятруднойиузкоспециализированной задачей. Однако такое преобразование определяетсятолько однажды и многократно может быть применено в дальнейшем. Сточки зрения затраченных усилий и времени окупаемость определенияпреобразования является хорошей, но решение этой задачи под силу тольковысококвалифицированному специалисту.Специалист, занимающийся проектированием PIM, может работать, незадумываясь о деталях и специфических особенностях целевых платформ имножестве других технических деталях. Они будут автоматически добавленывовремяпреобразованияPIMвPSM.Этоспособноулучшитьпроизводительность по двум причинам:49o во-первых, объем работ проектировщиков PIM сокращается, потомучто отпадает надобность описывать специфичные для платформыдетали.
Объем кода, требующего ручное написание, на уровне PSM также сокращается, потому что большая часть кода генерируетсяавтоматически;o во-вторых, разработчики могут сконцентрироваться на создании PIM,таким образом, уделяя больше внимания решению именно бизнеспроблемы, а не написанию кода. Это позволяет быстрее разрабатыватьсистемы, намного больше соответствующие требованиям конечныхпользователей. Кроме того, такие системы более устойчивы кошибкам, так как они более детально промоделированы.Такое повышение эффективности может быть достигнуто только спомощью инструментов, которые полностью автоматизируют процессгенерации PSM из PIM. Подразумевается, что большая часть информации осистеме должна быть включена в PIM или инструмент генерации.Высокоуровневая модель перестает быть «просто бумагой», как это былораньше.