электронный документ - Высшая школа экономики

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение высшего профессионального образования
"Национальный исследовательский университет
"Высшая школа экономики"
Пермский филиал
Факультет бизнес-информатики
Кафедра информационных технологий в бизнесе
УДК 004.434+004.91
РАЗРАБОТКА ПРЕДМЕТНО-ОРИЕНТИРОВАННОГО
ЯЗЫКА ОПИСАНИЯ СТРУКТУРЫ И СОДЕРЖАНИЯ
ЭЛЕКТРОННЫХ ДОКУМЕНТОВ
Выпускная квалификационная работа бакалавра
Работу выполнил студент
группы БИ-10-2
4 курса факультета бизнес-информатики
Агалакова Е.З.
Научный руководитель:
старший преподаватель кафедры
информационных технологий в бизнесе
Ланин В.В.
“_____”
Пермь 2014
1
20__ г.
Оглавление
Основные обозначения и сокращения ...................................................................... 4
Введение ...................................................................................................................... 5
Глава 1. Теоретические аспекты языков описания .................................................. 7
электронных документов ........................................................................................... 7
1.1. Понятие «электронный документ»................................................................ 7
1.2. Обзор существующих способов описания структуры электронного
документа ...................................................................................................................... 12
1.2.1.
Документы HTML формата .................................................................. 14
1.2.2.
Документы SGML формата .................................................................. 15
1.2.3.
Документы XML формата .................................................................... 16
1.2.4.
Результаты обзора существующих способов описания структуры
электронного документа ........................................................................................... 17
1.3. Обзор существующих способов описания документов ............................ 18
1.3.1.
Подход Dublin Core ............................................................................... 21
1.3.2.
Проект SHOE ......................................................................................... 22
1.3.3.
Онтология проекта исследовательской группы KWARC ................. 23
1.3.4.
Онтология DoCO ................................................................................... 24
1.3.5.
Результаты обзора способов описания документов ........................... 24
1.4. Требования к разрабатываемому предметно-ориентированному языку. 25
1.5. Понятие предметно-ориентированного языка ........................................... 27
1.6. Обзор методов и средств разработки предметно-ориентированных
языков 28
Глава 2. Разработка предметно-ориентированного языка описания структуры и
содержания электронных документов ........................................................................... 34
2.1. Описание элементов электронного документа в EDocSACD .................. 34
2.2. Описание реквизитов электронного документа в EDocSACD ................. 38
2.3. Описание видов электронного документа в EDocSACD .......................... 45
2.4. Разработка модели описания структуры и содержания электронного
документа ...................................................................................................................... 51
2.4.1.
Пример: приказ о зачислении на 1 курс .............................................. 52
2
2.4.2.
Пример: письмо-извещение .................................................................. 53
2.4.3.
Пример: техническое задание .............................................................. 54
2.5. Результаты разработки предметно-ориентированного языка описания
структуры и содержания электронных документов ................................................. 57
Заключение ................................................................................................................ 59
Библиографический список ..................................................................................... 61
Приложение A. Описание элементов «Дублинского ядра» ................................. 65
Приложение
B.
Оценка
технологий
создания
предметно-
ориентированного языка ................................................................................................. 67
Приложение C. Метамодель описания реквизитов электронного документа .... 68
Приложение D. MXM-файл графа метамодели EDocSACD ................................ 69
Приложение E. Метамодель описания структуры и содержания ЭД .................. 75
Приложение F. Сгенерированный отчет метамодели описания элементов ЭД . 76
Приложение G. Форма приказа о зачислении на 1 курс ....................................... 83
Приложение H. Образец письма-извещения .......................................................... 84
3
Основные обозначения и сокращения
ЭД
Электронный документ.
CASE
Computer-Aided Software / System Engineering
(автоматизированная разработка программного обеспечения).
DC
Dublin Core (Дублинское ядро).
DSL
Domain Specific Language (предметно-ориентированный язык /
язык предметной области).
DSM
Domain Specific Modeling (предметно-ориентированное
моделирование).
EDocSACD
Language
Electronic Document Structure and Content Description Language
(язык описания структуры и содержания электронных
документов).
HTML
Hypertext Markup Language (гипертекстовый язык разметки).
PDF
Portable Document Format (формат переносимых документов).
SGML
Standard Generalized Markup Language (стандартный
обобщенный язык разметки).
WWW
World-Wide Web (всемирная паутина).
XML
Extensible Markup Language (расширенный язык разметки).
4
Введение
В наше время люди стали все чаще сталкиваться с необходимостью
получения из массива исходной информации сведений, которые нужны для
решения конкретной проблемы. Согласно исследованиям компании IDC (The
Digital Universe in 2020: Big Data, Bigger Digital Shadows, and Biggest Growth in the
Fare East, December 2012), количество неструктурированной информации,
получившей в профессиональной ИТ-среде название Big Data («большие данные»),
все стремительнее растет, составляя большую часть (примерно 80%) накопленной в
мире информации. В результате роста объемов неструктурированной информации,
хранящейся в электронных документах, можно столкнуться с рядом трудностей,
наиболее значимыми из которых станут проблемы обработки и аналитики данных.
Для разрешения этого было выбрано использование подхода, основанного на
предметно-ориентированном
моделировании,
а
именно
предметно-
ориентированного языка (Domain Specific Language, DSL) и DSM-платформ для
создания DSL описания структуры и содержания электронного документа. Данное
решение было принято по причине того, что DSL достаточно просты в применении
и понятны пользователям, так как они оперируют терминологией предметной
области.
С другой стороны, DSL является достаточно сложным языком для
разработки. Если языки общего назначения дают возможность программировать в
любой предметной области, то в случае DSL это невозможно. Для каждой
конкретной предметной области придется создавать собственный предметноориентированный язык.
Объектом исследования являются системы управления электронными
документами, их структурой и содержанием. Предметом исследования являются
средства описания структуры и содержания электронных документов, а именно
предметно-ориентированный язык.
Целью
выпускной
квалификационной
предметно-ориентированного
языка
описания
электронных
для
снижения
документов
работы
является
структуры
и
содержания
трудоемкости
обработки
неструктурированных данных, а в частности электронных документов.
5
разработка
Для достижения сформулированной цели работы следует ряд задач,
поставленных на время выполнения выпускной квалификационной работы:
 сбор, систематизация и обобщение материалов о языках описания как
структуры, так и содержания электронных документов;
 сбор и формулировка требований к разрабатываемому предметноориентированному языку;
 анализ литературы о предметно-ориентированных языков;
 анализ существующих информационных средств создания предметноориентированного языка и выбор инструментального средства для
дальнейшей разработки;
 разработка предметно-ориентированного языка описания структуры и
содержания электронных документов.
В ходе выполнения данной выпускной квалификационной работы была
предпринята попытка объединить наиболее значимые элементы электронного
документа, его реквизиты и виды с тем, чтобы получить максимально удобный и
полно отображающий предметную область язык описания структуры и содержания
электронных
документов.
Для
достижения
этого
будет
использоваться
инструментарий MetaEdit+.
В первой главе представлен обзор существующих способов описания
структуры и содержания электронных документов, а также раскрыты такие
понятия
как
электронный
документ
и
предметно-ориентированный
язык,
рассмотрены средства создания предметно-ориентированного языка и обоснован
выбор инструментального средства для дальнейшей разработки. Вторая глава
посвящена выявлению требований к разрабатываемому языку и непосредственной
разработке предметно-ориентированного языка описания структуры и содержания
электронных документов.
6
Глава 1. Теоретические аспекты языков описания
электронных документов
Целью данной главы является изучение способов описания электронного
документа, его структуры, а также предметно-ориентированных языков и
инструментальных средств, используемых для их разработки. Для достижения
данной цели следует раскрыть таких понятий как электронный документ и
предметно-ориентированный язык. Кроме того необходимо указать какие
существуют способы анализа структуры электронных документов на данный
момент. На основании рассмотренных способов описания следует определить
каким требованиям в дальнейшем должен удовлетворять разрабатываемый язык.
Понятие «электронный документ»
1.1.
Первое знакомство с понятием электронного документа состоялось еще в
1970-ых
годах
(на
тот
момент
в
СССР
было
принято
называть
его
машиночитаемым документом), когда с массовой компьютеризацией и появлением
более современных технологий возникла возможность перехода на «непечатные
материалы».
Факт наличия в документальной среде документации на новых носителях
был официально закреплен в ГОСТ 6.10-84, вышедшем в 1984 году. На тот момент
под
машиночитаемым
документом
понимался
документ,
пригодный
для
автоматического считывания содержащейся в нем информации [1]. Отличительной
особенностью таких документов являлось то, что они должны были быть пригодны
для обработки на ЭВМ, или созданы с помощью вычислительной техники, но их
реквизиты должны оформляться в установленном порядке. Именно в этот период
времени термин «электронный документ» стал зарождаться и рассматривался как
документ, обладающий новыми характеристиками.
С того момента и до сих пор вопрос о понятии электронного документа
является актуальным, так как специалистам данной предметной области как в
научном мире, так и в современном законодательстве еще не удалось прийти к
единому универсальному определению данного явления.
7
На сегодняшний день известен ряд официальных определений электронного
документа, закрепленных в современном законодательстве:
 Документ
на
использованием
машинном
носителе
носителей
и
–
способов
созданный
«документ,
записи,
с
обеспечивающих
обработку его информации электронно-вычислительной машиной» [2].
 Электронный документ – «документ на машиночитаемом носителе, для
использования
которого
необходимы
средства
вычислительной
техники» [3].
 Документ электронный –информационный объект, состоящий из двух
частей:
 «реквизитной, содержащей идентифицирующие атрибуты (имя,
время и место создания, данные об авторе и т.д.) и электронную
цифровую подпись»;
 «содержательной, включающей в себя текстовую, числовую и/или
графическую информацию, которая обрабатывается в качестве
единого целого» [4].
 Электронный документ – «форма представления документа в виде
множества
взаимосвязанных
реализаций
в
электронной
среде
и
соответствующих им взаимосвязанных реализаций в цифровой среде» [5].
 Электронный
документ
–
«документ,
в
котором
информация
представлена в электронно-цифровой форме» [6, статья 3].
Несмотря на то, что формальное определение электронного документа
существует, сущность его не раскрыта, что значительно осложняет нормативное
закрепление правил его использования.
Согласно мнениям, полученным в научном мире, также нет единства
относительно данного вопроса. Предлагается огромное множество определений
понятия электронного документа, данные учеными, например:
 Электронный
документ
–
«совокупность
данных
в
памяти
вычислительной, предназначенная для восприятия человеком с помощью
соответствующих программных и аппаратных средств» [7].
8
 Электронный документ – «это документ, носителем которого является
электронная среда – магнитный диск, магнитная лента, компакт-диск и
т.д.» [8].
 Электронный
документ
–
«документ
в
электронной
форме:
закодированное и переданное в информационную систему электронное
сообщение,
все
реквизиты
которого
заверены
и
оформлены
в
соответствии с нормативными требованиями» [9].
 Электронный документ – «зафиксированная на электронном (машинном)
носителе информация, которая записывается, сохраняется, передается и
представляется
в
приемлемой
для
человека
форме
с
помощью
технологий, поддерживаемых электронно-вычислительными машинами,
и которая содержит реквизиты, позволяющие ее идентифицировать. При
этом под электронным (машинным) носителем следует понимать
материальный носитель, предназначенный для записи и хранения
информации посредством электронно-вычислительной техники» [10].
 Документом является запись информации на материальном носителе,
 «совершенная
с
помощью
любой
известной
или
могущей
возникнуть в будущем технологии и в форме, обусловленной
правилами оформления и в соответствии с ними»;
 «предназначенная для передачи этой информации во времени и
пространстве»;
 «утверждающая,
сопутствующая,
подтверждающая
или
отражающая какой-либо факт или событие»;
 «содержащая атрибуты своей аутентичности (подлинности)» [11].
 Электронный документ – «письменный документ, выполненный либо в
виде объективной формы записи цифрового машинного кода на
материальном носителе, входящем в состав электронных технических
средств, либо в виде физического поля различного рода сигналов
(электромагнитных,
электрических,
оптических
и
акустических),
передаваемых по телекоммуникационному каналу связи во времени и
пространстве» [12].
9
По
результатам
рассмотрения
существующих
определений
понятия
электронного документа видно, что не существует единого варианта. В
дальнейшем, при работе с понятием «электронный документ», будем опираться на
определение, данное Тихоновым В.И. [10], так как оно является наиболее полным и
соответствующим
действительности.
Также,
исходя
из
рассмотренных
определений понятий электронного документа, можно выделить основные
свойства и требования, которым электронный документ должен удовлетворять, а
кроме того его признаки и выполняемые функции.
Функции, выполняемые электронными
документами,
условно
можно
поделить на три группы: главные, общие и специальные.
Наиболее обобщенной функцией документа является главная функция, а
именно хранение и передача информации во времени или пространстве. Документ
создается для обеспечения потребностей общества с помощью размноженной
документной информации.
Общие
функции,
такие
как
информационная,
коммуникативная,
кумулятивная, характерны для всех документов, вне зависимости от их типа и
вида. Информационная функция – это способность документа удовлетворять
потребности общества и информации, то есть служить источником информации.
Следующая функция, коммуникативная – это способность документа быть
информативным
средством
передачи,
обмена,
коммуникации,
общения
и
преемственности. Последней функцией является кумулятивная функция, а именно
способность документа накапливать, концентрировать, собирать и упорядочивать
информацию с целью ее сохранения для нынешнего и грядущего поколения [13].
Специальные функции, а именно управленческая, образовательная, правовая,
общекультурная, мемориальная и другие функции, присущи не всем, а лишь
определенным видам и типам документов, где они появляются в большей степени в
соответствии с социальными потребностями общества. Управленческая функция
выполняется документами, которые созданы для целей управления и в процессе его
реализации.
Образовательная
функция
–
способность
документа
служить
средством получения и передачи знаний для изучения процессов и явлений
природы и общества. Правовая функция – способность документа служить
средством доказательства, подтверждения каких-либо фактов. Общекультурная –
10
способность документа содействовать развитию культуры общества, выступать
средством закрепления и передачи культурной традиции, усвоения системы
ценностей. Мемориальная функция служит «внешней памятью» человека и
общества в целом, сохраняя информацию и передавая ее от одного поколения к
другому [14].
Для обеспечения выполнения рассмотренных функций в электронном
документе выделяют следующие свойства [15]:
 Атрибутивность – наличие в документе информационной (содержание) и
