Методика количественной оценки информационного наполнения документов комплекта проектной документации Текст научной статьи по специальности «Компьютерные и информационные науки»

Полищук Ю.В., Черных Т.А.

Оренбургский государственный университет E-mail: [email protected]

МЕТОДИКА КОЛИЧЕСТВЕННОЙ ОЦЕНКИ ИНФОРМАЦИОННОГО НАПОЛНЕНИЯ ДОКУМЕНТОВ КОМПЛЕКТА ПРОЕКТНОЙ ДОКУМЕНТАЦИИ

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

Ключевые слова: моделирование документов; квазиструктурированная информация; проектная документация.

Введение

Этап проектирования сложных технических объектов является очень важным, так как именно на этом этапе закладывается «фундамент» для разрабатываемого объекта. Использование документации ГОСТ при проектировании способствует повышению качества подготавливаемой документации.

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

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

Таким образом, проектировщику для создания нового документа необходима модель проектного документа.

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

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

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

Квазиструктурированная модель информационного наполнения S представляет собой графовую модель вида:

S = (root, sObj, LObj,mmOcc\xrs,ma.xOccurs,

sMet,Obj _smet}, (1)

где root - корневой объект, root є sObj ;

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

Для объектов-контейнеров доступны следующие метасвойства: smetc - определяет объект в качестве контейнера; mixed - разрешает использование объектов-потомков в произвольном порядке;

LObj - отображение, определенное на множестве sObj , такое, что sObj LObJ >{objj,...,objn}, где obJi є sObJ - дочерний объект; n - количество дочерних объектов;

Obj met - отображение, определенное на множестве sObj, такое, что

sObj —Obb_smet >^smetc I smetc,mixed | smet1,smetj} ,

где smett є sMet - метасвойство ограничения на содержимое объекта;

minOccurs - функция, определяющая минимально возможное количество раз использования объекта в модели;

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

Рассмотрим пример графического представления документа (рисунок 1).

Документ, представленный на рисунке 1, состоит из пяти объектов. Объект A - выполняет роль контейнера для объектов B и C, объект B -выполняет роль контейнера для объектов D и E. Объекты A, B, D - обязательно должны быть использованы при разработке документа, объект С - является необязательным к использованию, объект E в рассматриваемом примере должен быть использован от трех до пяти раз.

Объекту-контейнеру A соответствует метасвойство ограничения smetc, а для объекта-контейнера B определено дополнительно метасвойство mixed. Объект С представлен числовым наполнением, т. е. ему соответствует метасвойство ограничения smet2 . Объекты D, E имеют символьное информационное наполнение, которому соответствует метасвойство ограничения smet1.

Таким образом, документ может быть представлен с помощью модели следующим образом: root = {a}; sObj = {A,B,C,D,E};

LObj(A ) = {B , C}, LObj(B) = {D,E\E,D},

LObj(C) = {}, LObj(D) = {}, LObj(E) = {};

Obj _ smet(A) = \smetc }, Obj _ smet(B) = \smetc, mixe d}, Obj _smet(C) = {smet2}, Obj _smet(D) = {smetj},

Obj _smet(E) = {smetj}; minOccurs(A )= 1 , maxOccurs(A) = 1; minOccurs(B)= 1, maxOccurs(B)= 1; minOccurs(c) = 0 , maxOccurs(c) = 1; minOccurs(D)= 1, maxOccurs(D)= 1; minOccurs(E)= 3 , maxOccurs(D)= 5 .

Практическая реализация

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

Стоит отметить, что Microsoft Word начиная с версии 2003 Professional поддерживает технологию XML, а проектные документы, как правило, формируются именно этим текстовым процессором.

При работе с XML-документами стандартом определены два уровня «правильности» [2]: правильно построенный (Well-formed), действительный (Valid).

Правильно построенный документ соответствует всем правилам синтаксиса XML. Действительный документ дополнительно соответствует некоторым семантическим правилам.

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

Рассмотрим подробнее процесс валидации ХМЬ-документов, для этого рассмотрим схему, изображенную на рисунке 2.

Из анализа схемы валидации можно сделать вывод, что использование схемы (модели документа) обеспечивает контроль корректности вводимых данных в ХМЬ-документ. Документ сохраняется без выдачи сообщения об ошибке только при полном соответствии модели документа.

Пример использования

