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

Санкт-Петербургский Государственный Университет

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

ГГБ ОД

Кознов

Дмитрий Владимирович

з и:он гзоо

Визуальное моделирование компонентного программного обеспечения

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

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

Санкт-Петербург 2000

Работа выполнена на кафедре системного программирования математико-механического факультета Санкт-Петербургского государственного университета.

Научпый руководитель - доктор физико-математических наук, профессор

Андрей Николаевич Терехов.

Официальные оппоненты: доктор физико-математических наук, профессор

Игорь Васильевич Поттосин, кандидат физико-математических наук, профессор Всеволод Павлович Котляров.

Ведущая организация - Санкт-Петербургский государственный университет аэрокосмического приборостроения.

Защита состоится "_" _ в _ часов на

заседании диссертационного совета К 063.57.54 по защите диссертаций на соискание ученой степени кандидата наук в Санкт-Петербургском государственном университете по адресу 198904, Санкт-Петербург, Библиотечная пл., д. 2.

С диссертацией можно ознакомиться в научной библиотеке Санкт-Петербургского государственного университета по адресу: 199034, Санкт-Петербург, Университетская набережная, 7/9.

Автореферат разослан "

Ученый секретарь диссертационного совета,

доктор физико-математических наук, профессор Б.К.Мартынснко

З^и-о о

Общая характеристика работы

Актуальность проблемы. Объектно-ориентированное визуальное моделирование является молодой и бурно развивающейся областью компьютерной инженерии. С начала 90-х годов по этой теме появляется много фундаментальных работ. Наибольшее влияние на формирование этой области оказывают исследования Г.Буча, И. Джакобсона, Д. Рэмбо, П.Коуда, Д.Харела, Б.Селика и др., усилиями которых создается стандарт в этой отрасли - язык UML (Unified Modeling Language). Общие методы объектно-ориентированного анализа и проектирования программного обеспечения оказывают существенное влияние на целое направление компьютерной инженерии - компонентный подход к созданию программного обеспечения (ПО), в частности, на методы с средства разработки систем реального времени. Например, компания Microsoft создала большое количество компонентных технологий под общим названием ActiveX, а международный комитет ITU (International Télécommunication Union) активно развивает семейство объектно-ориентированных стандартов для спецификации телекоммуникационных систем - языки SDL (Spécification and Description Language), MSC (Message Sequence Chart) и т.д.

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

Цель диссертационной работы: создание и реализация в рамках CASE'-пакета Real языка визуального моделирования для проектирования компонентного ПО со сложной событийно-ориентированной логикой и возможностью "автоматической генерации конечного кода. К языку моделирования предъявлялись следующие требования:

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

• удобство и лаконичность, выразительная сила;

• сквозной характер (преодоление семантических разрывов) — средства спецификации должны быть едиными на различных фазах создания ПО - от раннего анализа до кодогенерации.

Научная новизна диссертационной работы раскрывается в следующих результатах:

• методологический подход, обобщающий практический опыт разработки CASE-средств и предназначенный для построения эффективных

1 Computer Aided Software Engineering.

технологических решений применения CASE-пакета в конкретных проектах;

• расширенная модель классов UML, предназначенная для проектирования компонентных систем различных видов - систем реального времени, приложений, использующих различные распределенные компонентные архитектуры типа COM (Component Object Model), CORBA (Common Object Request Broker Architecture) и т.д.;

• поведенческая модель, совмещающая в себе черты расширенного конечного автомата SDL и STD2-диаграмм Харела, имеющая исполняемую семантику, являющаяся не замкнутым языком, а средством, предполагающим интеграцию с языками реализации системы; основное предназначение этого формализма - спецификация поведения систем реального времени с событийно-управляемой логикой.