материальной (форма, которая служит для закрепления и передачи
информации) составляющих.
 Функциональность – предназначенность для передачи информации в
пространстве
и
времени.
Способность
документа
выполнять
разнообразные функции позволяет рассматривать его как источник
информации и как средство социальной документной коммуникации.
 Структурность – наличие взаимосвязанных элементов и подсистем,
обеспечивающих эффективность использования, его целостность и
сохранение основных свойств.
К основным признакам электронного документа можно отнести наличие
смыслового содержания; стабильную вещественную форму, которая обеспечивает
долговременную
сохранность
документа,
возможность
многократного
использования и перемещения информации в пространстве и во времени;
предназначенность для использования в социальной коммуникации для хранения и
передачи во времени и пространстве; завершенность сообщения [15].
Помимо всего прочего, при описании электронного документа следует
помнить, что документ должен соответствовать ряду требований, таким как
понятность, простота, недвусмысленность и последовательность, кроме того,
согласно Типовому проекту «Об электронном документе» [16], ЭД должен:
 создаваться, обрабатываться, передаваться и храниться с помощью
программных и технических средств;
 иметь структуру, установленную законом, согласно которому структура
электронного документа состоит из общей (информация, составляющая
11
содержание документа, и информация об адресате) и особенной
(электронная цифровая подпись) частей;
 содержать реквизиты, позволяющие его идентифицировать;
 быть представленным в форме, понятной для восприятия человеком.
1.2.
Обзор существующих способов описания структуры электронного
документа
Как было сказано ранее, одним из свойств электронного документа является
структурность, то есть электронные документы, как и многие другие объекты,
должны иметь свою структуру. Под данным понятием «структура электронного
документа» принято понимать порядок расположения показателей и данных в
документе, а также наличие взаимосвязанных элементов, обеспечивающих
целостность и эффективность его использования. Однако не всегда получается так,
что данные в документе находятся «в порядке», поэтому электронные документы
принято подразделять по степени структурированности на:
 Неструктурированные – текстовые документы, которые или не имеют
определенной модели данных, или не организованны определенным
способом в соответствии с моделью [17]. К таким документам относятся
письма, журнальные статьи, договоры.
 Слабоструктурированные – документы с гибкой формой, для которых
определены некоторые правила и форматы, но в самом общем виде
(приказы, распоряжения, служебные записки, счета-фактуры).
 Структурированные – электронные документы, использующие методы
вложенного кодирования, например разметку, для того, чтобы присвоить
всему документу и его частям различные структурные значения в
соответствии со схемой [18]. Примерами структурированных документов
являются заявления, обращения, жалобы, анкеты.
Основной целью большинства пользователей электронных документов на
данный момент является превращение неструктурированных данных, хранящихся
в документе, в структурированную информацию. Наиболее яркими примерами
средств структурирования данных в документах являются такие форматы
электронных документов как HTML, SGML и XML:
12
 Наиболее развитым является формат гипертекстового языка описания
документов Hypertext Markup Language (HTML). Был предназначен для
разметки
научных
документов
и
их
последующего
совместного
использования сотрудниками разных институтов.
 Стандартный обобщенный язык разметки Standard Generalized Markup
Language (SGML). Представляет собой метаязык, то есть средство
формального описания прикладных языков разметки, предназначенных
для кодирования структурированных документов.
 Формат eXtensible Markup Language (XML) представляет собой свод
общих синтаксических правил. Целью создания было обеспечение
совместимости при передачи структурированных данных между разными
системами обработки информации, особенно при передачи таких данных
через Интернет.
Рассмотренные средства структурирования документов непосредственно
взаимосвязаны друг с другом, так как первоначально язык HTML был всего лишь
одним из приложений универсального стандартизированного языка разметки
SGML. Другими словами, HTML – набор предписаний SGML, по которым
информация подготавливается для WWW. XML, в свою очередь, также имеет
отношение к SGML, а именно является его упрощенным подмножеством
(см. рис. 1.1):
Рисунок 1.1. Взаимосвязь языков разметки (SGML, HTML, XML)
13
Далее, для более полного понимания существующих способов описания
структуры электронного документа, необходимо рассмотреть данные форматы
подробнее.
1.2.1. Документы HTML формата
Как было сказано ранее, HTML – это стандарт, используемый программамибраузерами службы WWW в сети Internet, благодаря которому можно не только
форматировать документы, но и осуществлять связь текста и изображений с
документом, расположенным на другом сервере WWW [19].
HTML ориентирован на решение нескольких важных задач, в которых
участвуют его различные конструкции и элементы:
 описание структуры документа;
 адресация ресурсов;
 создание гипертекстовых ссылок и управление навигацией в локальных и
интернет базах данных;
 реализация интерфейсов с пользователем.
HTML – теговый язык разметки документов, то есть любой документ на
данном языке представляет собой набор элементов, причем начало и конец
каждого элемента обозначается специальными пометками – тегами. Другими
словами, HTML позволяет создавать документы, совместимые с браузерами
WWW, путем вставления управляющих кодов (тегов) в ASCII-текст для
обозначения заголовков, названий, графических изображений и гипертекстовых
связей [19].
Достоинствами данного языка являются простота освоения человеком и
реализации инструментальных средств создания и просмотра документов. Кроме
того, HTML является первым и единственным для своего времени языком разметки
для представления данных web.
Недостатками же формата являются отсутствие развитых средств разметки
структуры документов, а также ограниченность набора тегов.
14
1.2.2. Документы SGML формата
Для современного общества характерен огромный объем информации,
представленной в электронном виде в библиотеках, хранилищах данных, базах
данных
или
размещенной
в
дисковых
файлах.
Чтобы
воспользоваться
достижениями информационной революции, нужны средства быстрого доступа к
информации, позволяющие объединять взаимосвязанные материалы и обладающие
широкими возможностями поиска данных. Именно для этого и был разработан
стандарт подготовки ЭД SGML (Standard Generalized Markup Language),
представляющий собой набор правил для описания структуры и управления
содержанием электронных документов [19].
Данный
стандарт
является
открытым
стандартом,
которым
можно
пользоваться бесплатно, но он требует времени на обучение и применения
приложений, облегчающих работу с ним и расширяющих его возможности.
Документ в стандарте SGML состоит из трех частей: описание, определение
типа (Document Type Definition – DTD) и содержание [19]:
 Описание – это заголовок файла, содержащий информацию о системе, в
которой будет использоваться документ.
 Следующая часть – DTD – определение типа документа, что точно
отражает структуру создаваемого документа (связь между элементами) и
содержит информацию об обработке таких объектов, как графические
изображения, звуковая и видеоинформация. При этом основной задачей
является определение иерархии элементов документа.
 Третья часть документа – его текстовое содержание, помеченное тегами,
точно соответствующими спецификациям, заданным в DTD-определении.
Главным достоинством языка можно считать то, что SGML является
мощным метаязыком разметки, позволяющим создавать языки разметки для
различных предметных областей, например HTML, MathML, CML другие.
Однако, несмотря на все достоинства SGML, его основным недостатком
считается большая сложность по количеству, синтаксису и семантике объектов
языка, затрудняя его использование в качестве языка разметки. Вследствие чего
появился XML (Extensible Markup Language) – производный язык разметки
15
документов, позволяющий структурировать информацию разного типа, используя
для этого произвольный набор инструкций.
1.2.3. Документы XML формата
Как уже было сказано ранее, XML – упрощенное подмножество языка
SGML. Он предназначен для хранения структурированных данных (взамен
существующих файлов баз данных), для обмена информацией между программами,
а также для создания на его основе более специализированных языков разметки
(например, XHTML).
XML-документ представляет собой обычный текстовый файл, в котором при
помощи специальных маркеров создаются элементы данных, последовательность и
вложенность которых определяет структуру документа и его содержание [19].
Другими словами, каждый XML документ содержит один или несколько
элементов, границы каждого из которых обозначены либо парой тегов (начальный
и конечный), либо тегом пустого элемента, если это пустой элемент. Каждый
элемент имеет определенный тип, который идентифицируется по имени и иногда
называется «общим идентификатором» этого элемента, а также может иметь набор
спецификаций к атрибутам, содержащих его имя и значение.
На рисунке 1.2 наглядно показана схожесть составных частей документа, то
есть структура XML не сильно отличается от структуры SGML-документ, так как
XML является подмножеством языка SGML, и состоит из трех частей: описание,
определение типа и содержание:
Рисунок 1.2. Структура XML-документа
16
Основным
достоинством
XML
документов
является
то,
что
при
относительно простом способе создания и обработки (обычный текст может
редактироваться любым тестовым процессором и обрабатываться стандартными
XML анализаторами), они позволяют создавать структурированную информацию,
которая одновременно понятна как человеку, так и компьютеру. Кроме того к
достоинствам данного формата можно отнести и строго определенный синтаксис,
что позволяет ему оставаться простым, эффективным и непротиворечивым. Также
XML широко используется для хранения и обработки документов как online, так и
offline.
Однако, синтаксис языка XML избыточен, то есть размер документа
существенно больше, чем документы в альтернативных текстовых форматах
передачи данных. Избыточность может повлиять на эффективность приложения.
Возрастает стоимость хранения, обработки и передачи данных. Более того,
существуют другие, обладающие сходными с XML возможностями, текстовые
форматы данных, которые обладают более высоким удобством чтения человеком
(YAML, JSON, SweetXML).
1.2.4. Результаты обзора существующих способов описания структуры
электронного документа
Рассмотрев наиболее известные существующие способы описания структуры
электронного документа, такие как SGML, HTML и XML, можно говорить, что
растущий интерес к технологии XML, являющейся попыткой вернуться к истокам
идеологии SGML, приспособив замыслы его создателей к нуждам современного
Интернета, ясно показывает, что www уже созрел для чего-то более мощного, чем
современный HTML.
Сравнительный
анализ
рассмотренных
технологий
представлен
в
таблице 1.1:
Таблица 1.1. Сравнительный анализ языков разметки документов
SGML
HTML
XML
Год создания
формата
Тип разметки
1986
Строго логическая
1992
Логическая, но теги
имеют жестко
фиксированные
параметры
форматирования
17
1997
Строго логическая,
определяется внешними
стилевыми
спецификациями
Набор тегов
языка и
атрибутов
Синтаксис тегов
языка
Определение типа
документа
(Document Type
Definition)
Гипертекстовая
модель
Совместимость с
языками
стилевых
спецификаций
Версии и
спецификации
Трудность
освоения
SGML
HTML
XML
Произвольный
Фиксированный
Произвольный
Гибкий
Фиксированный
Фиксированный
Обязательно для
каждого документа
Одно на все документы
Может быть свое у
каждого документа, но
может и отсутствовать
Отсутствует
Примитивная
Развитая
DSSSL
(язык описания
семантики и стиля)
CSS
(каскадные таблицы
стилей)
DSSSL-o
Одна стабильная
версия с полной и
формально строгой
спецификацией
Множество версий и
диалектов, не все из них
достаточно строго
документированы
Незаконченная
спецификация первой
версии языка
формально строга и
легко расширяема
Высокая
Низкая
Средняя
Из таблицы видно, что разметка в SGML логична, синтаксис тегов гибкий,
определение типа документа обязательно для каждого документа и трудность
освоения высокая. Для формата HTML наоборот: разметка логическая, но теги
имеют жестокие фиксированные параметры форматирования, синтаксис тегов
фиксированный и трудность усвоения низкая [20].
Таким образом, XML является компромиссом между строго логическим
языком SGML и фиксированным языком HTML, не допускающим изменение его
структуры. Другими словами, XML сочетает в себе простоту HTML и свободу
логической структуры SGML.
1.3.
Обзор существующих способов описания документов
Ранее был проведен обзор существующих способов описания структуры
документов, однако немаловажным аспектом в рассмотрении электронных
документов является его содержание.
Библиотеки – пример организации, которая непосредственно сталкивается с
проблемой описания документов. Первые документы в электронных каталогах
библиотек имели описание по весьма ограниченному списку полей (примерно 8 –
10). Однако по прошествии времени ситуация стала постепенно меняться.
18
В библиотеках стали появляться каталоги, где в документах использованы
ключевые
слова.
При
проведении
сравнительного
анализа
поисковых
возможностей информационно-поисковых языков в Государственной публичной
научно-технической библиотеке Сибирского отделения Российской академии наук
было установлено, что наиболее высокую точность, а именно 91%, показал поиск
по ключевым словам [21]. Тем не менее, данный вид поиска не всегда является
узконаправленным и не во всех случаях обеспечивает релевантный поиск. Кроме
того вводимые операторами ключевые слова не всегда соответствуют требованиям
читателей, то есть достаточно часто можно встретить такие лексические единицы,
которые никогда не будут использованы читателем в качестве поискового образа
документа.
Аннотации чаще всего являются весьма поверхностными, недостаточно
полно описывая содержание аннотируемого документа, что не позволяет читателю
точно определить возможность использования данной книги.
В последние же годы данная тема стала набирать обороты, и были
предприняты попытки создания новых систем структурирования электронных
документов, которые за основу используют так называемые метаданные. Согласно
ГОСТ Р ИСО 15489-1 – 2007 «Система стандартов по информации, библиотечному
и издательскому делу. Управление документами. Общие требования», метаданные
– данные, описывающие контекст, содержание, структуру документов и
управление документами в течение времени. Управление метаданными –
неотъемлемая часть управления документами, которая обеспечивает выполнение
множества различных функций и целей [22].
Некоторые исследователи различают следующие 3 группы метаданных:
1.
Метаданные, создаваемые web-службами индексирования и поиска
(это данные, собираемые программами-роботами на основе использования
протокола http и скриптов CGI для автоматического создания записей об
онлайновых информационных ресурсах).
2.
Метаданные, используемые для описания информационного ресурса
(например, форматы Dublin Core и IAFA/WHOIS++ (проект ROADS); записи могут
создаваться вручную или автоматически).
19
3.
Метаданные, используемые для задания месторасположения, анализа,
оценки, документирования и т.п. информационного ресурса (такие метаданные
довольно сложные и очень детализированы, что требует привлечения специалистов
для их разработки и сопровождения).
Вторая категория метаданных, в свою очередь, включает в себя перечень
некоторых наиболее известных систем метаданных, относящихся к электронному
документу, таких как [23]:
 GILS – Глобальная (правительственная) служба поиска информации,
