6. Концепции реализации

Необходимо подчеркнуть, что на настоящем этапе концепция MDA не является полностью проработанной: более того, существует несколько своеобразных «конкурирующих» подходов к ее реализации. Из них можно выделить два основных ¬ это, условно выражаясь, подходы «интерпретатора» и «генератора». В чем их суть и различие?

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

Напротив, в концепции «генератора» все внимание сосредоточено на как можно более полной и универсальной реализации автоматической генерации кода приложения, с использованием оптимизации кода по различным параметрам: скорости, размеру и т. д. Этот подход несколько больше схож с CASE-системами.

7. Возможные последствия внедрения mda

Легко видеть, что само понятие «разработчик программного обеспечения» может при внедрении MDA довольно сильно видоизмениться. Со смещением акцента на создание модели разработкой приложений будут заниматься не столько программисты, сколько специалисты, владеющие описываемой предметной областью. Возможно, что также в какой-то степени «пострадает» традиционное деление специалистов на разработчиков баз данных и разработчиков приложений баз данных. Как будет показано в следующих главах, уже сейчас возможно при разработке MDA-приложений практически полностью абстрагироваться от знания конкретной СУБД; более того, во многих случаях нет необходимости и использовать язык SQL, поскольку рассматриваемые в этой книге инструменты MDA предоставляют возможность работать на более «высоком» уровне (бизнес-уровне), где становится абсолютно не важным знание конкретной структурной схемы базы данных или состава полей ее таблиц.

Однако программисты-разработчики вряд ли останутся без работы, так как, с одной стороны, создание MDA-инструментария само по себе является чрезвычайно интересной, сложной и объемной задачей для них. А с другой стороны, внедрение MDA уже сейчас избавляет и самих программистов от рутинной работы, передавая большую ее часть искусственному программному интеллекту ¬ инструментам реализации MDA [6].

8. Унифицированный язык моделирования uml

Архитектура MDA ставит во главу угла модель приложения и поэтому непосредственно связана с языком, на котором такие модели создаются, ¬ языком унифицированного моделирования UML Язык UML (Unified Modelling Language) является основным инструментом MDA для создания модели приложения. Обладая довольно выразительными графическими возможностями, UML является одновременно и средством описания, и средством документирования разработки.

В настоящее время имеется довольно много литературы, описывающей язык UML [3].

Причиной появления UML стала необходимость в унификации разнообразных подходов к описанию моделей бизнес-приложений. В последнем десятилетии прошлого века появилось несколько десятков вариантов инструментария для создания подобных моделей, все они были не согласованы между собой, что мешало разработке CASE-средств и приводило к трудностям их внедрения. CASE-средства (Computer Aided Software Engineering ¬ дословно «разработка программного обеспечения с помощью компьютера») в то время использовались в основном в качестве универсальных графических инструментов для визуального проектирования реляционных баз данных с возможностями последующей автоматической генерации БД. У истоков разработки языка Unified Modeling Language (UML) стоит компания Rational Software, автор одного из первых CASE-средств ¬ Rational Rose. В 1995 году консорциум OMG включается в работу по стандартизации UML, к разработке языка активно подключаются и другие компании, и после выхода нескольких промежуточных версий в 1997 году появляется версия UML 1.0.

Сегодня последней стандартизованной OMG версией является UML 1.4, на заключительном этапе находится разработка версии 2.0. Развитие UML в настоящее время координируется OMG, который считает разработку и продвижение этого языка одним из своих стратегических направлений.

Можно выделить следующие характерные черты UML:

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

• UML не является языком программирования и не содержит алгоритмов и операторов в обычном смысле, он в первую очередь является средством описания.

• UML, являясь платформенно-независимым языком, абстрагируется от специфики конкретных языков программирования и средств разработки.

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

UML базируется на объектно-ориентированном подходе и содержит диаграмму классов для описания структуры и состава модели. Диаграмма классов является основой для формирования модели приложения и играет важнейшую роль при разработке MDA-приложений [3].

Выводы

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

• Рассмотрение существующих инструментальных средств и технологий для реализации MDA-приложений;

• Выбор конкретного инструментального средства для реализации поставленной задачи;

• Технический обзор основных моментов при проектировании информационных систем с использованием технологии MDA в выбранном конкретном инструментальном средстве.

31