авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 3 | 4 || 6 |

«Федеральное агентство по образованию ГОУ ВПО Уфимский государственный авиационный технический университет Управление в сложных системах ...»

-- [ Страница 5 ] --

Н.О. Никулина, Л.Р. Хусаинова Сравнительный анализ стандартов… УПРАВЛЕНИЕ В СОЦИАЛЬНЫХ И ЭКОНОМИЧЕСКИХ СИСТЕМАХ УДК 005. СРАВНИТЕЛЬНЫЙ АНАЛИЗ СТАНДАРТОВ ЖИЗНЕННОГО ЦИКЛА ИС ГОСТ 34.601- И ISO/IEC Н.О. НИКУЛИНА, Л.Р. ХУСАИНОВА* *Уфимский государственный авиационный технический университет Аннотация: Для моделирования жизненного цикла информацион ной системы можно использовать различные стандарты. Однако акту альной является тема сравнения двух конкретных стандартов: ГОСТ 34.601-90 и ISO/IEC 12207. В статье приведен сравнительный анализ этих стандартов. Даны описания процессов, моделей и стадий жиз ненного цикла информационной системы. Результаты анализа осно вываются на общей структуре и особенностях двух стандартов.

Ключевые слова: информационная система (ИС) ;

жизненный цикл информационной системы (ЖЦ ИС) ;

процессы жизненного цикла ;

стадия жизненного цикла ;

модель жизненного цикла ;

стандарт.

1. ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ИС Информационная система (ИС) — это система, реализующая информационную модель предметной области, чаще всего — какой либо области человеческой деятельности. ИС должна обеспечивать:

получение (ввод или сбор), хранение, поиск, передачу и обработку (преобразование) информации. Жизненный цикл информационной системы — период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации2.

Основные процессы жизненного цикла:

• Приобретение (действия и задачи заказчика, приобретаю щего ИС);

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

Братищенко В.В. Проектирование информационных систем. — Иркутск: Изд-во БГУЭП, 2004. — 84 с.

Стандарт IEEE Std 610.12, Глоссарий ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 • Разработка (действия и задачи, выполняемые разработчи ком: создание ПО, оформление проектной и эксплуатационной до кументации, подготовка тестовых и учебных материалов и т. д.);

• Эксплуатация (действия и задачи оператора — организа ции, эксплуатирующей систему);

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

Вспомогательные процессы ЖЦ:

• Документирование (формализованное описание информа ции, созданной в течение ЖЦ ИС);

• Управление конфигурацией (применение административ ных и технических процедур на всем протяжении ЖЦ ИС для опре деления состояния компонентов ИС, управления ее модификация ми);

• Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержден ным планам);

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

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

• Совместная оценка (оценка состояния работ по проекту: кон троль планирования и управления ресурсами, персоналом, аппара турой, инструментальными средствами);

• Аудит (определение соответствия требованиям, планам и условиям договора);

• Разрешение проблем (анализ и решение проблем, независи мо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов).

Организационные процессы ЖЦ:

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

• Создание инфраструктуры (выбор и сопровождение техноло гии, стандартов и инструментальных средств, выбор и установка ап Н.О. Никулина, Л.Р. Хусаинова Сравнительный анализ стандартов… паратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО);

• Усовершенствование (оценка, измерение, контроль и усо вершенствование процессов ЖЦ);

• Обучение (первоначальное обучение и последующее посто янное повышение квалификации персонала).

Каждый процесс включает ряд действий. Каждое действие включает ряд задач.

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

1. Стадии, 2. Результаты выполнения работ на каждой стадии, 3. Ключевые события — точки завершения работ и принятия решений.

2. МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ИС • Каскадная модель жизненного цикла («модель водопада», англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом.

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

• Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act).4 При использовании этой модели ИС создается в несколько итераций (витков спирали) мето Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М.: Финансы и статистика, 2000.

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. — М.: Интернет университет информационных технологий - ИНТУИТ.ру, 2005.

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 дом прототипирования. Каждая итерация соответствует созданию фрагмента или версии ИС, на ней уточняются цели и характеристи ки проекта, оценивается качество полученных результатов и плани руются работы следующей итерации.

• Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональной сочетание этих моде лей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов: RUP, MSF, XP.

3. СРАВНИТЕЛЬНЫЙ АНАЛИЗ СТАНДАРТОВ ГОСТ 34.601-90 И ISO/IEC 3.1 МЕЖДУНАРОДНЫЙ СТАНДАРТ ISO/IEC 12207: 1995 08- Стандарт ISO/IEC 12207:1995 «Information Technology — Software Life Cycle Processes» («Информационные технологии – Про цессы жизненного цикла программ») является основным норматив ным документом, регламентирующим состав процессов жизненного цикла ИС. Этот стандарт разработан подкомитетом SC 7, совместно го технического комитета ISO/IEC JTC 1 организаций ISO и IEC (the International Electrotechnical Commission). Есть его российский ана лог ГОСТ Р-1999. Первая редакция ISO12207 подготовлена в году объединенным техническим комитетом ISO/IEC JTC1 «Инфор мационные технологии, подкомитет SC7, проектирование про граммного обеспечения».

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ. Стандарт ISO равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь);

может быть в равной степени применен, когда обе стороны - из од ной организации 5.

http://www.lib.csu.rudlbasesprgdbms Н.О. Никулина, Л.Р. Хусаинова Сравнительный анализ стандартов… 4.1.1 ОБЩАЯ СТРУКТУРА Основные процессы ЖЦ ПО:

1. Процесс приобретения. Определяет действия предприятия покупателя, которое приобретает АС, программный продукт или сервис ПО.

2. Процесс поставки. Определяет действия предприятия поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.

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

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

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

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

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

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 4.1.2 ОСОБЕННОСТИ «Динамический» характер стандарта определяется способом оп ределения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть.

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

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

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

При выполнении анализа требований к ПО предусмотрено классов характеристик качества, которые используются позже при гарантировании качества и корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ34 по видам обеспечения системы.

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

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

Степень обязательности: после решения организации о приме нении ISO12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых про Н.О. Никулина, Л.Р. Хусаинова Сравнительный анализ стандартов… цессов и задач, которые составляют согласованность с этим стандар том.

Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как раз ные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать БД вовсе.

3.2 СТАНДАРТ ГОСТ 34.601- ГОСТ 34.601-90 задумывался в конце 80-х годов как всеобъем лющий комплекс взаимоувязанных межотраслевых документов.

Объектами стандартизации являются АС различных видов и все виды их компонентов, а не только ПО и БД.

Комплекс рассчитан на взаимодействие заказчика и разработ чика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализи рованное подразделение). Однако формулировки ГОСТ 34.601-90 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ 34.601-90 в основном уделяет внимание содержанию проектных до кументов, распределение действий между сторонами обычно делает ся, отталкиваясь от этого содержания. 3.2.1 ОБЩАЯ СТРУКТУРА ГОСТ 34.601-90 (Стадии создания АС) считается наиболее попу лярным. Стандарт предусматривает стадии и этапы выполнения ра бот по созданию АС, но не предусматривает сквозных процессов в явном виде.

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

