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

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ИНСТИТУТ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

__о

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

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

комплексов, систем и сетей"

Диссертация на соискание ученой степени кандидата физико-математических наук

Научный руководитель Чернышов Л.Н.

Москва - 1998

Содержание

Введение 4

Глава I Обзор существующих технологий CASE 7

1. Определение CASE, классификация систем CASE, требования к CASE 7

2. Современные методологии проектирования ПО - обзор 18 2.1 Определение методологии 19

2.2. Концепции моделирования 20

2.3. Метамодели 22

2.4. Нотация 22

2.5. Результаты разработки 24

2.6. Процесс 24

2.7. Шаблоны 26

2.8. Примеры методологий 26

3. Мета-CASE, примеры подходов 35

3.1. Метамоделирование 35

3.2. Мета-CASE 41

4

Глава II Архитектура системы MetaBuilder 45

1. Существующие системы мета-CASE 45

2. Постановка задачи 49

3. Требования и цели работы 51

4. Определение подсистем и их взаимосвязей 56

4.1. Репозиторий метамоделей 61

4.2. Подсистема спецификации метамоделей 63

4.3. Описание механизма языка спецификации (механизма сценариев) 66

4.4. Подсистема спецификации графических примитивов метамоделей 73

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

4.6. Графический интерфейс пользователя 75

Глава III Методика применения системы MetaBuilder 76

1. Классы решаемых системой задач 76

1.1. Задачи метамоделирования 76

1.2. Задачи статического моделирования 78

1.3. Задачи динамического моделирования 80

2. Цикл проектирования в системе 99

3. Планы дальнейшего развития системы 103

Заключение 103

Библиографический список 106

Приложение I. Глоссарий метамоделирования 111

Приложение И. Краткое описание стандарта CDIF 113

Приложение III. Библиотека классов CDIF системы MetaBuilder 118

1

Введение

Здесь необходимо хотя бы коротко охарактеризовать понятия, о которых пойдет речь. Определение системы CASE и мета-CASE системы дается в разделе 2.1 первой главы, здесь же отметим, что система CASE (Computer Aided System/Software Engineering) - программный продукт, который характеризуется поддержкой ограниченного набора методологий проектирования, жестко закодированных в системе. Система же мета-CASE -это CASE-система, средствами которой могут быть созданы новые методологии проектирования, которые затем можно в этой же системе применять.

В мире существует около пятисот CASE-систем. Из них лишь несколько отнесены производителями в категорию мета-CASE. С другой стороны, технология мета-CASE в последнее время вызывает все больший интерес. Действительно, не надо доказывать, что в крупных компаниях информационные технологии играют огромную роль. И часто невозможно на уровне корпорации применять традиционную "жесткую" CASE-систему без потери качества проектируемых моделей. Поясним подробнее. В крупной компании существует набор корпоративных стандартов. Эти стандарты накладываются практически на все - на модель финансового документооборота, структуру компьютерной сети, способ наименования серверов и формирования электронных адресов, штатное расписание филиала и так далее. Следовать этим стандартам "вручную", основываясь на наборе документации по ним достаточно сложно, "подстроить" существующие стандарты компании под готовые методологии либо трудно, либо просто невозможно, либо при этом произойдут качественные потери представления информации. Поэтому компании в последнее время обратили свое внимание на мета-CASE системы. Стали даже говорить о "второй волне" интереса к CASE.

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

Мета-CASE применяют:

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

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

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

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

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

-f

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

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

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

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

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

Глава I

Обзор существующих технологий CASE

1. Определение CASE, классификация систем CASE, требования к CASE

Сокращение CASE расшифровывается как Computer Aided System/Software Engineering. Как мы видим, можно расшифровать данное сокращение и достаточно широко, как автоматизированное проектирование систем, и достаточно узко, как автоматизированное проектирование программного обеспечения. В данном случае будем считать что 'S' - это 'Software', т.е. будем рассматривать более узкое понятие. Дать определение CASE-технологии нелегко. Например, возьмем определение, данное в [1]:

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

Инструмент (система, средство, продукт) CASE - программное обеспечение,

4

поддерживающее CASE-технологию.

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

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

СА8Е-технология - совокупность методов способов и приемов разработки программного обеспечения. Включает использование стандартных методологий проектирования ПО. Предполагает использование специализированных компьютерных программ (САБЕ-систем).

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

В данной работе предлагается следующая классификация САБЕ-систем (см. рис.1):

САБЕ-системы

CASE

мета-CASE

по реализации мета-подхода

"конструктор" CASE-систем

- расширяемое ядро CASE

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

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

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

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

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

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

[ЩЗ].

Подробно речь о системах мета-CASE пойдет ниже в разделе 2.3. Здесь же приведем определения:

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

Система мета-CASE - программная система поддержки мета-CASE технологии.

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

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

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

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

Определение CASE-системы не определяет требований, предъявляемых к программным продуктам данного класса. Требования к системам мета-CASE дополняют требования к системам CASE и рассмотрены в разделе 2.3. Поскольку CASE-технология, как и любая действующая технология программирования, была изобретена с целью повышения эффективности труда разработчика, требования к CASE-системам формулируются именно с этой точки зрения. Ниже следует изложение требований сформулированных Terry Moriarty в [3]:

1. Усиление методологии

Если продукт рекламируется, как поддерживающий определенные методологии анализа и проектирования, тогда он должен усиливать эти методологии. Усиление должно быть реализовано способом, который скорее помогает пользователю, а не наказывает его. Предположим, используется инструмент, который поддерживает методологию ГОЕР1Х для информационного моделирования. Пусть пользователь поместил две независимые сущности в модель и создал определяющее отношение между этими двумя сущностями. Инструмент должен удостовериться, что сущность-потомок в этом отношении - это зависимая сущность.

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

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

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

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

Хотя усиление правил методологии важно, в некоторых случаях требование может быть ослаблено. Например, некоторые диаграммы выполняются в первую очередь для презентации. Эти диаграммы должны быть выполнены простыми средствами, с целью подчеркнуть некоторые важные концепции высокого уровня, в этом случае точное следование методологии может помешать. Для этого типа диаграмм существенна возможность отключить правила методологии.

2. Поддержка архитектуры информационных систем

Данное положение является в действительности расширением первого.

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

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

Возможно, наибольший выигрыш в производительности может быть достигнут, если из спецификаций, записанных в инструменте CASE, автоматически получается исполняемый код, как для баз данных, так и для процессов. Так как многие компании разрабатывают для множества платформ, требуется возможность генерации приложений для разных платформ по единой спецификации. Инструменты для генерации тестовых ситуаций, SQL-скриптов

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

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

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

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

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

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