автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Инструментальная поддержка САSЕ-технологий

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ИНСТИТУТ . _ „ (технический университет)

РГБ Ой

^ ^ ДЕН 1398 На правах рукописи

ЧЕКРИЙ Сергей Павлович

УДК 681.324.001.2

Инструментальная поддержка САБЕ-технологий

Специальность 05.13.11

Математическое и программное обеспечение вычислительных машин, комплексов,

систем и сетей"

АВТОРЕФЕРАТ диссертации на соискание ученой степени

кандидата физико-математических наук

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ИНСТИТУТ (технический университет)

На правах рукописи

ЧЕКРИЙ Сергей Павлович

УДК 681.324.001.2 Инструментальная поддержка САБЕ-технологий

Специальность 05.13.11

'Математическое и программное обеспечение вычислительных машин, комплексов,

систем и сетей"

АВТОРЕФЕРАТ диссертации на соискание ученой степени

кандидата физико-математических наук

Работа выполнена в Московском авиационном институте.

Научный руководитель: Официальные оппоненты:

кандидат физико-математических наук,

доцент Л.Н. Чернышов

кандидат технических наук, Калянов Г.Н.

доктор технических наук, профессор Кузнецов С.Д.

Ведущая организация

Российский технологий

НИИ информационных

Защита состоится "_"_ 1998г. в _ часов на заседай»

специализированного Совета К 053.18.09 в Московском государственно авиационном институте (техническом университете) по адресу: 125871, г.Москв ГСП, Волоколамское ш., 4.

С текстом диссертации можно ознакомиться в библиотеке МАИ.

Ваш отзыв на автореферат в одном экземпляре, заверенный печатью, проси направлять по указанному адресу.

Автореферат разослан Ж- шЩ 1998г. Ученый секретарь Совета

кандидат физ.-мат. наук, доцент М.В. Ротанина

1. Общая характеристика работы актуальность темы работы. В настоящее время при проектировании программных нстем все шире применяется CASE-технолог ия (Computer Aided System/Software ingineering), которая основана на использовании методологий проектирования и одерживается специализированными компьютерными программами (CASE-истемами). Системой мета-CASK называют CASE-систему, позволяющую ввод юрмального описания методологии с целью дальнейшего использования данного писания при создании моделей и содержащую в себе средства создания юрмальных описаний методологий. Таким образом, система мета-CASE является иструмептом поддержки CASE-технологий. Такие системы наиболее интересны ля корпоративного использования. Мета-CASE применяют: в компаниях, где используются собственные стандарты или собственная методология;

если есть необходимость модифицировать существующую методологию;

если есть необходимость интегрировать несколько методологий;

если есть необходимость применить в методологии новые технологии, такие как

CORBA.

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