1. ФТ- Формирование требований к АС 1. Обследование объекта и обоснование необходимости создания АС;

2. Формирование требований пользователя к АС;

3. Оформление отчета о выполнении работ и заявки на разработ ку АС.

2. РК- Разработка концепции АС http://www.lib.csu.rudlbasesprgdbms ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 1. Изучение объекта;

2. Проведение необходимых научно-исследовательских работ;

3. Разработка вариантов концепции АС и выбор варианта кон цепции АС, удовлетворяющего требованиям пользователей;

4. Оформление отчета о проделанной работе.

3. ТЗ- Техническое задание 1. Разработка и утверждение технического задания на создание АС;

4. ЭП- Эскизный проект 1. Разработка предварительных проектных решений по системе и ее частям;

2. Разработка документации на АС и ее части.

5. ТП- Технический проект 1. Разработка проектных решений по системе и ее частям;

2. Разработка документации на АС и ее части;

3. Разработка и оформление документации на поставку ком плектующих изделий;

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

6. РД- Рабочая документация 1. Разработка рабочей документации на АС и ее части;

2. Разработка и адаптация программ.

7. ВД- Ввод в действие 1. Подготовка объекта автоматизации;

2. Подготовка персонала;

3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплекса ми, информационными изделиями);

4. Строительно-монтажные работы;

5. Пусконаладочные работы;

6. Проведение предварительных испытаний;

7. Проведение опытной эксплуатации;

8. Проведение приемочных испытаний;

8. Сп- Сопровождение АС.

1. Выполнение работ в соответствии с гарантийными обязатель ствами;

2. Послегарантийное обслуживание.

Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно Н.О. Никулина, Л.Р. Хусаинова Сравнительный анализ стандартов… или последовательно (то есть по сути - процессов), и составляющих их задач. Такой прием может использоваться при построении про филя стандартов ЖЦ проекта, включающего согласованные под множества стандартов ГОСТ 34.601-90 и ISO12207.

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

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

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

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

определять уровень качества результата;

выбирать те конкретные методики (с их моделями ЖЦ, набо ром документов и др.), которые наиболее подходят к условиям раз работки и соответствуют используемым Информационным Техноло гиям;

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

Разработчики комплекса стандарта ГОСТ 34.601-90 выбрали способ, близкий к первому из указанных выше, то есть пошли по пу ти, более близкому к схемам конкретных методик, чем к стандартам типа ISO12207. Тем не менее, благодаря общности понятийной базы стандарт остается применимым в весьма широком диапазоне случа ев.

Степень адаптивности формально определяется возможностями:

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 опускать стадию эскизного проектирования и объединять ста дии «Технический проект» и «Рабочая документация»;

опускать этапы, объединять и опускать большинство докумен тов и их разделов;

вводить дополнительные документы, разделы документов и работы;

динамически создавая т. н. ЧТЗ - частные технические задания - достаточно гибко формировать ЖЦ АС;

как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

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

Введение единой, достаточно качественно определенной терми нологии, наличие достаточно разумной классификации работ, доку ментов, видов обеспечения и другое безусловно полезно. ГОСТ 34.601-90 способствует более полной и качественной стыковке дейст вительно разных систем, что особенно важно в условиях, когда раз рабатывается все больше сложных комплексных АС.

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

Прежняя полная степень обязательности отсутствует, материа лы ГОСТ 34.601-90, по сути, стали методической поддержкой, при чем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ 34.601-90 может многократно возрасти в случае их более гиб кого использования при формировании профиля ЖЦ АС.

Ключевым документом взаимодействия сторон является ТЗ техническое задание на создание АС. ТЗ является основным исход ным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика.

Н.О. Никулина, Л.Р. Хусаинова Сравнительный анализ стандартов… 3.3 РЕЗУЛЬТАТЫ АНАЛИЗА ISO12207 имеет набор процессов, действий и задач, охватываю щий наиболее широкий спектр возможных ситуаций при макси мальной адаптируемости. Он показывает пример того, как должен строиться хорошо организованный стандарт, содержащий минимум ограничений (принцип «нет одинаковых проектов»). При этом де тальные определения процессов, форм документов и т. п. целесооб разно выносить в различные функциональные стандарты, ведомст венные нормативные документы или фирменные методики, которые могут быть использованы или не использованы в конкретном проек те.

По этой причине центральным стандартом, положения которого берутся за начальный «стержневой» набор положений в процессе по строения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO12207. Этот «стержень» может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования каче ства, модель управления проектом. Другие стандарты или материа лы полезно включать в профиль теми положениями, требованиями и методами, которые:

а) согласовывают модель ЖЦ с требованиями стандартов на АС в целом и ее компоненты, отличные от ПО;

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

Стандарт ГОСТ 34.601-90 могут с пользой применять при созда нии профиля стандартов на АС, если его использовать в открытом и динамичном стиле, определяемом ISO12207. ГОСТ 34.601-90 полно и фундаментально определяет: систему как объект создания или развития;

аналитические и, при необходимости, исследовательские работы, направленные на разработку обоснованной концепции АС;

виды т. н. «обеспечений» системы, которые хорошо гармонизируются с требованиями ISO12207 к системе и ПО, и т. п. Материалы ГОСТ 34.601-90 почти так же, как и ISO12207, а, может быть, еще более четко определяют, что АС - это в первую очередь люди, которые вы полняют свои функции с помощью Информационных Технологий.

ГОСТ 34.601-90 благодаря своей комплексной ориентации на систему помогает избегать ситуаций, в которых разработчики раз ных профессий (например, финансовые аналитики, специалисты по оргструктурам и человеческому фактору, проектировщики баз дан ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 ных и др.) говорят на столь разных языках, что страдает итоговая цельность проекта, глубина комплексной проработки.

СПИСОК ЛИТЕРАТУРЫ 1) Жизненный цикл информационной системы [Электронный ресурс] (http://ru.wikipedia.org/wiki/) 2) http://www.lib.csu.rudlbasesprgdbms19970341.html [Элек тронный ресурс].

3) Братищенко, В.В. Проектирование информационных сис тем / В.В. Братищенко. Иркутск : БГУЭП, 2004. 84 с.

4) Вендров А.М. Проектирование программного обеспечения экономических информационных систем / А.М. Вендров. М. : Финан сы и статистика, 2000.

5) Грекул, В.И. Проектирование информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. М. : Интернет университет информационных технологий, 2005.

В.В. Миронов, Г.Р. Шакирова К вопросу о программной реализации … МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН … УДК 004. К ВОПРОСУ О ПРОГРАММНОЙ РЕАЛИЗАЦИИ ИНСТРУМЕНТАЛЬНОГО СРЕДСТВА ДЛЯ СОЗДАНИЯ И ВЕДЕНИЯ ДИНАМИЧЕСКИХ XML-ДОКУМЕНТОВ В. В. МИРОНОВ, Г. Р. ШАКИРОВА* *Уфимский государственный авиационный технический университет Аннотация: Обсуждаются вопросы проектирования и реализации программно-инструментального средства для создания и ведения XML-документов со встроенной динамической моделью. Дается харак теристика используемой технологии программной реализации, при водится обоснование ее выбора. Рассматриваются особенности про граммной реализации всех модулей инструментального средства для создания и ведения динамических XML-документов.