обеспечивающая доступ частным лицам и организациям к федеральным
информационным ресурсам, через общедоступный каталог этих ресурсов,
используя систему метаданных.
 MARC – машиночитаемый каталог, отличающийся детальным составом
элементов данных, универсальностью и развитой структурой.
 ЕАД. – кодировка архивных описаний. Набор изначально текстовых
метаданных на базе языка разметки SGML, разработанный для нужд
архивов
и
используемых
для
стандартизации
и
классификации
уникальных архивных материалов, прежде всего рукописей.
 TEI – инициатива по кодированию текстов, разработанная в Центре
электронных текстов Вирджинии в 1989 г. как инструмент при процессе
оцифровке, который идентифицирует электронный ресурс и его печатный
источник
посредством
метаданных,
размещенных
внутри
самого
электронного ресурса.
 IAFA/WHOIS++ – шаблонно-ориентированные метаданные для описания
сетевых ресурсов, первоначально использовавшиеся для описания
списков электронной почтовой рассылки, а позднее распространенные на
другие ресурсы.
 Dublin Core Metadata Set (DC) – формат описания практически любых
ресурсов сети Интернет.
Общая схема взаимосвязи рассмотренных систем метаданных, описанных
выше, приведена на рисунке 1.3, демонстрируя непосредственное отношение
систем:
20
VRA
MPEG
MARC
GILS
SMPTE
Dublin
Core
RDF
LOM
GELOS
IMS
Рисунок 1.3. Взаимосвязь систем метаданных
Из рисунка видно, что справочники Dublin Core являются источниками
многих систем метаданных. Кроме того, элементы DC могут быть использованы в
шаблоне описания ресурса (RDF) для описания семантической составляющей
информационных ресурсов.
1.3.1. Подход Dublin Core
В настоящее время наиболее распространённой схемой метаданных для
описания документа, непосредственно находящегося в сети Интернет, является
набор, создаваемый уже в течение нескольких лет международной группой "The
Dublin Core initiative". Этот набор называется, соответственно, "Dublin Core
Metadata Elements".
Дублинское
предназначенный
ядро
для
(Dublin
описания
Core)
–
содержания
набор
элементов
документов
метаданных,
различного
типа
(публикации, аудиозаписи, видеозаписи). Спецификация этого набора имеет статус
официального международного стандарта (ISO:15836-2003). Стандарт разделён на
два уровня: простой (неквалифицированный), состоящий из 15 элементов и
компетентный
(квалифицированный),
добавляющий
к
простому
набору
квалификаторов, которые уточняют семантику элементов (Приложение A).
Особенностью Дублинского ядра является то, что каждый элемент опционален и
может повторяться.
21
Дублинское ядро является мощным инструментом при описании ресурсов
различного
характера.
Его
неоспоримым
преимуществом
является
распространённость и гибкость.
Основное преимущество Дублинского ядра заключается в том, что если
традиционные методы каталогизации требуют профессиональной подготовки для
эффективного использования, Дублинское ядро использовать весьма просто.
Однако простота конфликтует с точностью. Первоначальная цель заключалась в
создании простого набора элементов метаданных для неподготовленных людей,
которые публикуют электронные материалы с описанием своих результатов.
Некоторые продолжают придерживаться этого минималистского подхода, они
хотели бы видеть простой набор правил, которыми мог бы воспользоваться любой.
Другие предпочитают ориентироваться на преимущества более тщательно
разработанных правил каталогизации и согласны на увеличение трудоемкости и
стоимости. Они указывают на то, что дополнительные структурные элементы
позволяют добиться большей точности в метаданных [23].
Однако, несмотря на все достоинства данного подхода, у него есть ряд
недостатков. Например, схема метаданных является довольно общей и подходит
только для минимального описания ресурсов. Кроме того, стандартизация
проведена только на уроне базового набора из 15 элементов, другие аспекты
данный подход не описывает. Также DC ориентировано на описание реквизитов
документа, т.е. информации, напрямую не относящейся к содержанию документа.
Другие аспекты электронного документа невозможно описать [24].
1.3.2. Проект SHOE
Кроме того, для описания контента документа также можно использовать
онтологические подходы. Таким образом, другим примером по праву может
считаться онтология документов проекта SHOE (Simple HTML Ontology
Extensions) [25]. Рассмотренная онтология документов описывает огромное
количество видов документов, однако особое внимание уделяется публикациям.
Источниками для данной онтологии могут считаться справочники Дублинского
ядра и классификатор документов PubMed [26].
22
Проект SHOE был ориентирован на решение проблемы добавления к webстраницам
семантической
информации
и
соотнесения
ее с онтологиями
соответствующих предметных областей. Предполагалось, что, используя эту
информацию, поисковые системы смогут обеспечивать более релевантные ответы
на запросы, чем это возможно на базе использования стандартных машин поиска,
функционирующих в сети Интернет.
Для поддержки процессов аннотирования в рамках проекта был разработан
специальный набор инструментальных средств, основой которых был язык
интернет
совместимого
представления
знаний,
давший
название
всему
проекту [27].
На рисунке 1.4 представлен фрагмент визуализации онтологии документа:
Рисунок 1.4. Фрагмент Onto-графа онтологии документа проекта SHOE
1.3.3. Онтология проекта исследовательской группы KWARC
Данная онтология представляет проект, ориентированный на разработку
формального описания структуры документа (онтология документов в формате
CNXML), имеющей непосредственное отношение к их семантике (онтология
документов в формате OMDoc (см. рис. 1.5)). Онтологии документов также могут
быть использованы для классификации видов документов и их частей.
Для таких форматов документов как CNXML (Connexions Markup Language)
онтология документов описывает такие понятия как параграф, раздел, ссылка и
23
прочие. А для математических документов в формате типа OMDoc включены
различного рода математические понятия и логические связи между этапами
доказательства теорем [28].
Рисунок 1.5. Фрагмент визуализации онтологии документа в формате OMDoc
1.3.4. Онтология DoCO
DoCO, или как принято расшифровывать, Document Components Ontology –
онтология, характеризующая составные части библиографического документа.
Представляет как структурированную лексику компонентов документа, например
блок, раздел, глава, так и риторическую лексику (введение, обсуждение,
благодарность, список литературы, рисунки, приложения). Это позволяет данным
компонентам и документам, состоящих из них, быть описанными в формате RDF.
Однако в настоящее время данная онтология находится в разработке.
1.3.5. Результаты обзора способов описания документов
В результаты проведенного обзора были выявлены существующие решения
для описания документов, такие как Dublin Core, SHOE, проект docOnto
исследовательской группы KWARC, DoCO. Каждый из рассмотренных проектов
имеет достаточное количество преимуществ.
Например, Dublin Core предоставляет возможность описания контента
документов различного типа (как публикаций, так и аудио и видеозаписей), являясь
достаточно гибким инструментом при описании ресурсов различного характера.
Однако оно ориентировано только на описание реквизитов документа, что не
позволяет описать другие возможные аспекты электронного документа.
Проект
SHOE,
разработавший
онтологию
описания
публикаций,
ориентирован непосредственно на решение проблем добавления к web-страницам
24
семантической информации и соотнесения ее с онтологиями соответствующих
предметных областей. Основным недостатком данного подхода является то, что
для полной его реализации необходимо, чтобы все разработчики web-страниц
включали в них дополнительную информацию, что является невыполнимой
задачей.
Разработанная онтология docOnto исследовательской группы KWARC
ориентирована на разработку формального описания структуры и семантики
документов, а также механизма семантического индексирования документов и
инструментальных средств обработки документов. Но, к сожалению, активные
работы по данному направлению приостановлены.
Как видно из проделанного обзора способов описания документа, кроме
достоинств каждый из них имеет свои недостатки. Вследствие чего было принято
решение использовать подход, основанный на предметно-ориентированном
моделировании, использовании предметно-ориентированного языка (Domain
Specific Language, DSL) и DSM-платформ, предназначенных для создания DSL, так
как он является достаточно простым в применении и понятным для пользователя,
оперирующим терминологией предметной области. Разрабатываемый язык будет
опираться на преимущества рассмотренных подходов, однако ряд недостатков
рассмотренных способов описания документов, которые необходимо учесть.
1.4.
Требования
к
разрабатываемому
предметно-ориентированному
языку
Принимая во внимание сложность описания структуры и содержания
электронных документов крайне важно на начальном этапе определиться, каким
требованиям должен удовлетворять разрабатываемый предметно-ориентированный
язык. Он должен позволять выполнять описание всех элементов и реквизитов
электронного документа, но при этом быть простым и понятным для
пользователей, не являющихся экспертами в данной области.
25
Возможность применения в различных предметных областях может быть
обеспечена соблюдением следующих требований:

Доступность. Это требование обеспечивает возможность построения
моделей пользователем, не имеющим глубоких знаний в области
моделирования, что подразумевает наличие специализированной лексики.

Ясность. Под требованием ясности получившейся модели понимается,
что
модель,
с
одной
стороны,
должна
обладать
достаточной
выразительной мощностью, а с другой, не должна быть слишком
запутанной и перегруженной.

Неизбыточность. В языке моделирования не должно быть «лишних» или
неоднозначных элементов. Пользователь не должен метаться в выборе
между той или иной конструкцией языка.

Достаточность. Под данным требованием подразумевается то, что набор
элементов модели должен полностью удовлетворять потребностям
пользователя,
чтобы
не
возникло
ситуации,
когда пользователю
понадобятся дополнительные объекты модели, без которых дальнейшее
построение модели невозможно.

Отчуждаемость. Требование заключается не только в разработке
визуальных элементов, но и в создании языка с помощью специального
языкового инструментария, который позволит экспортировать созданные
модели.
Основываясь на проблемах, выявленных в ходе анализа предметной области,
а именно структуры электронного документа, основной список требований можно
дополнить следующими аспектами:

возможность выбора вида документа для дальнейшего описания;

отображение структурных элементов электронного документа;

отображение реквизитной части электронного документа;

осуществление
трехуровневого
описания
структуры
электронного
документа (1 уровень – элементы, 2 уровень – реквизиты, 3 – виды ЭД);

возможность добавления неограниченного количества объектов в модель
описания.
26
Соблюдение
вышеперечисленных
требований
позволит
более
полно
отобразить всю информацию о процессе описания структуры электронного
документа, не перегружая при этом модель дополнительными элементами.
1.5.
Понятие предметно-ориентированного языка
В современном мире достаточно остро стоит вопрос о постоянном росте
слабоструктурированных электронных документов. В связи с этим информация,
хранящаяся в электронных документах, стала сложно извлекаемой и сложно
обрабатываемой. Для разрешения данных проблем было принято решение об
использовании
подхода,
моделировании,
разработке
основанного
на
предметно-ориентированном
предметно-ориентированного
языка
описания
структуры и содержания электронных документов. В противопоставление
традиционных языков программирования, которые нацелены непосредственно на
выполнение определенных функций, предметно-ориентированные языки нацелены
на создание единой модели предметной области [29].
Существует
большое
множество
вариантов
определений
предметно-
ориентированного языка, но самым распространенным на данный момент является
определение Мартина Фаулера, согласно которому предметно-ориентированным
языком является «язык программирования с ограниченными выразительными
возможностями, ориентированный на некую конкретную предметную область»
[30]. Иными словами, понятие предметно-ориентированного языка можно
определять как «урезанный язык программирования».
Однако
позднее
было
дано
более
точное
определение: предметно-
ориентированный язык – это язык программирования, специализированный для
конкретной области применения (в противоположность языку общего назначения,
применимому к широкому спектру областей и не учитывающему особенности
конкретных сфер знаний). Поскольку в каждой области могут существовать
различные понимания одних и тех же терминов, то в связи с этим предметноориентированный язык определяет соглашение о значении терминов и является
посредником
между
человеко-
и
машинно-ориентированным
представления информации.
27
уровнем
1.6.
Обзор методов и средств разработки предметно-ориентированных
языков
В общем случае DSL языки могут быть как текстовыми, так и визуальными.
Первые позволяют описывать модель в текстовом виде, а вторые – в графическом.
Однако наиболее распространенными являются визуальные DSL, по причине того,
что диаграммы обладают большей наглядностью и понятностью не только для
программистов, но и для экспертов в предметной области и другим пользователям
системы. Такой подход к использованию визуальных DSL принято называть
предметно-ориентированное моделирование (Domain Specific Modeling, DSM).
При
пользоваться
создании
предметно-ориентированного
подходящими
языковыми
языка
инструментариями,
целесообразно
или
DSM-
платформами, предназначенными для их проектирования, редактирования и
анализа. Другими слова, DSM-платформа – инструментальное программное
обеспечение, служащее для поддержки разработки и сопровождения языков
предметной области.
Наиболее существенным достоинством DSM-платформы является то, что
такие
инструментальные
средства
облегчают
процесс
создания
языков
моделирования, а также существенно упрощают процедуру внесения изменений в
уже имеющиеся DSL. Пользователю не придется разбираться в коде языка, он
сможет просто изменить описание DSL в DSM-платформе. Кроме того, существует
возможность интеграции в одной системе сразу нескольких DSL, так как при
задании ограничений на объекты предметной области и описании бизнеспроцессов используются совершенно разные языки.
На сегодняшний день известен ряд зарубежных и отечественных систем,
предназначенных
для
разработки
графических
редакторов
предметно-
ориентированного языка с возможностью определения собственных графических
нотаций. В основе этих систем находятся различные формализмы описания знаний,
разнообразные модели понятий и отношений, а также разные методы обработки
знаний.
Ниже представлен перечень наиболее развитых на данный момент и
наиболее часто встречаемых DSM-платформ:
28
 MetaEdit+
