WS Electronic Publication 2002

РАЗРАБОТКА МОДЕЛИ ВИРТУАЛЬНОГО МУЗЕЯ НА ОСНОВЕ CASE-ТЕХНОЛОГИЙ.

А.А. Зарубин

Институт Угля и Углехимии СО РАН

Кемерово, Россия

e-mail: zarubin@nktec.kuzbe.elektra.ru

Ускорившиеся темпы создания и накопления информации, усложнение и глобализация знаний сделали необходимым поиск инструментов, позволяющих обеспечить быстрый и эффективный доступ к различным знаниям, рассеянным по разным источникам. Одним из таких инструментов по праву считаются технологии электронных коллекций, развитие которых началось в 1990-х годах. Электронные коллекции представляют собой перспективные формы сложных распределенных информационных систем и рассматриваются как основа создания глобального распределенного хранилища знаний. Электронная коллекция – это распределенная информационная система, позволяющая надежно сохранять и эффективно использовать разнородные массивы объектов (текст, графика, аудио, видео и др.), доступные в удобном для пользователя виде через глобальные сети передачи данных [1]. Наиболее близка идея электронных коллекций к традиционным музеям – та же идея об интеграции различных типов информации, та же четко выделенная иерархия отделов и экземпляров, а также возможность одновременно принять достаточно большое количество посетителей.

Поэтому неудивительно, что сегодня в Интернете существует множество проектов электронных коллекций, и в частности, электронных музеев. В качестве примера можно привести электронный музей Нобеля (www.nobel.se, JavaScript), Лувра (www.louvre.fr/louvrea.htm, HTML). Не отстают от западных коллег и российские разработчики электронных музеев, например, Государственный Эрмитаж располагает собственным электронным музеем, расположенным по адресу www.hermitage.ru (CGI). На начало 2002 года в Интернете находятся порядка 400 ссылок на электронные музеи (по данным поисковой системы Яндекс). Одной из разновидностей виртуальных музеев являются геоинформационные музеи, предоставляющие данные о полезных ископаемых, флоре, и пр. По данным того же источника ссылок на них насчитывается порядка 150. Это показывает достаточно широкую распространенность таких коллекций среди научных центров России.

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

HTML	DHTML	JAVA	CGI	PHP(API)	XML(XHTML)	другие
40	10	15	18	10	3	2

Первое место с большим отрывом занимает HTML, и это отражает существующее положение дел в этой области. Несмотря на возникновение новых, перспективных технологий – Java, XML и пр., по-прежнему основой для большинства сайтов служит стандарт, безнадежно отстающий от современных требований и имеющий больше недостатков, чем достоинств. Другие технологии даже если и используются, то в основном в виде небольших вкраплений на HTML-страницах. Другой крайностью является написание громадных и сложных программ, выполняемых по технологии CGI/API. Все эти способы имеют один существенный минус – не предполагается наличия четкой формализованной информационной модели, и, следовательно, сайты, сделанные на основе только этих технологий (без использования CASE-средств) имеют жесткую, трудноизменяемую структуру. Вследствие этого поддержка подобных проектов требует высоких временных и ценовых затрат. CASE-средства позволяют свести издержки связанные с разработкой и поддержкой программного обеспечения к минимуму. Одним из постулатов CASE-средств является возможность в простой и наглядной форме смоделировать предметную область информационной системы, прежде чем начинать ее программную разработку, т.е. построить так называемые визуальные модели. На дальнейших этапах сложность разрабатываемых систем будет постоянно расти, однако визуальные модели информационных систем позволяют обеспечивать ясность представления выбранных архитектурных решений и понять разрабатываемую систему во всей ее полноте. Таким образом, уже на ранних этапах проектирования снижается риск возникновения ошибок, которые могут привести в дальнейшем к пересмотру все модели и, следовательно, к большим временным задержкам. CASE-средства поддерживают все основные этапы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. Помимо этого самые современные средства визуального моделирования (CASE) предоставляют возможности обновления кода (Code update) по изменениям в модели и наоборот, обновления модели из кода, что максимально упрощает поддержку электронных приложений.

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

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

· легкость и простота модификации;

· соответствие современным требованиям к оформлению интерфейса онлайнового музея;

· платформонезависимость;

· независимость от языка программирования и СУБД;

· небольшие материальные затраты на разработку и использование;

· максимальная автоматизация процесса разработки и поддержки музея.

На данный момент на рынке существует множество CASE-средств, позволяющие моделировать различные аспекты работы приложения. Одни служат для создания функциональной модели, т.е. описания функциональных возможностей программы (BPWin фирмы PLATINUM technology), другие позволяют строить объектные модели, отражающие предметную область (Rational Rose компании Rational Software), и, наконец, при помощи последних возможно создание логической и физической моделей баз данных (ERwin). Отметим, что функциональный и объектный подходы к разработке приложений являются в каком-то роде конкурентными, в то время как моделирование БД необходимо в обоих случаях. Во многих случаях в среде CASE присутствует поддержка сразу нескольких типов моделей. Примером такого средства может послужить продукт Rational Rose 2002 Enterprise – лидер на рынке продуктов для объектно-ориентированного анализа, моделирования, проектирования и инструментальных средств разработки.

Rational Rose полностью поддерживает стандарт UML 1.4, содержит инструменты для генерации кода основных языков программирования, имеет удобный и интуитивный интерфейс, содержит такие возможности как создание модели из исходного текста, обновление модели из кода и кода из модели. Помимо этого в состав Rational Rose входят несколько «мостов» для связи с другими средствами проектирования: ERWin, Oracle 8 и.т.д.