Ключевые слова: XML-документ ;

встроенная модель ;

платформа.NET ;

программно-инструментальное средство.

ВВЕДЕНИЕ Понятие динамического документа (ДД) было введено в работе [1]. Под ДД которым понимается документ, который содержит встро енную динамическую модель своего создания и использования. В качестве инструментального средства создания и ведения ДД в ра боте [1] используется текстовый процессор Microsoft Word, а сами динамические документы являются документами Word. Внутренняя структура встроенной модели реализуется посредством макросов, а ее внешнее представление – с помощью соответствующих элементов управления, поддерживаемых в пользовательских формах.

Однако подобный подход, хотя и реализует концепцию динами ческих документов, не является в полной степени оправданным. Ие рархическая структура встроенной динамической модели, основан ная на этом метода реализации, не является очевидной. Кроме того, при использовании doc-формата возникают сложности при публика ции материалов в Интернет. К тому же, Word-документы не облада ют достаточно гибкой межплатформенной переносимостью, что не ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 приемлемо в процессе обмена электронными документами. Еще од ним существенным недостатком существующего подхода является то, что он не является универсальным. Разработанный программно инструментальный комплекс жестко привязан к той практической задаче, которая ставилась перед разработчиком (а именно, к созда нию и ведению комплекса документов из диссертационного дела со искателя ученой степени).

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

Анализ существующих технологий представления и обработки электронных документов показал, что оптимальной технологией для динамических документов является XML. Эта идея получила разви тие в понятии динамических XML-документов (XML-DD), представ ляющих собой XML-документы со встроенной динамической моде лью [2, 3].

1. ТЕХНОЛОГИЯ ПРОГРАММНОЙ РЕАЛИЗАЦИИ Очевидно, что главным требованием, предъявляемым к языку программирования для реализации программно-инструментального средства создания и ведения XML-DD, является поддержка XML.

Для разработки инструментария создания и ведения XML-DD была выбрана платформа.NET Framework и ее основной язык – C#.

Среди преимуществ.NET Framework по сравнению с другими технологиями можно отметить:

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

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

• простота (по сравнению с COM-технологиями) [4] и т. д.

Что касается поддержки XML, можно отметить намного более функционально развитую библиотеку классов, которую предостав ляет платформа.NET для манипулирования XML-данными, по сравнению с традиционными языками программирования.

В.В. Миронов, Г.Р. Шакирова К вопросу о программной реализации … Общая структура классов.NET Framework, связанных с обра боткой XML-данных, представлена на рис. 1.

W3C XML DOM Level 2 Core XmlNode XmlElement XmlDocument XmlAttribute XmlReader XPathNavigator XmlWriter XPath Xml 1. XslTransform Namespaces Schemas XmlResolver XmlNameTable Рис. 1. Схема взаимодействия классов XML.NET в пространстве имен System.XML Таким образом, представленные классы Microsoft.NET Frame work обеспечивают поддержку стандартов XML и предоставляют мощный API для доступа к XML-документам. В сочетании с прин ципами объектно-ориентированного подхода это позволяет разрабо тать программно-инструментальное средство, обеспечивающее под держку любых операций манипулирования XML-DD.

2. АРХИТЕКТУРА ИНСТРУМЕНТАЛЬНО-ПРОГРАММНОГО СРЕДСТВА На основе описанной выше технологии было разработано про граммно-инструментальное средство «XML-DD Manager», предна значенное для создания и ведения XML-DD [6].

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

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

Основной модуль является связующим звеном между всеми остальными модулями программно-инструментального средства. В рамках этого модуля выполняется вызов всех остальных программ ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 ных модулей и задание пользовательских настроек, необходимых для работы с XML-DD.

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

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

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

Модуль работы с ассоциированными фрагментами. Со гласно концепции XML-DD, с каждым состоянием модели ассоции рованы один или несколько фрагментов документа. Поэтому преду смотрена возможность последовательной обработки каждого фраг мента, ассоциированного с ситуацией.

3. ОСОБЕННОСТИ ПРОГРАММНОЙ РЕАЛИЗАЦИИ Разметка XML-DD является самостоятельным языком описания данных, разработанным в соответствии с синтаксисом XML. Ее обра ботка должна базироваться на функциональных возможностях XML парсера, осуществляющего проверку синтаксиса документа. Следо вательно, для XML-DD должен быть разработан собственный пар сер, который позволит выполнять обработку документов такого типа с точки зрения как их синтаксиса, так и семантики.

В.В. Миронов, Г.Р. Шакирова К вопросу о программной реализации … 3.1. Основной модуль Основной модуль служит связующим звеном между всеми ос тальными модулями. Вызов функций этих модулей осуществляется через соответствующие пункты меню.

После загрузки XML-DD необходим механизм, позволяющий свободно оперировать иерархией элементов и атрибутов. В.NET для работы с XML-документами используются классы XmlReader, XmlWriter и XmlDocument.

Классы XmlReader и XmlWriter – это абстрактные базовые клас сы, предоставляющий некэшируемый однонаправленный доступ со ответственно только для чтения (XmlReader) и только для записи (XmlWriter).

Класс XmlDocument реализует W3C Document Object Model (DOM) Level 1 Core и Core DOM Level 2, предназначенные для пред ставления XML-документа в памяти. DOM позволяет программно читать, управлять и изменять XML-документ. Это распространен ный и структурированный способ представления XML-данных в па мяти. При считывании XML в DOM, его части переводятся в узлы, и эти узлы сохраняют дополнительные метаданные о себе, такие как тип узла и значения.

Поскольку администрирование XML-DD предполагает постоян ное изменение значений атрибутов, создание новых и изменение существующих элементов и атрибутов, то применение класса XmlDocument позволит обеспечить большую функциональность по сравнению с классами чтения и записи XmlReader и XmlWriter.

Для загрузки XML-файла используется метод Load класса XmlDocument. Метод Load загружает XML-документ в память. В ка честве параметра ему передается полное имя загружаемого файла, полученное с помощью диалогового окна открытия файла:

...

dlg.ShowDialog();

filename = dlg.FileName;

XmlDocument dom = new XmlDocument();

dom.Load(filename);

Еще одна функция основного модуля – задание пространства имен, которое используется для описания элементов модели XML DD. Согласно модели XML-DD, это пространство имен задано под префиксом hsm, для которого в качестве URI используется иденти фикатор http://asu.ugatu.ac.ru/hsm. Для определения пространств имен в.NET используется класс XmlNamespaceManager. В качестве ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 параметра этому классу передается совокупность имен элементов и атрибутов в заданной иерархии:

XmlNamespaceManager nsmgr = new XmlNamespaceManager(dom.NameTable);

nsmgr.AddNamespace("hsm", "http://asu.ugatu.ac.ru/hsm");