[ель работы. Целью научной работы является исследование задачи нструментальной поддержки CASE-технологий на основе метамоделирования. редполагается под инструментальной поддержкой CASE-технологий понимать ;.\нологию мета-CASE.

Система мета-CASE должна основываться на некоторой метаметамодели. [>ыло рнпяго решение воспользоваться существующей стандартной метаметамоделью. истема мета-CASE должна: создавать описания метамоделей (методологий роектирования) с помощью заложенной в нее метаметамодели, строить уже

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

Научная новизна. В ходе выполнения работы достигнут ряд научных результатов:

• Определена архитектура системы мета-CASE.

• Предложен механизм спецификации метамоделей.

• Предложен универсальный подход к заданию динамических свойств моделей и метамоделей.

Практическая ценность. Разработана система мета-CASE MetaBuilder. Внедрение полученных в диссертационной работе результатов позволяет значительно снизить затраты на создание CASE-систем, прежде всего результаты работы могут быть интересны разработчикам систем CASE и их пользователям. Система мета-CASE удобна для применения в учебном процессе.

Апробация работы. Результаты работы используются в учебном процессе в курсе "Технология построения больших программных систем" факультета "Прикладная математика" МАИ. Система MetaBuilder используется при выполнении лабораторных работ по курсу. Работа апробирована при выступлениях на научных конференциях и на веб-сайте vvvvvv.ineta-case.com. Публикации. По теме диссертации опубликовано 6 печатных работ. Структура работы. Диссертация состоит из введения, 3-х глав, заключения, списка литературы, содержащего 53 наименования, и 3-х приложений. Машинописных страниц - 126, рисунков - 25, таблиц -II, объем приложений - 16 страниц.

2. Краткое содержание работы 1 Во ВВЕДЕНИИ обосновывается актуальность диссертационной работы, формулируются ее цели и задачи.

В ПЕРВОЙ ГЛАВЕ дается обзор существующих технологий CASE.

В работе предлагается следующая классификация CASE-систем (см. рис. 1):

CASE-системы

\

CASH Maa-CASii

1 i

------по реализации мета-ио,г\оди

----- "конструктор" CAST-ciicrcM

j ----- расширяемое ЯЛ['>о СЛЯГ

-по отношение к метаметамодели

------- основанные на мсимеымодетл

--------не основанные на метаметамодели

Рис Л Классификация CASE-систем

Согласно данной классификации, CASE-системы подразделяются на два основных класса - CASE и мета-CASE. Классификация собственно CASE не

рассматривается в данной работе, наиболее полно она изложена в [2], см. также

(ЩЗ).

Выявляется два подхода к созданию систем мета-CASE:

• создается программа ("конструктор"), в которую вводятся данные о методологии (или нескольких методологиях), и которая впоследствии используется для генерации CASE-системы, поддерживающей заданный набор методологий;

• создается гибкая настраиваемая CASE-система ("ядро"), настраивая которую, можно получить CASE-систему, поддерживающую любой заданных набор методологий.

В работе обосновывается выбор второго подхода и рассматривается архитектура системы мета-CASE, созданной на его основе. Формулируются основные требования к системам CASE.

В главе приводится обзор современных методологий проектирования 110. Приводится определение методологии [4], включающее следующие компоненты:

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

Понятия, затронутые в определении методологии, рассматриваются подробно. В главе рассматриваются системы мета-CASE и связанное с ними понятие "метамоделирование".

Приводятся примеры применения метамоделей:

• концептуальная схема репозитория;

• концептуальная схема для инструмента моделирования, такого как система CASE;

• определение языка моделирования, например, языка объектного анализа и проектирования;

• часть технологии, позволяющей совместно использовать различные системы моделирования.

Описываются крупные проекты в области метамоделирования: интегрированная метаметамодель CD1F, метаметамодель UML, метаметамодель OPEN Object Alliance, интегрированная метаметамодель OPEN/OML.

Далее в работе дается определение мета-CASE, рассматриваются причины интереса к таким системам.

Как один из результатов первой главы формулируются общие требования к системам мета-CASE:

• Система мега-CASE должна быть основана на стандартной метаметамодели.

• Ввод семантики и нотации метамоделей (методологий) в систему мета-CASE должен быть достаточно прост для пользователя.

• Метамодели и модели должны храниться в открытом для внешних средств репозитории.

• Система CASE, полученная с помощью мета-CASE системы, должна удовлетворять требованиям к CASE-системам, приведенным в данной работе.

Во ВТОРОЙ ГЛАВЕ рассмотрена архитектура системы MetaBuilder. В главе дается анализ проблемы и приводится постановка задачи для системы MetaBuilder, служащей иллюстрацией избранного подхода.

Поиск информации по существующим CASE системам проводился в базе данных, основанной на архивах конференции USENET comp.software-eng.

На момент поиска (14.05.98) в базе данных было зарегистрировано 489 CASE-систем. Из них 7 было зарегистрировано как мета-CASE. Проведен анализ трех существующих систем мета-CASE: MetaEdit+, Paradigm, ToolBuilder. По результатам анализа сделан вывод о том, что только про систему мета-CASE, основанную на апробированной метаметамодели, можно достоверно утверждать, что она годится для применения в мета-CASE технологии.

Формулируется постановка задачи для системы мета-CASE, основанной н«. метаметамодели (системе дано название MetaBuilder).

Система должна удовлетворять общим требованиям к системам мета-CASE, а гакже:

• должна позволять создавать модели с помощью описанных метамоделей,

• должна быть открыта для расширений;

• должна обладать графическим интерфейсом.

В основу системы положена метаметамодель CDlF[5-9]. Обосновывается выбор да н 11 о й м era м era м оде л и :

• Реализация метаметамодели легко представима в виде библиотеки классов.

• Метаметамодель CDIF определена в рамках стандарта CDIF, поддерживаемого большинством производителей.

• Данная метаметамодель не является собственностью отдельного поставщика (как UML - фирмы Rational). Разработка метаметамодели ведется независимой от производителей организацией (Electronic Industries Association).

Метаметамодель CDIF имеет иерархическую структуру и достаточно хорошо представима в виде библиотеки классов. Метамодели образовываются путем уточнения основной метаметамодели. На настоящий момент дерево иерархии метамоделей в стандарте CDIF выглядит так:

Интегрированная метаметамодель CDIF метаметамодель Foundation

метаметамодель Common метамодель DFD мета модель SADT метамодель E-R

При уточнении метаметамодели Common классы, уточняющие метаметамодель, являются наследниками классов ComponentObject и DefmitionObject.

Таким образом, создавая метамодель какой-либо методологии по CDIF, например, методологии DFD, аналитик образует наследники этих двух основных классов, закладывая в них семантику метамодели (см. рис.2). На рисунке классы, относящиеся к метаметамодели, показаны закрашенными прямоугольниками. Классы, относящиеся к метамодели диаграмм потоков данных, показаны белыми

прямоугольниками.

DefinesPath

HasMember 2-N_

Component Objcct

Referenced Equivalence

Element Set

ProducesOt Consumes ON

0,

Pro lu e:

FlowProdi-cerCcnsum«-

onstimes Ni)J4-

Flow

FlowPoi t

0:N References 0.^

Contains 0:1

Definition Object

Flow Definition

DFM Process

Attributte

DFM Process Definition

nataT^pe

Store Definition

CplFExtAgeil r>^firtiUrm

External Agent

Рис.2 Метамодель диаграмм потоков данных

В главе рассмотрена программная реализация метаметамодели СОП\

На рис.3 показана иерархия классов программной системы. Данная иерархия

описана в рамках самой системы метапроектирования.

I ■■ ■ йлм _ __^

-0|К1/ч|1 I - 4 - Гя I II,-. им* Я..'1.1» .Г 1ЛЛ"1

Рис.3 Упрощенное описание метаметамодели системы Ме1аВш1с)ег (создано с помощью самой системы).

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

• подсистема спецификации метамоделей (методологий);

• репозитории метамоделей (методологий) и моделей;

• подсистема спецификации графических примитивов метамоделей (методологий);

• подсистема спецификации сценариев поведения метамоделей (методологий);

• графический интерфейс пользователя.

Эти подсистемы и их взаимосвязи изображены на рис.4.

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

поведения. Сценарии поведения - это предлагаемый подход к отображению динамических свойств создаваемых в системе моделей.

Далее отдельно рассматривается каждая подсистема. В работе описана структура реиозишрия, являющегося ядром системы. В репозитории метамоделей хранятся:

• количество объектов, их имена, атрибуты каждого объекта;

• взаимосвязи между объектами;

• спецификации изображения метаобъектов;

• спецификации поведения метаобъектов, объектов, модели.

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

подсистема спецификации примитивов поведения

подсистема спецификации графических примитивов

I 5спр10га>« Ме(аОЬ|ес1

Бспр|3;ти1а|с Ме1аОЬ)(ХЛ

Т .. . Т_ ________

Бспр(Зрти1аГе ВспрГЗгтиМе ОЦес! I Мос1е1

исходные тексты скриптов/ ^ Л___

исполнение скриптов может менять объекты репозитория

тттт__

СопТатетСЭДес!

▼ ▼ Т

СИРАтгау

[ данные Т

репозитории метамоделей

01адгат

графический интерфейс пользователя

Ме1аМос1е1Е(А1ог

подсистема спецификации метамоделей

взаимодеиствие ~с диаграммой

Пользователь |

Рис.4 Архитектура программной системы

т

Язык спецификации применяется в системе для описания графических примитивов и описания сценариев поведения. При разработке системы было решено сделать механизм применения языка спецификации максимально настраиваемым. В результате предложен подход, когда пользователь может задать собственный язык спецификации. При этом уже существует два "встроенных" языка - это Java Script и Visual Basic. Данный подход реализован с помощью технологии свободно-распространяемого элемента ActiveX Microsoft Script Control.

Элемент ActiveX Microsoft Script Control позволяет пользователю писать и выполнять сценарии для любого языка спецификации. Два языка спецификации, VBScript и JScript, включены в данный элемент ActiveX. В элемент можно добавить любой объект вида Ole Automation. При этом общедоступные методы и свойства такого объекта становятся видимыми в сценарии.

Такой объект используется в системе для расширения свойств языка спецификации. Данный объект типа TContainerObject виден в сценариях под именем "contobject" (см. рис.5)

ГЧ^-у Froidure

•mDi^Jbx-clfl

Srxiate Procedure |ria<y$)

1

rrrl'+iTi W

Ы .

w*»44 ^wriftttivflr l •mW"« • vrtrt^rrl

- err*t*v* ' Vj

tmtfi • rirntxl 1/' H'qfPjyxit яО -or»f*m wvfciry I rf | vwt^n-t «HrriHi^ql ? n^

СапСоптаа

ф§ ЧеиМи-вЦ ÛOTgWMOâiè

1

2 FMMFWOI

î Ччи«»>

•Soi j

WEM01 ME МГц WfMflf

•Г1

¡FW |D*T

• • ]

J_I » I - I « 1 - 1 I 1 - M »1 -1

Рис.5 Функция DrawObjectQ - процедура изображения метаобъекта Class.

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

1J

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

Таблица I. Использование подсистемы спецификации сценариев поведения

Возможность Пример применения

спецификация сценариев поведения метаобъекгов создание генератора кода; определение формата им порта-экспорта

спецификация сценариев поведения объектов прототип системы; сеть Петри

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

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

Таким образом, во второй главе описана архитектура и основные подсистемы системы мета-САЯЕ, основанной на метаметамодели. Описан механизм задания динамических свойств метамоделей и моделей.

В ТРЕТЬЕЙ ГЛАВЕ рассмотрена методика применения системы МтВшМег.

Описываются классы задач, решаемых системой. Это задачи метамоделирования, задачи статического моделирования, задачи динамического моделирования.

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

Потребность в решении задач такого класса возникает при:

а) вводе в систему известной метамодели, не заложенной в системе;

б) расширении известной метамодели;

в) упрощении известной метамодели;