Для примера рассмотрим модель документа «Руководство пользователей АРМ» (АРМ -автоматизированное рабочее место) из пакета документов рабочей документации, подготовленного в соответствии с требованиями ГОСТ 19.505-79 «Руководство оператора. Требования к содержанию и оформлению».

Модель документа «Руководство пользователей АРМ» состоит из сегментов (рисунок 3). Каждый сегмент отвечает за описание раздела документа, а он в свою очередь подразделяется на более мелкие сегменты и объекты.

Сегменты «аЪЬг__ІІ8ґ.» и «изег_§шёе» пока-

заны на схеме пунктиром. При описании доку-

корневой элемент (root) smet

smet , mixed.

smeti необязательный элемент

повторяю ЩИИйЛ элемент

Рисунок 1. Граф информационного наполнения документа

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

Сегмент «title» описывает информационное наполнение титульного листа документа (рисунок 4), которое состоит из объектов «organization» - организация-разработчик, «project_ name» - название проекта, «doc_name» - название документа, «doc_type» - тип документа и двух сегментов: сегмента «cipher» - полный шифр документа, состоящего из двух атрибутов «cipher_project» - шифра проекта и «cipher_ doc» - шифра документа, и сегмента «dev_dt_ plc» - место и год создания документа, в кото-

title

Титульный

chiefs іу

Руководство

■І list of executors PE

Спис ок ис полните ле й

Содержание

Список используемых сокращений

2™Э

Состав комплекта руководств пользователей

Н ардаЫтеП Щ

Назначена АРМ

conditions

IS

Усло вия функционирования АРМ

1

Интерфейс взаимодей:твия с АРМ

Рисунок 3. Базовый сегмент схемы

title_type

Г-С organization |

Организация-разработчик

HZ project name ~|

-C

Название документа

hC doc type I

Тип документа

Название проекта

doc name

Рисунок 4. Сегмент титульного листа

ром определены два атрибута: «dev_place» и «dev_date» - место создания документа и дата создания документа соответственно.

На втором листе документа размещена информация о руководителях проектной организации, которая описана с помощью сегмента «chiefs» (рисунок 5). Этот сегмент включает в себя следующие объекты: «engineer_institute» - главный инженер института, «engineer_project» - главный инженер проекта, «chief_depertment» - начальник отдела. Каждый из перечисленных объектов будет содержать Ф. И. О. соответствующего руководителя.

Далее использован сегмент «list_______of_

executors» - список исполнителей документа (рисунок 6). Этот сегмент состоит из списка авторов документа, для каждого из которых определены его Ф. И. О. и занимаемая им должность. Количество исполнителей документа неограниченно.

Содержание документа описано с помощью объекта «contents», который представляет собой блок неограниченного размера.

Сегмент «abbr__list» позволяет описать со-

кращения, использованные в документе. Структура этого сегмента представлена на рисунке 7. Количество использованных аббревиатур в документе неограниченно. Каждое сокращение определено с помощью двух объектов: «abbr_ name» - аббревиатура и «abbr_decryption» -расшифровка аббревиатуры.

Состав комплекта руководств пользователей описан с помощью сегмента «user_guide» (рисунок 8). Количество руководств комплекта неограниченно. Для каждого руководства определены следующие объекты: «cipher_guide» -шифр руководства и «name_ guide» - название руководства.

Для описания функционального и эксплуатационного назначения АРМ используется сегмент «appointment» (рисунок 9). Для него определены следующие объекты: «functio-nal_appointment» - функциональное назначение, «main-tenance_appointment» - эксплуатационное назначение, а также с помощью объекта «function_name» - функции АРМ может быть описано неограниченное количество функций, реализуемых АРМом. Далее в документе опреде-

С

list of executors

Список исполнителей

лены условия функционирования АРМ. Их описание реализует сегмент «conditions» (рисунок 10), который в свою очередь состоит из сегментов «min_system_ requirements» - минимальные системные требования, «adv_system_ requirements» - рекомендуемые системные требования и объектов «conditions_operator» - условия эксплуатации АРМ, «software» - список программного обеспечения (ПО).

Объект «conditions_ operator» определяет требования к рабочему месту оператора АРМ. Сегменты «min_system_requirements» и «adv_ system_requirements» состоят из неограниченного количества объектов «hardware_name» - наименование и «hardware_ metrics» - характеристика. Сегмент, формирующий рекомендуемые системные требования, является необязательным и может отсутствовать в документе. Эти сегменты позволяют описать минимальные и рекомендованные требования к компьютеру АРМ. Неограниченная последовательность объектов «software» позволяет задать перечень программных средств, требуемых для функционирования АРМ на компьютере.