3.2. Модуль навигации Главная цель навигационного инструментария состоит в том, чтобы отобразить структуру встроенной модели так, чтобы пользова тель без труда мог перемещаться по ее элементам с учетом их спе цифики. Значит, для внешнего (интерфейс) и внутреннего (свойства и методы) представления встроенной модели в рамках пользова тельского инструментария необходим программный класс, ориенти рованный на особенности встроенной модели XML-DD.

За основу предлагается взять класс TreeView (дерево), исполь зуемый во многих объектно-ориентированных языках программиро вания высокого уровня и предназначенный для отображения иерар хических структур. Элементы структуры TreeView являются объек тами класса TreeNode, а все эти объекты образуют коллекцию Nodes.

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

Согласно принципу наследования, в классе XMLTreeNode дос тупны все свойства и методы класса TreeNode, на основе которого он был разработан. Кроме того, в него введено свойство xpath, в которое можно записывать XPath-выражение для доступа к тому XML элементу, которому соответствует данный экземпляр класса XMLTreeNode:

public class XMLTreeNode : TreeNode { public XMLTreeNode(string tn) { this.Text = tn;

} string xpath_set;

public string xpath { set { xpath_set = value;

} get { return xpath_set;

} } } В.В. Миронов, Г.Р. Шакирова К вопросу о программной реализации … Значение свойства xpath задается специально разработанной функции FindXPath. В качестве входного параметра этой функции передается XML-узел, для которого нужно найти XPath-выражение.

Выходное строковое значение содержит искомое XPath-выражение.

Как известно, пространство имен System.Xml содержит класс XPathNavigator. Можно было бы использовать его возможности для получения XPath-выражения. Однако возвращаемое при этом зна чение не относится к строковому типу данных и не может быть кор ректно конвертировано в этот формат. Такой вариант неприемлем, поскольку в процессе работы с XML-DD возникает необходимость сравнения именно строковых значений XPath-выражений, напри мер, при определении направления перехода и т. д. Поэтому пред почтительно использовать разработанную функцию FindXPath.

Все операции работы с ПТС определены в функции CreatePTS, в рамках которой выполняется создание элемента «Па мять_текущего_состояния» и добавление в него элементов, позво ляющих отразить смену текущих состояний при выполнении преди катов переходов.

Элемент, который создается в ПТС, является своего рода обра зом элемента модели (по концепции XML-DD). Для организации со ответствия между элементами ПТС и элементами модели для каж дого из первых элементов задается атрибут xpath, значение которого формируется с помощью функции FindXPath.

Все изменения в структуре ПТС изначально выполняются толь ко на уровне DOM-объекта, в который был загружен XML-файл с динамическим документом. Поскольку все последующие операции работы с XML-DD определяются содержимым ПТС из файла с дина мическим документом, то необходимо сохранить все изменения в этот файл. Для этого используется команда Save класса XmlDocu ment, доступная в пространстве имен System.Xml:

dom.Save(filename).

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

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 Первая из этих функций – DisplaySubModel. Она предназначе на для формирования узлов дерева навигации, соответствующих подмоделям исходной модели. Согласно модели и концепции XML DD, в состав подмоделей входят состояния. Эти состояния также не обходимо представить в дереве навигации. Для этого в рамках функции DisplaySubModel выполняются команды вставки узла состояния с помощью одноименной функции. Помимо самого состоя ния с помощью соответствующих функций формируются узлы, соот ветствующие переходам и погружениям из этого состояния. Для это го используются функции ProcessJump и DisplaySubModel. Особен ность реализации этих функций заключается в том, что они зависят от источника элемента-состояния. Если состояние является элемен том модели, то переходы и погружения являются непосредственны ми дочерними элементами этого состояния. Если же состояние явля ется элементом ПТС, то выполняется следующая последователь ность действий. На основании значения свойства xpath соответст вующего узла дерева навигации обращаемся к исходной модели XML-DD и находим соответствующий элемент-состояние модели.

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

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

Любой выполненный переход можно отменить и вернуть ПТС к предыдущему текущему состоянию. Для этого была разработана функция отката текущего состояния rollback. В качестве входного параметра этой функции передается XML-элемент модели, который был последним занесен в ПТС. Этот параметр доступен в качестве значения атрибута last_step_xpath, определенного в общей струк турной модели XML-DD.

3.3. Модуль редактирования Функции рассматриваемого модуля становятся доступны при переходе к режиму «Редактирование модели» из основного режима В.В. Миронов, Г.Р. Шакирова К вопросу о программной реализации … навигации. Изменение структуры исходной модели может привести к конфликту новых элементов и существующих XPath-выражений в ПТС. Чтобы избежать подобных коллизий, переход к режиму редак тирования сопровождается удалением всех элементов ПТС. Осталь ные XPath-выражения, заданные в рамках самой исходной модели (например, состояния-цели переходов), должны изменяться вместе со структурой соответствующих элементов.

При выборе пользователем узла дерева определяется тип соот ветствующего элемента модели и формируется список доступных операций редактирования. Тип элемента определяется на основа нии значения свойства Name, которое было задано при формирова нии дерева редактирования. Список операций редактирования эле мента модели доступен пользователю в качестве контекстного меню соответствующего узла дерева. Формирование меню реализовано в функции CreateContextMenu. Выбирая тот или иной пункт меню, пользователь запускает на выполнение соответствующую функцию редактирования выделенного элемента.

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

3.4. Модуль работы с ассоциированными фрагментами Каждый ассоциированный фрагмент представляет собой текст в формате WordML. Формат WordML построен на основе XML разметки, а потому наследует все ее преимущества как в плане платформенной независимости, так и с точки зрения простоты реа лизации. Для работы с WordML-фрагментами используются воз можности текстового процессора MS Word 2003. С его помощью WordML-фрагменты представляются в виде документов Word, при этом от пользователя скрыты образующие эти фрагменты теги. Ре дактирование WordML-фрагментов сводится к редактированию до кументов Word. При этом допускаются операции форматирования, вставки различного рода объектов (например, мультимедиа) и их последующее сохранение в исходный фрагмент в виде соответст вующей разметки WordML.

Операция просмотра и редактирования ассоциированных фраг ментов предполагает интеграцию процессора MS Word в основную экранную форму инструментария администрирования XML-DD. Для этого используются механизмы COM-технологии. Технология COM предоставляет разработчику доступ к объектам и методам других ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 приложений, которые максимально приспособлены для решения специализированных задач. При реализации поставленной задачи в качестве COM-сервера выступает приложение Microsoft Word, а COM-клиентом является наш инструментарий ведения XML-DD.

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

Для этого создаем ссылку на библиотеку объектов-серверов COM. В нашем случае это Microsoft Word 11.0 Object Library. В результате в программном коде проекта среди используемых пространств имен будет добавлено еще одно. Используем для этого пространства имен переменную Word:

using Word = Microsoft.Office.Interop.Word;

Чтобы создать экземпляр объекта COM, используется ключевое слово new:

Word.ApplicationClass wd = new Word.ApplicationClass();

После этого можно использовать любые свойства и методы, которые предоставляет Microsoft Word.