является
инструментальным
средством
CASE-системы,
разработанной компанией MetaCase (Финляндия), предназначенным для
создания языка моделирования и генераторов, а также с наличием среды
разработки
собственных
систем
с
поддержкой
языков
возможности
моделирования,
использования
генераторов
кода
и
документации [32].
 Microsoft Tools for Domain-Specific Languages (MS DSL Tools) позволяет
создавать собственные визуальные языки моделирования, а также строить
для них графические редакторы. DSL используется исключительно как
составная часть Microsoft VS, вне которой ни DSL, ни редактор
использовать нельзя [29].
 Eclipse Graphical Modeling Framework (GMF) предназначена для создания
графических средств, то есть для визуальных DSL, интегрируемых
непосредственно в среду Eclipse. Архитектура DSL строится на основе
шаблона MVC (model – view – controller). Модели разрабатываются при
помощи технологии EMF, а для создания уровней представления и
контроллера используется технология GEF [29].
 State Machine Designer является исследовательской разработкой по
созданию инструментов для описания DSL, созданный на основе DSMплатформы DSL Tools. Данное инструментальное средство было
предложено
Санкт-Петербургским
информационных
технологий
государственным
механики
и
университетом
оптики
на
кафедре
Компьютерных технологий.
 Технология
REAL-IT
предназначена
для
быстрой
разработки
(моделирования и автоматической генерации) приложений, бизнес-логика
которых целиком обуславливается схемой данных. В этом случае все
целевое
приложение
является
только
средством
заполнения
и
редактирования данных.
 Qreal, разрабатываемая на кафедре системного программирования СанктПетербургского государственного университета, изначально должна была
быть развитием REAL-IT, основывающимся на использовании новой
29
версии
языка
UML
2.0
и
удовлетворяющим
требованиям
многоплатформенности. Однако в систему были включены элементы
метамоделирования, что позволило упростить процесс создания новых
редакторов [33].
 UFO-toolkit – DSM-платформа, позволяющая проводить системнообъектный анализ с применением концептуальных классификационных
моделей. К преимуществам данного инструментального средства можно
отнести
возможность
взаимосвязанного
представления
структуры,
состава элементов и функций моделируемых систем; имитирования
функционирования
системы на
основе объектной
модели;
учета
семантики предметной области и семантического взаимодействия с
инструментарием.
 Meta Programming System разработка компанией JetBrains и используется
совместно
со
средой
разработки
Java-приложений
Intellij-IDEA.
Отличительной особенность данной системы является тот факт, что
технология Meta Programming System – мощный инструмент для
текстового проектирования языка при помощи таких инструментальных
средств как язык структуры, язык редактирования, базовый язык и язык
шаблонов [29].
Для выбора системы построения предметно-ориентированного языка
описания
структуры
и
содержания
электронных
документов
необходимо
выполнить сравнительный анализ существующих. Критериями сравнений будут
являться:
 динамическое изменение описания метамоделей;
 средства описания метамодели;
 возможность модификации метаязыка;
 создание визуальных DSL;
 создание текстовых DSL;
 средства «ручной» доработки DSL;
 изменение графического редактора для работы с DSL;
 генерация;
30
 трансформация моделей;
 интеграция нескольких DSL;
 отчуждаемость DSL от DSM-платформы.
Результаты анализа представлены в таблице 1.2, демонстрируя, что каждая
из рассмотренных технологий обладает как своими сильными сторонами, так и
слабыми по сравнению с другими системами:
MetaEdit+
Динамическое
изменение
создаваемых
метамоделей
Средства
описания
метамодели
Возможность
модификации
метаязыка
Создание
визуальных
DSL
Создание
текстовых
DSL
Наличие
средств
«ручной»
доработки DSL
Возможность
изменения
графического
редактора для
работы с DSL
Генерация
Возможность
горизонтальной
трансформации
моделей
Интеграция
нескольких
DSL
Отчуждаемость
DSL от DSMплатформы
+
GOPRR
Таблица 1.2. Сравнительный анализ технологий создания
предметно-ориентированного языка
MS Tools,
State
Eclipse
UFOMPS
REAL-IT
Machine
GMF
toolkit
Designer
-
-
-
Языки:
UMLUML,
структуры,
диаграммы
MetaGME редактора,
классов
базовый
-
-
Расширение
Язык
UMLUFOдиаграмм
элементов
классов
+
-
-
-
-
-
+
+
+
-
+
+
-
-
-
+
-
-
-
+
+
+
+
-
+
+
+
-
-
-
Код,
документ-ия
Исходный
код
-
-
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
Исходный Исходный
Исходный код
код
код
31
Код,
док-ия
Эти же данные можно представить в более понятном виде, если применить
оценочную шкалу (Приложение B). Для удобства было принято решение
использовать двухбалльную шкалу: 0 – отсутствие, 1- присутствие критерия.
Очевидно, что каждая из представленных технологий имеет несомненные
достоинства. Так, например, MetaEdit+, в отличие от других технологий, позволяет
вносить изменения в описание DSL во время работы системы и модифицировать
метаязык. Кроме того, данный инструментарий, как и DSL Tools, Eclipse GMF и
Meta Programming System, позволяет интегрировать несколько языков в одной
системе.
Технология DSL Tools помимо визуального редактора метамоделей
предоставляет в распоряжение пользователя среду программирования MS Visual
Studio. Благодаря интеграции с MS Visual Studio существует возможность
«ручной» доработки кода на языках высокого уровня.
Однако, основываясь на результатах анализа данной таблица, ни одна из
рассмотренных выше технологий не позволяет производить трансформацию
созданных моделей. Отсутствие встроенных компонентов трансформации моделей
ограничивает пользователей в выборе языка моделирования, а также не позволяет
им разрабатывать ИС на нескольких DSM-платформах.
Более того, к недостаткам данных систем можно отнести то, что
разработанные предметно-ориентированные языки не могут быть использованы в
сторонних приложениях. Технологии DSL Tools, Eclipse GMF, MPS сильно связаны
с
платформами
разработки
–
MS
Visual
Studio,
Eclipse,
IntelliJ-IDEA
соответственно. В случае с системой MetaEdit+ для экспорта моделей используется
свой собственный формат файлов MXM, который отличается от общепринятого
стандарта XML, что значительно сказывается на открытости данной технологии и
не
позволяет
использовать
разработанные
модели
в
других
CASE-инструментариях.
Разнообразие систем создания предметно-ориентированного языка делает
сложным их непосредственное сравнение, поэтому выбирать подходящую систему
лучше ориентируясь на конкретную поставленную задачу.
Для
разрабатываемого
предметно-ориентированного
языка
описания
структуры и содержания электронных документов было принято решение
32
использовать систему MetaEdit+ по причине возможности вносить изменения в
описание DSL во время работы системы благодаря использованию подхода,
основанного на интерпретации метамоделей, а не на генерации. Система позволяет
работать как с языками, так и с метаязыками единообразно, используя один и тот
же инструментарий. Кроме того, в данном средстве для разработки графических
редакторов возможно создание собственных визуальных DSL, а также изменения
графического
редактора
и
интеграции
нескольких
DSL.
Несомненным
достоинством также является возможность построения новых метамоделей на
основе существующих, другими словами создание иерархий моделей.
33
Глава 2. Разработка предметно-ориентированного языка описания
структуры и содержания электронных документов
Проблемы анализа и обработки слабоструктурированных электронных
документов послужили толчком к разработке предметно-ориентированного языка
описания
структуры
и
содержания
электронных
документов,
который
структурировал бы документ, позволяя сделать анализ документов более
осмысленным.
В данной главе, после изучения и анализа предметной области и
существующих инструментальных средств, следует преступать к непосредственной
разработке предметно-ориентированного языка описания структуры и содержания
электронных документов EDocSACD в выбранной нами ранее среде, а именно в
MetaEdit+ с использованием языка метамоделирования GOPRR, при помощи
которого описываются основные объекты языка и связи между ними.
2.1.
Описание элементов электронного документа в EDocSACD
Для создания предметно-ориентированного языка EDocSACD необходимо
определить его абстрактный и конкретный синтаксис. Абстрактный синтаксис, как
известно, описывает понятия, используемые в языке. Другими словами, он
использует существующие элементы, их свойства и их взаимодействие друг с
другом.
Конкретный синтаксис представляет собой описание конструкций языка с
помощью визуального представления языковых элементов на диаграммах, а
именно то, как элемент языка будет отображаться для пользователя. Конкретный
синтаксис обычно задается в специальных графических редакторах.
Описание языка целесообразно начать с абстрактного синтаксиса, который
чаще всего определяется в метамодели. Ключевые понятия, используемые в языке
описания структуры и содержания электронных документов, на этапе работы с
элементами электронного документа являются: слово, служебный символ,
предложение, абзац, изображение, таблица, ячейка, строка, столбец.
В нашем случае ключевые понятия также будут являться основными
объектами языка. Однако к ним добавятся еще такие классы как Element и
34
Document.
Класс
Document
отображает связь элементов с описываемым
документом, который может содержать много элементов.
В данной метамодели класс Element является абстрактным. Он отмечен
символом «{0}». Это означает, что количество объектов данного типа в модели
будет равно нулю. Однако кроме класса Element объекты Word, Symbol, Sentence
также отмечены символом «{0}». Это было сделано для того, чтобы при
построении модели данные объекты не отображались.
Описание конкретных объектов с их атрибутами представлено ниже в
таблице 2.1:
Объект языка
Имя класса
Слово
Word
Служебный
символ
Symbol
Предложение
Sentence
Абзац
Paragraph
Изображение
Image
Таблица
Table
Строка
Столбец
Ячейка
Ссылка
Элемент
Row
Column
Box
Link
Element
Документ
Document
Таблица 2.1. Описание классов метаязыка и их атрибутов
Описание
Атрибут
Тип атрибута
атрибута
Содержание
description
String
слова
number
Number (unique
per graph)
content
Text
Onto-link
String
number
Number (unique
per graph)
Номер
предложения
Содержание
предложения
Ссылка на
онтологию
предметной
области
Номер абзаца
Ссылка на
онтологию
предметной
области
Название
изображения
Название
таблицы
Ссылка на
онтологию
Onto-link
String
title
String
title
String
Onto-link
String
link
String
Ссылка
title
String
Название
документа
35
Далее необходимо описать виды отношений, которые будут реализованы в
метамодели. В нашем случае уместно использовать такие виды связи как
наследование, агрегация и ассоциация.
Для представления связи ассоциации может быть использован только один
вид связи have, который показывает, что какой-то элемент документа содержит
другой элемент. При таком роде отношений появляется связь между одним и более
объектами метамодели. Кроме того в данной метамодели присутствует одна связь
ассоциации, которая является двунаправленной. Это необходимо для того, чтобы
показать, что как объект Table может содержать объект Box, так и наоборот
(см. рис. 2.1):
Рисунок 2.1. Двунаправленная связь, ассоциация
Для того чтобы конкретные объекты обладали свойствами абстрактного
класса необходимо провести связь наследования. Благодаря этому отношению мы
сможем создавать новые объекты на основе существующих.
В данном случае связи наследования проведены от практически всех
объектов, а именно от Word, Symbol, Paragraph, Image, Table, Row, Column, Box, к
объекту Element, так как вышеупомянутые классы являются его наследниками (см.
рис. 2.2):
Рисунок 2.2. Связь наследование
36
После создания всех классов и отображения связей между ними, получилось
подробное описание синтаксиса метамодели, представленное на рис. 2.3, а также в
таблице 2.2 предложено графическое отображение и описание объектов созданной
метамодели:
Таблица 2.2. Графическое отображение объектов EDocSACD
Графическое
Наименование
Описание
представление
Document
Объект служит для отражения на диаграммах
визуального представления документа
Paragraph
Объект
используется
для
расположения абзацев в документе
Image
Объект отражает
изображения
Column
Объект используется для демонстрации столбцов
таблицы
Row
Объект служит для отображения строк таблицы
Table
Служит для добавления таблицы и ее названия в
документ
Box
Объект используется
таблицы
Связь «have»
Связь «have» служит для соединения элементов
электронного документа между собой.
имеющиеся
для
отображения
в
документе
отображения
37
ячеек
Рисунок 2.3. Метамодель элементов электронного документа
В приложении D представлен код MXM-файла графа метамодели
EDocSACD, описывающей элементы электронного документа.
2.2.
Описание реквизитов электронного документа в EDocSACD
Согласно ГОСТ Р 6.30-2003 «Унифицированная система организационнораспорядительной документации. Требования к оформлению документов» [34],
который устанавливает состав реквизитов документов и требования к их
оформлению, при подготовке и оформлении документов используют следующие
реквизиты:
1) Государственный герб Российской Федерации;
2) герб субъекта Российской Федерации;
3) эмблема организации или товарный знак (знак обслуживания);
4) код организации;
5) код формы документа;
6) наименование организации;
7) справочные данные об организации;
8) наименование вида документа;
9) дата документа;
10) регистрационный номер документа;
11) ссылка на регистрационный номер и дату документа;
38
12) место составления или издания документа;
13) гриф ограничения доступа к документу;
14) адресат;
15) гриф утверждения документа;
16) резолюция;
17) заголовок к тексту;
18) отметка о контроле;
19) текст документа;
20) отметка о наличии приложения;
21) подпись;
22) гриф согласования документа;
23) визы согласования документа;
24) оттиск печати;
25) отметка о заверении копии;
26) отметка об исполнителе;
27) отметка об исполнении документа и направлении его в дело;
28) отметка о поступлении документа в организацию;
29) идентификатор электронной копии документа.
Как известно, при оформлении электронного документа, имеющего
отношение
к
унифицированной
системе
организационно-распорядительной
документации, реквизиты группируются в пределах трех составных частей,
условно на которые можно поделить документ, такие как заголовочная,
содержательная и оформляющая части.
 Заголовочная часть электронного документа – начало документа,
