WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 16 |

Рисунок 3. Создание MDA-приложений Поскольку (по крайней мере, такие намерения декларирует концепция MDA) PSM-модель и генератор кода в идеале должны быть полностью отработаны и функционировать «в автоматическом режиме», постольку все изменения PIM должны реализоваться в измененном коде приложения без искажений. Здесь уместно провести некоторую аналогию с прикладной программой и драйверами операционной системы: если прикладная программа использует некий стандартный драйвер, и он штатно функционирует, то при корректном изменении прикладного кода не произойдет никаких неожиданностей в работе - 33 - УМП «Автоматизированные методы разработки архитектуры ПО» программы в целом. Аналогию можно и несколько расширить: если мы заменим имеющийся драйвер на драйвер другого устройства (например, модернизировав в персональном компьютере звуковую карту), а прикладную программу оставим без изменений, то наше приложение должно по-прежнему штатно функционировать, взаимодействуя уже с другим устройством. Таким образом, создав один раз PIM-модель и заменяя потом «драйверы» (PSM), – добьемся функционирования нашего приложения на совершенно разных платформах. Уже из сказанного, очевидно, какие преимущества дает архитектура MDA. К этому можно добавить еще ряд полезных качеств нового подхода.

o Кардинальное повышение производительности разработки. По сути, при использовании MDA-архитектуры вся разработка сводится к корректному формированию PIM-моделей, устраняется этап «ручного» программирования.

o Документированность и легкость сопровождения. PIM-модель в MDA играет роль как проекта, так и основного документа — описания приложения в достаточно компактном виде.

o Централизация логики функционирования. В отличие от традиционного подхода, где логика работы приложения «разбросана» по программному коду, в MDA она сосредоточена в одном месте — в PIM-модели. Приложение изменяет свое поведение при изменении PIM-модели.

o Облегчение доступности и управляемости разработки. С точки зрения заказчика или менеджера наличие платформеннонезависимой PIM-модели резко облегчает понимание проекта в целом и управление разработкой. Это объясняется тем, что PIM-модель «не привязана» к специфическим особенностям сред программирования и по этой причине не содержит сложных или непонятных заказчику/менеджеру элементов и конструкций. UML-диаграммы, представленные в графическом виде, являются достаточно наглядными и по существу не требуют знания программирования или теоретических основ разработки реляционных баз данных...”.

Не случайно аббревиатура MDA расшифровывается как Model Driven Architecture (архитектура, управляемая моделью). MDA это архитектура, описывающая новый способ разработки программного обеспечения. Создание приложений этой архитектуры базируется на разработке модели приложения.

MDA предствляет собой концепцию модельно ориентированного подхода к разработке программного обеспечения. Его суть состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и т.д.). Создание метамодели определяется технологией моделирования MOF (Meta Object Facility), являющейся частью концепции MDA.

- 34 - УМП «Автоматизированные методы разработки архитектуры ПО» По мнению создателей, архитектура MDA является новой технологией программирования, так как описывает процесс разработки в целом. Новизна MDA заключается в том, что описание процесса разработки в ней выполнено с использованием современных средств представления и позволяет автоматизировать создание приложений.

Процесс разработки ПО состоит из трёх этапов.

На первом этапе разрабатывается вычислительно-независимая модель (CIM). Модель, создаваемую на этом этапе, также называют доменной или бизнес-моделью. Цель данного этапа разработка общих требований к системе, создание общего словаря понятий, описание окружения, в котором система будет функционировать. Сущности, описываемые в модели CIM, должны тщательно анализироваться и отрабатываться. Право на включение в модель должны иметь только те элементы, которые будут использованы и развиты на последующих этапах разработки. Для создания модели CIM на данном этапе желательно иметь описание модели на языке UML.

Модель CIM первого этапа не является необходимой для процесса разработки приложения, и представляет собой общую концепцию системы. В случаях разработки сложных или крупных программных систем этот этап является обязательным.

На втором этапе разрабатывается платформенно-независимая модель (PIM). Если модель CIM не разрабатывалась, модель PIM разрабатывается «с нуля», а при наличии модели CIM модель PIM основываться на CIM. Преобразование модели CIM в модель PIM осуществляется на основе описания на языке UML, созданного на первом этапе. В модель PIM добавляются элементы, описывающие бизнес-логику, общую структуру системы, состав и взаимодействие подсистем, распределение функционала по элементам, общее описание и требования к пользовательскому интерфейсу. На этом этапе производится включение модели PIM во все автоматизированные среды разработки приложений на основе MDA (рис 4).