г) интеграции различных метамоделей;

д) наделении метамодели средствами имитации;

е) построении полностью собственной метамодели.

На примере рассматривается, как происходит метамоделирование в системе. Пусть требуется заложить в систему некоторое подмножество методологии объектно-ориентированною анализа (00А).

I. Аналитик заносит в репозиторий системы сведения о следующих объектах ООА: class, relation, attribute, method. Для каждого из этих объектов аналитик задает исходный текст процедуры изображения на языке спецификации графических примитивов.

II. Аналитик заносит в репозиторий информацию о зависимости между объектами, как ведут себя объекты диаграммы при декомпозиции. В данном случае достаточно будет занести информацию о том, что объект class на следующем уровне декомпозиции может представляться объектами class, relation, attribute, method.

III. Для каждого объекта метамодели может быть задан исходный текст сценария поведения. С ее помощью можно произвести "тонкую настройку" метамодели. Поддерживается три вида сценариев поведения.

A. сценарии поведения метаобъектов, задаются для метаобъектов диаграммы, т.е. в случае ООА class, relation, attribute, method.

B. сценарии поведения объектов, задаются для объектов диаграммы, т.е. для каждого конкретного класса, атрибута, метода.

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

К задачам статического моделирования относятся задачи построения моделей по введенным в систему метамоделям (методологиям).

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

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