состоящее из сведений об организации, являющаяся автором документа,
и первичных данных непосредственно о документе (реквизиты 1-16). К
первичным
данным
можно
отнести
такую
информацию
как
наименование, дату составления, регистрационный номер или код
документа по ОКУД и другие реквизиты-признаки.
 Содержательная часть по праву может называться основной частью,
раскрывающая назначение и смысл документа (реквизиты 17-20).
39
Рассматриваемая часть, в свою очередь, состоит либо из табличной, либо
из текстовой частей. К табличной части относятся реквизиты-признаки
для характеристики описываемого объекта (заголовки таблиц, строк,
граф) и реквизиты-основания для количественной характеристики.
 Третью частью считается оформляющая часть, которая включает в себя
совокупность реквизитов, подтверждающих подлинность и достоверность
информации, содержащейся в документе (реквизиты 21-24), а также
вспомогательные надписи, которые помогут облегчить работу с ним
(реквизиты 25-29) [34].
Изучив состав реквизитов электронного документа, было принято решение
выделить следующие объекты языка, которые представлены в табл. 2.3. В данном
случае
в
метамодели
символом {1}.
Это
встречаются
значит,
что
такие
при
классы,
построении
которые
модели
обозначаются
объект
может
использоваться только один раз. В ином случае пользователю будет выведено
сообщение об ошибке, согласно которому вторичное использование данного
элемента не возможно.
Объект языка
Таблица 2.3. Описание классов метаязыка
Тип
Описание
Атрибут
атрибута
атрибута
Имя класса
Документ
Заголовочная часть
Содержательная часть
Оформляющая часть
Государственный герб
РФ
Герб субъекта РФ
Эмблема организации
Код организации
Document
HeaderPart
SubstantialPart
MakePart
EmblemOfCity
OrgEmblema
EnterpriseCode
Code
Number
Код формы документа
CodeOfDocumentForm
Code
Number
Наименование
организации
CorporateName
Name
String
Организационные
справочные данные
OrganizationReferenceData
Email
String
Telephone
Fax
String
String
DocType
Collection
Наименование вида
документа
NationalEmblemOfRF
DocumentType
40
Код организации
Код формы
документа
Название
организации
Адрес
электронной
почты
Номер телефона
Номер факса
Наименование
вида документа
DocumentDate
Day
Month
Year
Тип
атрибута
Number
Number
Number
TailNumber
Number
Number
PlaceOfIssue
Addressee
TextTitle
TitleName Text
Отметка о контроле
ControlMark
Mark
String
Текст
Отметка о наличии
приложения
Text
Content
Text
MarkOfApplication
Number
Number
Name
String
Sheets
Number
Copies
Number
Объект языка
Имя класса
Дата документа
Регистрационный
номер
Место составления
Адресат
Заголовок текста
Атрибут
Гриф согласования
GrifOfApprovals
Date
Object
Вид согласования
ApprovalType
Type
String
Печать
Подпись
Отметка о заверении
копии
Отметка об
исполнении
Отметка о
поступлении
Stamp
Subscription
MarkOfTheCompletionOf
TheCopy
Date
Object
Организация
Organization
Name
String
Должностное лицо
OfficePerson
Position
String
Описание
атрибута
День
Месяц
Год
Регистрационный
номер
Заголовок
Отметка о
контроле
Текст документа
Номер
приложения
Название
Количество
страниц
Количество
копий
Дата
согласования
Вид
согласования
Дата заверения
копии
MarkOfExecution
MarkOfTheReceipt
Название
организации
Должность
Такие классы как PhysicalPerson и Address будут являться абстрактными
классами, что значит, что свойства, используемые в классах, будут наследоваться
другими классами (табл. 2.4):
Объект языка
Физическое
лицо
Адрес
Таблица 2.4. Описание абстрактных классов метаязыка
Тип
Описание
Имя абстрактного класса
Атрибут
атрибута
атрибута
ФИО
PhysicalPerson
Fio
String
человека
Название
Address
Org_name
String
организации
41
Объект языка
Country
City
Тип
атрибута
String
String
Street
String
House
Office
Index
Number
Number
Number
Имя абстрактного класса
Атрибут
Описание
атрибута
Страна
Город
Название
улицы
Номер дома
Номер офиса
Индекс
В данной метамодели описания реквизитов электронных документов
реализованы следующие виды отношений:
 Связь «can be» описывает адресата. Это значит, что, согласно
ГОСТ Р 6.30-2003
«Унифицированная
система
распорядительной
документации.
документов» [34],
адресатом может быть как организация, так и
Требования
организационнок
оформлению
должностное или физическое лицо (см. рис. 2.4):
Рисунок 2.4. Связь «can be»
 Связь «work in» (см. рис. 2.5) соединяет должностное лицо, которое
может являться адресатом, и организацию, в которой он работает:
Рисунок 2.5. Связь «work in»
 Ассоциативная связь «have» (см. рис. 2.6), которая также была
использована
в
предыдущей
метамодели
описания
элементов
электронного документа. Она означает причастность реквизита к
определенной части документа.
42
Рисунок 2.6. Отображение связи «have»
 Связь наследования (см. рис. 2.7), применимая к классу Physical person, от
которого класс
Addressee наследуют свойство
FIO, а также к
абстрактному классу Address:
Рисунок 2.7. Связь наследования
Графическое отображение и описание объектов метамодели после создания
всех классов и отображения связей между ними, представлено в таблице 2.5:
Наименование
Document
HeaderPart
Таблица 2.5. Графическое отображение объектов EDocSACD
Графическое
Описание
представление
Объект служит для отражения на
диаграммах визуального представления
документа.
Для обозначения
части.
границ
43
заголовочной
Наименование
Графическое
представление
Описание
SubstantialPart
Для обозначения границ содержательной
части.
MakePart
Для обозначения границ оформляющей
части.
NationalEmblemOfRF
Показывает
наличие
в
государственного
герба
Федерации.
EmblemOfCity
Показывает наличие герба города.
OrgEmblema
Отображает эмблему организации, которая
является составителем документа.
EnterpriseCode
Показывает код организации.
CodeOfDocumentForm
Данный объект отображает код формы
документа.
CorporateName
Отображает название организации.
OrganizationReferenceData
Предоставляет
возможность
ввода
организационно-справочной информации, а
именно адрес компании, электронную
почту, телефон.
Объект служит для предоставления
информации о типе документа.
DocumentType
документе
Российской
DocumentDate
Позволяет отобразить дату составления
документа.
TailNumber
Представляет собой
номер документа.
PlaceOfIssue
Указание
места
составления,
если
затруднено его определение по реквизитам
«Наименование
организации»
и
«Справочные данные».
44
регистрационный
Наименование
Описание
Объект адресат отображает сведения о
получателе документа. Им может быть
организация,
его
структурное
подразделение,
должностное
или
физическое лицо.
Выводит заголовок текста и включает в
себя краткое содержание документа.
Представляет собой отметку о контроле за
исполнением документа.
Addressee
TextTitle
ControlMark
Text
Текст документа может быть оформлен в
виде анкеты, таблицы, связного текста или
в виде соединения этих структур.
MarkOfApplication
Объект «отметка о наличии приложения»
отображает количество приложения, его
название,
количество
страниц
и
экземпляров.
Гриф
согласования
показывает
согласованность документа.
GrifOfApprovals
Stamp
Объект отображает штамп организации.
Subscription
Объект
отображает
должность
подписывающего, его инициалы и саму
подпись.
Необходим при заверении соответствия
копии документа подлиннику.
MarkOfTheCompletionOf
TheCopy
OfficePerson
Графическое
представление
Заключается в описании должностного
лица, а именно его инициалов и должности.
Получившаяся метамодель с отображением всех классов и
связей
представлена в приложении C.
2.3.
Описание видов электронного документа в EDocSACD
Использование рассмотренных ранее реквизитов электронного документа, то
есть его обязательных элементов, непосредственно зависит от вида документа.
Поэтому третий уровень заключается в описании видов электронных документов,
что в дальнейшем поможет выявить перечень обязательных реквизитов для
45
конкретного вида ЭД, так как разные документы состоят из разного набора
реквизитов.
Электронные документы принято подразделять на:
 система организационно-правовой документации;
 система распорядительной документации;
 система информационно-справочной документации [35].
В свою очередь каждая из этих систем включает в себя свой перечень
документов. Далее рассмотрим данные системы, виды документов, относящиеся к
ним, и обязательные реквизиты подробнее.
Система
организационно-правовой
документации
–
правовая
основа
деятельности организации и содержащая положения, основанные на нормах
административного права и обязательные для исполнения. К организационноправовым документам относятся [36]:
 устав;
 учредительный договор;
 положение об организации;
 положение о структурном подразделении;
 положение о коллегиальном органе;
 регламент;
 штатное расписание;
 инструкция;
 должностная инструкция.
Обязательными реквизитами для организационно-правовых документов
являются следующие: наименование организации; наименование вида документа;
дата; номер документа; место составления; заголовок к тексту; подпись; гриф
утверждения.
К следующей системе, системе распорядительной документации, относятся
документы,
в
которых
фиксируются
решения
административных
организационных вопросов деятельности организации, такие как [36]:
46
и
 распорядительные документы, издаваемые в условиях единоличного
принятия решения, когда власть по всем вопросам управления в
организации принадлежит ее руководителю:
 приказ;
 распоряжение;
 указание;
 распорядительные документы, издаваемые в условиях коллегиального
принятия решения, то есть они издаются на основании решений,
принимаемых совместно группой работников:
 решение;
 постановление.
У распорядительных документов обязательными реквизитами указания
являются:
наименование
организации;
название
вида
документа;
дата
и
регистрационный номер документа; место составления или издания; заголовок к
тексту; подпись; визы согласования документа.
Система информационно-справочной документации и информационносправочные
документы
сообщают
сведения,
побуждающие
принимать
определенные решения, то есть инициируют управленческие решения, позволяют
выбирать тот или иной способ управленческого воздействия. Они не содержат
поручений и не обязывают выполнять их. К таким системам относятся [36]:
 докладная записка;
 служебная записка;
 объяснительная записка;
 предложение;
 представление;
 заявление;
 протокол;
 акт;
 справка;
 заключение;
 отзыв;
47
 перечень;
 список;
 служебное письмо – это обобщенное название различных по содержанию
документов, выделяемых в связи с особым способом передачи текста, –
пересылкой почтой:
 сопроводительное письмо;
 письмо-просьба;
 письмо-запрос;
 письмо-ответ;
 письмо-сообщение;
 письмо-подтверждение;
 информационное письмо;
 письмо-извещение;
 письмо-приглашение;
 письмо-напоминание;
 письмо-требование;
 письмо-благодарность;
 телеграмма;
 факс;
 электронное сообщение.
Как и другим системам, системе информационно-справочной документации
присущи свои обязательные реквизиты, такие как: наименование организации;
наименование вида документа; дата и регистрационный номер; место составления;
адресат; заголовок к тексту; подпись; гриф утверждения (в необходимых случаях).
Однако для описания служебных писем используется более обширный перечень
обязательных реквизитов:
 наименование организации;
 справочные данные об организации;
 код организации;
 основной
государственный
регистрационный
юридического лица;
48
номер
(ОГРН)
 идентификационный номер налогоплательщика;
 код причины постановки на учет;
 дата;
 регистрационный номер;
 адресат;
 заголовок к тексту (при составлении письма на бланке формата А4);
 подпись;
 отметка об исполнителе;
 отметка о наличии приложений (в сопроводительных письмах).