CIM Модель Модель PIM платформы платформы PSM PSM Рисунок 4. Схема взаимодействия - 35 - УМП «Автоматизированные методы разработки архитектуры ПО» На третьем этапе создаются платформенно-зависимые модели (PSM) путем преобразования модели PIM с учетом требований модели платформы. Количество PSM соответствует количеству программных платформ, для которых разрабатывается ПО. На этапе создания модели PSM разработка приложения завершается.

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

Архитектура MDA описывает еще один вариант прохождения третьего этапа, который называется прямым преобразованием в код. В соответствии со спецификацией, допускается применение инструментальных средств преобразующих модель PIM в исполняемый код приложения. Модель PSM, при этом, может создаваться как контрольное описание, позволяющее проверить результат прямого преобразования.

3.1.1. Преобразование моделей PIM PSM Наиболее сложным и ответственным этапом при разработке приложений в рамках архитектуры MDA является преобразование модели PIM в модель PSM. Именно на этом этапе общее описание системы на языке UML приобретает вид, пригодный для воплощения приложения на конкретной платформе. Как уже отмечалось выше, в процессе проектирования принимает участие модель платформы.

Преобразование моделей проходит три последовательные стадии:

• Разработка схемы преобразования (mapping).

• Маркирование (marking).

• Собственно преобразование (transformation).

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

Наборы марок могут быть объединены в тематические шаблоны, - 36 - УМП «Автоматизированные методы разработки архитектуры ПО» которые возможно использовать в различных схемах преобразования.

Процесс задания марок называется маркированием. В простейшем случае один элемент модели PIM соединяется маркой с одним элементом модели PSM. В более сложных случаях один элемент модели PIM может иметь несколько марок из разных схем преобразования. Что касается преобразования метамодели, то в большинстве случаев марки могут расставляться автоматически. А вот для элементов модели часто требуется вмешательство разработчика. В процессе маркирования необходимо использовать сведения о платформе. Эти сведения содержатся в модели платформы (рис. 5).

PSM PIM Схема Метамодель Марка Метамодель Марка Модель Модель Марка Марка Модель платформы Рисунок 5. Модель платформы Процесс преобразования моделей заключается в переносе маркированных элементов модели и метамодели PIM в модель и метамодель PSM. Процесс преобразования должен документироваться в виде карты переноса элементов модели и метамодели. Способ преобразования моделей может быть:

• Ручной.

• С использованием профилей.

• С настроенной схемой преобразования.

• Автоматический.

3.1.2. Многоплатформенные модели Архитектура MDA учитывает возможность разработки приложений, одновременно функционирующих на нескольких платформах. Для этого марки схемы преобразования моделей PIM PSM устанавливаются в соответствии с распределением средств приложения по платформам. Затем генерируется несколько платформенно - 37 - УМП «Автоматизированные методы разработки архитектуры ПО» зависимых частей приложения. Проблема взаимодействия частей такого гетерогенного приложения решается на уровне бизнес-логики приложения на этапе разработки. Для обмена данными могут использоваться специально разработанные подсистемы, использующие для организации обмена заранее согласованные механизмы, форматы данных, интерфейсы. Более того, разработка механизмов межплатформенного взаимодействия хорошо поддается автоматизации.

Инструментарии MDA могут содержать средства для создания таких механизмов.

Архитектура MDA описывает и структурирует поэтапный процесс разработки любых программных систем на основе создания и использования моделей. При этом используется несколько типов моделей, создаваемых и преобразуемых на различных этапах разработки. Процесс разработки по MDA это последовательное (поэтапное) продвижение от одной модели системы к другой. При этом каждая последующая модель преобразуется из предыдущей и дополняется новыми деталями. Модели, общая схема разработки и процесс преобразования моделей – ключевые составные части архитектуры.

При применении технологии разработки ПО применяются следующие общие термины и определения:

Модель описание или спецификация системы и ее окружения, созданная для определенных целей. Часто является комбинацией текстовой и графической информации. Текст может быть описан специализированным или естественным языком.

Управление на основе модели процесс разработки системы, использующий модель для понимания, конструирования, распространения и других операций.

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

Вычислительная независимость – качество модели, обозначающее отсутствие любых деталей структуры и процессов.