Помимо основной информации о метамодели, занесенной в репозиторий, аналитик, используя сценарии поведения уровня метаобъектов, может занести в репозиторий такую информацию о метамодели, как, например, ограничение на количество объектов на диаграмме (в БАЭТ - не более шести), или задать собственные правила наименования объектов и/или генерации их имен и др. Построение генераторов кода

С помощью сценариев поведения также можно внести в метамодель возможность генерации исходного кода на некотором языке программирования. Так, в системе построена метамодель ООЛ с возможностью генерации исходного текста на языке С++. Для любой модели, созданной по этой метамодели, возможно получить исходные тексты на С++.

Построение генераторов документации

Также сценарии поведения можно использовать для дополнения метамодели возможностью автоматической генерации документации для модели. Импорт-экспорт

Если требуется экспортировать модель в другую систему, то здесь также возможно использовать сценарии поведения. Построение прототипов

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

Далее в главе рассматривается цикл проектирования в системе. Также в главе рассматриваются планы дальнейшего развития системы. Так, в первую очередь, планируется:

• добавить возможности обратного инжиниринга;

• внес I и поддержку рабочих групп;

• «нести возможность работы с другими инструментами разработки.

В разделе ЗАКЛЮЧЕНИИЕ диссертации сформулированы ее основные результаты и направления дальнейших исследований.