Для просмотра ассоциированных WordML-фрагментов используется экземляр объекта Document. Однако ассоциированные фрагменты не являются самостоятельными документами, поэтому невозможно их открыть в приложении Word напрямую. Поэтому при запуске функции просмотра и редактирования ассоциированных фрагментов (DisplayWord) создается временный файл с именем temp.xml. Создание нового XML-файла и запись в него основных тегов реализовано с помощью классов FileStream и BinaryWriter.

Следующий шаг – это запуск текстового процессора MS Word и открытие файла temp.xml.Для этого, как уже говорилось выше, используется экземляр объекта Document под именем document. В него записывается документ Word, открытый с помощью метода Open класса Documents. Этот метод принимает 12 входных параметров, основными из которых являются имя файла, режим, в котором открывается документ, и его видимость. Остальные параметры являются второстепенными, поэтому для их задания используется объект Missing пространства имен System.Reflection, задающий неопределенное значение.

object current_fileName = current_directory + "\\temp.xml";

object ReadOnly = false;

object missing = System.Reflection.Missing.Value;

В.В. Миронов, Г.Р. Шакирова К вопросу о программной реализации … document = wd.Documents.Open(ref current_fileName, ref missing, ref ReadOnly, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref isVisible, ref missing, ref missing, ref missing, ref missing);

document.Activate();

После этого пользователь получит возможность работы с ассо циированным фрагментом.

Чтобы реализовать интеграцию окна приложения MS Word не посредственно в экранную форму XML-DD Manager, была примене ны возможности библиотеки функций Win32 API. Процедуры Win API хранятся в нескольких DLL-файлах в зависимости от того, для выполнения каких функций они могут быть использованы. По скольку мы должны управлять только внешним видом окна, то нам понадобится библиотека DLL, представленная в файле user32.dll.

Чтобы использовать WinAPI-процедуры, которые заданы в файле user32.dll, необходимо импортировать его в программу. Для этого используется выражение DllImport("user32.dll"). В.NET прежде чем использовать внешнюю функцию, ее нужно определить в программе.

Так, например, для получения числового дескриптора окна, в кото ром открывается приложение MS Word, используется функция FindWindow, которая импортируется следующим образом:

[DllImport("user32.dll")] public static extern int FindWindow(string strclassName, string strWindowName);

Аналогичным образом были объявлены следующие функции:

– SetParent, которая задает родительское окно для заданного окна.

– SetWindowPos, предназначенная для задания позиции данно го окна относительно родительского окна – MoveWindow, которая задает размеры окна, дескриптор кото рого передается в качестве параметра.

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

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 ВЫВОДЫ 1. Необходимо создание программно-инструментального средст ва, позволяющего выполнять универсальную обработку динамиче ских документов в XML-формате независимо от того, какие задачи какой предметной области они решают.

2. Для разработки инструментария создания и ведения динами ческих XML-документов предлагается использовать платформу.NET Framework, поскольку она располагает широким набором ме ханизмов для обработки XML-данных.

3. Инструментарий администрирования XML-DD должен учи тывать как XML-синтаксис документа, так и встроенную модель это го документа и принципы ее интерпретации.

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

СПИСОК ЛИТЕРАТУРЫ 1. Гарифуллин, Т.А. Обеспечение целостности комплекса электронных документов на основе встраиваемых динамических мо делей: автореф. дис… на соиск. уч. степ. канд. техн. наук / Т.А.Гарифуллин. Уфа : УГАТУ, 2006.

2. Миронов, В. В. Концепция динамических XML-документов / В. В. Миронов, Г. Р. Шакирова // Вестник УГАТУ. 2006. Т. 8. № (18). С. 58–63.

3. Миронов, В. В. Интерпретация XML-документов со встро енной динамической моделью / В. В. Миронов, Г. Р. Шакирова // Вестник УГАТУ. 2007. Т. 9. № 2 (20). С. 88–97.

4. Троелсен, Э. С# и платформа.NET. Библиотека програм миста / Э.Троельсен. СПб. : Питер, 2004. 796 с.