Рассмотрев основные понятия видов электронных документов и список
обязательных реквизитов для каждой системы электронных документов, можно
выделить следующие объекты языка (табл. 2.6), абстрактные классы (табл. 2.7) и их
атрибуты:
Объект языка
Документ
Организационноправовая система
Распорядительная
система
Информационносправочная система
Служебное письмо
Имя класса
Document
Procedural and
institutional system
Administrative
system
Inquiry and
communications
system
Service letter
Таблица 2.6. Описание классов метаязыка
Тип
Атрибут
Описание атрибута
атрибута
title
String
Название документа
System (PaI)
String
Система документа
System (A)
String
Система документа
System (IaC)
String
Система документа
Addressee
Organization
reference data
Enterprise code
Mark of
execution
Object
Адресат документа
Организационносправочные данные
Код организации
Отметка о получении
документа
Отметка о
приложениях
документа
Mark of
application
Объект языка
Системы
документов
Object
Object
Object
Object
Таблица 2.7. Описание абстрактных классов метаязыка и их атрибутов
Имя абстрактного
Тип
Атрибут
Описание атрибута
класса
атрибута
Corporate
Название
SystemDoc
Object
name
организации
Document type Object
Вид документа
Document data Object
Дата составления
49
Объект языка
Имя абстрактного
класса
Атрибут
Тип
атрибута
Описание атрибута
Tail number
Object
Place of issue
Text title
Subscription
Grief of
approval
Object
Object
Object
Регистрационный
номер
Место составления
Заголовок текста
Подпись
Object
Гриф согласования
При создании метамодели видов электронных документов добавление
дополнительных связей, кроме наследования и имеющейся связи «is», между
объектами не потребовалось. В данном случае связь «is» показывает, что
описываемый документ будет являться экземпляром системы документов, либо
организационно-правовой,
либо
распорядительной,
либо
информационно-
справочной.
После создания всех классов и отображения связей между ними необходимо
отобразить графически и описать объекты созданной метамодели. Описание
представлено в таблице 2.8:
Таблица 2.8. Графическое отображение объектов EDocSACD
Наименование
Описание
Графическое представление
Document
Объект служит для отражения
на диаграммах визуального
представления документа
Объект
используется
для
отображения того, к какой
системе относится документ, а
именно к организационноправовой системе.
Объект
используется
для
Administrative
отображения
того,
что
system
документ
относится
к
распорядительной системе.
Объект
используется
для
Inquiry and
отображения
того,
что
communications документ
является
экземпляром информационноsystem
справочной системы.
Объект
используется
для
того,
что
Research system отображения
документ относится к научноисследовательской системе.
Procedural and
institutional
system
50
Наименование
Service letter
Описание
Отображает
причастность
документа к объекту, который
наследуется
от
информационно-справочной
системы.
Графическое представление
Получившаяся метамодель описания видов электронных документов
представлена на рисунке 2.9:
Рисунок 2.9. Отображение связей наследования и ассоциации в метамодели
2.4.
Разработка модели описания структуры и содержания
электронного документа
Для объединения созданных метамоделей для описания элементов ЭД,
реквизитов и видов необходимо было создать новую метамодель (приложение E),
которая бы интегрировала все имеющиеся метамодели в одну. Однако после этого
потребовалось добавление новых связей, чтобы показать взаимосвязь между
элементами документа и его реквизитами, а также удаление некоторых атрибутов
из объектов метамодели описания видов документов (см. рис. 2.10):
51
Рисунок 2.10. Элементы метамодели
Далее необходимо перейти к непосредственному созданию модели,
используя разработанный DSL, для демонстрации возможностей языка. Для этого
рассмотрим конкретные примеры описания структуры и содержания электронных
документов на основе трех документов: приказ о зачислении на 1 курс; письмоизвещение; техническое задание.
2.4.1. Пример: приказ о зачислении на 1 курс
Форма приказа о зачислении на 1 курс представлена в приложении G,
согласно которой документ состоит из трех частей: заголовочной, содержательной
и оформляющей. В качестве основных реквизитов документа распорядительной
системы заголовочной части выступают эмблема организации, содержащая
название, тип документа, распорядительный номер и дата составления документа.
К содержательной части относятся заголовок текста и сам текст, который может
быть оформлен в виде анкеты, таблицы, связного текста или в виде соединения
этих структур. Оформляющая часть включает в себя совокупность реквизитов,
подтверждающих подлинность и достоверность информации, содержащейся в
документе: подпись человека, который издал приказ, его инициалы и занимаемая
должность.
Кроме того в описываемом документе существует приложение к приказу,
которое отображено в модели как раздел «Приложение». Данный раздел имеет
содержательную и оформляющую часть, при том текст содержательной части
52
является таблицей, а оформляющая часть содержит подпись заместителя
ответственного секретаря.
На рисунке 2.11 представлено описание приказа о зачислении на 1 курс
факультета
бизнес-информатики
Пермского
филиала
Государственного
университета – Высшей школы экономики:
Рисунок 2.11. Описание структуры приказа о зачислении
2.4.2. Пример: письмо-извещение
Следующий пример описания структуры и содержания основан на письмеизвещении, которое является служебным письмом. Служебное письмо, в свою
очередь, является подмножеством информационно-справочной системы.
Созданная модель, отображающая структуру и содержание письмаизвещения, представлена на рисунке 2.12:
53
Рисунок 2.12. Описание структуры письма-извещения
Согласно образцу письма-извещения (приложение H), в полученной модели
документ поделен на три части, каждая из которых имеет свои реквизиты. Так,
например, заголовочная часть содержит в себе данные об адресате, который
работает в конкретной организации, имеющей организационно-справочные данные
(адрес и контакты). Кроме того туда входят дата составления письма и его
регистрационный номер. Содержательная часть, как и в других документах,
включает в себя заголовок текста и сам текст, который в данном случае состоит из
трех параграфов. Подпись отправителя, его инициалы и должность заносятся в
оформляющую часть.
2.4.3. Пример: техническое задание
Как известно, техническое задание является исходным документом на
проектирование технического объекта и устанавливает основное назначение
разрабатываемого объекта, его технические характеристики, показатели качества и
технико-экономические требования, предписанные по выполнению необходимых
стадий создания документации и ее состав, а также специальные требования.
Согласно
ГОСТ
34.602-89
техническое
задание
должно
содержать
следующие разделы, включающие в себя некоторые подразделы и реквизиты:
 общие сведения:
 полное наименование системы и ее условное обозначение;
54
 шифр темы или шифр (номер) договора;
 наименование предприятия разработчика и заказчика, их
реквизиты;
 перечень документов, на основании которых создается система;
 плановые сроки начала и окончания работы по созданию
системы;
 сведения об источниках и порядке финансирования работ;
 порядок оформления и предъявления заказчику результатов
работ по созданию системы;
 определения, обозначения и сокращения;
 назначение и цели создания системы:
 назначение системы;
 цели создания системы;
 характеристика объектов автоматизации:
 краткие сведения об объекте автоматизации;
 сведения об условиях эксплуатации объекта автоматизации;
 требования к системе:
 требования к системе в целом:
 требования к структуре и функционированию системы;
 показатели назначения;
 требования к надежности;
 требования безопасности;
 требования к эксплуатации;
 требования к защите информации;
 дополнительные требования;
 требования к функциям и задачам, выполняемым системой;
 требования к видам обеспечения;
 состав и содержание работ;
 порядок контроля и приемки:
 виды испытаний;
55
 общие требования к приемке работ;
 статус приемной комиссии;
 требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие;
 требования к документированию;
 источники разработки.
Кроме того, в состав ТЗ входят титульный и последний листы, которые
содержат перечень обязательных реквизитов: название компании разработчика ТЗ,
дата составления документа, вид документа, подписи разработчика и заказчика и
штамп на титульном листе; код формы документа, отметки о составлении и
согласовании с подписями на последнем.
На основании состава и содержания технического задания была построена
модель описания структуры и содержания ТЗ (см. рис. 2.13 и рис. 2.14), созданная с
помощью ранее построенной метамодели:
Рисунок 2.13. Описание технического задания. Фрагмент 1: Разделы «Характеристики
объектов», «Состав и содержание работ», «Порядок контроля и приемки системы»,
«Источники разработки»
56
Рисунок 2.14. Описание технического задания. Фрагмент 2: разделы «Общие сведения»,
«Назначение и цели», «Требования к системе»
На данных фрагментах показаны те объекты языка EDocSACD, которые
позволяют описать состав и содержание технического задания.
2.5.
Результаты разработки предметно-ориентированного языка
описания структуры и содержания электронных документов
Данная глава была посвящена описанию процесса разработки предметноориентированного
языка
описания
структуры
и
содержания
электронных
документов, который интегрирует в себе три метамодели описания: элементов ЭД,
его реквизитов и видов. Разработанный язык был реализован при помощи
платформы MetaEdit+.
В ходе создания метамоделей предметной области можно констатировать,
что DSM-платформа MetaEdit+ позволяет наглядно представить модели описания
структуры и содержания ЭД. Одной из положительной особенностью построенной
метамодели является универсальность применения ее в описании электронного
документа. Визуализация объектов по праву может считаться одним из основных
достоинством, что позволяет пользователю лучше ориентироваться в них. Также
57
преимуществом
использования
данной
системы
является
возможность
динамического изменения модели при внесении корректировок в метамодели.
Однако в процессе работы с данным инструментальным средством были
выявлены некоторые недостатки предлагаемой платформы:
 отсутствие
возможности
ручной
доработки
кода,
а
именно
невозможность исправления ошибок, возникающих в коде в процессе
разработки метамодели;
 недопустимость задания иной ориентации для символов, позволяющих
наглядно представить как объекты, так и связи;
 громоздкость
метамодели
и
модели
при
масштабировании
и
возможность возникновения трудностей с восприятием;
 неосуществимость экспорта метамодели и модели, так как для этих
целей данная DSM-платформа использует свой собственный формат
файлов MXT.
58
Заключение
В результате работы все задачи, поставленные на время написания
выпускной квалификационной работы, были решены и цель достигнута. Для этого
были проанализированы источники, дающие определение понятия электронного
документа. Анализ существующих вариантов показал, что единого варианта не
существует как в научном мире, так и в современном законодательстве. На
основании рассмотренных определений выделены его функции и основные
свойства, для обеспечения выполнения рассмотренных функций, а также его
признаки и требования, которым электронный документ должен удовлетворять.
В рамках проделанной работы были проанализированы существующие
способы описания структуры электронных документов, таких как форматы HTML
и SGML, и существующие способы описания документов (подходы Dublin Core,
SHOE, DoCO, онтология проекта исследовательской группы KWARC). Анализ
показал, что существующие способы описания документов имеют не только
достоинства, но и ряд недостатков, которые были учтены при разработке
предметно-ориентированного
языка
описания
структуры
и
содержания
электронного документа.
Кроме того в работе был выполнен анализ материалов о предметноориентированных языках и обзор методов и средств их разработки: MetaEdit+, MS
DSL Tools, Eclipse GMF, State Machine Designer, Meta Programming System, REALIT, UFO-toolkit. Ни одна из рассмотренных технологий не позволяет производить
трансформацию созданных моделей из одной нотации в другую, а также
отсутствует возможность отчуждения DSL от DSM-платформ во всех описанных
технологиях. Основываясь на результатах анализа, MetaEdit+, в отличие от других
технологий, позволяет вносить изменения в описание DSL во время работы
системы и модифицировать метаязык, поэтому для разработки была использована
данная система.
Результатом работы является разработанный предметно-ориентированный
язык описания структуры и содержания электронных документов EDocSACD,
реализованные при помощи платформы MetaEdit+. Созданный язык достаточно
прост в понимании и адекватно отражает понятия исследуемой предметной
59
области, так как используются конструкции, разработанные специально для
решения задачи описания структуры и содержания электронных документов.
Кроме того, DSL удовлетворяет сформулированным требованиям:
 предоставление возможности построения моделей пользователем, не
имеющим глубоких знаний в области моделирования;
 являться наглядной для пользователя и не перегруженной лишними
элементами;
 набор
