Архитектура, управляемая моделью (курсовая), страница 5
Описание файла
PDF-файл из архива "Архитектура, управляемая моделью (курсовая)", который расположен в категории "". Всё это находится в предмете "распределённые ис и базы данных" из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве НИУ «МЭИ» . Не смотря на прямую связь этого архива с НИУ «МЭИ» , его также можно найти и в других разделах. Архив можно найти в разделе "курсовые/домашние работы", в предмете "распределённые ис и базы данных" в общих файлах.
Просмотр PDF-файла онлайн
Текст 5 страницы из PDF
Всякий раз, когда часть бизнеса-процессаподдерживается программной системой, пишется программная модель этойсистемы. Эта модель - описание системы программного обеспечения. Можносделать вывод о том, что бизнес-модели и модели программных системописывают совершенно разные в реальной жизни системы.Однако, требования к программной системе часто вытекают из бизнесмодели, которую должно поддерживать разрабатываемое программноеобеспечение. Для большинства бизнес-моделей существует множество27программных систем.
Каждая система используется для поддержания какойлибо части главной бизнес-модели. Таким образом, есть отношение междубизнес-моделью и моделями программных систем, поддерживающих бизнеспроцессы.Тип системы, описанной моделью, очень важен для процессапреобразования. CIM – это модель, совершенно не зависящая отпрограммногообеспечения.Онаописываеттолькобизнес-процесс.Отдельные части CIM могут поддерживаться системами программногообеспечения, но сама CIM остается независимой. Автоматическая получениеPIM из CIM не возможно, потому что составление списка частей CIM,которые должны отражаться в программной системе, всегда остается зачеловеком. Для каждой части CIM, поддерживаемой системой, сначаладолжна быть разработана PIM [9].Структурные и динамические моделиВ UML, например, диаграмму классов считают структурной моделью, адиаграмму состояний -динамической моделью, в то время как вдействительности диаграмма классов и диаграмма состояний настолькозависят друг от друга, что они должны быть расценены как часть одной и тойже модели.Факт, что моделирование программного обеспечения начинается ссоздания диаграммы классов, не означает, что разрабатывается лишь моделькласса.
В этом случае при разработке программной модели определяютсястатическиеаспектыпосредствомстатичногопредставления.Иногдаразработка начинается с создания динамической схемы, такой как схемасостояний или переходов. В этом случае определяются динамическиеаспекты посредством динамического представления. Позже, например, когдадиаграмма состояний добавляется диаграмме классов, мы просто добавляемдинамические аспекты к той же самой модели, или наоборот.
Поэтому, общаятерминология немного неверна. Диаграммы классов и диаграммы состояний28лучше называть структурными и динамическими представлениями. Нарисунке показано, как различные схемы в UML являются представлениямиодной и той же модели.ВUMLсуществуетпрямаясвязьмеждустатическимиидинамическими представлениями, потому что они отражают один и тот жеобъект на разных уровнях визуализации. Например, класс в UML-моделивыглядит как прямоугольник с именем класса в режиме «Представлениекласса», в то время как тот же класс выглядит как тип экземпляра в схемепоследовательности. Схемы всех видов описывают один и тот же объект.Система может иметь и структурный, и динамический аспекты.
Еслииспользуемый язык способен отразить оба аспекта, есть возможностьспроектировать полнуюмодель системы. Примером такого языка можетслужить UML.Если структурные и динамические аспекты не могут быть описаны водной модели, потому что используемый язык не в состоянии отразить обааспекты, естественно возникает надобность в двух разных моделях. Отметим,что обе модели связаны; они описывают одну и ту же систему. Тип модели в29таком случае может более понятно определен исследованием языка. Рисунокпоказывает ситуацию, где две различных модели, описывающие одну и ту жесистему, записаны на двух различных языках.Можно сделать вывод о том, что аспект, описанный в диаграмме илимодели, не обязательно связан с типом модели.
Существенная характеристикамодели - язык, на котором записана модель. Некоторые языки являются болеевыразительными, чем другие и более подходящими для того, чтобыпредставить определенные аспекты системы [10].Платформо-независимые и зависимые моделиСуществуетнесколькоопределенийPIMиPSMмоделей.Вдокументации OMG эти модели кардинально отличаются. Модель можетбыть либо PIM, либо PSM. В реальности очень сложно провести черту,30разделяющую эти два типа моделей. Единственное, что можно сказать, этото, какая из них более зависима от платформы.
В рамках MDA модели менеезависимые от платформы трансформируются в более зависимые отплатформы модели. Поэтому понятия PIM и PSM сильно связаны [9].ПреобразованиеВыше было рассказано, какие роли в концепции MDA играют PIM,PSM и код. Инструменты преобразования переводят PIM в одну илинесколько PSM. Следующий инструмент преобразовывает PSM в конечныйкод. Эти преобразования естественны для процесса MDA. На рисунке ранееинструмент трансформации был показан как «черный ящик». Входнымиданными является модель одного типа, выходными – модель другого типа иликод.
При более пристальном рассмотрении инструмента преобразованияможно увидеть элементы, которые принимают участие в самом процессепреобразования. Где-то внутри записаны правила, по которым происходиттрансформация.Важнопониматьразличиемеждунепосредственнопроцессомпреобразования, который состоит в генерации одной модели из другой, иправилами преобразования. Инструмент трансформации использует одни и теже правила для любой входной модели.Правила задают связи между конструкциями исходного языка и языка,на котором описана выходная модель. Например, можно задать правила31преобразования из UML в C#.
Они будут описывать, какие конструкции C#будут сгенерированы из разных UML-моделей.В общем случае, правила преобразования – это однозначное описаниеспособа, которым одна модель может быть использована для создания из неедругой. Основываясь на этих наблюдениях, можно дать определенияпреобразованию, описанию преобразования и правилам преобразования.o Преобразование - автоматическая генерация целевой модели изисходной модели согласно описанию преобразования.o Описание преобразования - ряд правил преобразования, которыеописывают, как модель на исходном языке может быть преобразованав модель на выходном языке.o Правило преобразования - описание того, как одна или болееконструкций на исходном языке могут быть преобразованы в одну илиболее конструкций на выходном языке.Чтобы быть работоспособной, преобразование должно обладатьопределеннымихарактеристиками.Самаяважнаяхарактеристика-преобразование должно сохранить соответствие между источником и целевоймоделью.
Значение отдельного элемента модели может быть сохранено,только если оно выражено и в источнике, и в целевой модели. Например,спецификация поведения может быть частью модели UML, но не ER-модели.Даже в этом случае должна быть возможность преобразовать UML-модель вER-модель, сохраняя структурные характеристики системы [9].32Преобразования между идентичными языкамиСказанное выше не помещает ограничений на входные и выходныеязыки. Это означает, что исходная и целевая модели могут быть записанылибо на одном языке, либо на разных. Мы можем определить преобразованияот UML-модели до UML- модели или от Java до Java.Есть несколько примеров таких ситуаций. Метод рефакторинга моделиили части кода (помним, что код также являются моделью) может бытьописан определением преобразования между моделями, описанными наодном и том же языке. Другой известный пример - нормализация ER-модели.Есть четко определенные правила нормализации, которые могут бытьприменены много раз на различных ER-моделях с ожидаемым корректнымрезультатом.
Например, правило нормализации, которое приводит модель ковторой нормальной форме:o переместить все атрибуты объекта, которые не зависят от полногоключа этого объекта, к отдельному объекту, сохраняя отношениямежду исходным объектом и заново создаваемым.Это правило может быть применено к любой ER-модели. Оноразбивает одну сущность и ее атрибуты в исходной модели на две сущности,их атрибуты и отношения между ними в результирующей модели, где обемодели написаны на ER-языке.В случае преобразований между UML-моделями нужно быть особенноаккуратным. Очень часто цели, которые выполняют исходная и целеваямодели кардинально отличаются [9].33Основы фреймворка MDAКак было сказано ранее, модель – это описание системы.o PIM-модель – это платформо-независимая модель, описывающаясистему без каких-либо знаний о конечной платформе, на которойбудет размещена созданная система.o PSM-модель – это платформо-зависимая модель, которая описываетсистему с точки зрения знаний о том, на какой платформе будетразмещена система.Модель должна быть написана на хорошо определенном языке.Описание преобразования показывает, как модель на исходном языкеможет быть преобразована в модель на результирующем языке.Инструмент преобразования выполняет преобразование исходноймодели, основываясь на описании преобразования.С точки зрения разработчика самыми важными элементами являютсяPIM и PSM.
Разработчик фокусируется на создании PIM, описывая системуна высоком уровне абстракции. На следующем этапе выбирается инструментпреобразования, способный провести трансформацию разработанной PIM34согласно какому-либо описанию преобразования. В результате получаетсяPSM, которая в дальнейшем может быть преобразована в код.На рисунке выше показана только одна PSM, но в то же время из однойPIM можно получить несколько PSM с готовыми мостами между ними.В зависимости от уровня детализации платформы, модели (кроме моделиплатформы) могут содержать сведения о различных функциональных частяхсистемы. В этом случае говорят об уровнях модели.
Обычно различаютследующие основные уровни модели [11].35Этапы разработкиПроцесс разработки разбивается на три этапа.Первый этапНа первом этапе разрабатывается вычислительно-независимая модель(CIM). Часто модель, создаваемую на этом этапе, также называют доменнойили бизнес-моделью. Цель данного этапа разработка общих требований ксистеме, создание общего словаря понятий, описание окружения, в которомсистема будет функционировать. Сущности, описываемые в модели CIMэтого этапа, должны тщательно анализироваться и отрабатываться. Право навключение в модель должны иметь только те элементы, которые будутиспользованы и развиты на последующих этапах разработки. Для созданиямодели CIM на данном этапе можно использовать любые средства.