Наконец, начиная с версии 2000, в Rational Rose включены средства для разработки моделей баз данных - DataModeler. Ранее для создания модели БД ее либо приходилось проектировать в специализированном CASE-средстве (например, в ERWin), либо создавать объектную модель, а затем экспортировать ее в тот же ERWin для доработки и создания БД. Это приводило к потере времени и средств. Теперь же Rational Rose Data Modeler позволяет использовать один продукт и один язык для написания проекта полностью, стирая грани между объектной моделью и моделью данных.

Объектная модель создана в нотации UML и представляет собой формализованную структуру любого электронного музея. Модель содержит как интерфейс, отражающий работу посетителя с музеем: аутентификация, выбор отдела музея, выбор экземпляра и пр., так и логику ПО, обеспечивающую работу музея: выбор информации из БД, ее визуализацию, редактирование БД и.т.д.

Создание объектной модели было разделено на три этапа. На первом этапе построена основная диаграмма «вариантов использования» (use case diagram).

Эта диаграмма описывает функциональность информационной системы, основные ее действия и возможности, служит основой всей модели. При построении диаграммы был использован принцип декомпозиции, который заключается в нижеследующем. Сначала после предварительно проведенного анализа задача разбивается на несколько крупных блоков, т.н. «вариантов использования», каждый из которых отражает часть программной логики приложения. В нашем случае диаграмма содержит несколько действующих лиц (актеров), представляющих собой посетителей музея с разными правами доступа: гость, администратор и оператор БД, каждый из которых может выполнять определенные действия, например актер «Посетитель» может использовать вариант «Идентификация», т.е. идентифицироваться в музее, а актер «Администратор» может применить вариант «Назначить права доступа» и.т.д. Таким образом, в данной модели на диаграмме вариантов использования изображены лишь всевозможные действия посетителей музея, что не полностью отражает работу программы. Для этого логика каждого из вариантов использования по принципу декомпозиции уточняется более подробными вложенными диаграммами. Это могут быть как диаграммы вариантов использования, так и другие диаграммы. Эта процедура должна продолжаться до полного понимания работы приложения. Такой принцип моделирования позволяет строить программное обеспечение «сверху-вниз», что способно существенно сократить затраченное время и ошибки в разработке. В результате была получена функциональная модель, пусть и уступающая полноценным моделям в нотации IDEF0, но, тем не менее, в полной мере отражающая возможности музея.

После построения функциональной структуры приложения в виде диаграммы вариантов использования на следующем этапе была построена диаграмма классов (Class diagram), которая и служит основой для генерации программного кода на выбранном языке программирования. Эта диаграмма является центральной частью модели музея. Она содержит все необходимые классы музея: актеров, экранов музея, баз данных и прочие. Классы в объектной модели Rational Rose, отраженные на диаграмме классов, полностью соответствуют канонам объектно-ориентированного программирования, - каждый класс содержит атрибуты, – какие-либо данные, и операции, выполняющие какие-либо действия над атрибутами. Так же на этой диаграмме показываются некоторые аспекты взаимодействия классов – отношения генерализации, связи и.т.д. Для примера приведем класс «Экран экземпляра», получающий ID выбранного экземпляра, инициализирующий экран вывода и выводящий информацию об экземпляре на экран:

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

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

Так же на этом этапе была построена логическая модель БД. Структура модели в Data Modeler напоминает схемы (schema) СУБД Oracle. Классы таблиц, а также связи между ними, индексы, ключи, также были отражены на диаграмме классов, что позволило связать объектную модель и модель БД воедино и лучше показать логику приложения. Data Modeler также поддерживает триггеры и хранимые процедуры. После окончания разработки модели данных был сгенерирован DDL-скрипт, который содержит SQL-инструкции по созданию структуры баз данных и может быть выполнен в любой SQL-ориентированной СУБД.

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

· Диаграммы взаимодействия объектов (Collaboration diagram)

· Диаграммы последовательности взаимодействий (Sequence diagram)

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

Например, приведем диаграмму последовательностей для варианта использования «Выбор экземпляра».

Сначала класс «Экран выбора отдела» инициирует выполнение классом «Экран выбора экземпляра» операции инициализации экрана. Далее происходит запрос в БД «Экземпляры» списка всех экземпляров выбранного отдела музея и инициализация диалога выбора экземпляра (заметим, что здесь возможна дальнейшая декомпозиция). После выбора актером «Посетитель» номера экземпляра происходит инициализация класса «Экран экземпляра».

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

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

После построения «очередного слоя» модели можно провести генерацию приложения. На уровне кода можно ввести новые классы, изменить атрибуты и операции классов модели и затем синхронизовать код и модель, выполнив "обратное проектирование". Т.е. по модифицированному коду Rational Rose позволяет построить новую диаграмму классов. Повторение такой процедуры несколько раз называется итерационным моделированием (round-trip modeling), которое составляет основу постепенного уточнения постановки задачи и согласования требований, предъявляемых к программе, с имеющимися ресурсами.

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

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

Список литературы

1. Александр Фролов и Григорий Фролов. Базы данных в интернет. – М. Издательско-торговый дом «Русская Редакция», 2000 – 432 с.

Научный электронный журнал "Электронные библиотеки" www.iis.ru/el-bib/
Электронный музей Нобеля. www.nobel.se
Официальный сайт Лувра. www.louvre.fr
Эрмитаж. www.hermitage.ru
www.citforum.ru
www.obana.ee

Ваши комментарии
Обратная связь

[Головная страница]
[Конференции]
[СО РАН]

VII Международная конференция по электронным публикациям "EL-Pub2002"