Объект «interface» использован в модели для маркирования разделов, содержащих описание интерфейса взаимодействия с АРМом.

Предложенная модель документов «Руководство пользователей АРМ» позволяет описать информационное наполнение документов этого вида. Использование модели позволяет упростить процесс создания документа, так как в этом случае документ разрабатывается в соответствии со структурой и информационным наполнением, определенным моделью.

На рисунке 11 изображен фрагмент документа, разработанного с использованием предложенной модели.

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

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

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

По аналогии с многокритериальной оптимизацией технических систем [3] будем ис-

^Thiefs_type

I " Н

Руководство

engineer_institute |

Главный инженер института HZ engineer_project |

Главный инженер проекта

HZ chief department |

Начальник отдела

Рисунок 5. Сегмент второго титульного листа

I list_of_execuibrstype

I

із-іон:

- I

1..?

Исполнитель

ФИО исполнителя

Н Post I

Должность исполнителя

Рисунок 6. Сегмент «Список исполнителей документа»

Список используемых сокращений

^bbr_list_type

I

■1®=Ч™

abbr_type

abbr

1..?

Аббревиатура вместе с расшифровкой

г-С abbr name |

Аббревиатура HZ abbr_decryption |

Расшифровка

аббревиатуры

Рисунок 7. Сегмент «Список использованных сокращений»

I ікеїд giude_ _Д

Состав комплекта руководств пользователей

I user_guide_lSt_type

I

і

user_guide_type

use r_guide _

V

1.. ?

Элемент списка руководств

-|_çipier_aiii^_|

Шифр руководства

HZ

Название руководства

Рисунок 8. Сегмент «Состав комплекта руководств пользователей»

^ appohtmentjype

Назначение АРМ

-|_^uactioaal_ap}ointmea^__|

Функциональное назначение

Н= maintenance appointment I

Эксплуатационное назтчение

^Tunc tions_1yp e

-I functions

Состав функции ^ j ?

I Функции АРМ

fuctioa name .

Рисунок 9. Сегмент «Назначение АРМ»

пользовать для методики оценки пять параметров.

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

obj count , jj = (2)

где obj count - функция, возвращающая количество обязательных объектов, использованных в документе;

Oobj - отображение, ставящее в соответствие множеству sObj мощность множества, состоящего из элементов, удовлетворяющих условиям: Obj _ smet(sObji) n [smetc} = 0;

minOccurs(sObji) = 1; maxOccurs(sObji) = 1;

LObj(sObji) = 0, где sObji є sObj.

Вторым параметром является количество использованных в документе необязательных объектов. Этот параметр должен быть максимизирован:

Uobj(sObj) ^ max, (3)

где Uobj - отображение, ставящее в соответствие множеству sObj мощность множества, состоящего из элементов, удовлетворяющих условиям: minOccurs(Obji) = 0; maxOccurs(Obji) = 1; LObj( sObji) = 0, где sObji є sObj.

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

Robj(sObj) ^ max, (4)

где Robj - отображение, ставящее в соответствие множеству sObj мощность множества, состоящего из элементов, удовлетворяющих условиям: minOccurs(Obj; ) = 1; maxOccurs(Obj; )> 1;

LObj(sObji ) = 0, где sObji e sObj.

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

Cobj(sObj) ,_ч

---—---— ^ max, (5)

char_count

где Cobj - отображение, ставящее в соответствие множеству sObj мощность множества, состоящего из элементов, удовлетворяющих условию: LObj(sObji) = 0 , где sObji e sObj ; char_count - функция, возвращающая количество символов в документе.

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

І = 1

------т---г--> min, (6)

Cobj(sObj )

где len - функция, возвращающая количество символов из объекта, а в рассмотрение прини-

Условия

функционирования

АРМ

conditions_type

К min_system_requirements ---------,

Минимальные системные I 1?

требования I Технические средства I

I 1

conditions_operator |

У словия эксплуатации АРМ оператора

1 system_requirem3nts_type

hardware_type

—I hardware_name~

Наименование

-.1

_Ji

—I hardware_metrics |

Характеристика

j system_requirements_type

I

“ ^ _adv _sLstem_re quirements

Рекомендуемые системные I 1 ?

требования I Технические средстваї

L-C software \\ I I

software fl Список ПО 1..?

Наименование |

4L hardware metrics І її і

