CC BY
70
В заключение отметим, что дальнейшим развитием описанной метамодели может являться добавление классов, предоставляющих механизмы фильтрации данных и элементов, позволяющих описать элементы поведения (например, правила валидации) и принципы отображения (подходы формирования графических форм приложения). Также необходимо предусмотреть возможность добавления пользователем программного кода, реализующего бизнес-логику предметной области, т.к. невозможно предусмотреть заранее весь функционал, который потребуется в прикладной предметной области.
Литература
1. Грэхем И., Объектно-ориентированные методы. Принципы и практика. 3-е издание.: Пер. с англ. - М.: Издательский дом «Вильямс», 2004. - 880 с.: ил. - Парал. тит. англ.
2. Cattell R.G., Barry D.K. The Object Data Standard:ODMG 3.0, Morgan Kaufmann Publishers,
2000, 288p.
3. Джордан Д. Обработка объектных баз данных на C++. Программирование по стандарту ODMG. : Пер. с англ. : Уч. пос. - М.:Издательский дом "Вильямс", 2001.-384с.:ил.-Парал. тит. англ.
4. Calero C., Ruiz F. and oth. An ontological approach to describe the SQL:2003 ob-ject-relational features, Ontologies for Software Engineering and Software Technology, Springer Berlin Heidelberg, 2006, 197-215pp.
5. Новиков Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. - СПб.: Профессиональная литература, Наука и Техника, 2010. - 640 с.: ил. + цв. Вклейки (+ 2 DVD).
6. Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. Рефакторинг: улучшение существующего кода. - М: Символ-Плюс, 2008. - 432 с.: ил. - Парал. тит. англ.
7. Олейник П.П. Принципы организации иерархии атомарных литеральных типов объектной системы на основе РСУБД Microsoft SQL Server 2005, http://citforum.ru/database/articles/oleynick/
УДК 519.711
АНАЛИЗАТОР ДИАГРАММНЫХ ЯЗЫКОВ ДЛЯ MICROSOFT VISIO1
Гайнуллин Ринат Фаязович, аспирант, Ульяновский государственный технический университет,
Россия, Ульяновск, r.gainullin@gmail.com
Брагин Дмитрий Геннадьевич, аспирант, Ульяновский государственный технический университет,
Россия, Ульяновск, dmbragin@gmail.com
Введение
При концептуальном проектировании автоматизированных систем широкое применение находят различные графические спецификации: сети Петри, диаграммы переходов состояний, блок-схемы и другие. В сфере разработки программного обеспечения особое место заняли методологии Rational Unified Process (RUP) и Structured Analysis and Design Technique (SADT). При проектировании в соответствии с данными методологиями активно используются графические спецификации UML и IDEF.
В проектном моделировании применяются различные графические редакторы, которые можно разделить на универсальные и специализированные. Применение универсальных редакторов сводится к созданию неформализованных схем и диаграмм, чаще всего в демонстрационных целях. К таковым можно отнести Microsoft Visio и Dia. Специализированные редакторы входят в состав инструментальных средств реализации той или иной технологии. Так, Rational Suite, Visual Paradigm for UML, ArgoUML представляют собой специализированные графические редакторы для методологии UML. Примерами редакторов семейства графических спецификаций IDEF являются BPWin, ERWin, Business Studio. Общим недостатком как универсальных, так и специализированных редакторов
1 Статья рекомендована к опубликованию в журнале "Информационные технологии"
40
является либо полное отсутствие, либо ограниченность инструментов анализа и контроля построенных диаграмм.
1. RV-грамматика
В основу разработанного анализатора положен аппарат RV - грамматик [1,3].
RV - грамматикой языка L (G) называется упорядоченная пятерка непустых множеств
G = (V ,2,2, Я, r0), где
V = {ve, e = 1,L} - вспомогательный алфавит (алфавит операций над внутренней
памятью);
Е = {at, t = 1, T} - терминальный алфавит графического языка, являющийся
объединением множеств его графических объектов и связей (множество примитивов графического языка);
Е = {at, t = 1, T} - квазитерминальный алфавит, являющийся расширением
терминального алфавита.
Я = {rt, i = 0,1} - схема грамматики G (множество имен комплексов продукций, причем каждый комплекс r состоит из подмножества Pj продукций r = {Pj, j = 1,J});
r0 e Я - аксиома RV - грамматики (имя начального комплекса продукций), rk е Я -
заключительный комплекс продукций.
~ Ц.№,Ы, "О].
Продукция Рц g /; имеет вид а'ь f Тт
Таблица 1 . RV- грамматики диаграмм Use Case
Комплекс Квазитерм Комплекс- преемник RV - отношение
Го Ri Гз W1(et(1))/W3(et(1) == о || et(2) == о)
Re Г4 W1(et(1))/W3(et(1) == о || et(2) == о)
Rg Г5 W1(et(1))/W3(et(1) == о || et(2) == о)
Ri Гб -
Re Г7 -
Rg Г8 -
Г: Ra Г2 -
Rg Г5 -
Г2 C Го -
Гз C Го -
Г4 C Го -
Г5 C Го -
A Г1 -
Гб C Го W1(et(1))/W3(et(1) == о || et(2) == о)
Г7 C Го W1(et(1))/W3(it(1) == о || et(2) == о)
Г8 C Го W1(et(2))/W3(et(1) == о || et(2) == о )
A Г1 -
В качестве внутренней памяти предлагается использовать стеки для обработки графических объектов, имеющих более одного выхода (чтобы хранить информации о связях
41
- метках), и эластичные ленты для обработки графических объектов, имеющих более одного входа (чтобы отмечать количество возвратов к данной вершине, а, следовательно, количество входящих дуг). Ленты позволяют считывать данные из ячеек без уничтожения их содержимого, а ячейки лент могут работать в режиме счетчика целых положительных чисел.
Приведем примеры графических грамматик спецификаций UML и IDEF.
2. Грамматика языка Use Case
Use Case-диаграммы предназначены для описания проектируемой системы (или ее части) с точки зрения взаимодействия пользователя (актора) с вариантом использования системы (прецедентом). Этот вид диаграмм решает задачу представления системы в виде, удобном для обсуждения на общем языке функциональности между заказчиком, пользователем и разработчиком. В табл. 1 представлена RV-грамматика диаграммы Use Case языка UML после минимизации.
После окончания разбора необходимо провести операцию контроля:
* = W2(et(1), et(2))/W3(et(1) <> 0 && et(2) <> 0)
В результате должны остаться пустые ленты.
Таблица 2. RV- грамматики диаграмм IDEF3
Комплекс Квазитерм Комплекс -преемник RV - отношение
U Г1 -
Г0 L Г2
Г1 Relp Г5
reloF Гб —
Г2 relp Г5
S Го и-‘2<ЬА7И]
lAND Го
== ft*®)
Гз lOR Го w2(bani)
lXOR Го w2(b Sm]
w3fmcCn: == k.f<icy)
no_label Гк -
Г4 lOR Го
U Г1 —
L Г2 wl
AND Гз
AND Гз wl w3ffcc^ > l)
Г5 OR Г4 . i/
OR Гз и-1
X OR Гз
X OR Гз vi-1 w3ffctCe^ > l)
Гб U Г1 —
Гк —
42
3. Грамматика языка IDEF3
Методология IDEF3 - это методология графического моделирования, предназначенная для описания и документирования информационных потоков в системе, взаимоотношений между процессами обработки информации и объектами, являющимися частью этих процессов. В табл. 2 представлена RV-грамматика языка IDEF3 после минимизации [2].
4. Реализация анализатора диаграммных языков
В качестве практического применения предлагаемого подхода к анализу диаграммных языков было реализовано расширение для программного продукта Microsoft Visio. Общая структура системы представлена на рисунке 1.
Рис. 1 - Общая структура системы анализа и контроля
Для анализа языков IDEF и UML было реализовано два отдельных анализатора, что обусловлено спецификой данных графических нотаций.
На практике используются два варианта создания расширения для Microsoft Visio:
1. Создание компонента согласно технологии Component Object Model (COM);
2. Создание встраиваемого в документ макроса на языке Visual Basic for Application (VBA).
Достоинствами первого варианта являются недостатки второго и наоборот. Так, разработка макроса на языке VBA занимает меньшее время, но ограничена по функциональности. Поэтому для разработки анализатора был выбран первый вариант, так как он обеспечивает более широкие возможности по работе как с объектами самого Visio, так и со сторонними библиотеками и самой операционной системой в целом. Компонент COM представляет собой обычную DLL библиотеку, которая регистрируется в системе и имеет свой уникальный номер. Непосредственно в компоненте согласно стандарту COM необходимо реализовать интерфейс IUnknown [3].
Информация по этому компоненту указывается в ключе HKEY_CURRENT_USER/ Software/Mirosoft/Visio/Addins/ реестра системы для того, чтобы Visio мог загрузить данные компонента. Подключение компонента в самом Microsoft Visio осуществляется из пункта меню Сервис - Настройки - Панели Инструментов.
<memory> <storage id="1" type="0" />
<storage id=”2” type="1" />
<storage id="3" type="1" />
<storage id="4" type="0" />
</memory>
Листинг 1 - XML-описание внутренней памяти
RV-грамматика графического языка хранится в формате XML. Первая секция файла грамматики описывает структуру внутренней памяти, используемой данной грамматикой. Параметры для каждого элемента памяти это уникальный идентификатор и тип элемента
43
памяти (0 - стек, 1 - эластичная лента). В листинге 1 приведена внутренняя память автомата, состоящая из двух стеков с идентификаторами 1, 4 и двух эластичных лент 2, 3.
Далее идёт секция с описанием продукций грамматики, каждая составляющая которой отражает строку табличной формы RV-грамматики. Параметры продукции currentState и nextState отражают соответственно текущее и следующее состояния автомата, term -соответствующий графический примитив. Далее идет список операций записи значений во внутреннюю память. Каждая операция записи содержит информацию об идентификаторе элемента памяти storageld и заносимом значении value. Для элемента памяти «эластичная лента» необходим номер ячейки key, в которую производится запись. После списка операций следует условие выполнения этих операций, параметры у которого те же, что и параметры операций записи. Для примера приведем типичную продукцию, xml описание которой представлено в листинге 2.
<production>
<currentState>1</currentState>
<nextState>2</nextState>
<term>A</term>
<operations>
<operation storageId="2" key="t" value="1"/>
<operation storageId="3" key="t" value="k"/>
<operation storageId="4" value="t"/>
</operations>
<conditions>
<condition storageId="2" key="t" value="0" />
</conditions>
</production>
Листинг 2 - XML-описание продукции RV-грамматики
Алгоритм работы анализатора состоит из следующих шагов:
1. Проектировщик строит диаграмму в среде проектирования Visio.
2. С помощью разработанного расширения диаграмма преобразуется в XML-описание, которое содержит все элементы диаграммы и связи между ними. Описание не содержит информации о расположении элементов, т.к. данная информация не используется при разборе.
3. Анализатор принимает на вход XML-описание построенной диаграммы.
4. XML-описание преобразуется во внутреннее представление для работы анализатора. Внутреннее представление содержит описание диаграммы, аналогичное входному XML-файлу. Происходит дополнительная обработка входной информации необходимой для работы с RV-анализатором.
5. Последовательно, считывая элемент за элементом, анализатор производит анализ и контроль диаграммы.
6. По результатам анализа и контроля формируется список ошибок.
7. Список преобразуется в XML и возвращается в среду проектирования.
8. По полученному списку в Visio отмечаются типы и местоположения синтаксических и семантических ошибок, обнаруженные анализатором.
Выводы
Развитием предлагаемой системы является создание единого универсального анализатора диаграммных языков, предоставляющего возможность добавления определенной графической нотации, её грамматики и последующего анализа. Также ведутся работы по расширению предлагаемого подхода на другие программные средства и платформы.
Литература
1. Афанасьев А.Н. и др. Контроль информации в системах автоматизации проектирования. // Саратов: Изд-во Саратовского университета, 1985.- 136 с
44
2. Брагин Д.Г. Анализ IDEF3 диаграмм на основе автоматных графических грамматик // Сборник научных трудов «Информатика, моделирование, автоматизация проектирования». -Ульяновск: УлГТУ, 2011.- С. 67-74.
3. Шаров О.Г., Афанасьев А.Н. Синтаксически-ориентированная реализации графических языков на основе автоматных графических грамматик // Программирование. - 2005. - № 5. -С. 56-66.
УДК 004.04
ИНСТРУМЕНТАРИИ ОПТИМИЗАЦИИ РАБОТЫ СИСТЕМЫ УПРАВЛЕНИЯ ОБЪЕКТНО-РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
Микляев Иван Александрович, к.ф.-м. н., доцент, Филиал «СЕВМАШВТУЗ», Санкт-Петербургский государственный морской технический университет, Россия, Северодвинск,
ivanmia1@rambler.ru
Черткова Ольга Владимировна, старший преподаватель, Филиал «СЕВМАШВТУЗ», Санкт-Петербургский государственный морской технический университет, Россия, Северодвинск,
chertkova-o@mail.ru
Введение
Испокон веков человечество занято познанием окружающего мира и себя как его части. Парадигмы сменяют друг друга в попытках смоделировать окружающую реальность. Однако идея о том, что мир пронизан синергией - энергией взаимодействия, нашла удивительный отклик во всех сферах современного мира. Феноменом этого отклика стало представление о нашей жизни в целом в виде бесконечной совокупности взаимосвязанных и взаимозависимых открытых и закрытых систем. Элементы систем носят голографический или фрактальный характер, обладая вместе с тем уникальными свойствами, приводящими сами элементы и системы в целом к процессу постоянных изменений [1] .
И вся эта "реальность, данная нам в ощущениях" требует создания соответствующего информационного пространства - синергетического. Описываемые базами данных (БД) предметные области и бизнес-процессы, как и все живые системы, обладают свойствами жизнестойкости, функциональности и адаптивности. Информационный образ каждого объекта, занесённого в базу, должен быть синергетическим - отражающим зависимость значений характеристик объекта от среды взаимодействия. Естественно, программные средства и структуры представления данных в БД должны обладать теми же свойствами, чтобы адекватно отображать многогранный окружающий мир.
Стандартный реляционный подход к организации данных делает ставку на максимально эффективное манипулирование данными, для этого применяет дезинтеграцию данных до их полной однородности. А поскольку реальные бизнес-среды практически никогда не обладают однородностью, это приводит к чрезмерному абстрагированию от предметной области [2], и сложностям с описанием синергетических характеристик [3].
Напротив, стандартный объектно-ориентированный подход к организации данных предполагает каждый объект реального мира описывать индивидуально, всей совокупностью его параметров, что является более естественным для сложных систем. Безусловно, это позволяет адекватно отобразить структуру и состав предметной области, многообразие синергитических характеристик и облегчает проектирование.
1. Примеры решения задач синергетической природы
Организовать объектно-ориентированный подход в условиях реляционной базы данных можно с помощью выявления фрагментов баз данных, содержащих объекты с варьируемым числом параметров, и вынесения самих объектов и параметров-атрибутов в отдельные справочники, что сделает информационную систему более функционально и
45
