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

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

Если имеетсявозможность получения двух различных PSM из одной PIM, то, по идее, всяинформация, нужная для обеспечения взаимодействия между ними,доступна. Для каждого элемента в одном PSM мы знаем, от которогоэлемента в PIM он был сгенерирован. Также мы знаем, что от этого жеэлемента PIM был сгенерирован соответствующий элемент во второй PSM.Исходя из этого, можно сделать вывод о соответствии друг другу элементовразличных PSM. Кроме того, так как нам известны все технические детали51платформ обеих PSM (иначе, мы, возможно, не выполнили преобразованияPIM к PSM), у нас есть вся информация для генерации моста между этимидвумя моделями.Возьмем, например, две PSM: первую, ориентированную на Java ивторую - на модель реляционной базы данных.

В PIM определен элемент«Клиент».Разработчикзнает,ккакомуJava-классудолженбытьпреобразован этот элемент. Он также имеет представление о таблице в базеданных, которая должна соответствовать этому элементу. Создание мостамежду Java-классом и таблицей в базе данных не составит особого труда. Дляполучения объекта из базы данных, мы запрашиваем таблицу, полученную отэлемента «Клиент», и инициализируем Java-класс. Чтобы сохранить объект,мы берем информацию из Java-класса и записываем ее в таблицу «Клиент».Межплатформенная функциональная совместимость так же может бытьреализована с помощью инструментов, которые генерируют не только самиPSM, но и мосты между ними.

Так же могут быть сгенерированы мосты надругие платформы. Таким образом, внезапная смена платформы не приведет52к катастрофическим последствиям и не сделает необходимым полноепереписывание системы.ДокументацияPIM является абстракцией гораздо более высокого уровня, чем код. PIMиспользуется, чтобы генерировать PSM, которые поочередно используютсядля генерации код. Модель - точное представление кода. Таким образом, PIMвыполняет функцию высокоуровневой документации, которая необходимадля любой программной системы.Разница в том, что PIM не «забрасывают» после первого написания.Чтобы внести какое-либо изменение в систему, разработчик должен изменитьPIM.

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

Их задача – показать, какприменять концепцию MDA на конкретных примерах. В обоих примерахакцент делается на высоко-уровневую PIM, созданную на UML, и на PSMболее низкого уровня.Публичные и частные атрибутыВ первом примере рассматривается преобразование между двумя UMLмоделями. PIM трансформируется в PSM, рассчитанную на Java. Главное вэтом примере - преобразование публичных атрибутов в соответствующие имget- и set- методы. Класс «Клиент» содержит три атрибута: название, имя идата рождения. Все атрибуты публичные. В высоко-уровневой PIM можноиспользовать публичные атрибуты. Они лишь означают, что элемент имееткакие-то атрибуты и они могут быть изменены впоследствии.В PSM мы моделируем исходный код вместо бизнес-концепции.Использованиепубличныхатрибутовсчитаетсяплохимтоном.инкапсулировать публичные атрибуты, а изменять и получать их черезспециальные методы.54Все атрибуты частные и доступ к «Клиенту» осуществляется черезчетко-определенные операции.

Это позволяет только объекту «Клиент»управлять своим использованием и изменением атрибутов.Обе модели полезны, так как представляют разные уровни информациидля разных разработчиков. Однако между этими моделями есть явная связь.Описание трансформации из PIM в PSM включает несколько правил:o Для каждого класса с именем className в PIM должен существоватьпорожденный класс с таким же именем в PSMo Для каждого атрибута с именем attributeName из класса в PIMпорожденный класс в конечной модели должен включать:o частные атрибуты с такими же именами;o публичный метод с именем атрибута и приставкой get. Типвозвращаемого значения соответствует типу атрибута;o публичная операция с именем атрибута и приставкой set.Возвращаемоезначениеотсутствует.Типпараметрасоответствует типу атрибута.У этого правила преобразования есть отражение - правило, котороепреобразовывает аспект PSM в PIM:55o Для каждого класса с именем className в PSM есть класс-прородительс таким же именем в PIMТак как в этом примере мы знаем, что конечной платформой являетсяJava, мы сразу можем описать правила преобразования, по которым PSMбудет преобразована в код.

В конечном итоге, мы получим исходный код изPIM, применив две трансформации: из PIM в PSM и из PSM в исходный код.СвязиМожно расширить рассмотренный пример большим количествомклассов и ввести связи между ними.На рисунке добавлены два класса «Заказ» и «Предмет». Модельпоказывает, что «Клиент» может иметь несколько «Заказов», и к каждомузаказумогутотноситьсянесколько«Предметов».ВPSMпослепреобразования публичных атрибутов нужно заменить связи междууказанными классами чем-либо, присутствующем в конечном языкепрограммирования.

Естественно, для того, чтобы отобразить ассоциации сразмерностью больше единицы, приходится использовать набор классов.Дополнительные правила преобразования:o Для связи в PIM должно быть доступно следующее в PSM:56o В классах на обоих концах связи должен присутствовать частныйатрибут, с именем другого класса, участвующего в связи;o Тип этого атрибута - класс со стороны конца связи, если ихнесколько - набор классов;o для добавленного атрибута должны быть определены методыset и get.o Для направленной связи вышеупомянутое справедливо только длякласса, из которого выходит стрелка.Преобразование, которое содержит правила преобразования, как дляатрибутов, так и для связей в PSM, показано на следующем рисунке:Здесь PSM более отличается от PIM, чем в первом примере.

Сложнеепонять связи между классами. Если в нашем распоряжении есть только PSM,то можно видеть, что «Заказ» связан с «Клиентом» по полю «Клиент».Размерность связи может равняться нулю или единице. Мы не сможемпонять, направленная это связь или нет. Связь между «Заказом» и«Предметом» потеряна полностью, потому что в Java нет ограничений на типэлемента в функции setItems класса «Заказ», а класс «Предмет» не содержитссылки на «Заказ». Определение обратной трансформации становитсяневозможным.57В вышеупомянутом правиле было выбрано наличие операцийприсвоения для атрибутов.

В этом случае тип параметра – множество.Например, метод setOrders (o: Set) в классе «Клиент». Альтернативойявляется только ввод операции addOrder (o: Set). Это облегчит добавлениеединичных заказов. Выбор делается человеком или самим инструментом.Часторазработчикухочетсяиметьполностьюконтролироватьпреобразование. Например ему хочется заменить тип Set на HashSet и ввестиобе операции: setOrders и addOrder.

В этом случае ему придется вручнуюменять правила преобразования [14].58Перспективы развития MDAЕсли развитие MDA будет успешно продолжаться, то, возможно, черезнесколько лет этап написания кода системы полностью выпадет из процессаразработки. Внимание будет уделяться описанию моделей и правилпреобразования между ними.Насамом ли деле MDA так хорош? Действительно, тот факт, чтополная версия рабочей программы автоматически генерируется из модели,вызывает определенный скептицизм. Но подход MDA уже сегодняшнейступениразвитияможетобеспечитьпреимуществавмобильности,производительности и платформенном взаимодействии. Кроме того, еслиобратиться к истории, в 60-х годах, при переходе с ассемблерных языков напроцедурные многие специалисты так же скептически относились к этомунововведению.Ониобъяснялиэтонесовершенствомтогдашнихкомпиляторов и рядом других причин, действительно имевших место в товремя.