Платформенная независимость – качество модели, обозначающее ее независимость от свойств любой платформы.

Вычислительно-независимая модель – модель, скрывающая любые детали реализации и процессов системы; описывает только требования к системе и ее окружению.

Платформенно-независимая модель – модель, скрывающая детали реализации системы, зависимые от платформы, и содержащая элементы, не изменяющиеся при взаимодействии системы с любой платформой.

Платформенно-зависимая модель – модель системы с учетом деталей реализации и процессов, зависимых от конкретной платформы.

- 38 - УМП «Автоматизированные методы разработки архитектуры ПО» Модель платформы набор технических характеристик и описаний технологий и интерфейсов, составляющих платформу.

Преобразование модели – процесс преобразования одной модели системы в другую модель той же системы.

В MDA используются следующие типы моделей:

Вычислительно-независимая модель (Computation Independent Model, CIM) описывает общие требования к системе, словарь используемых понятий и условия функционирования (окружение).

Модель не должна содержать никаких сведений технического характера, описаний структуры и свойств системы. CIM максимально общая и независимая от реализации системы модель. Спецификация MDA подчеркивает, что CIM должна быть построена так, чтобы ее можно было преобразовать в платформенно-независимую модель. Поэтому CIM рекомендуется выполнять с использованием унифицированного языка моделирования UML.

Платформенно-независимая модель (Platform Independent Model, PIM) описывает состав, структуру, функционал системы. Модель может содержать сколь угодно подробные сведения, но они не должны касаться вопросов реализации системы на конкретных платформах.

Модель PIM создается на основе CIM. Для создания модели используется унифицированный язык моделирования UML.

Платформенно-зависимая модель (Platform Specific Model, PSM) описывает состав, структуру, функционал системы применительно к вопросам ее реализации на конкретной платформе. В зависимости от назначения модель может быть более или менее детализированной.

Модель создается на основе двух моделей. Модель PIM является основой модели PSM. Модель платформы используется для доработки PSM в соответствии с требованиями платформы.

Модель платформы описывает технические характеристики, интерфейсы, функции платформы. Зачастую модель платформы представлена в виде технических описаний и руководств. Модель платформы используется при преобразовании модели PIM в модель PSM. Для целей MDA описание модели платформы должно быть представлено на унифицированном языке моделирования UML.

В зависимости от уровня детализации платформы, модели (кроме модели платформы) могут содержать сведения о различных функциональных частях системы. В этом случае говорят об уровнях модели. Обычно различают следующие основные уровни модели.

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

- 39 - УМП «Автоматизированные методы разработки архитектуры ПО» Уровень данных описывает структуру данных приложения, используемые источники, форматы данных, технологии и механизмы доступа к данным. Для приложений.NET чаще всего используются возможности ADO.NET.

Уровень пользовательского интерфейса описывает возможности приложения по взаимодействию с пользователями, а также состав форм приложения, функционал элементов управления (например, контроль ввода данных). Легкость автоматизации этого уровня зависит от того, насколько унифицированы пользовательские операции. Если удается создать типовые шаблоны элементов управления для основных операций, появляется возможность автоматической генерации форм и их содержимого при создании приложения из модели.

Вместе с тем, концепция MDA критикуется, поскольку, по меткому замечанию Мартина Фаулера, мода на перспективные технологии программирования постоянно меняется.

Ивар Якобсон (12. 12. 2005): “Сегодня все мы уже фактически ведем разработку на базе моделей.

Но то, что предлагает OMG, — сделать модель анализа формальной, выполняемой и автоматически трансформируемой в модель, отражающую Ивар Якобсон, выдающийся специфику платформы, на самом деле реализовать программист, ученый, очень сложно” [16].

бизнесмен.

С 1995–2003 вицеМартин Фаулер (12. 06. 05): "...Пока не президент Rational Software. Автор существует никаких стандартов для определения трио архитектуры "схема, редактор и генератор". Создав язык в какомкомпонентов, соавтор UML, “visioner либо языковом инструментарии, вы тут же попадаете в зависимость от него. Раз нет никаких стандартных способов обмена данными между разными языковыми инструментария, значит, при переходе на другой языковой инструментарий, придется создавать заново и схему, и редактор, и генератор. Может быть, с течением времени возникнет некий специальный вид хранения данных – специально для таких случаев. Однако если этого не случится, то риск зависимости от поставщика инструментария будет весьма большим.

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 16 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.