Практическая ценность. Предложенный в диссертационной работе язык моделирования реализован в CASE-средстве Real 2.05. Методологический подход автора использован при создании стратегий возвратного проектирования и автоматической генерации документации по исходным текстам программ в различных проектах (кросс-компиляторы на С++, информационная система на Sybase/Delphi). Основные идеи компонентной и поведенческой моделей апробировались и использовались при разработке мобильной станции по стандарту ESTI GSM, Phase/2 (C++/Linux), в проекте по компьютерной телефонии (C++/Windows NT), при разработке ПО для телефонной станции (Алгол 68/Windows 95, операционная система реального времени "Бета").

Апробация работы и публикации. Основные идеи работы были изложены на семинарах: ИСП РАН (Москва, ноябрь 1999), ИСИ СО РАН "Технология программирования и системы программирования" (Новосибирск, октябрь 1999), МГУ (факультет ВМиК) "Автоматизация программирования" (Москва, ноябрь 1999). По теме диссертационной работы было опубликовано 7 научных работ и создано 3 научно-технических отчета.

Структура и объем работы. Диссертационная работа состоит из введения, семи глав, заключения, списка литературы. Работа содержит 86 страниц, 32 рисунка, список литературы из 62 наименований.

Содержание работы

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

В первой главе приводится обзор существующих объектно-ориентированных подходов к разработке ПО. Рассматриваются языки UML [12], SDL [10], методология RUP (Rational Unified Approach) [16], методы ROOM (Real-Time Object-Oriented Modeling) [13J, OOSE (Object-Oriented Software Engineering) [9], Буча [14] и Харела [15]. В результате обзора делаются следующие выводы:

• существующие методологии разработки ПО, основанные на визуальном моделировании, слишком общие для непосредственного применения и являются скорее философией (компьютерной инженерии вообще [9] или

State Transition Diagrams.

объектной ориентированности [14]), а не технологией; в них отсутствует сквозной характер, в числе их основополагающих принципов не учитываются критерии практической применимости;

• в приложении к задаче проектирования компонентного ПО рассмотренные средства визуального моделирования либо пригодны только для событийно-ориентированных систем [13], [10], либо как модель классов UML [12], слишком близки к языкам программирования (С++, Java и т.д.) и поэтому предоставляют низкоуровневые абстракции для эффективного проектирования;

• различные варианты расширенных конечных автоматов или семантически бедны, а потому неудобны для описания сложных телекоммуникационных алгоритмов [13], или богаты выразительными средствами, но не имеют строгой исполняемой семантики [12], или не предоставляют гибких выразительных средств для ранних фаз разработки алгоритмов [10].

• при обсуждении вопросов применимости поведенческой модели, как правило, ограничиваются определением классов задач [13], [15], оставляя за пределами рассмотрения проблему практической применимости и способы ее решения.

Во второй главе излагается методология CASE-пакета. Ее основное предназначение - создать методологический фундамент различным способам применения объектно-ориентированного визуального моделирования с помощью CASE-пакетов. При этом не делается попытка выработать общий рецепт, так как на бесполезность этого указывается в [9], [14], и практический опыт автора данной работы согласуется с этим выводом. Однако если эта задача не решается в общем виде, для любого ее частного случая решение существует. Это утверждение можно рассматривать как аксиоматический тезис, вытекающий из здравого смысла. Поэтому была поставлена цель обозначить и максимально формализовать положения, которые бы помогли в выработке конкретных решений по внедрению CASE-пакетов.

Основными положениями методологии CASE-пакета являются:

1. Предназначение визуального моделирования и определение CASE-пакета.

2. Принцип представления информации о разрабатываемой системе с точки зрения визуального моделирования.

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

4. Принципы моделирования - общин порядок использования языка и различных его частей (моделей).

5. Общие правила работы с CASE-пакетом.

6. Фиксированные типы стратегий использования языка визуального моделирования и CASE-пакета с возможностью создавать новые стратегии для конкретного класса задач или отдельного проекта.

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

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

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

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

Далее, необходимо описать общую философию использования визуального моделирования и CASE-пакета. На рис. 1 изображен принцип представления информации о разрабатываемой системе. Он имеет два измерения: первое соответствует взглядам (view) на систему в UML, второе определяет три уровня информации о системе - описания, схемы, программный код.

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

Схемы описывают каркас приложения - структуру классов системы или таблиц базы данных и т.д. Этот уровень, как правило, тесно связан с уровнем реализации через автоматическую генерацию текстов программ, возвратное проектирование (reverse engineering) и другие стратегии внесения изменений в проект с сохранением актуальности спецификаций обоих уровней. Если схема приложения определяется только на описательном уровне (т.е. в виде документов) или ее связь с уровнем реализации разовая (только через начальную water-fall генерацию), то сопровождение приложения остается проблемой, которую не решает используемое CASE-средство. Важность схем заключается в том, что всегда, когда говорится об автоматической генерации конечного кода по визуальным моделям, подразумевается генерация части

Схемы (логические и физические)

Программный код

Рис. 1. Принцип представления информации о разрабатываемой системе.

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

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

Представленная классификация информации о разрабатываемой системе проясняет возможные способы применения САБЕ-пакета: как средства документирования проекта, как средства построения схемы ПО с последующей кодогенсрацией или путем возвратного проектирования.

После того, как были намечены основные пути использования САБЕ-пакета, в работе рассматривается понятие языка визуального моделирования.

Принципы моделирования не зависят от САБЕ-пакета. Стратегии относятся и к языку моделирования, и к САБЕ-пакету, являясь реальными алгоритмами, выработанными для конкретного производственного процесса с целью оптимально использовать данный САБЕ-пакет. Технологическое решение является реализацией стратегий - в итоге пользователь получает СА8Е-пакет, интегрированный производственный процесс и готовый для использования. Связь между этими тремя понятиями показана на рис. 2.

Рис. 2. Связь принципов моделирования, стратегий и технологического

решения.

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

Различные типы стратегий определяются:

• специфическим способом применения языка моделирования и принципов моделирования в различных предметных областях;

• специфическим способом применения САБЕ-пакета для конкретного производственного процесса;

• механизмами импорта/экспорта информации для САЯЕ-пакета. Основными направлениями реализации выбранных стратегий в

технологическом решении являются:

• реализация связей данного САЗЕ-средства с другими пакетами, используемыми при разработке системы;

• определение точной семантики различных частей языка моделирования для данного случая;

• фиксация дисциплины проекта.

Положения методологии САБЕ-пакета структурируют процесс внедрения САЗЕ-средства и присутствуют в более-менее выраженной форме в

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

В третьей главе рассматривается часть языка моделирования Real, которая является расширением модели классов UML и предназначена для визуального проектирования компонентного ПО (компонентная модель). К классам UML добавляются порты; интерфейсы становятся бинарными, в них включаются сообщения, атрибуты и методы.

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

Интерфейс - это описание правил взаимодействия между двумя компонентами. Он определяется как абстрактный класс. Члены интерфейса содержатся в секции public; секций private и protected интерфейс не имеет. Между интерфейсами возможно отношение наследования.

Интерфейс может содержать сообщения, методы, атрибуты (все с обязательной пометкой направления), а также протокол, описанный при помощи диаграмм взаимодействий. Атрибуты имеют еще и права доступа -чтение/изменение. Методы и атрибуты интерфейса либо используются компонентой, либо реализуются. Сообщения могут посылаться или приниматься.

Интерфейсы подключаются к компонентам через порты. В один порт может быть подключено много интерфейсов, он может моделировать множественное подключение. Один и тот же интерфейс может быть подключен к разным портам одной и той же или разных компонент. На рис. 3 приводятся способы изображения портов и интерфейсов в компонентной модели Real.

Рис. 3. Способы изображения портов и интерфейсов. Итак, порт — это носитель конкретного соединения со стороны его компоненты. В простейшем случае порт реализуется как указатель на второго участника взаимодействия, в более сложном случае он может содержать

специальные данные, методы и таймеры для контроля целостности соединения и обработки данных.

Предложенная компонентная модель расширяет UML привлекая и обобщая событийно-ориентированными абстракции ROOM для проектирования компонентного ПО произвольной природы. Предлагаемое средство имеет точную семантику, что делает его пригодным для автоматической кодогенерации.

В четвертой главе описывается часть языка моделирования Real -поведенческая модель. Она является специфическим взглядом на поведение компоненты, основанным на понятиях состояние, событие, переход, действие. Данная поведенческая модель имеет две графических нотации: одну, основанную на STD, другую, основанную на SDL. CASE-пакет Real имеет два соответствующих графических редактора.

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

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

Переход - это линейная последовательность действий, осуществляемых компонентой вне состояния. В отличие от UML, переходы в Real следом за SDL не мгновенны. Переход компоненты из состояния в состояние может включать в себя несколько переходов поведенческой модели Real, связанных друг с другом через завершители различных типов - логическое ветвление, метку и т.д.

Событие — это единственный способ взаимодействия компонент Real. События могут создаваться либо самими компонентами, либо системой поддержки поведенческой модели уровня реализации (таймерные события).

Основные ограничения и предпосылки для создания поведенческой модели были следующими:

• закрепление поведенческой модели за компонентами системы;

• совмещение STD-днаграмм Харела и SDL-диаграмм в рамках одной модели;

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

• ориентация на создание законченных спецификаций для дальнейшей автоматической кодогенерации для систем реального времени с событийно-управляемой логикой;

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

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

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

системы решается просто: то, что создано с помощью STD-нотации, "загружается" на SDL-диаграммы, там дополняется и изменяется (и наоборот). Ниже приводятся достоинства SDL-нотации Real:

• больше графики чем в STD - составные части перехода изображаются в виде специальных графических символов;

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

возможностях:

• изображать действия в переходах в текстовом виде (что бывает в некоторых случаях предпочтительнее, чем иметь каждое из них в виде отдельного графического символа);

• располагать элементы диаграмм в произвольном порядке;

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

Таким образом, наличие двух нотаций существенно расширяет диапазон использования поведенческой модели. STD-нотацию можно применять на ранних этапах разработки системы - спецификации получаются более наглядными и компактными. SDL-нотацию лучше использовать при детальном проектировании, поскольку этот вид диаграмм более структурирован и соответствующий редактор можно сделать более удобным при работе с большими диаграммами (более 15-20 символов).

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

В пятой главе рассматривается часть пакета Real, которая реализует компонентную и поведенческую модели - редактор классов, STD-редактор, SDL-редактор.

Перечисляются и обсуждаются основные характеристики SDL-редактора:

• специфический вид изображаемого графа - наличие в нем остовного поддерева и его поддержка;

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

• возможность создавать элементы диаграмм в клавишном режиме без использования мыши;

• наличие текстового окна для отображения и редактирования информации о текущем графическом символе.

Отличия STD-редактора от SDL-редактора в следующем:

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

• возможность перераспределять сущности перехода по нескольким прямоугольникам;

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

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

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

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

• разбиение ПО на части: уровень схем, уровень реализации (системный уровень, реализуемый "вручную"), иные подсистемы, в разработке которых поведенческая и компонентная модели не используются;

• автоматическая генерация программного кода по уровню схем;

• распределение ПО между уровнем схем и уровнем реализации: на уровень схем попадает то, что может быть реализовано в виде объектов с единым механизмом обмена информацией, и результаты кодогеиерации приемлемы по быстродействию и расходу памяти;

• поведенческая модель не должна быть вырожденной;

• используемый CASE-пакет должен поддерживать итеративный процесс разработки;

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

поведенческой моделей на опыте конкретных телекоммуникационных проектов.

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

Данное исследование началось с создания интегрального языка моделирования и его реализации в рамках CASE-пакета Real. После получения первых результатов начались практические внедрения. Таким образом, фокус исследования оказался иным, чем у других работ по этой тематики. Его основной характеристикой стала интегральность - от языка моделирования до проблем использования CASE-пакетов.

Представленная в работе методология CASE-пакета конкретизирует схему компьютерной инженерии, представленной в [9]. В отличие от [9] детально обсуждаются требования к сервисам CASE-пакета и его архитектуре, фиксируется место визуального моделирования в процессе разработки ПО и обсуждается связь графических моделей с программным кодом. Понятие модели заимствовано из [14], определение языка визуального моделирования взято из [12]. Понятие стратегии близко к шаблонам и стратегиям из [11], однако существенно дополнено спецификой CASE-пакетов. Схемы и программный код заимствованы из [13] и дополнены уровнем описаний.

Представленная в работе компонентная модель расширяет модель классов UML. Понятие порта взято из [13] и расширено, из этой же работы взято понятие интерфейса, дополненное методами и атрибутами. В интерфейсах из [12] могут быть методы, но не сообщения, интерфейсы там односторонние. В [10] компоненты (процессы в терминологии SDL) могут общаться друг с другом с помощью методов и переменных, но там отсутствует понятие интерфейса. В данной работе предлагаются различные графические способы изображения интерфейсов, покрывающие возможности, представленные в [10], [13], а также рассматриваются новые варианты. Полученная компонентная модель расширяет по сравнению с [13] возможности взаимодействия компонент, но не столь проработана для проектирования систем на основе семиуровневой модели ISO/OSI. Кроме того при проектировании больших систем (более 50 типов компонент) в [13] есть хорошо проработанная модель агрегирования, которая отсутствует в предлагаемой компонентной модели. Таким образом, структурная модель из [13] в большей степени предпочтительна для проектирования больших систем. Для небольших и средних систем (до 10 и 50 типов компонент соответственно) обычно не нужны вложенные компоненты. В [13] есть возможность специфицировать динамически меняющуюся архитектуру системы, что отсутствует в предлагаемом подходе. В [17] динамический аспект модели из [13] специфицируется на диаграммах взаимодействий (collaboration diagrams). Дальнейшее развитие компонентной модели Real, пойдет по этому пути. По мнению автора, ни один из подходов, представленных в [10], [12], [13], не предоставляет необходимых абстракций для проектирования компонентного ПО, создаваемого на основе технологий ActiveX, Java Beans и др.

Поведенческая модель объединяет средства анализа сложных алгоритмов

[12] со средствами их полной спецификации [10], [13]. Следует отметить, что необходимость интеграции STD-диаграмм с SDL неоднократно обсуждалась в литературе, делались попытки ее формализации и реализации. Подход [19] в качестве перехода предлагает трансляцию. В данной работе предлагается интеграция на уровне единой модели, при этом STD-нотация урезана (как и в [19]), a SDL расширен, но так, что дополнительная семантика легко в нем выражается. При этом семантика взята из [10], понятие состояния - из [15] и

[13]. Понятие перехода изменено по сравнению с [10] на основе [13]. Создание полной спецификации с помощью поведенческой модели предполагает использование языка реализации (в виде различного вида вставок), однако, по сравнению с [13], событийно-ориентированные детали перехода попадают на уровень поведенческой модели, а по сравнению с [18] не фиксируется язык реализации.

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

• формализация различных итеративных стратегий связи диаграмм с программным кодом;

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

• разработка компонентной архитектуры CASE-пакета для его настройки под разные задачи.

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

Заключение

Основными результатами данной диссертационной работы являются:

• разработка сквозного подхода к созданию программного обеспечения с помощью объектно-ориентированных CASE-пакетов - от общей методологии до технологических решений в конкретных проектов;

• расширение модели классов UML - введение портов, добавление сообщений и атрибутов в интерфейсы с целью применения модели для проектирования компонентных систем различных видов (систем реального времени и приложений, использующих распределенные компонентные архитектуры типа COM, CORBA и т.д.);

• создание критериев применимости расширенной конечно-автоматной модели при создании систем реального времени с событийно-управляемой логикой;

• создание поведенческой модели, совмещающей в себе черты как расширенного конечного автомата SDL (рекомендации комитета ITU), так и STD-диаграмм Харела;

• промышленная реализация выработанных подходов в рамках CASE-пакета Real;

• апробация методологии и CASE-пакета в реальных проектах.

Публикации по теме диссертации

[1] Долгов П., Иванов А., Кознов Д., Лебедев А., Мурашева Т., Парфенов В., Терехов А. Объектно-ориентированное расширение технологии RTST. // Записки семинара кафедры системного программирования "CASE-средсгва RTST++". Вып. 1. — СПб, Издательство С.-Петербургского университета, 1998, с. 17-36.

[2] Иванов А., Кознов Дм., Мурашева Т., Поведенческая модель RTST++// Записки семинара кафедры системного программирования "CASE-средства RTST++". Вып. 1. ~ СПб, Издательство С.-Петербургского университета, 1998, с. 37-49.

[3] Кознов Дм. В. Проблемы разработки компонентного программного обеспечения. //Объектно-ориентированное визуальное моделирование / Под ред. Проф. Терехова А.Н. - СПб: Издательство С.-Петербургского университета, 1999. С.86-100.

[4] Кознов Дм. В. Конечный автомат - основа визуальных представлений поведения объектов // Объектно-ориентированное визуальное моделирование / Под ред. Проф. Терехова А.Н. - СПб: Издательство С.-Петербургского университета, 1999. С. 101-122.

[5] Терехов А.Н., Романовский К.Ю, Козпов Дм. В., Долгов П.С., Иванов А.Н. Объектно-ориентированная методология разработки информационных систем и систем реального времени. // Объектно-ориентированное визуальное

моделирование / Под ред. Проф. Терехова А.Н. - СПб: Издательство С.-Петербургского университета, 1999. С.4-20.

[6] Романовский К.Ю, Кузнецов С.В., Кознов Дм. В. Объектно-ориентированная подход и диаграммы классов в UML. //Объектно-ориентированное визуальное моделирование / Под ред. Проф. Терехова А.Н. - СПб: Издательство С.-Петербургского университета, 1999. С.21-56.

[7] А.Н.Терехов К.Ю.Романовсхий, Дм.В.Кознов, П.С.Долгов, А.Н.Иванов. Real: Методология и CASE-средство для разработки систем реального времени и информационных систем // Программирование, 1999, N 5.

[8] К.Ю.Романовский, Б.Д.Ивановский, Дм.В.Кознов, П.С.Долгов "Обзор нотаций методологии Real". http://www.tepkom.ru/products/real/Publications.asp. Технический отчет. 1999.

Цитируемая литература

[9] I.Jacobson. Object-Oriented Software Engineering. ASM press. 1992, 528 p.

[10] ITU Recommendation Z.100: Specification and Description Language. 1993. 204 P-

[11] B.P.Douglass. Real-Time UML. Addison-Wesley, 1998. 365 p.

[12] OMG Unified modeling language spesification (draft). Version 1.3R. http://www.rational.com/uml. 1999.

[13] B.Selic, G.Gullekson, P.T. Ward. Real-Time Object-Oriented Modeling. John Wiley & Sons. Inc. 1994. 525 p.

[14] Booch G. Object-Oriented Analysis And Design With Application, second edition. The Benjamin/Cummings Publishing Company, Inc. 1994. 589 p.

[15] D.IIarel, M.Politi. Modeling Reactivc Systems with Statecharts: state machine approach. McGraw-Hill. 1998.258 p.

[16] P. Kruchten. The Rational Unified Process: An Introduction. ADDISON-WESLEY. 1998. 255 p.

[17] B.Selic, J.Rumbaugh. Using UML for Modeling Complex Real-Time Systems. ObjecTime. http:/Avww.obiectime.on.ca/. 1998.22 p.

[18] Бардзинь Я.М., Калкиньш A.A., Стродс Ю.Ф., Сыцко В.А. Язык спецификаций SDL/PLUS и его применения. Рига 1988, 313 с.

[19] Wasowski М., Witaszek D., Verschaeve К., Wydaeghe В., Holz Е., Jonckers V. Methodology (the comlete OMT*). Report 1.4, December 1995. 102 p.