Характеристика Ц

Рисунок 10. Сегмент «Условия функционирования АРМ»

маются только объекты $0Ъ]1 е dObj , удовлетворяющие условию

L0Ъj(50Ц1) = 0 .

Заключение

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

12.05.2010

Функционально е назначение

(-"(ипс>кп«1_«еро{п11гип|1 Функциональным назначением АРМ оператора БПТО |ОК, является предоставление оператору возможности автоматизированного управления системой учета и транспортировки метанола )<ипсИопа| арроіпітіпі^

Эксплуатационное назначение

(<1 ггит«гипс«_ірсотт«іу(арм оператора БПТО иі£ предназначен для эксплуатации на технологическом объекте БПТО и К. Конечными пользователями АРМ являются операторы БПТО и

К )таіпЕеплсе ЁрроЫтепЕ*)

Состав функций

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

(■ЧипсііопіІ- ( ^пс*ісп_п№» (кпнтроль давления метанола на входе в БСМВ,

іцгс>ісп_гтгі«Іконтроль расхода метанола на выходе из БПТО ,

Funciicn_nim« ¡контроль давления метанола на выходе из БПТО иХО;

Functicn_nami ¡контроль температуры метанола на выходе из БПТ О hJ£,D,

іцгс>ісп_гтгі«Іконтроль плотности метанола на выходе в БПТО HJÇ.D,

Ьіпсцсп_пот7Тконтроль массового расхода метанола на выходе в БПТ О HjjD ;

Functicn_name^ сигнализация превышения плотности метанола на БПТ О и К D,

furclicn_ntro« ( включ еиие/откпючёниё режима опрессовки

( fane>icn_n««i«Tсигнализация понижения давления в

^еУ1 )Kjncticns*) )appohtment*)

Лист

07.082.088.3876-АСУ.И3.1 9

їж- Коп. Лист Ms док. Подпись Дата

Рисунок 11. Фрагмент документа, синтезированного по модели

Список использованной литературы:

1. Полищук, Ю.В. Моделирование системы обработки квазиструктурированных электронных документов / Ю.В. Полищук, Т.А. Черных // Вестник компьютерных и информационных технологий, 2009. №5. - С. 41-44.

2. Полищук, Ю.В. Автоматизация разработки технической документации с применением XML технологии / Ю.В. Полищук, Т.А. Черных // Нефтепромысловое дело. - 2008. - №11, - С. 112-115.

3. Гмошинский, В.Г. Теоретические основы инженерного прогнозирования / В.Г. Гмошинский, Г.И. Флиорент. - М.: Наука, 1973. - 304 с.

Работа выполнена при поддержке ФЦП НК-136/П1 П1004 «Разработка технологии хранения и обработки квазиструктурированных данных»

Сведения об авторах:

Полищук Юрий Владимирович, доцент кафедры математического обеспечения информационных систем Оренбургского государственного университета, кандидат технических наук 460018, г. Оренбург, пр-т Победы, 13, ауд. 2132, тел. (3532)372534, e-mail: [email protected]

Черных Татьяна Александровна, аспирант кафедры математического обеспечения информационных систем Оренбургского государственного университета 460018, г. Оренбург, пр-т Победы, 13, ауд. 2132, тел. (3532)372534, e-mail: [email protected] Polishchuk YV., Chernykh T.A.

The procedure of quantitative assessment of the information value of the documents of the complete set of project documentation

The work examines the procedure of the synthesis of project documents, which ensures increase in their quality due to the use of the quasi-structure models of their information filling. The mathematical interpretation of the model of the quasi-structure information filling of electronic documents is examined and the parameters of the quantitative assessment of the information value of a document according to its model are proposed. The key words: the simulation of documents; the quasi-structure information; project documentation.

Bibliography

1. Polishchuk Ju.V. Modeling System for kvazistrukturiro-bathroom electronic documents / Ju.V. Polishchuk, T.A. Chernykh / Vestnik komp’juternykh i informacionnykh tekhnologijj, 2009. №5. - S. 41-44.

2. Polishchuk Ju.V. Automating the development of technical documentation using XML technologies / Ju.V. Polishchuk, T.A. Chernykh / Neftepromyslovoe delo. - 2008. - №11 - S. 112-115.

3. Gmoshinsky V.G. Theoretical foundation engineering forecasting / V.G. Gmoshinsky, G.I. Fliorent. - M.: Nauka, 1973. -304 pp.