элементов
должен
полностью
удовлетворять
потребности
пользователя.
Язык EDocSACD имеет три метамодели, которые достаточно просто
редактировать в соответствии с особенностями конкретных предметных областей
или согласно меняющимся условиям, создавая новые объекты и добавляя связи
между ними.
В будущем данная тема будет расширяться. В разработанном предметноориентированном
языке
необходима
дальнейшая
реализация
возможности
добавления онтологии предметной области для описания содержания электронных
документов.
Использование созданного языка возможно в системе электронного
документооборота для валидации документов, что позволит компании облегчить
процесс анализа и обработки электронных документов за счет описания их
структуры и содержания. Кроме того, модель может быть использована при
реализации различных инструментальных средств для обработки электронных
документов, в частности для средств анализа документов, создания отчетов,
семантической индексации.
60
Библиографический список
1.
Хургин В.М. Еще раз об электронном документе. //
Российская
ассоциация электронных библиотек. [Электронный ресурс] [Режим доступа:
http://www.aselibrary.ru/datadocs/doc_790ra.pdf] [Проверено: 28.04.2014].
2.
Делопроизводство и архивное дело. Термины и определения [Текст]:
ГОСТ Р 51141-98. – М.: Изд-во стандартов, 1998.
3.
Межгосударственный стандарт. Система стандартов по информации,
библиотечному и издательскому делу. Электронные издания. Основные виды.
Выходные сведения [Текст]: ГОСТ 7.83-2001. – Минск: Межгосударственный
совет по стандартизации, метрологии и сертификации, 2001. 23 с: ил.
4.
Рекомендации по стандартизации. Информационные технологии
поддержки жизненного цикла продукции. Терминологический словарь. Часть 1.
Стадии жизненного цикла продукции [Текст]: Р 50.1.031-2001. – М.: Изд-во
стандартов, 2001.
5.
Приказ Федерального агентства по техническому регулированию и
метрологии от 29 декабря 2004 г. № 135-ст «Об утверждении национального
стандарта» //нет данных об опубликовании [ГОСТ Р 52292-2004 Информационная
технология. Электронный обмен информацией. Термины и определения.] – М.:
Изд-во стандартов, 2005.
6.
Федеральный закон от 10 января 2002 г. № 1-ФЗ «Об электронной
цифровой подписи» //СЗ РФ. – 2002. – № 2. – ст. 127; 2007, № 46. – ст. 5554.
7.
Воройский
Ф.С.
Систематизированный
толковый
словарь
по
информатике (вводный курс по информатике и вычислительной технике в
терминах). – М.: «Либерия», 1998. 376 с.
8.
Клименко С.В. Электронные документы в корпоративных сетях:
второе пришествие Гутенберга. – М.: Анкей – ЭК – Трендз, 1999. 271 с.
9.
Карминский А.М. Информатизация бизнеса. – М.: Финансы и
статистика, 1997.
10.
Тихонов В.И. Сущностные характеристики, состав и классификация
электронных документов. – М.: Росархив. ВНИИДАД. РОИА. – 2000. 204 – 218 с.
61
Тихонов В.И. Электронные архивы и электронный документооборот
11.
//Отечественные архивы. – 1999. – № 2.
Семилетов С.И. Информация как особый объект права //Проблемы
12.
информатизации. – 1999. – № 3.
Швецова–Водка Г.Н. Функции и свойства документа в системе
13.
социальных коммуникаций. // Кн.: исследования и материалы. – М. 1994. 37 – 57 с.
Кушнаренко Н.Н. Документоведение: Учебник.- 8-е изд. – Киев:
14.
Знання, 2008.
Серова Л.И. Документационное обеспечение управления. Учебное
15.
пособие.
//
Рудос.
[Электронный
ресурс]
[Режим
доступа:
http://rudocs.exdat.com/docs/index-304709.html?page=4] [Проверено: 15.04.2014].
Приложение к постановлению МПА ЕврАзЭС от 25 марта 2002 г. №2-
16.
19 «Об электронном документе». Глава 2. // Межпарламентская Ассамблея
Евразийского экономического сообщества. [Электронный ресурс] [Режим доступа:
http://www.ipaeurasec.org/docsdown/mz_eldoc.pdf] [Проверено: 29.04.2014].
Structure, models and meaning. Is “unstructured” data merely unmodeled?
17.
// InformationWeek. Connecting the business technology community. [Электронный
ресурс]
[Режим
доступа:
http://www.informationweek.com/software/information-
management/structure-models-and-meaning/d/d-id/1030187?] [Проверено: 30.04.2014].
18.
A representation of Textual Information and MetaInformation for Retrieval
and Interchange. // World Wide Web Consortium (W3C). [Электронный ресурс]
[Режим доступа: http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt] [Проверено:
30.04.2014].
Технология подготовки электронных документов с использованием
19.
программных средств. // Учебные материалы. [Электронный ресурс] [Режим
доступа: http://works.doklad.ru/view/sbM1En1aoA4/all.html] [Проверено: 22.04.2014].
Кирсанов Д. XML против HTML. // Александр Гагарин. [Электронный
20.
ресурс]
[Режим
доступа:
http://www.gagin.ru/internet/1/19.html]
[Проверено:
30.05.2014].
21.
Бобко А.В. О лингвистических средствах тематического поиска в
электронном каталоге ГПНТБ СО РАН // Региональные библиотечные системы:
История, современное состояние, перспектива. – Новосибирск, 1995.
62
Система стандартов по информации, библиотечному и издательскому
22.
делу. Процессы управления документами. Метаданные для документов. Часть 1.
Принципы [Текст]: ГОСТ Р ИСО 23081-1 – 2008. – М.: Изд-во стандартов, 2008.
Тевс Д.П. Создание электронной библиотеки образовательного
23.
учреждения. Барнаул: Изд-во БГПУ, 2004.
24.
Dublin Core Metadata Element Set, Version 1.1. // Metadata Dublin Core.
[Электронный
ресурс]
[Режим
доступа:
http://dublincore.org/documents/dces/]
[Проверено: 09.04.2014].
25.
Heflin J. Searching the Web with SHOE. // Computer science university of
Maryland.
[Электронный
ресурс]
[Режим
http://www.cs.umd.edu/projects/plus/SHOE/pubs/aiweb2000.pdf]
доступа:
[Проверено:
13.04.2014].
26.
SHOE. Document Ontology (draft). // Computer science university of
[Электронный
Maryland.
ресурс]
[Режим
http://www.cs.umd.edu/projects/plus/SHOE/onts/docmnt1.0.html]
доступа:
[Проверено:
28.04.2014].
Ефименко
27.
И.В.
Онтологическое
моделирование
экономики
предприятий и отраслей современной России. Онтологическое моделирование:
подходы, модели, методы, средства, решения. // Высшая школа экономики.
Национальный исследовательский университет. [Электронный ресурс] [Режим
доступа:
http://www.hse.ru/data/2011/12/22/1261631357/WP7_2011_08_1.pdf]
[Проверено: 29.04.2014].
Document Ontology. // The KWARK Research Group. [Электронный
28.
ресурс]
[Режим
доступа:
http://kwarc.info/projects/docOnto/]
[Проверено:
28.04.2014].
29.
Сухов А.О. Сравнение систем разработки визуальных предметно-
ориентированных языков.// Математика программных систем: межвуз. сб. науч. ст.
– Пермь: Изд-во Перм. гос. нац. исслед. ун-та, 2012. – Вып. 9.
30.
Фаулер М. Предметно-ориентированные языки программирования.
Пер. с англ. М.: ООО «И.Д. Вильямс», 2011. 121 с.
63
31.
Иванов А.Н. Моделирование интерфейса полнофункциональных веб-
приложений,
интенсивно
работающих
с
данными.
//
Вестник
Санкт-
Петербургского университета, серия 10, вып. 3. 2009. 8 с.
32.
Qreal.
ресурс]
[Электронный
[Режим
доступа:
http://qreal.ru/]
[Проверено: 28.04.2014].
33.
Унифицированная
система
организационно-распорядительной
документации. Требования к оформлению документов [Текст]: ГОСТ Р 6.30-2003. –
М.: Изд-во стандартов, 2003.
34.
виды
и
Межгосударственный стандарт. Электронные издания. Основные
выходные
сведения
[Текст]:
ГОСТ 7.83-2001.
–
Минск:
Межгосударственный совет по стандартизации, метрологии и сертификации, 2002.
3 с: ил.
35.
Энциклопедия делопроизводства. // Центр компетенции по вопросам
документационного обеспечения управления и архивного дела. [Электронный
ресурс] [Режим доступа: http://www.edou.ru/enc/index.php] [Проверено: 29.04.2014].
64
Приложение A. Описание элементов «Дублинского ядра»
Title
Имя элемента
Заголовок
Creator
Автор
Subject
Предмет
Description Описание
Publisher
Издатель
Участник
Contributor создания
материала
Date
Дата
Type
Тип
Format
Формат
Identifier
Идентификатор
Source
Источник
Language
Язык
Таблица А.1. Описание элементов Dublin Core
Описание элемента
Название, присвоенное ресурсу создателем или издателем.
Человек или организация, изначально ответственная за
интеллектуальное содержание ресурса (в случае рукописного
документа это авторы, исполнители, фотографы или
иллюстраторы в случае визуальных ресурсов).
Тема ресурса. Обычно предмет выражается в ключевых
словах или фразе, описывающей предмет или содержание
ресурса. Приветствуется использование контролируемых
словарей и формальных схем классификации.
Текстовое описание содержания ресурса, включая реферат в
случае документов или описание содержания в случае
визуального ресурса.
Организация, ответственная за создание ресурса в его
нынешней
форме,
например,
издательский
дом,
университетский департамент или корпорация.
Человек или организация, которые не являются авторами (не
обозначены в элементе “автор”), но внесли значительный
интеллектуальный вклад в ресурс, однако чей вклад вторичен
по отношению к любому человеку или организации,
указанной в числе авторов, например, редактор, переводчик,
иллюстратор.
Дата, указывающая на время создания или появления (в
доступном виде) ресурса.
Категория ресурса, например, домашняя страничка, роман,
поэма, статья, препринт, технический отчет, эссе, словарь.
Для выражения типа может использоваться следующий
минимальный набор обобщенных значений: текст (text);
изображение (image); звук (sound); набор данных (dataset);
программа (software); интерактивная система (interactive);
событие (event), которое в свою очередь может также быть
детализировано до конференции, семинара, круглого стола,
выставки, проекта; физический объект (physical object).
Формат представления данных ресурса (обычно указывается
тип программного обеспечения и, возможно, тип
компьютера, которые могут быть необходимы для
отображения и работы с ресурсом). Для данного элемента
рекомендуется выбирать значения из множества типов
контента MIME (Multipurpose Internet Mail Extensions), такие
как text/xml (документ на xml), text/plain (текст без
форматирования и разметки), image/gif (изображение в
формате gif).
Набор букв или цифр, используемый для уникальной
идентификации ресурса. В случае сетевых ресурсов
примерами являются URL и URN.
Информация о вторичном источнике, из которого был
получен настоящий ресурс.
Язык, на котором изложено интеллектуальное содержание
ресурса.
65
Имя элемента
Relation
Связь
Coverage
Охват
Rights
Права
Описание элемента
Идентификатор вторичного ресурса и его связь с настоящим
ресурсом. Этот элемент позволяет связывать между собой
близкие ресурсы, а также описания ресурса, которые
необходимо показать.
Характеристики
местонахождения
и
временной
продолжительности ресурса.
Утверждение об авторских правах и управление ими;
идентификатор, связанный с таким утверждением;
идентификатор, связанный с сервисом, представляющим
информацию об управлении правами на данный ресурс.
66
Приложение B. Оценка технологий создания предметно-ориентированного языка
Таблица B.1. Оценка технологий создания предметно-ориентированного языка
MS DSL
Tools,
UFOEclipse GMF
MPS
REAL-IT
State Machine
toolkit
Designer
0
0
0
0
0
Вес
MetaEdit+
1
1
Возможность модификации метаязыка
1
1
0
0
0
0
0
Создание визуальных DSL
1
1
1
1
0
1
1
Создание текстовых DSL
1
0
0
0
1
0
0
Наличие средств «ручной» доработки DSL
1
0
1
1
1
1
0
Возможность изменения графического
редактора для работы с DSL
Возможность
горизонтальной
трансформации моделей
1
1
1
1
0
0
0
1
0
0
0
0
0
0
Интеграция нескольких DSL
1
1
1
1
1
0
0
Отчуждаемость DSL от DSM-платформы
1
0
0
0
0
0
0
Сумма
9
5
4
4
3
2
1
Динамическое
метамоделей
изменение
описания
67
Приложение C. Метамодель описания реквизитов электронного документа
Рисунок C.1. Метамодель описания реквизитов электронного документа
68
Приложение D. MXM-файл графа метамодели EDocSACD
<?xml version="1.0" encoding="UTF-8"?>
<gxl xmlns="http://www.metacase.com/gxlGOPRRType" xmlns:sym="http://www.metacase.com/symbol">
<graph description="" id="Metamodel__Elementy_26_7260" typeName="Elementy">
<object description="" id="Object___Box_26_9866" typeName=" Box">
<superType>
<object description="" id="Object__Element_26_5096" typeName="Element">
</object>
</superType>
</object>
<object description="" id="Object__Column_26_5232" typeName="Column">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
</object>
<object description="" id="Object__Document_26_5758" typeName="Document">
<slot id="p26_5151" name="title" unique="false">
<property description="" id="Property_title_26_5151" typeName="title">
<dataType>
<simpleType>String</simpleType>
</dataType>
<widget>Input Field</widget>
</property>
</slot>
</object>
<object description="" id="Object__Image_26_5183" typeName="Image">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
<slot id="p26_5151" name="title" unique="false">
<property description="" id="Property_title_26_5151" typeName="title">
<dataType>
<simpleType>String</simpleType>
</dataType>
<widget>Input Field</widget>
</property>
</slot>
</object>
<object description="" id="Object__Link_26_8731" typeName="Link">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
<slot id="p26_16555" name="link" unique="false">
<property description="" id="Property_link_26_16555" typeName="link">
<dataType>
<simpleType>String</simpleType>
</dataType>
<widget>Input Field</widget>
</property>
</slot>
</object>
<object description="" id="Object__Paragraph_26_5140" typeName="Paragraph">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
<slot id="p26_8405" name="number" unique="false">
<property description="" id="Property_number_26_8405" typeName="number">
<dataType>
<simpleType>Number</simpleType>
</dataType>
</property>
</slot>
</object>
<object description="" id="Object__Row_26_5221" typeName="Row">
<superType>
<object href="#Object__Element_26_5096"></object>
69
</superType>
</object>
<object description="" id="Object__Table_26_5194" typeName="Table">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
<slot id="p26_5151" name="title" unique="false">
<property description="" id="Property_title_26_5151" typeName="title">
<dataType>
<simpleType>String</simpleType>
</dataType>
<widget>Input Field</widget>
</property>
</slot>
</object>
<relationship description="" id="Relationship__have_26_5265" typeName="have">
</relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<relationship href="#Relationship__have_26_5265"></relationship>
<role description="" id="Role__Abzac_26_5437" typeName="Abzac">
</role>
<role href="#Role__Abzac_26_5437"></role>
<role description="" id="Role__Box_26_8588" typeName="Box">
</role>
<role href="#Role__Box_26_8588"></role>
<role description="" id="Role__Document_26_5780" typeName="Document">
</role>
<role description="" id="Role__Predlozenie_26_5363" typeName="Predlozenie">
</role>
<role href="#Role__Predlozenie_26_5363"></role>
<role href="#Role__Predlozenie_26_5363"></role>
<role description="" id="Role__Stolbec_26_5511" typeName="Stolbec">
</role>
<role description="" id="Role__Stroka_26_5478" typeName="Stroka">
</role>
<role description="" id="Role__Tablica_26_5470" typeName="Tablica">
</role>
<role href="#Role__Tablica_26_5470"></role>
<role href="#Role__Tablica_26_5470"></role>
<role href="#Role__Abzac_26_5437"></role>
<role href="#Role__Box_26_8588"></role>
<role href="#Role__Box_26_8588"></role>
<role href="#Role__Box_26_8588"></role>
<role description="" id="Role__Element_26_5821" typeName="Element">
</role>
<role description="" id="Role__Izorazenie_26_5627" typeName="Izorazenie">
</role>
<role href="#Role__Izorazenie_26_5627"></role>
<role href="#Role__Izorazenie_26_5627"></role>
<role href="#Role__Predlozenie_26_5363"></role>
<role description="" id="Role__Simvol_26_5371" typeName="Simvol">
</role>
<role description="" id="Role__Slovo_26_5404" typeName="Slovo">
</role>
<role href="#Role__Stolbec_26_5511"></role>
<role href="#Role__Stroka_26_5478"></role>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
70
<connection>
<role href="#Role__Predlozenie_26_5363"></role>
<object description="" id="Object__Sentence_26_5129" typeName="Sentence">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
<slot id="p26_8405" name="number" unique="false">
<property description="" id="Property_number_26_8405" typeName="number">
<dataType>
<simpleType>Number</simpleType>
</dataType>
</property>
</slot>
<slot id="p26_8421" name="content" unique="false">
<property description="" id="Property_content_26_8421" typeName="content">
<dataType>
<simpleType>Text</simpleType>
</dataType>
</property>
</slot>
</object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Slovo_26_5404"></role>
<object description="" id="Object__Word_26_5107" typeName="Word">
<superType>
<object href="#Object__Element_26_5096"></object>
</superType>
<slot id="p26_8974" name="description" unique="false">
<property description="" id="Property_description_26_8974" typeName="description">
<dataType>
<simpleType>String</simpleType>
</dataType>
<widget>Input Field</widget>
</property>
</slot>
</object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Abzac_26_5437"></role>
<object href="#Object__Paragraph_26_5140"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Predlozenie_26_5363"></role>
<object href="#Object__Sentence_26_5129"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Predlozenie_26_5363"></role>
<object href="#Object__Sentence_26_5129"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Simvol_26_5371"></role>
<object description="" id="Object__Symbol_26_5118" typeName="Symbol">
<superType>
71
<object href="#Object__Element_26_5096"></object>
</superType>
</object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Tablica_26_5470"></role>
<object href="#Object__Table_26_5194"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Stroka_26_5478"></role>
<object href="#Object__Row_26_5221"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Tablica_26_5470"></role>
<object href="#Object__Table_26_5194"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Stolbec_26_5511"></role>
<object href="#Object__Column_26_5232"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Abzac_26_5437"></role>
<object href="#Object__Paragraph_26_5140"></object>
</connection>
<connection>
<role href="#Role__Izorazenie_26_5627"></role>
<object href="#Object__Image_26_5183"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Predlozenie_26_5363"></role>
<object href="#Object__Sentence_26_5129"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Izorazenie_26_5627"></role>
<object href="#Object__Image_26_5183"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Document_26_5780"></role>
<object href="#Object__Document_26_5758"></object>
</connection>
72
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Element_26_5821"></role>
<object href="#Object__Element_26_5096"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Tablica_26_5470"></role>
<object href="#Object__Table_26_5194"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Box_26_8588"></role>
<object href="#Object___Box_26_9866"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Stolbec_26_5511"></role>
<object href="#Object__Column_26_5232"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Box_26_8588"></role>
<object href="#Object___Box_26_9866"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Stroka_26_5478"></role>
<object href="#Object__Row_26_5221"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Box_26_8588"></role>
<object href="#Object___Box_26_9866"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Box_26_8588"></role>
<object href="#Object___Box_26_9866"></object>
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Izorazenie_26_5627"></role>
<object href="#Object__Image_26_5183"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<role href="#Role__Box_26_8588"></role>
<object href="#Object___Box_26_9866"></object>
73
</connection>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Abzac_26_5437"></role>
<object href="#Object__Paragraph_26_5140"></object>
</connection>
</binding>
<binding>
<relationship href="#Relationship__have_26_5265"></relationship>
<connection>
<cardinality start="1" stop="N"></cardinality>
<role href="#Role__Box_26_8588"></role>
<object href="#Object___Box_26_9866"></object>
</connection>
<connection>
<role href="#Role__Tablica_26_5470"></role>
<object href="#Object__Table_26_5194"></object>
</connection>
</binding>
<constraints>
<uniqueness>
<object href="#Object__Paragraph_26_5140"></object>
<propertyName>number</propertyName>
</uniqueness>
<uniqueness>
<object href="#Object__Sentence_26_5129"></object>
<propertyName>number</propertyName>
</uniqueness>
</constraints>
</graph>
</gxl>
74
Приложение E. Метамодель описания структуры и содержания ЭД
Рисунок E.1. Метамодель описания структуры и содержания электронных документов
75
Приложение F. Сгенерированный отчет метамодели описания
элементов ЭД
Elementy
Documentation Report
Filename:
Status:
Date:
Author:
Elementy
11.06.2014
Agalakova Elena
76
Elementy: Metamodel [GOPRR]
Properties [GOPRR]:
Constraints [GOPRR]:
Description [GOPRR]:
Diagram picture: Elementy
Graph dictionary
Object
Box
Column
Document
Element
Image
Note
Ontology
Paragraph
Row
Sentence
Symbol
Table
Word
Type of Object
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Object [GOPRR]
Box: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Documentation
Box
N
Box relationships:
In role
Box:
First
role
[GOPRR]
Box:
First
role
[GOPRR]
Box:
Last
role
[GOPRR]
Box:
Last
role
[GOPRR]
Box:
Last
role
[GOPRR]
: Subtype [GOPRR]
With
objects(s)
Binding
Image
In relationship
have:
[GOPRR]
have:
[GOPRR]
have:
[GOPRR]
have:
[GOPRR]
have:
[GOPRR]
:
[GOPRR]
Box links:
Link type
Decomposition
Explosions
Binding
Paragraph
Binding
Table
Binding
Column
Binding
Row
Inheritance
Graph's name
none
none
Column: Object [GOPRR]
Properties:
77
Element
In role
Izorazenie: Last role
[GOPRR]
Abzac:
Last
role
[GOPRR]
Tablica: First role
[GOPRR]
Stolbec: First role
[GOPRR]
Stroka: First role
[GOPRR]
: Supertype [GOPRR]
Column
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
N
Column relationships:
In role
With
objects(s)
Binding
Box
In relationship
Stolbec:
First
role
have:
[GOPRR]
[GOPRR]
Stolbec:
Last
role
have:
[GOPRR]
[GOPRR]
: Subtype [GOPRR]
:
[GOPRR]
Column links:
Link type
Decomposition
Explosions
Binding
Table
Inheritance
Eleme
Box: Last role [GOPRR]
Tablica:
First
role
[GOPRR]
: Supertype [GOPRR]
nt
Graph's name
none
none
Document: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Document
title
N
Document relationships:
In role
In relationship
Document:
First
role
have: Binding
[GOPRR]
[GOPRR]
Document links:
Link type
Decomposition
Explosions
Element: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
In role
With objects(s)
Element
In role
Element: Last role
[GOPRR]
Graph's name
none
none
Element
0
Element relationships:
In role
In relationship
Element:
Last
have:
Binding
role [GOPRR]
[GOPRR]
:
Supertype
:
Inheritance
[GOPRR]
[GOPRR]
:
Supertype
:
Inheritance
[GOPRR]
[GOPRR]
:
Supertype
:
Inheritance
[GOPRR]
[GOPRR]
With objects(s)
Document
Symbol
Row
Image
78
In role
Document: First
role [GOPRR]
:
Subtype
[GOPRR]
:
Subtype
[GOPRR]
:
Subtype
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
Supertype
Supertype
Supertype
Supertype
Supertype
Supertype
Supertype
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
Element links:
Link type
Decomposition
Explosions
Image: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Inheritance
Column
Inheritance
Paragraph
Inheritance
Table
Inheritance
Word
Inheritance
Sentence
Inheritance
Ontology
Inheritance
Box
Note: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Subtype
Subtype
Subtype
Subtype
Subtype
Subtype
Subtype
Graph's name
none
none
Image
title
N
Image relationships:
In role
In relationship
Izorazenie: Last
have:
Binding
role [GOPRR]
[GOPRR]
Izorazenie: Last
have:
Binding
role [GOPRR]
[GOPRR]
Izorazenie: Last
have:
Binding
role [GOPRR]
[GOPRR]
:
Subtype
:
Inheritance
[GOPRR]
[GOPRR]
Image links:
Link type
Decomposition
Explosions
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
:
[GOPRR]
With objects(s)
Paragraph
Sentence
Box
Element
Graph's name
none
none
Note
Description
N
Note relationships:
none
Note links:
79
In role
Abzac: First role
[GOPRR]
Predlozenie: First
role [GOPRR]
Box: First role
[GOPRR]
:
Supertype
[GOPRR]
Link type
Decomposition
Explosions
Graph's name
none
none
Ontology: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Ontology
Onto-link
N
Ontology relationships:
In role
In relationship
:
Subtype
:
Inheritance
[GOPRR]
[GOPRR]
Ontology links:
Link type
Decomposition
Explosions
In role
:
Supertype
[GOPRR]
Graph's name
none
none
Paragraph: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Paragraph
number Onto-link
N
Paragraph relationships:
In role
In relationship
Abzac: First role
have:
Binding
[GOPRR]
[GOPRR]
Abzac: First role
have:
Binding
[GOPRR]
[GOPRR]
Abzac: Last role
have:
Binding
[GOPRR]
[GOPRR]
:
Subtype
:
Inheritance
[GOPRR]
[GOPRR]
Paragraph links:
Link type
Decomposition
Explosions
With objects(s)
Sentence
Image
Box
Element
In role
Predlozenie: Last
role [GOPRR]
Izorazenie: Last
role [GOPRR]
Box: First role
[GOPRR]
:
Supertype
[GOPRR]
Graph's name
none
none
Row: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Row relationships:
In role
Stroka: First role
With objects(s)
Element
Row
N
In relationship
have:
Binding
With objects(s)
Box
80
In role
Box: Last
role
[GOPRR]
[GOPRR]
Stroka: Last role
have:
[GOPRR]
[GOPRR]
:
Subtype
:
[GOPRR]
[GOPRR]
Binding
Inheritance
Row links:
Link type
Decomposition
Explosions
Sentence
number content Onto-link
0
Sentence relationships:
In role
In relationship
Predlozenie:
have:
Binding
First role [GOPRR]
[GOPRR]
Predlozenie:
have:
Binding
First role [GOPRR]
[GOPRR]
Predlozenie:
have:
Binding
First role [GOPRR]
[GOPRR]
Predlozenie:
have:
Binding
Last role [GOPRR]
[GOPRR]
:
Subtype
:
Inheritance
[GOPRR]
[GOPRR]
Sentence links:
Link type
Decomposition
Explosions
With objects(s)
Word
Symbol
Image
Paragraph
Element
In role
Slovo: Last role
[GOPRR]
Simvol: Last role
[GOPRR]
Izorazenie: Last
role [GOPRR]
Abzac: First role
[GOPRR]
:
Supertype
[GOPRR]
Graph's name
none
none
Symbol
0
Symbol relationships:
In role
In relationship
Simvol: Last role
have:
Binding
[GOPRR]
[GOPRR]
:
Subtype
:
Inheritance
[GOPRR]
[GOPRR]
Symbol links:
Link type
Decomposition
Explosions
Element
[GOPRR]
Tablica: First role
[GOPRR]
:
Supertype
[GOPRR]
Graph's name
none
none
Sentence: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Symbol: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Table
With objects(s)
Sentence
Element
Graph's name
none
none
81
In role
Predlozenie: First
role [GOPRR]
:
Supertype
[GOPRR]
Table: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Table relationships:
In role
Tablica:
First
role [GOPRR]
Tablica:
First
role [GOPRR]
Tablica:
First
role [GOPRR]
:
Subtype
[GOPRR]
Table
title Onto-link
N
In relationship
have:
[GOPRR]
have:
[GOPRR]
have:
[GOPRR]
:
[GOPRR]
Binding
Column
Stolbec: Last role [GOPRR]
Binding
Box
Box: Last role [GOPRR]
Element
: Supertype [GOPRR]
Stroka: Last role [GOPRR]
Graph's name
none
none
Word: Object [GOPRR]
Properties:
Object name [GOPRR]
Property [GOPRR]s
Occurrence [GOPRR]
Description [GOPRR]
Word
description
0
In relationship
Slovo:
Last
role
have:
[GOPRR]
[GOPRR]
: Subtype [GOPRR]
:
[GOPRR]
Word links:
Link type
Decomposition
Explosions
In role
Inheritance
Table links:
Link type
Decomposition
Explosions
Word relationships:
In role
With
objects(s)
Binding
Row
With
objects(s)
Binding
Sentence
Inheritance
Graph's name
none
none
82
Element
In role
Predlozenie: First role
[GOPRR]
: Supertype [GOPRR]
Приложение G. Форма приказа о зачислении на 1 курс
??.??.????
ПРИКАЗ
№ ??.?-??/????
О зачислении на 1 курс факультета бизнес-информатики Пермского филиала
Государственного университета – Высшей школы экономики
На основании решения Приемной комиссии Государственного университета –
Высшей школы экономики (протокол от ??.??.???? № ?-??)
ПРИКАЗЫВАЮ:
Зачислить в 2010 году на 1 курс факультета бизнес-информатики по направлению
080700.62 «Бизнес-информатика» на очную форму обучения на места,
обеспеченные государственным финансированием, абитуриентов согласно списку
(приложение).
Должность
подпись
83
Ф.И. Отчество
Приложение H. Образец письма-извещения
Тверской областной
Дом печати
Справочные данные об организации-авторе
тел.:
факс:
Главному редактору
газеты «Вперед»
г-ну О.Б. Соколову
10.01.2005
№9
На № _________от____________
О переносе заседания
Уважаемый Олег Борисович!
Сообщаем Вам, что заседание главных редакторов переносится на 1
февраля 2000 г. на 15.00. Повестка заседания остается без изменений.
Секретарь Совета
подпись
84
М.Н. Козлов