МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ГОУ ВПО Пермский государственный университет УТВЕРЖДАЮ Ректор ГОУ ВПО ПГУ _____________ /И.Ю. Макарихин/ «___»_____________2010 г. м.п. РЕКЛАМНО-ТЕХНИЧЕСКОЕ ОПИСАНИЕ Инструментальное средство создания визуальных динамически настраиваемых предметно-ориентированных языков моделирования MetaLanguage .02069071.00243-01 99 01 Листов 31 Разработчики: ______________________/Сухов А.О./ ______________________/ Лядова Л.Н./ 19.11.2010> Пермь 2010 2 .02069071.00243-01 99 01 1. Функциональное назначение программы, область ее применения, ее ограничения 1.1. Назначение программы Система MetaLanguage предназначена для создания визуальных динамически настраиваемых предметно-ориентированных языков моделирования [7]. Языки моделирования, описанные с помощью MetaLanguage позволяют разработчикам в терминах предметной области создавать графические модели разрабатываемых приложений. Описание языков может быть настроено на меняющиеся условия эксплуатации и потребности пользователя без перегенерации кода системы. MetaLanguage состоит из двух компонентов: метаязык для описания языков моделирования и инструментальная среда разработки – визуальная надстройка над метаязыком. 1.2. Область применения программы С течением времени и увеличением числа требований к адаптируемым информационным системам (ИС) их разработка становится все более сложной. Главная проблема при этом состоит в том, что не существует единого языка, который позволил бы разделить процесс создания системы на отдельные части. Для создания ИС разработчику приходится использовать множество языков: языки программирования общего назначения для того, чтобы написать логику приложения, XML для передачи данных между компонентами приложения, SQL для создания запросов к базе данных (БД) и т.п. Кроме того, ни один из этих языков не оперирует привычными для пользователя терминами предметной области, а это часто бывает необходимо, поскольку при разработке ИС приходится прибегать к помощи экспертов в проблемной области, в которой будет функционировать система, и, как правило, такие эксперты не имеют представления о каких-либо языках программирования. Тот факт, что для разработки ИС используется сразу несколько различных языков говорит о том, что необходимо создавать метаязык, позволяющий описывать другие языки моделирования. Использование метаязыка значительно облегчит процесс разработки ИС и предоставит ряд преимуществ [2, 5, 6, 9]: появляется возможность настройки языка без перегенерации программного кода системы; при этом пользователь может самостоятельно определять собственный язык для создания ИС или изменять уже существующие языки; пользователь получает возможность работы в привычных для него терминах предметной области; языки могут переиспользоваться в схожих проектах, благодаря возможности экспорта/импорта описаний языка; 3 .02069071.00243-01 99 01 появляется возможность интеграции нескольких предметноориентированных языков в одной системе, что предоставляет возможность создания систем, работающих на стыке предметных областей; созданные языки обладают высокой степенью согласованности с метаязыком, все языки и модели всегда находятся в актуальном состоянии. Таким образом, визуальные динамически-настраиваемые предметноориентированные языки, созданные с помощью системы MetaLanguage могут интегрироваться в ИС, работающие в различных областях: имитационное моделирование, описание бизнес-процессов, моделирование приложений для сотовых телефонов и др. Созданием метамоделей, т.е. моделей языков моделирования, должен заниматься администратор системы, имеющий навыки разработки визуальных языков моделирования. Настраивать языки на меняющиеся условия эксплуатации и потребности пользователя, описывать модели предметной области могут бизнес-аналитики – непрофессиональные программисты. 1.3. Ограничения использования программы Для функционирования приложения необходимо наличие .NET Framework (распространяется бесплатно), СУБД (Microsoft SQL Server Express, распространяется бесплатно), Trial-версия графического компонента FlowChart (распространяется бесплатно). 2. Техническое описание программы 2.1. Структура разрабатываемой системы Для работы с объектами метаязыка спроектирована среда разработки, которая включает следующие компоненты (см. рис. 1): графический редактор; браузер объектов; репозитарий; валидатор. Среда разработки – это реализация общих сервисных функций создаваемой системы. Она обеспечивает интеграцию всех компонентов в единое целое. Среда включает в себя главное меню и панель инструментов с функциями создания/изменения/удаления объектов и всего проекта, настройки графических параметров: цветов, шрифтов, толщины линий и пр. Рассмотрим описание каждого из компонентов инструментальной среды подробнее. 4 .02069071.00243-01 99 01 Среда разработки Графический редактор Объекты предметной области Пользователь Браузер объектов Данные Репозитарий Валидатор Документация Генератор XML-файл Рис. 1. Архитектура системы MetaLanguage 2.1.1. Графический редактор Графический редактор – представляет собой рабочую область для рисования диаграмм. С его помощью пользователь может создавать сущности и отношения между ними, определять их атрибуты. Графический редактор предоставляет пользователю возможность располагать на рабочем листе различные фигуры (экземпляры конструкций языка), применять к этим фигурам наборы операций (наполнение текстом, растягивание/сжатие, перемещение, соединение друг с другом линиями и т.д.), задания для них различных графических свойств (выбор толщины линий, цвета, свойств шрифтов). 2.1.2. Браузер объектов Браузер – инструментальное средство, предназначенное для просмотра и редактирования информации, хранящейся в репозитарии. Используя браузер, пользователь может получить доступ ко всем объектам репозитария: метамоделям, моделям, созданным с помощью текущей метамодели, сущностям, отношениям, а также к их атрибутам. Кроме того, браузер позволяет создавать связи между различными моделями. Браузер предоставляет возможность экспорта/импорта моделей из других систем. В качестве формата для экспорта/импорта моделей был выбран XML, 5 .02069071.00243-01 99 01 поскольку данный формат является общепринятым стандартом передачи структурированных данных между разными системами обработки информации, кроме того, XML-файл содержит в себе метаданные, которые описывают структуру содержащейся в нем информации. В настоящее время большинство систем поддерживает возможность интерпретации XML-формата файлов. MetaLanguage предоставляет в распоряжение пользователя четыре вида браузеров: браузер метамодели, который позволяет пользователю просматривать и редактировать все объекты метамодели; браузер модели, оперирующий объектами модели; с помощью браузера объектов пользователь может работать с атрибутами сущностей и отношений модели. браузер типов позволяет просматривать существующие типы сущностей, создавать новые, выполнять операции над доменами допустимых значений. 2.1.3. Репозитарий Единым хранилищем всей информации о системе является репозитарий. Он содержит информацию о моделях, сущностях, отношениях, атрибутах, ограничениях, пиктограммах, используемых для отображения сущностей и отношений. Репозитарий хранит информацию как о моделях, так и о метамоделях единообразно. При внесении изменений в метамодель они будут отражены и во всех моделях, созданных на ее основе. Это позволяет гарантировать согласованность метамоделей и моделей. Физически репозитарий представляет собой БД, схема которой приведена в Приложении 1. БД репозитария может находиться как на локальном компьютере, так и на удаленном. Репозитарий может работать в многопользовательском режиме. При этом для согласования действий пользователя при изменении БД используется механизм транзакций. То есть, если один из пользователей в определенный момент времени изменяет какую-либо информацию в БД, то доступ к этой информации для других пользователей закрыт. Как только первый пользователь подтвердит транзакцию, то все остальные пользователи смогут получить доступ уже к обновленной информации. Таким образом достигается актуальность и согласованность информации, хранимой в БД. Кроме того, механизм транзакций используется для отмены всех изменений произведенных над моделью. При начале работы с моделью, для каждого пользователя создается сессия, с которой связана отдельная транзакция. Если пользователь после окончания работы не хочет сохранять изменения, то транзакция будет отменена, в результате чего никаких изменений в БД внесено не будет. 6 .02069071.00243-01 99 01 2.1.4. Валидатор Валидатор проверяет соответствие модели ограничениям, заданным пользователем. При выполнении проверки каждое ограничение будет применено к каждой сущности и отношению. В случае если ограничения не выполняется, будет выдано сообщение об ошибке. 2.1.5. Генератор Генератор позволяют на основе имеющихся моделей сгенерировать XMLфайл или документацию модели. XML-файл будет содержать информацию о модели: свойства модели, сущности, отношения, их атрибуты, наложенные на модель ограничения. Документация модели включает в себя: название модели, информацию о разработчиках, которые принимали участие в ее создании, графическое представление модели со ссылками на описание отдельных ее частей. 2.2. Принципы функционирования программного продукта Базовыми элементами метаязыка системы MetaLanguage являются: сущность, отношения, ограничения. Используя эти элементы, пользователь может описывать конструкции создаваемых языков моделирования [1, 3]. Рассмотрим базовые элементы более подробно. 2.2.1. Сущность Сущность – это какая-либо конструкция создаваемого языка моделирования. Сущности характеризуются именем, однозначно идентифицирующим сущность в рамках метамодели; количеством экземпляров сущности, которое может быть создано при построении модели; набором атрибутов сущности; набором операций над сущностью; набором ограничений, накладываемых на сущность; флагом уникальности, определяющим пределы уникальности имен экземпляров сущности. Рассмотрим некоторые из этих свойств более подробно. Количество экземпляров сущности определяет, сколько экземпляров данной сущности может быть создано при построении модели. Количество экземпляров задается целым числом из интервала [0, ). Если значение этой характеристики сущности равно нулю, то это означает, что при создании модели данный тип сущности не будет указан в списке сущностей, предлагаемых для создания. Если значение характеристики равно бесконечности, то допускается создание произвольного числа экземпляров сущности данного типа. Атрибут – это именованное свойство сущности, включающее описание множества значений, которые могут принимать экземпляры этой сущности. Атрибут имеет 7 .02069071.00243-01 99 01 имя, которое уникальным образом идентифицирует его в рамках данной сущности; тип, определяющий множество значений, которые может принимать атрибут, а также набор допустимых над атрибутом операций; значение по умолчанию, которое будет выбрано в качестве основного значения атрибута, если последнее не задано; описание, которое содержит некоторую дополнительную информацию об атрибуте. Сущность может иметь любой число атрибутов, либо не иметь их вовсе. В качестве типа атрибута может выступать домен допустимых значений, либо некоторая сущность метамодели. Операция – это абстракция действий, которые можно выполнять над сущностью. В большинстве случаев применение операции приводит к тому, что сущность меняет свое состояние. Операция включает в себя: имя, которое однозначно определяет операцию в рамках данной сущности; параметры операции; значения по умолчанию для параметров, которые в случае отсутствия основных значений будут использоваться при вызове операции; тип возвращаемого значения; описание, содержащее дополнительную информацию об операции. Сущность может иметь произвольное число операций либо не иметь их вовсе. Рассмотрим примеры сущностей. На рис. 2 приведен фрагмент метамодели диаграмм прецедентов UML. Метамодель содержит две сущности «Актор» и «Прецедент». Рис. 2. Фрагмент метамодели диаграмм прецедентов UML Сущность «Прецедент» имеет следующие атрибуты: «Имя», «Актор», «Описание», «Дата создания». Атрибут строкового типа «Имя» определяет название прецедента. Атрибут «Актор» имеет в качестве своего типа ссылку на сущность «Актор», поэтому при создании экземпляра сущности «Прецедент» в 8 .02069071.00243-01 99 01 качестве значения этого атрибута необходимо выбрать один из экземпляров сущности «Актор». Атрибут «Описание» содержит описание прецедента. Над сущностью «Прецедент» допустимо выполнение следующих операций: «Изменить()», «Задать актора()», «Установить дату()». Операция «Изменить()» задает значение атрибута «Описание», операция «Задать актора()» изменяет значение атрибута «Актор», используя операцию «Установить дату()» можно задать дату создания прецедента. Атрибутом сущности «Актор» являются строковый атрибут «Имя», которое задает имя актора. Допустимой операцией над сущностью «Актор» является «Связать с прецедентом()», в результате выполнения которой будет создано новое отношение между текущим экземпляром сущности «Актор» и заданным экземпляром сущности «Прецедент». 2.2.2. Отношения Конструкции визуальных языков в редких случаях существуют автономно, чаще всего они каким-либо образом взаимосвязаны друг с другом, поэтому при создании метамодели важно не только определить основные конструкции создаваемого языка, но и правильно задать связи между ними. Отношение используется для обозначения физической или концептуальной связи между сущностями. Любое отношение характеризуется именем, которое однозначно задает отношение в рамках данной модели; кратностью, которая определяет, сколько экземпляров сущности может участвовать в отношении; флагом уникальности, определяющим пределы уникальности имен экземпляров отношений; ограничениями, накладываемыми на отношение. В метамодели выделяются следующие виды отношений: наследование, ассоциация, агрегация. Рассмотрим каждый вид отношений более подробно. 2.2.2.1. Наследование Наследование – это отношение между общим объектом (суперклассом, родителем) и конкретным объектом (подклассом, потомком). Потомок наследует все атрибуты и операции родителя. Помимо родительских, он может иметь и свои собственные атрибуты и операции. Поэтому объект-потомок может использоваться всюду, где используется объектродитель, но обратное утверждение в общем случае не верно. Объект может иметь лишь одного родителя и неограниченное число потомков, т.е. кратность такого отношения 1:М. Как уже говорилось ранее, при создании сущности задается количество ее экземпляров, которое определяет, сколько экземпляров сущности может быть создано в модели. Абстрактной называется сущность, которая не имеет экземпляров и в построении метамодели не участвует. Чаще всего абстрактные сущности играют роль родителей и используется для простоты модификации метамодели и наглядности. 9 .02069071.00243-01 99 01 Рис. 3. Фрагмент метамодели диаграмм «Сущность-Связь» На рис. 3 представлен фрагмент метамодели диаграмм «Сущность-Связь». Метамодель содержит сущности: «Абстрактный класс», «Атрибут», «Связь», «Сущность». Для сокращения диаграммы на рисунке не представлены допустимые над сущностями операции. Атрибутами сущности «Абстрактный класс» являются «Имя», идентифицирующее экземпляр сущности и «Описание», содержащее дополнительную информацию об экземпляре сущности. Сущность «Атрибут» имеет следующие атрибуты: «Имя», «Тип», «Ограничения», «Описание». Атрибут «Ограничения» определяет ограничения целостности, задаваемые на атрибут в ERD-модели. Сущность «Абстрактный класс» является абстрактной, т.е. при создании модели экземпляры этой сущности создать невозможно. Сущность «Абстрактный класс» выступает в роли родителя для сущностей «Сущность» и «Связь» (на рисунке это изображено стрелкой с треугольным наконечником). Обе дочерние сущности наследуют все атрибуты и операции родительской, дополнительных атрибутов эти сущности не имеют. 10 .02069071.00243-01 99 01 2.2.2.2. Ассоциация Ассоциация – это структурное отношение, определяющее, что сущности одного типа некоторым образом связаны с сущностями другого типа. Если между двумя сущностями задана ассоциация, то можно перемещаться от экземпляров одной сущности к экземплярам другой. Ассоциация является двунаправленной и может быть проведена в любом направлении. Является допустимым случай, когда оба конца ассоциации принадлежат одной сущности. Это означает, что некоторый экземпляр сущности может быть связан с другим экземпляром этой же сущности. Помимо описанных ранее базовых характеристик отношений, существует дополнительная, применяемая лишь к ассоциации – роль. Сущности, связанные ассоциацией, играют в ней определенную роль. Роль – это имя, которое уникальным образом идентифицирует один из концов ассоциации. В ассоциации может участвовать произвольное число экземпляров сущности как с одной, так и с другой стороны, т.е. в общем случае кратность этого отношения М:М. По числу сущностей, участвующих в ассоциации, выделяют бинарные, тернарные и ассоциации более высокого порядка. Бинарная ассоциация – это ассоциация, в которой участвуют две сущности. Тернарная ассоциация соединяет три сущности. Чаще всего ассоциации, имеющие порядок больше двух, являются атомарными единицами и не могут быть разделены на бинарные ассоциации без потери информации. На рис. 3 представлены две ассоциации, которые изображены в виде неориентированных дуг. Первая из них соединяет сущности «Связь» и «Сущность», это говорит о том, что в ERD-моделях между экземплярами этих сущностей можно провести равноправную связь. Вторая ассоциация связывает сущность «Сущность» с самой собой, это позволяет в ERD-моделях любому экземпляру «Сущности» иметь суперкласс, т.е. родительскую «Сущность». 2.2.2.3. Агрегация Агрегация – это вид ассоциации, который моделирует неравноправное отношение типа «часть-целое». Основным отличием агрегации от простой ассоциации является то, что последняя отражает отношение между двумя равноправными сущностями, в то время как в агрегации одна из сущностей – главная, а другая – зависимая. Отличительными чертами агрегации также является и то, что этот вид отношения всегда является ориентированным, его кратность – 1:М, а концы не могут принадлежать одной сущности. В метамодели, представленной на рис. 3, между сущностями «Абстрактный класс» и «Атрибут» установлено отношение агрегации (на диаграмме этот вид отношений представлен дугой с наконечником в виде ромба). В результате чего в ERD-моделях экземпляры сущностей «Сущность» и «Связь» могут быть соединены агрегацией с экземплярами сущности «Атрибут». При этом при удалении экземпляров сущностей «Сущность» и «Связь», автоматически будут удалены все принадлежащие им «Атрибуты». 11 .02069071.00243-01 99 01 2.2.3. Ограничения На практике достаточно часто встречаются случаи, когда на сущности и связи между ними накладываются некоторые ограничения. Если правила соединения диаграмм задают синтаксис визуального языка, то ограничения определяют его семантику. Часть ограничений задается через структуру метамодели, а часть через непосредственное их задание на некотором языке, например OCL. Все ограничения, накладываемые на метамодель можно разделить на две группы: ограничения, накладываемые на сущности, и ограничения, накладываемые на отношения. Проведем детальное рассмотрение каждой из этих групп. 2.2.3.1. Ограничения, накладываемые на сущности Ограничения, накладываемые на сущности могут быть одного из следующих видов: ограничения на уникальность имени экземпляра сущности; ограничения на количество экземпляров сущности в модели; ограничения на значения атрибутов экземпляров сущности. Имя экземпляра сущности может быть уникальным в рамках метамодели, в рамках модели либо быть не уникальным. Уникальность в рамках метамодели означает, что во всех моделях, созданных на основе этой метамодели имя экземпляра сущности встретиться всего лишь один раз. Ограничение такого вида следует задать на сущность «Прецедент» метамодели диаграмм прецедентов UML, если необходимо указать, что все экземпляры сущности «Прецедент» должны быть уникальными во всех моделях. Уникальность в рамках модели означает, что имя экземпляра сущности будет уникальным лишь в рамках той модели, которой эта сущность принадлежит. Примером такого ограничения может служить условие на уникальность имени сущности «Актор» в рамках конкретной модели диаграммы прецедентов UML. Ограничение на количество экземпляров сущности в модели задается указанием количества экземпляров при создании сущности. Так экземпляры абстрактных сущностей, имеющих значение свойства «количество» равное нулю, не будут участвовать при построении модели. Если значение этого свойства равно единице, то в модели можно создать лишь единственный экземпляр сущности этого типа. Примером ограничения такого вида может служить условие, ограничивающее количество экземпляров сущности «Прецедент» величиной пять, это позволит создавать понятные диаграммы, не загроможденные большим числом «Прецедентов» и «Акторов». Наиболее важными с точки зрения задания семантики визуального языка являются ограничения, накладываемые на значения атрибутов сущности. Поскольку ограничения задаются на сущности в метамодели, то они будут применены ко всем экземплярам сущностей данного типа. Такие ограничения задаются в виде троек: <Имя атрибута> <Знак> <Значение>. 12 .02069071.00243-01 99 01 Здесь в роли «значения» может выступать константа, значение атрибута какого-либо экземпляра сущности модели либо некоторая функция над значениями атрибутов экземпляров сущностей. Так, например, в метамодели диаграмм прецедентов ограничение этого типа может быть наложено на атрибут «Дата создания» сущности «Прецедент», поскольку она не может превышать текущей даты. Тогда такое ограничение может иметь вид: Дата создания <= Now(). 2.2.3.2. Ограничения, накладываемые на отношения Все ограничения, накладываемые на отношения можно разделить на следующие группы: ограничения на уникальность имени экземпляра отношения; ограничения на типы соединяемых отношением экземпляров сущностей; ограничение на кратность отношений; ограничения на значения атрибутов соединяемых экземпляров сущностей. Ограничения на уникальность имени экземпляра отношения аналогично ограничениям на уникальность имени экземпляра сущности и могут принимать одно из значений: уникально в рамках метамодели, уникально в рамках модели, неуникально. Ограничения на типы соединяемых отношением экземпляров сущности определяются структурой метамодели. Эти ограничения задают правила соединения экземпляров сущностей различных типов. Так, например, на рис. 2 отсутствуют ассоциации, концы которых совпадают, это означает, что между двумя экземплярами сущности «Прецедент» и двумя экземплярами сущности «Актор» создать связь нельзя. Ограничения на кратность отношений задаются при их создании. Так отношение наследования и агрегация допускает в общем случае лишь кратность 1:М, которая может быть уточнена изменением кратности лишь для второй сущности. Ассоциация допускает кратность М:М с возможностью ее уточнения. Если в моделях диаграмм прецедентов необходимо указать, что число «Акторов», связанных с «Прецедентом» не может быть больше пяти, то при создании ассоциации между сущностями «Прецедент» и «Актор» необходимо установить кратность «М:1..5». Ограничения на значения атрибутов соединяемых экземпляров сущностей несут на себе наибольшую семантическую нагрузку. Отличие этих ограничений от ограничений, накладываемых на значение атрибутов экземпляров сущности, состоит в том, что ограничения первого типа позволяют задать конкретные экземпляры сущностей, на которые накладываются ограничения. Ограничение такого вида может быть задано на значения атрибута «Дата рождения» соединяемых сущностей «Человек» при построении метамодели «Генеалогическое дерево», поскольку даты рождения родителей не могут превышать даты рождения ребенка. 13 .02069071.00243-01 99 01 2.3. Процесс создания предметно-ориентированных языков с помощью системы MetaLanguage Описав основные конструкции метаязыка, перейдем к рассмотрению того, каким образом в системе MetaLanguage описываются визуальные предметноориентированные языки моделирования. Процесс создания языка начинается с построения его метамодели. Для этого необходимо задать его основные конструкции, определить отношения между ними, задать ограничения, накладываемые на сущности и отношения метамодели. После построения метамодели разработчик получает в распоряжение расширяемый настраиваемый визуальный предметноориентированный язык моделирования. Используя полученный язык моделирования, пользователь может создавать модели, содержащие объекты, описывающие конкретные сущности предметной области и связи между ними. После построения модели необходимо проверить удовлетворяет ли она ограничениям, которые были на нее наложены. Для этого необходимо выполнить валидацию созданной модели. Если какие-либо из ограничений не выполняются, то пользователь будет проинформирован об этом. Созданные модели могут использоваться в конкретной реализации ИС, либо быть экспортированы в другую систему. Таким образом, процесс создания нового предметно-ориентированного языка можно представить схемой, изображенной на рис 4. 14 .02069071.00243-01 99 01 Создание/модификация метамодели Создание конструкций языка Задание отношений между конструкциями Задание ограничений на объекты метамодели Создание/модификация модели Создание сущностей предметной области Задание отношений между сущностями Валидация Проверка ограничений, накладываемых на сущности Проверка ограничений, накладываемых на отношения Генерация Сохранение моделей в XML Генерация документации на основе моделей Рис. 4. Процесс создания/модификации языка предметной области с помощью системы MetaLanguage Заметим, что модификация метамодели может производиться на любом этапе создания языка. При этом после внесения изменений в метамодель система автоматически внесет все необходимые изменения в модели, созданные с помощью этой метамодели. Таким образом, все языки и модели всегда находятся в актуальном состоянии. 2.4. Логика работы системы MetaLanguage Рассмотрим логику работы системы. Наибольший интерес представляют операции открытия, изменения и удаления метамодели, поскольку при этом необходимо производить аналогичные операции и над всеми моделями, созданными на основе этой метамодели. Также будет рассмотрена процедура проверки ограничений, накладываемых на сущности и отношения метамоделей. 15 .02069071.00243-01 99 01 2.4.1. Открытие существующей метамодели При открытии метамодели из репозитария будут загружены все модели, созданные с помощью этой метамодели, все сущности, отношения метамодели и соответствующих моделей. Алгоритм открытия метамодели представлен на рис. 5. foreach (сущность in открываемая_метамодель) { Загрузить_атрибуты(сущность); Загрузить_операции(сущность); Загрузить_ограничения(сущность); } foreach (отношение in открываемая_метамодель) { Загрузить_атрибуты(отношение); Загрузить_ограничения(отношение); } foreach (модель in открываемая_метамодель) { foreach (экземпляр_сущности in модель) Загрузить_значения_атрибутов(экземпляр_сущности); foreach (экземпляр_отношения in модель) Загрузить_значения_атрибутов(экземпляр_отношения); } Рис. 5. Алгоритм открытия метамодели 2.4.2. Удаление объектов метамодели При удалении сущности необходимо 1. найти все экземпляры этой сущности во всех моделях, созданных с помощью метамодели, которой принадлежит удаляемая сущность; 2. для каждого из экземпляров сущности удалить все отношения, связанные с ним; 3. для каждой удаляемой сущности метамодели удалить из репозитария информацию обо всех отношениях, связанных с ней. 4. удалить сущность: удалить все ее атрибуты, операции, ограничения. При удалении отношения необходимо 1. найти все экземпляры отношения во всех моделях, созданных на основе изменяемой метамодели и удалить их; 2. удалить текущее отношение: удалить все его атрибуты и ограничения. 16 .02069071.00243-01 99 01 При удалении метамодели необходимо удалить все модели, созданные на ее основе, при этом удаление сущностей и отношений выполняется описанными выше способами. 2.4.3. Изменение метамодели При внесении изменений в метамодель для поддержания системы в согласованном состоянии необходимо внести все произведенные изменения и в зависимые от нее модели. При изменении сущности (отношения) необходимо во всех моделях, созданных на основе изменяемой метамодели, найти все экземпляры сущностей (отношений) данного типа и изменить их. Таким образом, алгоритм изменения сущности метамодели на псевдокоде может быть записан в виде: if (изменяемая_сущность.модель.созданные_модели != NULL) foreach (модель in изменяемая_сущность.модель.созданные_модели) foreach (экземпляр_сущности in модель) if (экземпляр_сущности.тип == изменяемая_сущность) Изменить_сущность(экземпляр_сущности); Изменить_сущность(изменяемая_сущность); Рис. 6. Алгоритм изменения модели При изменении ограничений, которые проверяются при создании объектов, необходимо проверить измененные ограничения для уже созданных объектов и выдать сообщение об ошибках, если они не выполняются. 2.4.4. Проверка ограничений Некоторые виды ограничений проверяется при создании сущностей и отношений, другие – непосредственно после создания модели. Рассмотрим проверку каждого из видов ограничений более подробно. Проверка ограничений на значения атрибутов экземпляров сущности происходит по окончании создания модели. При этом ограничения, наложенные на каждую сущность метамодели, будут проверены для всех экземпляров соответствующих сущнестей. Алгоритм проверки ограничений на псевдокоде представлен на рис. 7. foreach (сущность in модель.метамодель) foreach (ограничение in сущность) foreach (экземпляр_сущности in сущность.экземпляры_сущности(модель)) if (Ограничение_не_выполняется(ограничение, экземпляр_сущности)) Выдать_сообщение_об_ошибке(); Рис. 7. Алгоритм проверки ограничений на значения атрибутов экземпляров сущности Уникальность имени сущности проверяется непосредственно при ее создании. При этом в случае, если задано ограничение «уникально в рамках 17 .02069071.00243-01 99 01 метамодели», то будут просмотрены все экземпляры сущности во всех моделях, построенных на основе данной метамодели. Если значением свойства является «уникально в рамках модели», то достаточно просмотреть все экземпляры сущности текущей модели. Таким образом, алгоритм проверки уникальности имени экземпляра сущности на псевдокоде можно представить в виде: switch (новая_сущность.уникальность) { case “уникально в рамках метамодели”: foreach (модель in новая_сущность.модель.метамодель) foreach (сущность in модель) if (сущность.имя == новая_сущность.имя) { Выдать_сообщение_об_ошибке(); break; } Создать_сущность(новая_сущность); break; case “уникально в рамках модели”: foreach (сущность in новая_сущность.модель) if (сущность.имя == новая_сущность.имя) { Выдать_сообщение_об_ошибке(); break; } Создать_сущность(новая_сущность); break; case “неуникально”: Создать_Сущность(новая_сущность); break; } Рис. 8. Алгоритм проверки уникальности имени сущности Ограничения на количество экземпляров сущности в модели, как и ограничения на уникальность имени экземпляра проверяются непосредственно при создании экземпляра сущности. В случае если, число экземпляров сущностей определенного типа равно числу, указанному при создании сущности, то новый экземпляр создан не будет. Ограничения на уникальность имени экземпляра отношения, проверяются непосредственно при их создании. Алгоритм проверки ограничений этого вида аналогичен алгоритму проверки ограничений на уникальность имени экземпляра сущности, приведенного на рис. 8, с той лишь разницей, что вместо обхода по экземплярам сущностей производится обход по экземплярам отношений. 18 .02069071.00243-01 99 01 Ограничения на типы соединяемых сущностей проверяется при создании экземпляров отношений. Как только пользователь проводит связь между двумя экземплярами сущностей, система определяет тип соединяемых сущностей и проверяет, существует ли в метамодели отношение между сущностями этого типа. Если отношение существует, то система позволит создать связь, в противном случае будет выдано сообщение об ошибке. При проверке ограничения на кратность отношений система для каждого из соединяемых экземпляров сущностей посчитает количество уже созданных экземпляров сущностей данного типа в модели и в случае, если это число будет равно кратности создаваемого отношения, то будет выдано сообщение об ошибке и экземпляр отношения создан не будет. Проверка ограничений на значения атрибутов соединяемых экземпляров сущностей проводится по окончании создания модели. Алгоритм проверки ограничений данного типа представлен на рис. 9. foreach (экземпляр_отношения in модель) foreach (ограничение in экземпляр_отношения) { if (Ограничение_не_выполняется(ограничение, экземпляр_отношения.источник)) Выдать_сообщение_об_ошибке(); if (Ограничение_не_выполняется(ограничение, экземпляр_отношения.приемник)) Выдать_сообщение_об_ошибке(); } Рис. 9. Алгоритм проверки ограничений, накладываемых на значения атрибутов соединяемых экземпляров сущностей 2.5. Объектная модель системы MetaLanguage Описанный выше подход реализован в виде библиотеки классов. Рассмотрим базовые классы, используемые системой MetaLanguage для построения моделей. 19 .02069071.00243-01 99 01 Рис. 10. Спецификация класса Model Основным классом для работы с моделями является класс Model. Его спецификация приведена на рис. 10. Данный класс имеет следующие свойства и методы: Connection – ссылка на соединение с БД; Description – описание модели; FileName – имя файла, в котором хранится графическое представление модели; MetaModelName – имя метамодели, на основе которой создана модель; Models – список моделей того же типа, что и текущая модель; Name – имя модели; Entities – коллекция сущностей модели; Relations – коллекция отношений модели; Load – метод, отвечающий за загрузку модели из БД; Modify – метод, отвечающий за изменение модели в БД; RemoveModel – метод, отвечающий за удаление модели из списка моделей и БД. Экземпляром данного класса может быть как модель, так и метамодель, таким образом, модели и метамодели в системе представляются единообразно. Коллекция сущностей модели описывается классом EntityCollection, спецификация которого приведена на рис. 11. 20 .02069071.00243-01 99 01 Рис. 11. Спецификация класса EntityCollection Класс EntityCollection имеет следующие методы: GetEntity – метод, возвращающий элемент коллекции сущностей по его имени; GetEntityCount – метод, возвращающий число экземпляров сущности, созданных в текущей модели; Load – метод, отвечающий за загрузку коллекции сущностей текущей модели из БД; RemoveEntity – метод, отвечающий за удаление сущности из коллекции и БД. На рис. 12 приведено описание класса Entity, реализующего понятие «Сущность». Рис. 12. Спецификация класса Entity Класс Entity содержит следующие свойства и методы: Attributes – список атрибутов сущности; 21 .02069071.00243-01 99 01 Constraints – список ограничений, накладываемых на сущность; Count – число экземпляров сущности, которое может быть создано в моделях; Description – описание сущности; Name – имя сущности; EntityDrawType – пиктограмма для отображения сущности; Entities – коллекция сущностей модели, которой принадлежит текущая сущность; EntityType – тип сущности; для метамоделей это «Сущность», а для моделей тип определяется сущностями метамодели; Operations – список допустимых над сущностью операций; Values – список значений атрибутов сущности; GetAllRelations – метод, возвращающий список всех отношений сущности; GetInRelations – метод, возвращающий список отношений, для которой данная сущность является приемником; GetOutRelations – метод, возвращающий список отношений, для которой данная сущность является источником; Modify – метод, отвечающий за изменение сущности в БД; SaveToDataBase – метод, отвечающий за сохранение сущности в БД. Рис. 13. Спецификация класса Relation Класс Relation реализует понятие «Отношение» в моделях (см. рис. 13). Данный класс содержит следующие свойства: Constraints – список ограничений накладываемых на отношение; Description – описание отношения; EndEntity – ссылка на сущность-приемник отношения; 22 .02069071.00243-01 99 01 EndEntityMax – максимальное количество экземпляров сущностиприемника отношения; EndEntitytMin – минимальное количество экземпляров сущностиприемника отношения; Name – имя отношения; RelationDrawType – пиктограмма для отображения отношения; Relations – коллекция отношений модели, которой принадлежит текущее отношение; StartEntity – ссылка на сущность-источник отношения; StartEntityMax – максимальное количество экземпляров сущностиисточника отношения; StartEntityMin – минимальное количество экземпляров сущностиисточника отношения; Type – тип отношения. Для метамоделей это может быть: «Агрегация», «Ассоциация», «Наследование». Для моделей тип определяется отношениями метамодели. Методом класса, отвечающим за сохранение отношения в БД, является SaveToDataBase. Класс RelationCollection описывает коллекцию отношений модели (см. рис 14). Рис. 14. Спецификация класса RelationCollection Класс RelationCollection имеет следующие методы: GetRelation – метод, возвращающий элемент коллекции отношений по его имени; Load – метод, отвечающий за загрузку всех отношений текущей модели из БД; RemoveRelation – метод, отвечающий за удаление отношения из коллекции и БД. Понятие «Атрибут» описывается классом Attribute. Спецификация класса приведена на рис. 15. Свойствами и методами класса являются: Default – значение по умолчанию атрибута; Description – описание атрибута; Name – имя атрибута; 23 .02069071.00243-01 99 01 Type – тип атрибута; тип может быть ссылкой на домен допустимых значений или ссылкой на некоторую сущность; SaveToDataBase – метод, отвечающий за сохранение атрибута в БД. Рис. 15. Спецификация класса Attribute Коллекция атрибутов сущности задается классом AttributeCollection. Описание этого класса приведено на рис. 16. Рис. 16. Спецификация класса AttributeCollection Класс AttributeCollection задается следующими методами: GetAttribute – метод, возвращающий элемент коллекции атрибутов по его имени; Load – метод, отвечающий за загрузку коллекции атрибутов текущей сущности из БД; RemoveAttribute – метод, отвечающий за удаление атрибута из коллекции и БД. Класс, спецификация которого приведена на рис. 17, описывает понятие «Ограничение». 24 .02069071.00243-01 99 01 Рис. 17. Спецификация класса Constraint Класс имеет следующие свойства: ErrorMessage – текст сообщения об ошибке, которое будет выдано, если ограничение не выполняется; AttributeName – имя атрибута сущности, на который накладывается ограничение; Sign – знак ограничения; Value – значение атрибута в правой части ограничения. Методом класса, отвечающим за сохранение ограничения в БД, является SaveToDataBase. Коллекция ограничений, накладываемых на сущности и отношения, задается классом ConstraintCollection. Описание этого класса приведено на рис. 18. Рис. 18. Спецификация класса ConstraintCollection Методами класса ConstraintCollection являются: Load – метод, отвечающий за загрузку коллекции ограничений из БД; RemoveConstraint – метод, отвечающий за удаление ограничения из коллекции и БД. 2.6. Применяемые программные средства Реализация предложенного подхода требует выбора подходящих технологий, обеспечивающих выполнение требований, предъявляемым к метаязыку как к средству разработки языков создания корпоративных ИС. 25 .02069071.00243-01 99 01 В силу широко распространения MS Windows для обеспечения работы системы в качестве операционной системы была выбрана именно она. Для выбора программной технологии следует учитывать следующие требования: поддержка принципов открытых систем; возможность переноса на другую аппаратную или программную платформу; высокая надежность кода; расширяемость; компонентная технология. В качестве программной технологии была выбрана .NET Framework. Исходя из выбора операционной системы и программной технологии, следует остановить свой выбор на системах программирования, поддерживающих технологию .NET Framework. Такой системой на сегодняшний день является MS Visual Studio .NET. Эта система способна генерировать высокоуровневый код MSIL, являющийся независимым от аппаратной платформы. Система сочетает в себе три языка программирования, основанных на общей библиотеке типов. Для разработки был выбран язык C#. C# – это фактически гибрид разных языков. При этом C# так же прост, как Visual Basic, и обладает практически той же мощью и гибкостью, что и C++. Для обеспечения адаптируемости и расширяемости, в частности, за счет смены СУБД, желательно обеспечить возможность выбора СУБД. Поэтому интегрированные системы, сочетающие в себе СУБД и системы программирования не подходят, так как впоследствии смена СУБД без перезаписи всего программного кода невозможна. Наиболее распространенными серверными СУБД являются: MS SQL Server – серверная СУБД, имеющая средства OLAP, XML, многомерных БД, хранилищ данные репликации данных, хранимых процедур, хранимых параметризованных запросов, OLE DB провайдера. ORACLE – серверная СУБД, имеющая средства OLAP, XML, многомерных БД, хранилищ данных, репликации данных, хранимых процедур, OLE DB провайдера. Данные СУБД являются примерно равными по возможностям. Но наиболее подходящей является все-таки MS SQL Server, по причине того, что работа ведется с продуктами компании Microsoft и система разработки MS Visual Studio .NET имеет встроенную интеграцию с данной СУБД, но иметь совместимость с ORACLE, для хранения БД, также необходимо. Данная работа написана в рамках проекта создания CASE-технологии METAS. Эта технология базируется на: технологии разработки RUP (Rational Unified Process); технологии разработки XP (eXtreme Programming); инструментальном средстве MDKSuite. 26 .02069071.00243-01 99 01 2.7. Используемые технические средства и требования к аппаратуре Требования к аппаратуре определяются требованиями, соблюдение которых необходимо для установки используемого программного обеспечения. Минимальные требования: процессор Pentium IV, 2048 Мб ОЗУ. 3. Специальные условия применения и требования организационного, технического и технологического характера Для работы с программами нет необходимости создания специальных условий применения и выполнения особых требований организационного, технического и технологического характера. Условия применения и требования определяются требованиями к применяемому программному и аппаратному обеспечению, перечисленными выше, а также выполнением лицензионных соглашений при использовании необходимого для работы программ программного обеспечения. 4. Условия передачи программной документации или ее продажи Продажа и передача программ и программной документации для их использования в каких-либо целях осуществляется с письменного согласия авторов, связаться с которыми можно по адресу sukhov_psu@mail.ru. 27 .02069071.00243-01 99 01 Библиографический список 1. Лядова Л.Н., Сухов А.О. Метаязык построения визуальных языков моделирования // Технологии Microsoft в теории и практике программирования / Материалы конференции. Нижегородский ун-т. Нижний Новгород, 2009. С. 267273. 2. Лядова Л.Н., Сухов А.О. Предметно-ориентированный язык в информационных системах, основанных на метаданных // Технологии Microsoft в теории и практике программирования / Материалы конференции. Нижегородский ун-т. Нижний Новгород, 2008. С. 223-225. 3. Лядова Л.Н., Сухов А.О. Языковой инструментарий системы MetaLanguage // Математика программных систем: Межвуз. сб. научн. тр. / Перм. ун-т. Пермь, 2009. 4. Сухов А.О. Использование предметно-ориентированных языков для создания приложений для мобильных устройств // Технологии Microsoft в теории и практике программирования / Материалы межвуз. конкурса-конференции. Москва, 2009. С. 289-290. 5. Сухов А.О. Предметно-ориентированный язык в адаптируемых информационных системах // Технологии Microsoft в теории и практике программирования / Материалы конференции. Академгородок. Новосибирск, 2008. С. 25-26. 6. Сухов А.О. Решение проблем традиционного подхода к разработке информационных систем на основе использования предметно-ориентированных языков // Сборник трудов VI Всероссийской научно-практической конференции студентов, аспирантов и молодых ученых "Технологии Microsoft в теории и практике программирования". Томск, 2009. С. 180-181. 7. Сухов А.О. Среда разработки визуальных предметно-ориентированных языков моделирования // Математика программных систем: Межвуз. сб. научн. тр. / Перм. ун-т. Пермь, 2009. 8. Сухов А.О., Лядова Л.Н. Использование визуальных предметноориентированных языков для описания бизнес-процессов // Технологии Microsoft в теории и практике программирования / Материалы межвуз. конкурса-конференции. Политехнический ун-т. СПб, 2009. С. 117. 9. Сухов А.О., Лядова Л.Н. Предметно-ориентированный язык построения выражений для компонента автоматической генерации запросов // Технологии Microsoft в теории и практике программирования / Материалы межвуз. конкурса-конференции. Политехнический ун-т. СПб, 2008. С. 164-165. 28 .02069071.00243-01 99 01 Приложение 1. Схема базы данных репозитария На рис. 19 представлена схема БД репозитария. Рассмотрим ее подробнее. Таблица «Models» содержит информацию обо всех моделях системы. Полями этой таблицы являются: idModel – уникальный идентификатор модели; idMetaModel – ссылка на метамодель, с помощью которой создана модель; ModelName – название модели; ModelFileName – имя файла, в котором хранится визуальное представление модели; ModelDescription – описание модели. Таблица «Entities» хранит данные обо всех сущностях системы. Данная таблица имеет следующие атрибуты: idEntity – уникальный идентификатор сущности; idModel – ссылка на модель, которой принадлежит сущность; EntityName – название сущности; EntityType – тип сущности, ссылка на родительскую сущность; EntityDrawType – вид пиктограммы, с помощью которой визуализируется сущность; EntityCount – допустимое число экземпляров сущности; EntityDescription – описание сущности. В таблице «Operations» содержится информация обо всех операциях, которые могут быть выполнены над сущностями системы. Полями таблицы являются: idOperation – уникальный идентификатор операции; idEntity – ссылка на сущность, которой принадлежит операция; OperationName – название операции; ResultType – тип возвращаемого значения; OperationDescription – описание операции. Данные о параметрах операций хранятся в отдельной таблице «Parameters», которая связана с таблицей «Operations» связью «М:1». Атрибутами данной таблицы являются: idParameter – уникальный идентификатор параметра операции; idOperation – ссылка на операцию, которой принадлежит данный параметр; ParameterName – название параметра; ParameterType – тип параметра; ParameterNumber – номер параметра при вызове операции; ParameterDescription – описание параметра. Атрибуты всех сущностей системы хранятся в таблице «Attributes». Эта таблица имеет следующие поля: idAttribute – уникальный идентификатор атрибута; 29 .02069071.00243-01 99 01 idEntity – ссылка на сущность, которой принадлежит атрибут; AttributeName – название атрибута; AttributeType – тип атрибута; AttributeDefaultValue – значение по умолчанию, которое будет выбрано в качестве основного, в случае отсутствия последнего; AttributeDescription – описание атрибута. Значения атрибутов экземпляров сущности содержатся в таблице «AttributesValues». Структура таблицы имеет вид: idValue – уникальный идентификатор значения атрибута; idAttribute – ссылка на атрибут, которому принадлежит значение; idEntity – ссылка на сущность Value – значение атрибута. Таблица «Relations» хранит информацию обо всех отношениях системы. Полями таблицы являются: idRelation – уникальный идентификатор отношения; idModel – ссылка на модель, которой принадлежит отношение; RelationName – название отношения; idStartEntity – ссылка на сущность–источник отношения; idEndEntity – ссылка на сущность-приемник отношения; RelationType – тип отношения, ссылка на родительское отношение; RelationDrawType – вид пиктограммы с помощью которой визуализируется отношение; StartEntityMin – минимальное количество сущностей-источников отношения; StartEntityMax – максимальное количество сущностей-источников отношения; EndEntityMin – минимальное количество сущностей-приемников отношения; EndEntityMax – максимальное количество сущностей-приемников отношения. Таблица «Constraints» содержит данные об ограничениях, накладываемых на сущности и отношения моделей системы. Данная таблица имеет следующие поля: idConstraint – уникальный идентификатор ограничения; idAttribute – ссылка на атрибут, на который накладывается ограничение; Sign – знак сравнения в ограничении; Value – значение в правой части ограничения; ErrorMessage – сообщение об ошибке, которое будет выдано в случае нарушения ограничения. Parameters Operations idParameter idOperation idOperation idEntitу ParameterName OperationName ParameterType ResultType ParameterNumber FileName ParameterDescription OperationDescription AttributesValues Entities Models idValue idEntitу idModel idModel idMetaModel EntityName ModelName EntityType ModelFileName EntityDrawType ModelDescription EntityCount EntityDescription idAttribute idEntitу Value Constraints Attributes idAttribute Relations idEntitу idRelation AttributeName idModel AttributeType RelationName AttributeDefaultValue idStartEntity AttributeDescription idEndEntity RelationType RelationDrawType StartEntityMin StartEntityMax EndEntityMin EndEntityMax RelationDescription Рис. 19. Схема базы данных репозитария idConstraint idAttribute Sign Value ErrorMessage СОДЕРЖАНИЕ 1. ФУНКЦИОНАЛЬНОЕ НАЗНАЧЕНИЕ ПРОГРАММЫ, ОБЛАСТЬ ЕЕ ПРИМЕНЕНИЯ, ЕЕ ОГРАНИЧЕНИЯ ........................................................................................................... 2 1.1. Назначение программы ................................................................................. 2 1.2. Область применения программы ................................................................ 2 1.3. Ограничения использования программы .................................................... 3 2. ТЕХНИЧЕСКОЕ ОПИСАНИЕ ПРОГРАММЫ .................................................................. 3 2.1. Структура разрабатываемой системы ................................................... 3 2.2. Принципы функционирования программного продукта ........................... 6 2.3. Процесс создания предметно-ориентированных языков с помощью системы MetaLanguage ............................................................................. 13 2.4. Логика работы системы MetaLanguage.................................................. 14 2.5. Объектная модель системы MetaLanguage ............................................ 18 2.6. Применяемые программные средства ..................................................... 24 2.7. Используемые технические средства и требования к аппаратуре .... 26 3. СПЕЦИАЛЬНЫЕ УСЛОВИЯ ПРИМЕНЕНИЯ И ТРЕБОВАНИЯ ОРГАНИЗАЦИОННОГО, ТЕХНИЧЕСКОГО И ТЕХНОЛОГИЧЕСКОГО ХАРАКТЕРА ............................................ 26 4. УСЛОВИЯ ПЕРЕДАЧИ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ ИЛИ ЕЕ ПРОДАЖИ .......... 26 БИБЛИОГРАФИЧЕСКИЙ СПИСОК ................................................................................... 27 ПРИЛОЖЕНИЕ 1. СХЕМА БАЗЫ ДАННЫХ РЕПОЗИТАРИЯ .............................................. 28