В ПРИЛОЖЕНИИ I приводится глоссарий метамоделирования. ПРИЛОЖЕНИЕ 2 содержит краткое описание стандарта С13П;. В I ПРИЛОЖЕНИИ 3 описана библиотека классов СП1Р, реализованная в системе Ме1аВш1с1ег.

3. Основные результаты работы В результате выполнения работы достигнуты следующие научные результаты. • Разработана архитектура системы мста-САЯЕ, основанной на метамоделировании. Обоснован выбор мета мета модели, лежащей в основе данной системы.

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

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

В качестве иллюстрации предлагаемых подходов создана система мета-CASE MetaBuildcr.

4. Печатные работы

Чернышов Л.Н, Чекрий С.П. Адаптация метода SADT для объектно-ориентированного проектирования Деп. в ВИНИТИ 21.6.95 1772-В95

Чернышов Л.Н, Чекрий СП. Обзор стандарта обмена данными средств проектирования - CDIF (CASE Data Interchange Format) Деп. в ВИНИТИ 7.7.97 2207-В97 v

Чернышов Л.Н, Чекрий С.П. Тезисы доклада на Второй Международной студенческой школе-семинаре "Новые информационные технологии" Интерпретация метода SADT Росса в терминах объектно-ориентированного проектирования по Бучу. Пример применения.. Судак, 1995

Чернышов Л.П., Чекрий С.П. Тезисы доклада на международной конференции "Современные технологии обучения" . CASE технологии в обучении., Санкт-Петербург, 1998.

Чекрий С.П. Тезисы доклада на 6-й международной школе-семинар "Новые информационные технологии". Архитектура средства Мета-CASE., Судак, 1998

Чекрий С.П Архитектура системы мета-CASE MetaBuilder Деп. в ВИНИТИ 12.10.98 2968-В98

Артюхов С.В., Чернышов JI.H., Чекрий С.П. Тезисы доклада на международной конференции "Анализ систем на рубеже тысячелетия". Интеграция и взаимосвязь разнородных систем на базе метамоделирования., Москва, 1998.

5. Библиографический список [1 ]CASE Vendor/Product Review University of California, San Diego Holly A. Cartwright,

1995

[2]Калянов Г H CASE. Структурный системный анализ (автоматизация и

применение). М., "Лори", 1996. [3JCASE metamorphosis, (computer-aided software engineering tools are enhanced to increase MIS productivity) Author: Moriarty, Terry, 1995

[4] What Is a Method? Dr. James Rumbaugh, 1995

[5] [CDIF94a] CDIF - Framework for Modeling and Extensibility, Interim Standard, EIA

1994.

[6] fCDIF94e] CDIF - Integrated Mela-model, Foundation Subject Area, Interim Standard, EIA 1994.

[7] [CDIF96a] CDIF - Integrated Meta-model, Common Subject Area, Interim Standard, EIA 1996.

[8] [CDlF96b] CDIF - Integrated Meta-model, Data Flow Subject Area, Interim Standard, EIA1996.

[9| Обзор стандарта обмена данными средств проектирования - CDIF (CASE Data Interchange Format) Деп. в ВИНИТИ 7.7.97 2207-В97