5. XML на практике. Управление XML-данными через интег рированные классы чтения и записи в.NET Framework : Сборник документов и материалов в помощь IT-специалисту [Электронный ресурс] (http://www.networkdoc.ru/files/press/read.html?xml.html // NetWorkDoc.ru).

6. Миронов, В.В. Инструментально-программное средство «XML-DD Manager 1.0» для создания и ведения динамических XML документов : свидетельство об официальной регистрации программы для ЭВМ №2007613614 от 24.08.2007 / В.В.Миронов, Г.Р.Шакирова.

Р.Н. Агапов, Н.М. Дубинин Применение портальных коммуникаций… УПРАВЛЕНИЕ В СОЦИАЛЬНЫХ И ЭКОНОМИЧЕСКИХ СИСТЕМАХ УДК 519.8 : [621.452 : 681.5] ПРИМЕНЕНИЕ ПОРТАЛЬНЫХ КОММУНИКАЦИЙ В ОБРАЗОВАТЕЛЬНЫХ ПРОЦЕДУРАХ Р. Н. АГАПОВ, Н.М. ДУБИНИН* *Уфимский государственный авиационный технический университет Аннотация: В статье приводится понятие образовательной проце дуры, рассматриваются особенности использования портала в обра зовательных процедурах, требования к порталу, функциональные возможности реализации образовательных процедур и пример задач по реализации образовательных процедур.

Ключевые слова: образование ;

портал ;

образовательный портал ;

образо вательные процедуры ;

образовательные сервисы ;

бизнес-процессы ;

федераль ный портал.

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


Под образовательной процедурой в рассматриваемом контексте, будем понимать совокупность действий, направленных на обучаемо го, с целью получения им перечня навыков и умений образователь ного процесса за ограниченный интервал времени с возможностью ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 тестирования качества полученных знаний. Объем требований к знаниям и умениям регламентируется государственным образова тельным стандартом Министерством образования РФ в разрезе спе циальности подготовки.

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

Таблица 1 составлена по материалам учебного плана на 2007 2008 учебный год специальности АСОИУ кафедры АСУ УГАТУ.

Портал должен предполагать персонификацию студентов (вы дача индивидуальных регистрационных данных для идентифика ции и работы на портале). Идентификация позволит вести учет ак тивности студентов - посещаемость, проводить on-line консультации и предварительные тестирования - оценка успеваемости. Таким об разом, возникает задача создания портальной сущности студент, преподаватель (профессорско-преподавательский состав - ППС) и администрация (учебно-вспомогательный персонал - УВП). Аналоги этих сущностей созданы на портале кафедры АСУ УГАТУ [2]. Каж дой сущности соответствует группа с набором функциональных ро лей- прав и атрибутов. Примером совокупности таких прав группы «Преподаватель» может выступать перечень на рисунке 1. Права представлены в виде доступных задач. Дополнительно задачи сгруппированы в виде трех групп: преподаватели, портал и прочие, с указанием числа задач в каждой.

анкета преподавателей правка (персональные данные);

биография (автобиография);

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

документы: нормативно-справочные (размещение документов справочного характера на портале);

новости (объявления для студентов и преподавателей);

обновления портала (просмотр изменений портала);

поиск на файловом сервере (с применением поисковой маши ны);

пособия (методические указания к дисциплине, сопутствующее ПО);

почасовка: просмотр (просмотр персональной часовой нагрузки по кафедре с выводом итоговой таблицы часов);

Р.Н. Агапов, Н.М. Дубинин Применение портальных коммуникаций… Таблица Обеспечение образовательных процедур Имя ОП Требования к порталу Работа с преподавателем: публикация методических файлов, анализ загру зок материалов, расписание лекции рекомендуемая литература практические (семинары) учет успеваемости и посещаемости студентов, тре бования к оценке занятия учет успеваемости и посещаемости студентов, ме лабораторные занятия тодические указания, портальные мультимедиа стенды, требования к оценке Самостоятельная работа поисковые механизмы, сообщества портала, пере чень тем Отчетность: требования к оценке экзамены методические материалы, перечень тем, предва рительное on-line тестирование на портале зачеты методические материалы, перечень тем, предва рительное on-line тестирование на портале, требо вания к оценке курсовые проекты список вариантов заданий с закреплением выбо ра, ГОСТы, сроки сдачи, рекомендуемая литера тура, образец курсовые работы список вариантов заданий с закреплением выбо ра, ГОСТы, сроки сдачи, рекомендуемая литера тура, образец коллоквиумы (промежу- лекционный материал, перечень тем точные контрольные) расчетно-графические ра- ГОСТы, список вариантов заданий с закреплени ем выбора боты Дополнительно:

перечень предприятий практики, примеры тем, учебная практика сроки сдачи, ответственные лица производственная прак- перечень предприятий практики, примеры тем, сроки сдачи, ответственные лица тика дипломные работы или перечень дипломных руководителей с актуализа цией свободных мест, ГОСТы, сроки сдачи, требо проекты вания к оценке научная деятельность научные направления, календарь мероприятий, (статьи, доклады, тезисы, требования к материалам олимпиады) консультации календарь проведения, список вопросов, ответы на частые вопросы междисциплинарный эк- список контрольных тем и вопросов замен ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 Задачи портала для группы «преподаватель»:

протоколы кафедры (просмотр протоколов заседаний ка федры);

публикации, просмотр и правка (правка и просмотр своих публикаций и формирование списка литературы);

расписание занятий (формирование своего расписания);

сообщения (система внутренних сообщений участников портала);

справочники: просмотр (просмотр справочных данных – группы, дисциплины, типы публикаций и другие);

студенты (перечень курируемых по диплому студентов).

Рис. 1 Пример прав сущности «преподаватель»

Перечень доступных задач является динамическим. По мере разработки и внедрения новых задач, временного закрытия модер низируемых, администраторами портала могут вноситься измене ния в права, как для групп, так и для индивидуальных пользовате Р.Н. Агапов, Н.М. Дубинин Применение портальных коммуникаций… лей. Дополнительно существуют блокировки пользователей и их групп по перечню задач или групп задач.

Например, задачи: «пособия», «расписание занятий», «ново сти» обеспечивают функционирование группы ОП «Работа с препо давателем», а задачи: «дипломные темы студентов», «студенты» - ОП «дипломные работы или проекты». Ряд ОП в настоящий момент на стадии тестирования и внедрения, другие – в проектной проработке.

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

Ряд подходов к формированию образовательного портала выноси лись на страницах федерального портала «Российское образование»

[3].

СПИСОК ЛИТЕРАТУРЫ 1. Агапов, Р.Н. Организация эффективного взаимодействия пользо вателей образовательного портала / Р.Н. Агапов, Н.М. Дубинин. Уфа :

УГАТУ, 2007.

2. http://asu-ugatu.ueuo.com, зеркало портала кафедры АСУ УГАТУ.

3. http://www.edu.ru, Федеральный образовательный портал «Россий ское образование».

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН … УДК 004. ПОСТРОЕНИЕ КОНЦЕПТУАЛЬНЫХ МОДЕЛЕЙ БАЗ ДАННЫХ НА ОСНОВЕ XML-ТЕХНОЛОГИЙ В. В. МИРОНОВ, К.Э. МАЛИКОВА, Г. Р. ШАКИРОВА* *Уфимский государственный авиационный технический университет Аннотация: Обсуждаются вопросы построения внешних концепту альных моделей баз данных, создаваемых на начальном этапе проек тирования и отражающих информационные потребности пользовате лей. Рассматриваются особенности применения семейства XML технологий для логического проектирования и визуального представ ления моделей этого класса.

Ключевые слова: XML-технологии ;

базы данных ;

концептуальные модели базы данных ;

преобразование XML-Word ;

SVG-преобразование ВВЕДЕНИЕ Эффективность реализации базы данных в значительной степе ни определяется корректностью лежащей в его основе концептуаль ной модели. Как известно, эта модель ориентирована на базу дан ных в целом и не зависит ни от конкретных приложений, ни от кон кретной среды реализации базы данных [1]. Ее проектирование со стоит из нескольких этапов, начиная от создания исходных внешних моделей данных и заканчивая разработкой глобальной реляцион ной модели и моделей внешних представлений.

Внешние модели данных, которые строятся на начальном этапе проектирования концептуальной модели, отражают информацион ные потребности отдельных автоматизированных функций или приложений базы данных [1]. Построение таких моделей с помощью стандартных CASE-средств (например, ERWin) не всегда оправдан но, потому что внешние модели, как правило, не нормализованы и представляют собой «пользовательское видение» информационных потребностей базы данных. В связи с этим возникает задача разра ботки такого унифицированного подхода к построению внешних мо делей, который позволит максимально упростить работу проекти В.В. Миронов, К.Э. Маликова Г.Р. Шакирова Построение концептуальных … ровщика базы данных при разработке оптимизированной концепту альной модели. В данной работе предлагается реализовать этот под ход на основе XML-технологий.

1. XML-ПРЕДСТАВЛЕНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ БАЗЫ ДАННЫХ Внешняя модель представляет собой структуру, состоящую из следующих компонентов [1]:

• единственная сущность;

• атрибуты сущности (обязательные/необязательные, однозначные/многозначные, идентификаторы);

• агрегаты (обязательные/необязательные, однознач ные/многозначные);

• атрибуты агрегата сущности (обязательные/необязательные, однозначные/многозначные, идентификаторы).

Объектность XML-разметки позволяет каждому из этих объектов поставить в соответствие XML-элемент определенного типа. Чтобы избежать при этом создания «случайных» элементов, не имеющих никакого отношения к внешним моделям базы данных, необходим механизм, позволяющий строго контролировать структуру соответст вующего XML-документа.

Наиболее распространенным подходом, позволяющим регла ментировать структуру XML-документа, является использование схем XML-документа. В общем случае схема документа – это модель, отделенная от самого документа, в которой заданы его структурные и параметрические ограничения. Она определяет, что должно и чего не должно быть в документе. Существует три вида схем – DTD, XDR и XSD, и только одна из них – XSD – утверждена консорциумом W3C. Именно ее предлагается использовать для реализации рас сматриваемого подхода.


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

Здесь определены три типа элементов:

– kdb:FUNC, соответствующий единственной сущности каждой из автоматизируемых функций;

– kdb:REQU, соответствующий атрибутам и агрегатам сущности и атрибутам и агрегатам агрегата сущности.

Каждый из этих элементов имеет сложную структуру и содер жит, в свою очередь, два дополнительных вложенных элемента:

– kdb:NAME – для указания имени сущности/агрегата/атрибута;

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 – kdb:COMM – для указания возможных комментариев к объек ту модели.

В схеме для каждого XML-элемента модели указывается его тип и допустимое число экземпляров, задаются вложенные элемен ты и атрибуты, для каждого из которых определяется тип данных и способ использования. Так, например, элемент типа kdb:TOPIC мо жет иметь ноль, один или несколько вложенных элементов типа kdb:FUNC, поэтому для элемента последнего типа определены два дополнительных атрибута: minOccurs = 0 (допустимы ноль экземп ляров элемента данного типа) и maxOccurs = unbounded (допустимо неограниченное количество экземпляров элемента данного типа).

Задаваемые в модели атрибуты могут ранжироваться по много значности и обязательности. Поэтому в XSD-схему документа были введены два обязательных XML-атрибута – MULTI и OPTION, – за дающие, соответственно, тип многозначности и обязательности каж дого атрибута. Приведенные XML-атрибуты являются параметрами флагами атрибута модели. При этом выполняются следующие пра вила их логической интерпретации:

• если значение XML-атрибута MULTI равно 1, то данный ат рибут модели является многозначным, т. е. допускает множество своих экземпляров. В противном случае атрибут является однознач ным, т.е. в модели может быть лишь один экземпляр атрибута этого типа;

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

Те же правила относятся и к агрегатам, которые так же, как и атрибуты, могут быть однозначными (или многозначными) и обяза тельными (или необязательными). Для их описания используются XML-атрибуты MULTI и OPTION, семантическая нагрузка которых та же, что и для атрибутов модели.

Каждый экземпляр сущности характеризуется уникальным значением некоторого атрибута (или группы атрибутов), называе мых идентификатором [1]. Для того чтобы указать, какой именно атрибут сущности или агрегата является идентификатором, в XSD схему был введен необязательный XML-атрибут ID. Наличие этого атрибута у атрибута модели свидетельствует о том, что его значение является ключом для сущности или агрегата модели.

В.В. Миронов, К.Э. Маликова Г.Р. Шакирова Построение концептуальных … TOPICs TOPIC NOM NAME COMM FUNC NOM NAME COMM MULTI OPTION REQU ID AGGR NOM NAME COMM MULTI OPTION REQU ID AGGR NOM NAME COMM Рис. 1. Логическая XSD-схема структуры внешней концептуальной модели базы данных Таким образом, подобная XSD-схема XML-документа позволяет построить иерархическую структуру, моделирующую внешние кон цептуальные модели базы данных, а возможности XML-технологий позволяют в полной мере учесть особенности моделей этого класса.

2. ГЕНЕРАЦИЯ ФОРМАЛИЗОВАННОГО ОПИСАНИЯ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ БАЗЫ ДАННЫХ НА ОСНОВЕ ОТОБРАЖЕНИЯ XML-WORD Как уже говорилось ранее, внешняя концептуальная модель представляет собой ненормализованное пользовательское представ ление об информационных потребностях автоматизируемых функ ций. Эта структура является основой дальнейшего проектирования ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 и последующей практической реализации базы данных, однако предложенный способ логического представления данной модели наряду с очевидными преимуществами может вызвать затруднения для разработчика, незнакомого с XML-технологиями. В связи с этим возникает задача формализованного представления требований к структуре базы данных, то есть формулировки технического задания для разработчика базы данных на основе заданной XML-иерархии.

Простейшим решением этой задачи является использование наибо лее распространенного и доступного пользователям формата – доку ментов Word.

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

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

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

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

Как известно [4], для того, чтобы представить XML-данные в требуемом формате, необходимо использовать XSLT-преобразование, в рамках которого определяются правила применения определен ных инструкций трансформации к отдельным группам XML элементов. Рассмотрим, каким образом можно применить этот меха низм для генерации формализованного описания концептуальной модели базы данных в документ необходимого содержания, структу ры и формата (в данном случае – документ формата Microsoft Office Word).

В.В. Миронов, К.Э. Маликова Г.Р. Шакирова Построение концептуальных … Синтаксис и семантика языка XSLT построены по следующему принципу: определяются части XML-документа, которые соответст вуют заранее описанным шаблонам, а затем определенные правила преобразования применяются к каждой из найденных объектов внешней модели базы данных. Логика обработки и вывода резуль татов преобразования заключается в создании XSL-таблицы стилей.

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

В нашем случае, XSLT-преобразование должно базироваться, с одной стороны, на встроенной схеме WordML документа Word, а с другой – на особенностях организации XML-представления логиче ской структуры внешней модели базы данных. При этом XSL таблица стилей должна быть максимально гибкой, чтобы иметь воз можность обработать любой вариант структуры внешней модели.

Обобщенная схема взаимодействия объектов механизма генера ции формализованного описания концептуальной модели базы дан ных на основе отображения XML-Word приведена на рис. 2.

Рис. 2. Обобщенная схема механизма генерации формализованного описания концептуальной модели базы данных на основе отображения XML-Word ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 На начальном этапе преобразования мы располагаем XML файлом, содержащим логическое представление внешних концепту альных моделей базы данных, и XSL-таблицей стилей, в которой определены правила преобразования XML-документа в документ Word. При этом в нем заданы и особенности форматирования ре зультирующего документа с учетом того, какая информация должна быть в нем размещена.

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

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

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

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

3. ПОСТРОЕНИЕ ГРАФИЧЕСКОГО ПРЕДСТАВЛЕНИЯ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ БАЗЫ ДАННЫХ С ПОМОЩЬЮ XML-ТЕХНОЛОГИИ SVG Помимо логического и формализованного представления внеш них концептуальных моделей используется также специфическая графическая нотация, использующая простые визуальные компо ненты, отражающие структуру модели этого класса. Графическая система должна обеспечить проектировщику:

• возможность работы с набором графических объектов в но тации модели базы данных;

В.В. Миронов, К.Э. Маликова Г.Р. Шакирова Построение концептуальных … • унифицированный пользовательский интерфейс, позво ляющий встроенными средствами увеличивать, уменьшать и, при необходимости, перемещать изображение;

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

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

Ключевое применение XML в области передачи графики – спе цификация SVG (Scalable Vector Graphics), предназначенная для разрешения множества существующих проблем с графической ин формацией. По сравнению с другими графическими форматами SVG универсальнее при программном управлении графикой. В частно сти, SVG можно управлять при помощи интернет-браузеров (или других приложений), используя, например, технологию Document Object Model (DOM). Немаловажно и то, что SVG можно преобразо вывать и создавать с помощью привычных XML-технологий, таких как XSLT, или с помощью библиотек, поддерживающих работу с XML. Можно комбинировать SVG с другими форматами XML, ис пользуя пространства имен [3].

Среди других преимуществ SVG-формата можно отметить:

• SVG имеет статус свободно распространяемой рекомендации W3C. Спецификация SVG полностью задокументирована, т. е. это прежде всего открытый формат, что существенно упрощает его обра ботку сторонними приложениями;

• SVG изображения могут быть динамическими и интерактив ными;

• в отличие от растровых форматов GIF или JPEG, SVG являет ся векторным форматом. Это означает, что изображения SVG могут выводиться с высоким качеством при любом разрешении без воз никновения эффекта «ступенек» [3];

• меньший размер файлов, чем при использовании полностью растровых форматов GIF и JPEG, и т. д.

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

Для каждого из типов элементов, представленных в логической схеме концептуальной модели, может быть выделен свой графиче ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 ский объект, реализуемый с помощью SVG-графики. Например, единственную сущность каждой внешней модели можно изображать при помощи графического объекта типа «прямоугольник». Зафикси ровав его размеры и стилевые особенности, можно сделать этот эле мент стандартным для всех моделей любой базы данных. Элемент типа «прямоугольник» задается при помощи следующих XML-тегов:

rect id = "entity" y = "10" height = "25" width = "37"/ Аналогичным образом можно создать библиотеку базовых гра фических объектов для представления внешних концептуальных моделей баз данных: прямоугольников – для сущностей, комбина ции линии и круга – для однозначных атрибутов и агрегатов, ком бинации линии и квадрата – для атрибутов-идентификаторов и т. д.

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

Рис. 3. Обобщенная схема графического представления внешней концептуальной модели базы данных Комбинация различных графических объектов (например, для визуального представления атрибутов-идентификаторов) строится с помощью последовательного описания всех ее компонентов. В рас сматриваемом примере результирующий графический объект дол жен быть представлен в виде линии (теги line) и закрашенного В.В. Миронов, К.Э. Маликова Г.Р. Шакирова Построение концептуальных … квадрата (теги rect). Соответствующая иерархия XML-тегов может иметь следующий вид:

g id="attr_id” line x1="20" y1="38" x2="75" y2="38" / rect id = "entity" y = "38" height = "5" width = "5"/ /g Таким образом, встроенных механизмов SVG-представления достаточно для того, чтобы построить графическое представление внешней концептуальной модели с учетом всех возможных компо нентов модели этого класса.

ЗАКЛЮЧЕНИЕ 1. Унифицированное логическое представление внешних концеп туальных моделей базы данных может быть реализовано с примене нием XML-технологий. Для задания допустимой структуры XML документа, содержащего логическое описание модели этого вида следует использовать схему XML-документа, реализованную в клас се XSD-схем. Это дает возможность, с одной стороны, жестко регла ментировать структуру такого документа, что позволит избежать за несения в него «случайной» информации, а с другой, – создать дос таточно гибкую структуру для описания внешней концептуальной модели любой сложности.

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

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 3. Визуальное представление внешних концептуальных моделей на этапе проектирования может быть реализовано стандартными графическими механизмами. Однако реализация такого подхода имеет ряд трудностей, связанных с необходимостью синхронизации этого представления с логическим и формализованным описанием модели. В связи с этим наиболее приемлемым вариантом является использование технологии, базирующейся на XML, что позволит, с одной стороны, задействовать уже имеющееся XML-описание внеш ней модели, а с другой, – использовать все преимущества механиз мов данного класса. Таким форматом является преобразование SVG, которое представляет собой набор XML-инструкций для работы с графикой. Стандартных механизмов этого преобразования вполне достаточно для того, чтобы графически представить любые объекты внешней концептуальной модели базы данных.

СПИСОК ЛИТЕРАТУРЫ 1. Миронов, В.В. Концептуальные модели баз данных. Внеш ние модели данных / В.В.Миронов, Н.И.Юсупова. Уфа : УГАТУ, 2006. 52с.

2. Миронов, В.В. Информационная Интернет-технология ведения электронных документов с использованием Microsoft Of fice 2003 на основе языка XML / В.В. Миронов, К.Э.Маликова, В.Э.

Яфаев // Сб. науч. тр. междунар. молодежн. науч. конф. XXXIII Га гаринские чтения, 2007. С. 183–184.

3. Харди, В. Введение в SVG / В. Харди (http://xml.nsu.ru) [Элек тронный ресурс].

4. Миронов, В.В. XML-технологии в базах данных / В.В.Миронов, Н.И.Юсупова. Уфа : УГАТУ, 2004. 182с.

А.Р. Фахруллина, Л.Е. Родионова К вопросу использования… МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН … УДК 378.14: К ВОПРОСУ ИСПОЛЬЗОВАНИЯ УНИФИЦИРОВАННОГО ЯЗЫКА МОДЕЛИРОВАНИЯ ПРИ СОЗДАНИИ WEB-САЙТА ОБРАЗОВАТЕЛЬНОГО УЧРЕЖДЕНИЯ А. Р.ФАХРУЛЛИНА, Л. Е.РОДИОНОВА * *Уфимский государственный авиационный технический университет Аннотация: В статье рассмотрено моделирование web-сайта образо вательного учреждения с использованием унифицированного языка моделирования UML.

Ключевые слова: web-сайт ;

унифицированный язык моделирования UML.

ВВЕДЕНИЕ Обычно web-сайт образовательного учреждения представляют собой сложную и динамическую структуру. На его разработку выде ляют короткое время, чтобы сайт как можно быстрее заработал и да вал эффект. Часто разработчики сразу же садятся за написание ко да, даже не обдумав, что они собираются создавать, и как они это со бираются сделать. Код для сервера часто пишется с листа, таблицы в базах данных создаются по мере надобности, и в итоге иногда архи тектура системы начинает развиваться в совершенно непредсказуе мом направлении. Однако с помощью простого моделирования и строгого подхода к программированию можно сделать процесс раз работки в гораздо более гладким и гарантировать, что созданную web-систему будет просто поддерживать в дальнейшем. UML (Unified Modeling Language) - унифицированный язык моделирова ния – это язык, с помощью которого описываются системы. Следова тельно, этот язык поможет описать и отобразить будущую систему.

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

ISBN 5-86911-268-0. УПРАВЛЕНИЕ В СЛОЖНЫХ СИСТЕМАХ. Уфа, 2009 ИСТОРИЯ СОЗДАНИЯ UML Унифицированный язык моделирования UML появился в кон це 80-х и начале 90-х годов 20 века. Создание UML фактически на чалось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали ра боту по объединению их методов Воосh и ОМТ под эгидой компании Rational Software. К концу 1995 г. они создали первую специфика цию объединенного метода, названного ими Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE Ивар Якобсон.

В 1996 г. OMG (Object Management Group) обратилась к объ ектно-ориентированному сообществу с предложением создать стан дартную нотацию для объектно-ориентированного анализа и соот ветствующую семантическую метамодель. Первая версия UML (UML 1.0) появилась в январе 1997 г. как ответ на данное предложение.



Pages:     | 1 |   ...   | 3 | 4 || 6 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.