Уровни модели
В зависимости от уровня детализации платформы, модели (кроме модели платформы) могут содержать сведения о различных функциональных частях системы. В этом случае говорят об уровнях модели. Обычно различают следующие основные уровни модели.
Уровень бизнес-логики содержит описание основного функционала приложения, обеспечивающего исполнение его назначения. Как правило, уровень бизнес-логики хуже всего поддается автоматизации. Он составляет львиную долю кода приложения, который приходится писать вручную.
Уровень данных описывает структуру данных приложения, используемые источники, форматы данных, технологии и механизмы доступа к данным.
Уровень пользовательского интерфейса описывает возможности приложения по взаимодействию с пользователями, а также состав форм приложения, функционал элементов управления (например, контроль ввода данных). Легкость автоматизации этого уровня зависит от того, насколько унифицированы пользовательские операции. Если удается создать типовые шаблоны элементов управления для основных операций, появляется возможность автоматической генерации форм и их содержимого при создании приложения из модели.
Этапы разработки
Процесс разработки разбивается на три этапа. На первом этапе разрабатывается вычислительно-независимая модель (CIM). Часто модель, создаваемую на этом этапе, также называют доменной или бизнес-моделью. Цель данного этапа разработка общих требований к системе, создание общего словаря понятий, описание окружения, в котором система будет функционировать. Сущности, описываемые в модели CIM этого этапа, должны тщательно анализироваться и отрабатываться. Право на включение в модель должны иметь только те элементы, которые будут использованы и развиты на последующих этапах разработки. Для создания модели CIM на данном этапе можно использовать любые средства. Однако для совместимости с последующими этапами весьма желательно иметь описание модели на языке UML. Следует учитывать, что модель CIM первого этапа представляет собой скорее общую концепцию системы и не является насущно необходимой для процесса разработки приложения. При создании небольших программных систем этот этап можно опустить, однако при работе со сложными проектами он становится почти обязательным. К примеру, разработка текстового технического задания, казалось бы, никак не помогает собственно процессу программирования, зато, существенно способствует пониманию задачи в целом и позволяет избежать грубых ошибок проектирования в дальнейшем. На втором этапе разрабатывается платформенно-независимая модель (PIM). Она может разрабатываться с нуля в случае отсутствия модели первого этапа или основываться на CIM. Преобразование CIM в PIM осуществляется на основе описания на зыке UML, созданного на первом этапе. Здесь в него добавляются элементы, описывающие бизнес-логику, общую структуру системы, состав и взаимодействие подсистем, распределение функционала по элементам, общее описание и требования к пользовательскому интерфейсу. Модель PIM этого этапа обязательно включается во все автоматизированные среды разработки приложений на основе MDA. (см. рис. 1)
рис. 1 Схема преобразования моделей.
На третьем этапе создаются платформенно-зависимые модели (PSM). Их число соответствует числу программных платформ, на которых будет функционировать приложение. Кроме этого, возможны случаи, когда приложение (или его составные части) должны работать на нескольких платформах одновременно. Модель PSM создается путем преобразования модели PIM с учетом требований модели платформы. Процесс преобразования описывается ниже. На этапе создания модели PSM разработка приложения согласно архитектуре MDA заканчивается. Считается, что правильно построенная PSM содержит техническую информацию, достаточную для генерации исходного кода (там, где это возможно) и необходимых ресурсов приложения. Здесь эстафетную палочку должна подхватить среда разработки, реализующая MDA. Однако архитектура MDA описывает еще один вариант прохождения третьего этапа, который называется прямым преобразованием в код. Спецификация MDA для этого случая сообщает, что могут существовать инструментарии, напрямую преобразующие модель PIM в исполняемый код приложения. Модель PSM при этом может создаваться как контрольное описание, позволяющее проверить результат прямого преобразования. [10]
Таким образом, основная цель MDA — минимизация затрат, связанных с привязкой к конкретным системным платформам и программным инфраструктурам, путём уменьшения зависимости ИС от технологий реализации. Для этого вводятся вышестоящие уровни описаний программной системы и предметной области, на основе которых в идеале решается или облегчается задача генерации программного кода, настроек, параметров и т.п. для различных платформ. Это позволяет, при необходимости, применяя незначительные затраты, сгенерировать модифицированную ИС для функционирования на совершенно другой платформе и с использованием отличных технологий. [11]
Подход MDA применим не только в рамках классических программных приложений, но и, при наличии соответствующего инструментария, для построения специфических приложений. Именно таким инструментарием является Rational Method Composer, позволяющий генерировать web-сайты с информацией о процессе разработки на основе модели этого процесса.
|
