Архитектура, управляемая моделью (курсовая), страница 7

Они нужны в случае, если разработчика не устраиваютимеющиеся правила преобразования, и ему требуется написать своисобственные. Как было сказано ранее, такими средствами могут являтьсяинструментально-специализированныескриптовыеязыки.Жесткаязависимость всей концепции 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 или инструмент генерации.Высокоуровневая модель перестает быть «просто бумагой», как это былораньше.

Теперь она непосредственно связана с кодом. Из-за этой связи к PIMпредъявляются более высокие требования. Она должна быть законченной,непротиворечивой, полной и абсолютно точной. Человек, анализирующийнеточную высокоуровневую модель, все-таки может правильно понятьнеполностью или не совсем верно отраженные в ней аспекты. Инструментавтоматической генерации – нет.МобильностьКак было сказано ранее, основное внимание уделяется разработке PIM.Поопределению,PIM–платформо-независимаямодель.Из-занепривязанности основной модели к какой-либо платформе достигаетсявысокая мобильность.

Одна и та же PIM может быть автоматическипреобразована во множество PSM, каждая из которых генерируется для50различных платформ. Поэтому, все что определяется на уровне PIM обладаетабсолютной мобильностью.Степеньдостигаемоймобильностизависитотимеющихсяинструментов автоматического преобразования. Для популярных платформуже доступно (или станет доступно в ближайшем будущем) множество такихинструментов.

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