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

ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ 4
ГЛАВА 1. ОФОРМЛЕНИЕ РАСПОРЯДИТЕЛЬНЫХ ДОКУМЕНТОВ С ИСПОЛЬЗОВАНИЕМ ИНФОРМАЦИОННЫХ СИСТЕМ В ОТЕЧЕСТВЕННОМ ДОКУМЕНТОВЕДЕНИИ 21
1.1. Проблемы оформления распорядительной документации в отечественной системе документоведения 21
1.2. Типовые и трафаретные тексты в распорядительной документации 29
1.3. Фрагменты трафаретного текста для автоматизированной подготовки русскоязычной распорядительной документации 38
1.4. Классификация документов с точки зрения автоматизации их подготовки 42
ГЛАВА 2. ОПРЕДЕЛЕНИЕ ВОЗМОЖНЫХ ПУТЕЙ И СПОСОБОВ ОПТИМИЗАЦИИ АВТОМАТИЧЕСКОЙ ПОДГОТОВКИ РАСПОРЯДИТЕЛЬНЫХ ДОКУМЕНТОВ В ОТЕЧЕСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ 46
2.1. Обзор существующих подходов в оптимизации автоматической обработки распорядительной документации 46
2.1.1. Направления оптимизации автоматической подготовки документов 46
2.1.2. Существующие подходы в оптимизации 48
2.1.3. Алгоритмы склонения в информационных системах 50
2.1.4. Обзор существующих решений 51
2.1.5. Сравнение рассмотренных решений 58
2.1.6. Недостатки существующих решений 59
2.2. Разработка алгоритмов автоматического склонения антропонимов, наименований должностей и структурных подразделений с учетом русскоязычной традиции 61
2.2.1. Пакет «jz-decliner» 61
2.2.2. Разработка алгоритма автоматического склонения фамилий и личных имен (антропонимов) 65
2.2.3. Разработка алгоритма автоматического склонения наименований должностей 74
2.2.4. Разработка алгоритма автоматического склонения наименований структурных подразделений 80
ГЛАВА 3. ОПТИМИЗАЦИЯ АВТОМАТИЧЕСКОЙ ПОДГОТОВКИ РАСПОРЯДИТЕЛЬНЫХ ДОКУМЕНТОВ В ИНФОРМАЦИОННОЙ СИСТЕМЕ НОВГОРОДСКОГО ОАО «АКРОН» 84
3.1. Информация о документообороте предприятия 84
3.2. Корпоративная информационная система предприятия 85
3.3. Обзор процесса интеграции пакета «jz-decliner» 86
3.4. Модификация базы данных 88
3.5. Модификация серверной части системы 91
3.6. Использование результатов работы пакета «jz-decliner» 95
3.7. Оперативная настройка правил работы пакета 95
ЗАКЛЮЧЕНИЕ 100
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ 102
ПРИЛОЖЕНИЯ 110

ВВЕДЕНИЕ
Современная экономическая ситуация требует от организаций всех форм собственности широкого применения компьютерных информационных систем для автоматизации задач, связанных с управлением, учетом и планированием. Развитая автоматизированная система аккумулирует внутри себя всю информацию, производимую и получаемую организацией в процессе деятельности. Благодаря возможностям разграничения, фильтрации и поиска информации, данные, хранимые внутри системы, могут быть оперативно доставлены туда, где в них существует потребность. Внедрение информационной системы внутри организации, несомненно, позволяет значительно повысить эффективность управления ресурсами и бизнесом. Информационная система позволяет автоматизировать трудоемкие рутинные операции и увеличить долю рабочего времени сотрудников для выполнения собственно управленческих и аналитических и функций.
Несмотря на возрастающее значение автоматизации, при обмене информацией между организациями самым распространенным форматом передачи данных, по-прежнему является традиционный бумажный документ. Бумажные документы важны и в некоторых законодательно регламентированных информационных процессах внутри организации, например, при управлении персоналом. В связи с этим, одной из ключевых функций большинства автоматизированных информационных систем всегда была и остается возможность простого и быстрого получения печатных документов на основе данных, содержащихся в информационной системе. С точки зрения информационных технологий, эта возможность известна под названием генерации отчетов, с точки зрения документоведа, она может трактоваться как автоматизированная подготовка документов.
Актуальность работы состоит в том, что печатные формы документов, традиционно применяемые в Российской Федерации, часто имеют ряд особенностей, существенно ограничивающих возможность применения для автоматизации их подготовки стандартных средств генерации отчетов, встроенных в платформы информационных систем и предлагаемых на рынке программного обеспечения. В рамках данной работы мы постараемся выявить такие особенности, отобрать из них те, которые принципиально не поддерживаются стандартными программными средствами и предложить пути решения этой проблемы.
Объектом исследования дипломной работы является использование современных информационных технологий при подготовке документов.
Предметом исследования является использование информационных систем при подготовке распорядительных документов в соответствии с русскоязычной традицией.
Цель данной работы заключается в оптимизации процесса автоматической подготовки распорядительных документов в соответствии с русскоязычной традицией.
Для достижения поставленной цели в дипломной работе решаются следующие задачи:
1. Исследование типовых печатных форм современных распорядительных документов;
2. Выявление особенностей заполнения печатных форм в соответствии с русскоязычной традицией;
3. Определение возможных путей и способов оптимизации процесса автоматического оформления (подготовки) распорядительных документов в соответствии с русскоязычной традицией;
4. Разработка алгоритма автоматического склонения фамилий и личных имен;
5. Разработка алгоритма автоматического склонения наименований должностей;
6. Разработка алгоритма автоматического склонения наименований структурных подразделений;
7. Создание референтной реализации разработанных алгоритмов в виде готового программного компонента;
8. Внедрение разработанных алгоритмов в информационную систему предприятия.
Значительная часть выявленных особенностей в оформлении документов удовлетворяется путем грамотного использования возможностей, представляемых стандартными генераторами отчетов. Наиболее же сложными из рассмотренных особенностей являются задачи автоматического получения форм косвенных падежей именных грамматических конструкций. Об актуальности этой проблемы говорят и многочисленные сообщения в интернет-форумах для разработчиков информационных систем.
Для приближения к решению поставленных задач нами был выполнена разработка алгоритмов склонения антропонимов, наименований должностей и структурных подразделений.
На основе разработанных в рамках работы алгоритмов был создана референтная их реализация в виде пакета на языке Java. Текущая версия пакета вместе с исходными кодами и стандартной документацией свободно доступна на сайте www.sourceforge.org (проект «russian-names-decliner») под лицензией типа BSD.
Практическая ценность работы состоит в использовании созданного пакета в качестве одного из компонентов автоматизированной информационной системы новгородского ОАО «Акрон».
Алгоритмы, реализованные в пакете, были протестированы на значительных объемах естественных данных. Было также выполнено перекрестное тестирование с привлечением лидирующей среди отечественных разработчиков закрытой программной библиотеки.
Разработанный пакет был интегрирован в подсистему управления персоналом информационной системы реального предприятия. Опыт его опытной эксплуатации показал высокую эффективность и полезность пакета. Начата промышленная эксплуатация пакета.
Рассматриваемая в дипломной работе тема крайне скудно освещена в литературе и печатных источниках. Как известно, информационные технологии в современном виде появились благодаря, в основном, деятельности представителей британо-американской культуры. Следовательно, большая часть существующих на рынке программных компонентов для построения корпоративных информационных систем проектировалась с учетом особенностей только англоязычного делопроизводства и, в частности, английского языка. С течением времени объективные процессы глобализации заставили разработчиков заняться поддержкой других языков в своих продуктах, однако приоритет этих работ сравнительно низок, идут они довольно медленно и распылены по разным направлениям. Помимо недостаточности возможностей существующих программных платформ для оформления русскоязычных документов, наблюдается и отсутствие качественных методических руководств по автоматизированной подготовке таких документов. Теоретически, данный пробел должен был бы постепенно заполняться отечественной литературой, однако этого пока не происходит. Причиной тому, возможно, послужила смена подхода к пониманию отношения автоматизированной информационной системы к печатному документу, выпавшая на трудные для отечественной практической науки 1990-е годы. В конце 1980-х годов многими бумажные документы рассматривались, как устаревшая технология и считалось, что в скором времени они исчезнут в связи с переходом к использованию, так называемых, «безбумажных» технологий. В этом свете, довольно интенсивно и у нас и на Западе прорабатывались способы автоматизированной обработки готовых текстов для извлечения из них самой сути, для помещения в информационные системы. К этой же теме вплотную примыкают такие интересные проблемы как ввод данных в информационную систему на естественных языках, голосовое управление компьютером и автоматизированный перевод с одного естественного языка на другой.
В 1990-х годах в связи с удешевлением компьютеров и движением информационных технологий «в массы» концепция радикально изменилась. Теперь информационные системы часто стали рассматриваться как хранилище данных и средство обработки управляющих воздействий, способное, при необходимости, создать на основе своих данных бумажный документ традиционного образца. Бумажный же документ по-прежнему остался де-факто «универсальным интерфейсом» для официального делового общения. Вялый прогресс во внедрении и стандартизации электронных форм делового общения заставляет думать о том, что такое положение вещей сохраниться еще довольно значительное время. Западные фирмы, в ответ на возникновение новой концепции, оперативно изменили состав предлагаемого на рынок программного обеспечения, породив многочисленные генераторы отчетов (report generators) – приложения или программные компоненты для получения печатных документов на основе данных информационных систем. Одновременно были разработаны методические рекомендации, и даже популярная литература по их использованию. Со временем вышли и интернациональные, в том числе и русскоязычные, версии этих программ, иногда снабженные документацией на русском языке. Однако опыт создания с помощью этих средств традиционных русскоязычных документов, отвечающих требованиям отечественных стандартов и законодательных актов, показал их слабую приспособленность для этого. Одной из необходимых, но отсутствующих в этих генераторах возможностей является получение косвенных форм грамматических имен из начальной формы. Причем, некоторые руководящие документы напрямую требуют применения таких форм, а другие неявно подразумевают. Отметим, что представители англоязычной культуры не сталкиваются с необходимостью употребления косвенных форм в связи с практическим их отсутствием в английском языке. При этом вызывает недоумение то, что не удалось обнаружить ни одного авторитетного отечественного источника, посвященного приемам решения данной проблемы. В тоже время, русскоязычными учеными уже к концу XX века была хорошо разработана более сложная тема автоматизации семантического анализа текстов. С достижениями одной из групп российских ученых в этой области можно ознакомиться на Web-сайте «Автоматизированная обработка текстов» . Из материалов ресурса нетрудно заметить, что вся работа группы концентрируется вокруг специально составленных семантических словарей, информация из которых используется программами. Процедура составления семантических словарей крайне трудоемка, а к уровню лингвистической подготовки ее исполнителей предъявляются весьма высокие требования. Несмотря на это, составленные данной группой семантические словари доступны для свободной загрузки и, возможно, в будущем могут послужить основой для создания программных компонентов, генерирующих косвенные формы именных конструкций. Отметим также, что разработка подобного программного обеспечения обычно требует глубоких знаний на стыке лингвистики, математики и информационных технологий и является весьма дорогостоящим мероприятием.
При полном отсутствии проработанных отечественных рекомендаций по автоматизированной подготовке документов, в литературе, предназначенной для документоведов и делопроизводителей, довольно часто приводятся рекомендации по «ручной» подготовке документов на компьютере, существенные для человека-оператора, но малопригодные для информационной системы. В некоторой степени проблему сглаживают авторы интернет-страниц и сообщений в форумах разработчиков информационных систем. Это очерчивает круг лиц, наиболее заинтересованных в разработке и решении рассматриваемой проблемы.
Как было отмечено выше, к числу наиболее характерных особенностей отечественного документооборота относится необходимость составления документов на государственном языке Российской Федерации. Об этом в частности говорится в статье 16 Закона РФ от 25 октября 1991 года N 1807-I «О языках народов Российской Федерации» . Статья 11 этого закона устанавливает государственный язык РФ в качестве рабочего языка федеральных органов государственной власти и органов власти субъектов РФ. В этом же законе в качестве государственного языка РФ определяется русский язык . Упоминание о государственном языке имеет место в и основном законодательном акте нашей страны – Конституции Российской Федерации. Пункт 1 стать 68 Конституции РФ гласит: «Государственным языком Российской Федерации на всей ее территории является русский язык» .
Интересно, что само понятие «русский язык» долгое время существовало вне отечественного правового поля. Не было определено круга документов и законодательных актов, нормирующих этот язык. Ничего не говорилось и о порядке принятия и изменения норм русского языка. Особенно примечательно, что до начала XXI века не было даже законодательной привязки русской кириллической письменности к русскому языку. Только в 2002 году появился Федеральный закон от 11 декабря 2002 г. N 165-ФЗ «О внесении дополнения в статью 3 Закона Российской Федерации «О языках народов Российской Федерации»». Несмотря на небольшой объем, данный документ, крайне важен для разработчика русскоязычных информационных систем. Основное его содержание гласит: «В Российской Федерации алфавиты государственного языка Российской Федерации и государственных языков республик строятся на графической основе кириллицы. Иные графические основы алфавитов государственного языка Российской Федерации и государственных языков республик могут устанавливаться федеральными законами» . Следовательно, все автоматизированные информационные системы производящие русскоязычные документы должны полностью поддерживать генерацию выходных печатных форм с использованием кириллического алфавита.
В 2005 году был издан Федеральный закон от 1 июня 2005 г. N 53-ФЗ «О государственном языке Российской Федерации» . Этот документ частично конкретизирует понятие «государственный язык». В частности пункт 2 ст. 1 предусматривает использование русского языка в сферах, определенных данным законом, которые перечислены в статье 3. Среди них для нас наиболее интересно применение государственного языка РФ в деятельности «организаций всех форм собственности, в том числе в деятельности по ведению делопроизводства», «при оформлении адресов отправителей и получателей телеграмм и почтовых отправлений, пересылаемых в пределах Российской Федерации». В пункте 2 статьи 3 говорится о необходимости дублирования текстов документов на государственных языках субъектов РФ и иностранных языках текстами на русском языке, аналогичными по содержанию. Определенный интерес представляет пункт 3 статьи 1 обязывающий Правительство Российской Федерации определять порядок утверждения норм современного русского литературного языка при использовании его в качестве государственного языка РФ. Кроме того, статья 6 предусматривает ответственность за препятствование «осуществлению права граждан на пользование государственным языком Российской Федерации».
Таким образом, из закона следует, что все деловые документы в Российской Федерации должные полностью или частично составляться на русском языке в соответствии с действующими нормами современного русского литературного языка. При этом до сих пор не определены границы понятия «русский язык», нет официального документа, утверждающего или рекомендующего какое-либо конкретное издание норм литературного русского языка. Большинство авторов сходится в том, что наиболее авторитетным источником по русской орфографии и пунктуации до сих пор являются «Правила русской орфографии и пунктуации», утвержденные Академией Наук СССР еще в 1956 году . Мы предпочли работать с электронной версией этого документа, поскольку такая форма представления информации значительно расширяет, по сравнению с традиционными изданиями, возможности поиска и использования конкретных статей.
Очевидно, что по прошествии пятидесяти лет назрела необходимость в более современной редакции данных Правил. Принятый в 2005 году Федеральный закон о государственном языке в РФ, отдает порядок утверждения норм литературного русского языка на усмотрение правительства. Однако до настоящего момента ни порядок, ни сами нормы законодательно определены не были. В начале 2000-х годов были предпринята попытка создания «Свода правил русского правописания» критического пересмотра упомянутых Правил. Над этим проектом работали сотрудники сектора орфографии и орфоэпии Института русского языка им. В. В. Виноградова РАН. Помимо адаптации правил к естественным изменениям в жизни общества, Свод предлагал ряд упрощений орфографии и пунктуации. Предлагаемые изменения вызвали резко негативную реакцию общественности и средств массовой информации, в результате чего проект был заморожен на неопределенный срок.
Если федеральное законодательство концентрируется, в основном, вокруг обязательности применения государственного языка, ведомственные нормативно-методические издания рассматривают вопросы, посвященные более конкретным правилам оформления документов.
Всем отечественным специалистам по делопроизводству хорошо знаком Государственный стандарт РФ ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» . Он устанавливает состав стандартных реквизитов для документов, относящихся к УСОРД, требования по их оформлению, а также устанавливает формат бланков документов. Изучение данного государственного стандарта необходимо каждому разработчику автоматизированных информационных систем для отечественного рынка, поскольку он представляет собой концентрированный массив информации о внешнем виде и ключевых особенностях современных отечественных распорядительных документов. Кроме того, анализ требований стандарта к реквизитам документов позволяет сразу выявить потенциальные трудности при автоматизации их оформления. Отдельный интерес представляют пункт 3.15, рекомендующий указывать должность лица, которому адресован документ в дательном падеже и пункт 3.16, предлагающий использовать наименование утверждающего документа в творительном падеже. Также стандарт дает краткий обзор способов оформления текста документа.
Своеобразным справочником разработчиков информационных систем, связанных с учетом персонала является Постановление Госкомстата РФ от 5 января 2004 г. N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты» . В нем приводятся образцы печатных форм, обязательных для правильной работы с персоналом. Анализ этих печатных форм, как минимум, позволяет определить примерный состав информации, подлежащей хранению внутри информационной системы, а также составить общее представление об основных информационных процессах, происходящих в службе по управлению персоналом. Степень реализации автоматизированной подготовки печатных форм, перечисленных в Постановлении, является определенным показателем качества информационной системы. Вместе с тем, правильная реализация автоматизированной подготовки печатных форм, перечисленных в Постановлении, представляет собой превосходный полигон для апробирования нетрадиционных технологий генерации отчетов, поскольку здесь представлены все основные формы представления текста документа, среди которых часто встречается трафаретный текст – наиболее сложная форма текста для автоматизации.
Помимо законодательства и методических документов о необходимости применения косвенных падежных форм говорит и периодическая печать. Так в статье «Приказ по личному составу» Л. В. Санкина употребляет формы косвенных падежей антропонимов, наименований должностей и структурных подразделений в образцах трафаретных текстов рассматриваемых распорядительных документов. Таким образом, она формулирует ряд неявных требований к системам автоматизированной подготовки таких документов. С другой стороны, поддержка генерации унифицированных печатных форм документов по учету персонала является ключевым требованием к автоматизированным системам управления персоналом .
Вопросы грамотной и эффективной организации современного делопроизводства рассматриваются во многих отечественных монографиях, методических и учебных пособиях. Помимо освещения общих принципов ведения документооборота, особенное внимание обычно уделяется оформлению документов по учету персонала. Иногда в литературе можно встретить общие рассуждения о тенденциях отечественного кадрового делопроизводства. В частности в известном учебном пособии В. В. Галахова и других «Делопроизводство…» отмечается: «Несмотря на широкую практику составления сложных приказов по личному составу, следует учитывать, что они не только не обеспечивают должной оперативности ручного поиска информации в процессе оперативной и контрольной работы, особенно при значительных объема этого вида документов, но и затрудняют использование автоматизированных систем обработки кадровой информации. Для обеспечения автоматизированных информационных кадровых систем все более интенсивно внедряются структурно простые приказы по личному составу и, как правило, индивидуальные» . Хотя наша практика не позволяет сделать однозначного вывода о предпочтительности автоматизации простых документов, по сравнению со сложными, обращение авторов к этой теме, безусловно, обнадеживает. В том же пособии справедливо отмечается, что «Составление текстовых традиционных приказов по личному составу, даже простых по структуре, сопровождается значительными трудозатратами работников отдела кадров за счет необходимости обработки множества дополнительных документов» .
В ходе работы нами было выяснено, что наиболее трудно автоматизации подвергается подготовка русскоязычного трафаретного текста. Достаточно полно трафаретный текст рассмотрен Сергеем Петровичем Кушнеруком в пособии «Документная лингвистика (русский деловой текст)». Трафаретный текст, согласно этому пособию, представляет собой результат процессов унификации документных текстов. Рассматриваются положительные и отрицательные стороны унификации текстов документов. В отношении информационных систем справедливо отмечается: «…. чем выше степень формализации, тем выше приспособленность к алгоритмической обработке документов вплоть до автоматизации этого процесса….» . Вместе с тем чувствуется, что автор весьма далек от практики информационных технологий. Так утверждение «… ближе к трафаретным являются табличные и анкетные документы» , возможно верно для человека, но не для информационной системы. Тезис же о том, что «Типизация и трафаретность документов отражаются в создании системы унифицированной документации, ориентированной как на ручную, так и на машинную обработку текстов…» звучит обнадеживающе, однако, с нашей точки зрения, излишне оптимистично, поскольку существующие российские системы унифицированной документации крайне слабо приспособлены для машинной обработки текстов.
Одной из наиболее специфических проблем автоматизации отечественного документооборота является задача получения косвенных форм антропонимов – сравнительно малоизученная область морфологической системы русского языка. Способы склонения антропонимов подробно рассмотрены в 1984 году Ларисой Павловной Калакуцкой . В монографии приводятся парадигмы основных морфологических типов антропонимов, даются рекомендации относительно склонения наиболее сложных фамилий и личных имен. Значительное внимание уделяется вопросу эволюции склонения русских антропонимов на протяжении предыдущих двух веков. Отмечаются следующие интересные особенности антропонимов, облегчающие задачу по созданию алгоритмов их автоматического склонения: отсутствие среднего грамматического рода, наличие только одушевленных существительных, обязательная согласованность по полу. Утверждается, что «причина повышенной вариантности в словоизменении антропонимов – отсутствие сдерживающего влияния литературной нормы, и не сложившаяся еще собственная система словоизменения антропонимов». В 1994 году Л. П. Калакуцкой был выпущен справочник по написанию и склонению фамилий имен и отчеств . Справочник содержит основные типы склонения фамилий и личных имен, русских и иноязычных, в русском литературном языке. В частности, обращается внимание на юридическое значение антропонимов: «Написание фамилий и склонение фамилий и личных имен непосредственно связаны с юридическими сферами жизни всего общества и каждого его члена, в частности. Орфографически правильное написание фамилии и имени в именительном падеже и правильное их написание в любом косвенном падеже является основой любого документа – от свидетельства о рождении и паспорта до оформления любого другого документа (диплома. получения и передачи ваучера, документов, связанных с получением и передачей наследования, оформления фирм и т.д. и т.п.).» .
С практической точки зрения, наибольшую ценность в справочнике представляет собой перечень основных типов склонения фамилий и имен с примерами. Кроме того, вторая часть книги содержит пространный перечень личных имен с указанием способа их склонения. Данный перечень, после его перевода в цифровую форму, может быть использован для тестирования правильности работы алгоритмов автоматического склонения личных имен.
Наиболее близким к современности обзором типов склонения русскоязычных антропонимов оказалась интернет-страница, содержащая статью Н. А. Еськовой «Особенности склонения фамилий и личных имен» . Этот материал представляет собой концентрированную вытяжку из книги Л.П.Калакуцкой 1984 года. Информация представлена сжато и максимально конкретно. Каждый тип склонения антропонима дополнен значительным количеством примеров. Особенно внимание уделено обработке трудносклоняемых антропонимов. В некоторых случаях предлагаются интересные и неожиданные решения. Так, например, для различения склоняемых немецких фамилий типы «Рерих» и «Фрейндлих» и несклоняемых русских «Долгих», «Глухих» предлагается анализировать третью с конца букву, которая обычно является передненебной (prepalatal) в немецких фамилиях и иная в русских. Приводится также искусственная фамилия «Синих», не соответствующая этому наблюдению. Информация, почерпнутая из статьи, оказалась крайне полезной для составления алгоритма склонения антропонимов в рамках практической части данной работы, а примеры «трудных» фамилий стали неоценимым подспорьем при тестировании правильности работы алгоритма.
Помимо получения косвенных форм антропонимов, для автоматизации подготовки трафаретных текстов часто требуется получение косвенных падежей и других именных конструкций. Семантическое значение косвенных падежных форм подробно рассматривается в монографии Е. В. Клобукова «Семантика падежных форм в современном русском языке» . Помимо общих сведений о падежной системе русского языка, в данной работе уделяется внимание дополнительным падежам, формы которых иногда приходится использовать для некоторых существительных. Для современной традиции подготовки трафаретных текстов наибольший интерес представляют локатив, иногда устанавливающийся для топонимов и дополнительные счетные падежи.
Интересна приводимая в работе точка зрения на роль именительного падежа в языковой системе: «Именительный падеж, по данным усвоения языка, нормы и патологии, является доминирующей падежной формой: с него начинается усвоение падежей, он наиболее устойчив к различным искажениям, он выступает заменой любого косвенного падежа, а при распаде падежной парадигмы (при рассмотренных формах афазии) является единственной употребляемой формой существительного». «Существительные хранятся в памяти в именительном падеже»… «именительный падеж занимает особое место в парадигме: он противопоставлен совокупности всех остальных падежей» . Возможно, что приведенные особенности номинатива и определили его полное доминирование в современных динамично развивающихся высокоэффективных естественных и искусственных языках. Отметим, что классическая компьютерная информационная система, как и человек, хранит именные конструкции (антропонимы, топонимы, наименования предметов, документов и т.п.) исключительно в именительном падеже.
Потребность в простых в использовании программных компонентах для получения косвенных форм именных конструкций не осталась незамеченной русскоязычным сообществом программистов. В сети Интернет нам удалось обнаружить несколько подобных решений. Старейшим из них следует признать алгоритм склонения антропонимов Юрия Железнякова . Этот алгоритм имеет открытый код, компактен, но трудно воспринимаем. Известны реализации того алгоритма для большинства используемых в настоящее время программных платформ. Технологическим же лидером в этой области является библиотека «padeg.dll» , предназначенная для получения форм косвенных падежей антропонимов, наименований подразделений и должностей в программах для операционных систем семейства Microsoft Windows. Изначально библиотека «padeg.dll» базируется на одной из ранних версий алгоритма Юрия Железнякова. Изучение опыта использования этой библиотеки позволило определить некоторые неявные требования к разработке таких программ, а также предусмотреть возможные трудности.
Как известно, процесс разработки серьезных программных продуктов начинается со сбора требований. К сожалению, литературы на русском языке, освещающей этот вопрос практически нет. Некоторую часть необходимых сведений нам удалось почерпнуть из книги Карла Вигерса «Разработка требований к программному обеспечению» . Несмотря на многообещающее название, книга лишь очерчивает круг вопросов, которые следует учитывать до начала разработки программы. Наиболее полезной книга оказалась при планировании процесса интеграции разработанного в практической части данной работы пакета с работающей информационной системой.
Поскольку разработка алгоритмов и программного пакета в рамках данной работы выполнялась силами одного программиста, крайне полезной оказалась одна из методик экстремального программирования «Разработка через тестирование». Экстремальное программирование — модный набор эффективных методик или техник, позволяющий небольшой группе программистов за известное время разработать качественный программный продукт с заданной функциональностью. Для ознакомления с методиками экстремального программирования мы изучили одну из фундаментальных монографий на эту тему – книгу Кена Ауэра и Роя Миллера «Экстремальное программирование: постановка процесса» . Хотя авторы рекомендуют применять весь набор методик комплексно, существенный рост производительности труда можно получить, используя лишь некоторые из них. Так применение одной лишь методики «Разработка через тестирование» позволило нам еще до начала разработки определить критерии оценки качества конечного продукта и следовать им.
Разрабатывая в рамках данной дипломной работы комплекс алгоритмов и их референтную реализацию, мы стремились сделать их максимально доступными большому числу независимых пользователей. С этой целью нами был проведен анализ популярных лицензий на открытое программное обеспечение. Источником текстов лицензий послужил Web-сайт «Open Source Initiative» . Определенную помощь оказало сравнение открытых лицензий Е. Тяпкиной . Изучение различных вариантов открытых лицензий позволило выбрать наиболее подходящую из них – лицензию типа BSD, налагающую минимальные обязательства на пользователя лицензируемой программы.
Дипломная работа состоит из введения, трех глав и заключения.
В первой главе описываются существующие способы классификации унифицированных форм документов, анализируются способы представления реквизита «текст» документа в этих формах, подробно рассматривается особенности трафаретного текста и трудности его автоматизированного формирования в соответствии с русскоязычной традицией. Особое внимание уделяется трафаретному тексту, как наиболее сложному с точки зрения автоматизации его подготовки. Выделяются разновидности составных частей трафаретных текстов (фрагменты) и рассматриваются потребности в программных компонентах для автоматизации вывода каждого типа фрагмента. Антропонимы, наименования должностей и подразделений определяются как наиболее востребованные изменяемые фрагменты трафаретного текста.
Во второй главе анализируются распространенные в настоящее время подходы к генерации различных документов с трафаретными текстами, содержащими косвенные формы антропонимов, наименований должностей и подразделений, приводится обзор доступных программных компонентов, способных облегчить задачу автоматического получения таких форм. Далее рассматриваются процесс разработки алгоритмов получения косвенных форм именных конструкций, реализация алгоритмов в виде пакета на языке Java, тестирование полученного пакета и особенности его применения.
Третья глава работы посвящена опыту интеграции разработанного пакета в корпоративную информационную систему реального предприятия с целью оптимизации процесса подготовки документов. Описываются все шаги интеграции и изменения, которые пришлось сделать в информационной системе для успешного ее проведения.
ГЛАВА 1. ОФОРМЛЕНИЕ РАСПОРЯДИТЕЛЬНЫХ ДОКУМЕНТОВ С ИСПОЛЬЗОВАНИЕМ ИНФОРМАЦИОННЫХ СИСТЕМ В ОТЕЧЕСТВЕННОМ ДОКУМЕНТОВЕДЕНИИ
1.1. Проблемы оформления распорядительной документации в отечественной системе документоведения
Современное отечественное делопроизводство считается сравнительно хорошо изученной и методически проработанной сферой деятельности человека. Однако даже беглый анализ существующих отечественных систем классификации видов документов показывает, что процессы изучения и нормирования делопроизводства все еще находятся в активной стадии и далеки от полного завершения.
Рассмотрим несколько распространенных подходов к классификации видов документов.
В учебных и методических пособиях виды документов обычно группируются по функциональному признаку. Как правило, в соответствии с этим подходом выделяются четыре группы документов:
1. Организационно-правовые документы. Формируются в процессе организационной деятельности учреждения (создание, реорганизация. ликвидация организации, установление структуры, определение штатной численности и номенклатуры должностей, регламентация деятельности структурных подразделений и работников, формирование коллегиальных и совещательных органов управления, регламентация деятельности аппарата управления, лицензирование деятельности, установление режима работы и системы охраны, организация и оценка труда работников). К организационно-правовым документам относятся учредительный договор, устав организации, положение об организации, положения о структурных подразделениях, положение о коллегиальных и совещательных органах учреждения, регламенты работы коллегиальных и совещательных органов, регламенты работы аппарата управления, штатное расписание, инструкции по отдельным видам деятельности, должностные инструкции работников, правила и т. п. Организационно-правовые документы содержат положения, основанные на нормах административного права и обязательные для исполнения. Эти документы составляют правовую основу деятельности организации.
2. Распорядительные документы. Регулируют и координируют деятельность организации, позволяют органу управления обеспечивать реализацию поставленных перед ним задач и получать максимальный эффект от своей деятельности. Распорядительные документы содержат управленческие решения, обязательные для выполнения. Решения, фиксирующиеся в распорядительных документах, могут быть направлены на совершенствование организационной структуры учреждения, выбор средств и способов осуществления основной деятельности, обеспечение организации финансовыми, трудовыми, материальными, информационными и иными ресурсами. Примерами распорядительных документов, создаваемых в организации, являются приказ, распоряжение, указание. Приказы издаются по вопросам основной деятельности и по личному составу. Идут сверху вниз по системе управления.
Среди распорядительных документов имеются как индивидуально готовящиеся документы, так и многочисленные типовые документы, индивидуальные различия которых незначительны. Если для подготовки документов первой группы возможности использования автоматизированных систем неочевидны, использование автоматизированных систем для подготовки документов второй группы в настоящее время более чем оправдано. Особенно это востребовано при управлении персоналом. Реально сложившаяся в настоящее время ситуация такова, что большая часть манипуляций с персоналом происходит внутри информационной системы предприятия. Многочисленные же бумажные документы фактически (особенно в неразвитых информационных системах) несут фиксирующую функцию (отражают уже произведенные изменения) и готовятся, по большей части, лишь для совместимости с текущим законодательством. Зачастую бумажная копия документа готовится и подписывается значительно позже фактического исполнения изложенного в документе решения. Соответственно, для экономии ресурсов и снижения вероятности возникновения ошибок, все чаще бумажная копия документа готовится автоматически на основе информации, содержащейся в базе данных информационной системы организации.
3. Информационно-справочные документы. По отношению к организационно-правовым и распорядительным документам играют служебную роль. Справочно-информационные документы не содержат поручений, не обязывают действовать строго определенным образом, но сообщают сведения, побуждающие принимать определенные решения, иначе говоря, инициируют управленческие решения, позволяют выбрать тот или иной способ воздействия. Идут снизу вверх по системе управления. К информационно-справочным документам относятся протоколы заседаний, совещаний, конференций, деловых встреч, различные разновидности актов, докладные записки, предложения, служебные записки, объяснительные записки, справки, сводки, заключения, отзывы, перечни и списки.
Поскольку на современном предприятии существенная часть информации хранится в автоматизированной информационной системе, появляется реальная возможность автоматизировать с помощью этих систем подготовку многих документов данной группы. Особенно выгодно использовать этот прием при подготовке справок, актов, перечней и списков. Наиболее часто этот подход применяется при подготовке документов, связанных с учетом товарно-материальных ценностей.
4. Переписка. Обобщенное название различных по содержанию документов (служебное письмо, телеграмма, телекс, телефонограмма, факсограмма, электронное сообщение и др.), обеспечивающих оперативный информационный обмен между организациями. Переписка используется для реализации информационных связей между организациями как состоящими, так и не состоящими в отношениях соподчинения.
Реквизит «текст документа» в документах, относящихся к деловой переписке обычно представляет собой свободный текст. Автоматизированная подготовка таких документов применяется либо при массовых рассылках однотипных писем (рекламные рассылки, поздравления, приглашения, уведомления, извещения), либо при периодически отсылаемых однотипных письмах (периодические отчеты, сообщения о важных событиях). Большая же часть документов этой группы предполагает индивидуальный и творческий подход к каждому документу.
Другим распространенным подходом к классификации видов документов является ситуативно-отраслевая классификация, нашедшая свое выражение в Общероссийском классификаторе управленческой документации (ОКУД или ОК 011-93) . Этот классификатор разработан в 1993 году научно-исследовательскими институтами и органами федеральной власти взамен Общесоюзного классификатора управленческой документации (1 89 012) для использования на территории Российской Федерации. Объектами классификации в ОКУД являются общероссийские унифицированные формы документов, утверждаемые разработчиками унифицированные систем документации (УСД). Следовательно, весь ОКУД представляет собой конгломерат более мелких классификационных единиц, называемых Унифицированные системы документации. В соответствии с ОКУД все многообразие форм документов, использующихся на территории Российской Федерации можно свести к конечному набору унифицированных форм. Эти унифицированные формы группируются в классы (класс, в общем, соответствует УСД), внутри которых выделяются подклассы. Каждая унифицированная форма документа в ОКУД должна иметь семизначный код, первая пара цифр в котором соответствует классу, а вторая пара цифр – подклассу документа. Таким образом, всего возможно 99 классов, 99 подклассов внутри каждого класса и 999 унифицированных форм внутри каждого подкласса. Отмечено, что ведомственные классификаторы, создаваемые на базе ОКУД должны размещать разрабатываемые формы внутри соответствующих классов ОКУД. Предусмотрена и возможность создания собственных ведомственных классов (классы 80-99). Для совместимости со сложившимися ведомственными системами документооборота, имеющими общероссийское значение, некоторые классы ОКУД содержат ссылки на индексы соответствующих ведомственных форм. Текущая редакция ОКУД (включающая все изменения до 2008 года) содержит девять классов, показанные в Таблице 1.
Табл. 1. Классы ОКУД
№ п.п. Класс Описание
1. 02 Унифицированная система организационно-распорядительной документации
2. 03 Унифицированная система первичной-учетной документации
3. 04 Унифицированная система банковской документации
4. 05 Унифицированная система бюджетной финансовой, учетной и отчетной документации
5. 06 Унифицированная система отчетно-статистической документации
6. 07 Унифицированная система учетной и отчетной бухгалтерской документации предприятия
7. 08 Унифицированная система документации по труду
8. 09 Унифицированная система документации Пенсионного фонда РФ
9. 10 Унифицированная система внешнеторговой документации

Кроме того, в ОКУД оговорено, что классы 60-78 выделены для унифицированных систем документации Вооруженных Сил Российской Федерации.
Считается, что набор документов, перечисленных в ОКУД, является необходимым и достаточным для решения управленческих функций любой организации.
Отметим, что Российская Федерация, как преемница делопроизводственных традиций Советского Союза, имеет продолжительную и, местами, успешную историю стандартизации форм деловой документации. Еще в 1970-х годах была начата разработка «Единой государственной системы документации» (ЕГСД). В конце 1980-х годов на ее основе были разработаны основные положения «Государственной системы документационного обеспечения управления» (ГСДОУ). В 1989 году они были одобрены коллегией Главархива СССР. В этом документе обобщен многолетний отечественный опыт в области организации работы с документами организаций, учреждений и предприятий. Основные положения ГСДОУ пока остаются действующими документами и рекомендованы организациям при решении вопросов, связанных с документационным обеспечением управления. Однако на настоящий момент эти положения во многом являются устаревшими, поскольку не учитывают изменений политического строя, социально-экономической ситуации, возникновения сферы автоматизированного делопроизводства. Кроме того, если на время своей разработки, ГСДОУ, несмотря на рекомендательный характер, использовалась организациями при построении своих систем делопроизводства, в настоящее время значительная часть организаций строит документооборот по-своему. Такое разнообразие систем документооборота осложняет работу с формами первичной учетной документации, что заставляет государственные органы регулярно, но бессистемно, издавать нормативные акты, повышающие степень стандартизации документооборота.
Многие авторы отмечают, что назрела необходимость в появлении новой редакции государственной системы делопроизводства, учитывающей, наряду с традиционными, и современные технологии создания и работы с документами, и устанавливающей единые базовые принципы организации ДОУ для органов государственной власти, местного самоуправления, организаций независимо от формы собственности. Затягивание подготовки этого важнейшего документа разрушает устоявшиеся рациональные формы и методы организации делопроизводства даже в государственных организациях.
Положения ОКУД и ГОСТов в настоящее время носят лишь рекомендательный характер. Обязательного их применения законодательство не требует. При этом государству крайне желательно иметь возможность легко и рационально учитывать и систематизировать документы организаций всех форм собственности. С этой целью органы исполнительной власти, в соответствии со своей компетенцией, эпизодически издают нормативные акты, обязывающие применять унифицированные формы документов в той или иной сфере. Часто эти нормативные акты входят в диссонанс с классификацией ОКУД, однако, благодаря обязательности их применения, реально используются в документообороте.
Одним из наиболее важных документов такого характера является Постановление Госкомстата РФ от 5 января 2004 года №1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты» . К этому документу прилагается «Альбом унифицированных форм первичной учетной документации по учету труда и его оплаты», показывающий внешний вид утверждаемых унифицированных форм. Утверждаемые в Постановлении формы документов повсеместно используются для учета персонала и являются жизненно важными для деятельности любой гражданской организации. Классификация форм в Постановлении частично совпадает с точкой зрения ОКУД, но во многом и отличается от нее. Так ОКУД, в числе прочего, относит приказы по личному составу, штатное расписание и график отпусков к Унифицированной системе организационно-распорядительной документации. Согласно Положению Госкомстата, все эти документы являются первичными учетными документами. В соответствии с этой концепцией данные формы документов получили дополнительные искусственные коды ОКУД. В Приложении 1 перечислены унифицированные формы, вошедшие в Постановление Госкомстата с указанием кодов для альтернативных форм тех же документов по ОКУД. По мнению авторов Постановления, формы документов, включенных в него, являются достаточными для организации полноценной работы службы по управлению персоналом.
Предыдущая версия данного Постановления Госкомстата (№26 от 06 января 2001 года) содержала также унифицированную форму трудового договора, имевшую код ТД-1 (ОКУД 0301014).
Причины нарушения Постановлениями Госкомстата структуры ОКУД непонятны, однако можно предположить, что свою роль сыграли попытки отойти от сложившейся советской системы делопроизводства, изменения в трудовом законодательстве и стремление собрать в одном месте все формы документов, необходимые для организации работы службы по управлению персоналом.
Приведенный обзор систем классификации видов документов говорит о некоторой искусственности и неполноте существующих методик классификации документов.
Помимо форм документов, включенных в различные официальные и научные классификации, в сложившейся делопроизводственной практике используется большое число форм документов, разработанных организациями самостоятельно для собственных внутренних целей. Серьезные организации сводят наборы таких форм во внутренние нормативные документы, носящие названия табелей типовых форм, стандартов предприятий и т. п. Такие совокупные объемы форм документации представляют собой хорошее пособие для изучения насущных потребностей и проблем хозяйствующих субъектов в области документационного обеспечения управления.
Поскольку данная работа преследует сугубо практические цели, которые мало зависят от применения той или иной искусственной классификации документов, имеет смысл рассмотреть документы не по их формальным классификационным признакам, а по физическим (материальным) особенностям их заполнения.
С точки зрения информационных технологий, каждый документ является не более чем совокупностью собственных реквизитов. Благодаря ГОСТ Р 6.30-2003 мы можем говорить о стандартном наборе реквизитов для организационно-распорядительной документации, а поскольку само понятие организационно-распорядительной документации, как было показано выше, довольно размыто, можно предположить, что довольно значительная часть реквизитов ГОСТ не специфична для какой-то определенной группы документов.
Реквизит «текст документа», являясь основным носителем документальной информации, в той или иной форме используется в документах всех групп. При этом форма представления текста различна для документов разных видов даже внутри одной группы.
1.2. Типовые и трафаретные тексты в распорядительной документации
Согласно ГОСТ Р 6.30-2003, текст документа – информация, зафиксированная любым типом письма или любой системой звукозаписи, заключающая в себе всю или основную часть речевой информации документа. Текст документа – основная содержательная часть документа. В соответствии с видом документа выбираются композиционная структура текста, стиль изложения и языковые средства. ГОСТ предписывает использовать для составления текста документа государственный язык Российской Федерации или государственные языки Субъектов Российской Федерации. Это положение подкрепляется и законодательно: «Официальная переписка и иные формы официальных взаимоотношений между государственными органами, организациями, предприятиями, учреждениями субъектов Российской Федерации с адресами в Российской Федерации ведутся на государственном языке российской федерации – русском языке».
Поскольку каждый документ имеет юридическую силу, принято ограничивать набор языковых средств, используемых при его составлении. Использование таких ограничений приводит к унификации текстов документов, составляемых в сходных управленческих ситуациях.
Унификация текстов заключается в установлении единой формы языкового выражения, наиболее точно передающей содержание регулярно повторяющихся управленческих ситуаций или действий. Унификация текстов документов проводится методом выделения постоянной и переменной информации. Постоянной является информация, повторяющаяся во всех документах, создаваемых в аналогичных управленческих ситуациях. Переменной считается информация, позволяющая различать повторяющиеся управленческие ситуации. Постоянная информация фиксируется в унифицированной форме документа, составляя неизменную, повторяющуюся часть текста. В унифицированной форме документа должно быть предусмотрено место для записи переменной, новой информации.
«… Унификация связывает используемую лексику, закрепляет позиции валентности в словосочетаниях, создавая малопроницаемые сверхфразеологизмы. Воспроизводимыми становятся не только словосочетания, но и целые фразы, и сверхфразовые единства. Количество единиц со строгой номинацией … создает лексическую основу официально-деловых документов». Чем выше степень закрепленности внутридокументной позиции словесных формулировок и чем жестче ограничения их лексико-фразеологического состава, тем ближе документ к тому, что называется бланком. Следовательно, документы, имеющие тем или иным образом закрепленную типовую форму, имеют предельно унифицированный текст. Наличие такого текста в документах позволяет всерьез рассматривать возможность применения для их подготовки, обработки и использования технических средств.
В сложившейся экономической ситуации трудно представить более или менее крупную организацию, обходящуюся без программы бухгалтерского учета. Постепенно стандартом становится и использование информационных систем по учету персонала. Организации, располагающие крупным парком технических средств и разветвленной инфраструктурой, часто используют автоматизированные информационные системы для учета основных фондов. Излишне говорить об эффекте, который способны оказать информационные системы на организации, работающие в сфере торговли, логистики, связи, транспорта и т.п.
Известно, что затраты на автоматизацию подготовки того или иного документа различны. Учитывая то, что наборы реквизитов для всех видов документов различаются мало, логично предположить, что причиной различия в трудоемкости автоматизации подготовки является различия форм представления текста документа.
Согласно нормативным документам и учебным пособиям, считается, что текст документа может быть представлен в виде грамматически связанного текста, анкеты или таблицы. «Тексты документов оформляются в виде анкеты, таблицы, связного текста или в виде соединения этих структур». Опыт составления документов показывает, что в ряде случаев, на основании данных текстов-таблиц могут быть построены графики или диаграммы, повышающие наглядность документа.
Рассмотрим перечисленные способы представления текстов документов подробнее:
1. Анкета – форма представления текста документа, в котором дается характеристика одного объекта по определенным признакам. Постоянной информацией в анкете являются обобщенные наименования признаков, по которым дается описание объекта, а переменной – конкретные характеристики признаков. Анкета строится по принципу «вопрос-ответ». В тексте анкеты постоянная информация выражается существительным в именительном падеже или словосочетанием, опорным словом которого является существительное в именительном падеже. Переменная информация в анкете может записываться также словосочетанием в именительном падеже, глаголом (например, имеет, не имеет), числительным (чаще в цифровой форме) или словами «Да», «Нет».
При составлении текста в виде анкеты наименования признаков характеризуемого объекта должны быть выражены именем существительным в именительном падеже или словосочетанием с глаголов второго лица множественного числа настоящего или прошедшего времени («имеете», «владеете» или «были», «находились» и т. д.). Характеристики, выраженные словесно, должные быть согласованы с наименованиями признаков .
2. Таблица – форма представления текста, содержащего описание нескольких или множества объектов по определенному набору признаков. Таблица имеет два уровня членения текста – вертикальный и горизонтальный. В таблицах, как и в анкетах, текст упрощен, в нем преобладают конструкции именного типа: наименование объекта, количество, размер, тип, марка и т.д. В таблице постоянная информация представлена наименованиями признаков, по которым описывается некоторое множество объектов, записанных в крайней левой графе таблицы – боковике. Переменная информация в таблице записывается в ячейки, образуемые пересечением горизонтальных строк и вертикальных граф. Таблицы, как правило, применяются для изложения цифровой информации в отчетно-статистических, бухгалтерских, банковских, организационно-распорядительных и других документах.
При составлении таблицы ее графы и строки должные иметь заголовки, выраженные именем существительным в именительном падеже. Подзаголовки граф и строк должны быть согласованы с заголовками. Если таблицу печатают более чем на одной странице, графы таблица должны быть пронумерованы и на следующих страницах должны быть напечатаны только номера этих граф.
3. Связный текст, как правило, состоит из двух частей. В первой части указывают причины, основания, цели составления документа, во второй (заключительной) – решения, выводы, просьбы, предложения, рекомендации. Текст может содержать одну заключительную часть (например, приказы – распорядительную часть без констатирующей; письма, заявления – просьбу без пояснения).
Все рассмотренные виды представления унифицированных текстов могут применяться раздельно и вместе. При необходимости в унифицированной форме документа часть текста может быть представлена в виде трафарета, часть в виде анкеты или таблицы.
В некоторых случаях авторы разделяют форму «связный текст» на две подформы: свободный текст (включая рубрицированный) и трафаретный текст . С точки зрения автоматизации подготовки документов такое разделение представляется весьма важным, поскольку существующий уровень развития информационных технологий позволяет надежно генерировать лишь трафаретный текст.
Трафаретность текста – такая форма документа, которая закрепляет сочетания устойчивых речевых отрезков с определенными позициями. В образующиеся пустоты заносятся те речевые фрагменты, которые имеют индивидуальный характер. Относительные положения клишированных речевых отрезков и первоначально незаполненных участков документа являются взаимнофиксированными для каждого вида документа. Трафаретный текст документа представляет собой заимствуемый от документа к документу текст, в котором изменяются лишь персонифицирующие документ сведения.
Приведем еще один обзор трафаретного текста, как явления в сфере документационного обеспечения управления. «Текст-трафарет – это форма представления текста, содержащая постоянную информацию и пробелы, предназначенные для внесения переменной информации, характеризующей конкретную управленческую ситуацию. В тексте-трафарете сохраняется грамматическая структура текста, то есть это грамматически связанный текст, построенный по нормам деловой письменной речи. Представление унифицированного текста в виде трафарета выбирается в том случае, когда основным содержанием документа является информация об управленческих действиях. К таким документам относятся приказы, распоряжения, указания, протоколы, акты, договоры, соглашения, докладные записки, справки, письма и т.д.». Последняя фраза цитаты объединяет столько видов документов, что подтверждает мысль об искусственности зависимости типа текста документа от его вида.
Очевидно, что при наличии автоматизированной информационной системы для какого-либо направления деятельности, удобно использовать ее для подготовки документов. Иными словами, управляющее воздействие сначала отражается в базе данных информационной системы, а уже потом на основе модифицированной информации генерируется и распечатывается бумажная копия документа, попадающая в документооборот в качестве полноценного документа.
Рассмотрим возможности современных информационных технологий в части генерации документов, содержание которых передается той или иной формой текста.
1. Анкета. Подготовка таких документов автоматизируется относительно просто. Большинство распространенных генераторов отчетов содержат достаточный набор средств для создания таких документов. Известные трудности представляют собой случаи необходимости грамматического согласования характеристики признака с его названием. В таких ситуациях автоматизация подготовки для текста-анкеты проводится также как и для трафаретного текста.
2. Таблица. Документы с текстом-таблицей представляют собой самый распространенный случай при автоматизации их подготовки. Как показано в Приложении 2, немало табличных документов и среди унифицированных форм по учету персонала. Все генераторы отчетов, присутствующие на рынке, оснащены развитыми и достаточными средствами для работы с табличными документами. Таким образом, автоматизация их подготовки является тривиальной задачей. При этом, однако, следует учитывать частое присутствие в документах «ложных» таблиц (псевдотаблиц), которые на деле представляют собой специфическую форму анкеты или трафаретного текста. Настоящая таблица представляет собой повторяющийся в каждой строке набор одних и тех же характеристик для разных объектов. То есть объект примерно соответствует строке таблицы. В сложившейся системе делопроизводства встречается немало унифицированных форм, которые нарушают это правило. Такова, например, форма Т-9а «Приказ (распоряжение) о направлении работников в командировку», в которой каждому работнику, направляемому в командировку, посвящена не строка, а колонка. При таком подходе, учитывая, что количество направляемых в командировку работников заранее неизвестно, неизвестно и количество потребных для отображения «псевдотаблицы» колонок, что существенно ограничивает спектр программных средств, применимых для подготовки таких документов.
3. Диаграмма и график. Эта форма текста документа, технически является особым способом представления данных, содержащихся в тексте таблицы. Соответственно, многие развитые средства генерации отчетов поддерживают возможность подготовки документов с такой формой представления информации.
4. Свободный текст. Использование такого способа представления информации подразумевает известную свободу в творчестве и выборе языковых средств. Это делает попытки автоматизации общих случаев подготовки таких документов неэффективными. Частные случаи автоматизации состоят в ручном наборе текста документа с последующим хранением его в базе данных в виде неструктурированного массива алфавитно-цифровых данных. На печать такой текст выводится как один целостный и неделимый реквизит. Такой подход используется, например, при автоматизации нотариальной деятельности. Похожую функциональность имеют и системы автоматизации документооборота, рассматривающие документ как неделимый информационный блок и не меняющие свое состояние в соответствии с информацией, содержащейся в документе. В случае регулярного повторения сходных управленческих ситуаций, побуждающих составлять документы со свободным текстом, возможна автоматизация их подготовки по типу трафаретного текста. Авторам известны, например, некоторые, впрочем, малоуспешные, попытки автоматизировать подготовку должностных инструкций.
5. Трафаретный текст. Является довольно распространенной формой передачи содержания документа. Это заставляет часто прибегать к автоматизации подготовки таких документов. На первый взгляд, такая автоматизация является простой задачей. Однако более детальное рассмотрение выявляет несколько проблем, часть из которых является общей как для отечественных, так и для англоязычных традиций документооборота, а часть представляет особые трудности лишь для подготовки русскоязычных документов.
Типовая распорядительная документация по управлению персоналом занимает особое место в документообороте любого предприятия. Из-за жесткой законодательной регламентации объем потока этой документации в больших организациях чрезвычайно высок. Причиной этому служит интенсификация экономики, вызывающая повышенную текучесть персонала на существующих предприятиях, открытие новых предприятий, закрытие старых предприятий, массовые реорганизации и реструктуризации, оптимизацию занятости персонала внутри предприятия, повышение значимости фактора мотивации труда. Все это требует подготовки и обработки большого объема распорядительной документации и особенно по управлению персоналом.
Наиболее интересными для нас представляются документы, содержание которых передается трафаретным текстом. Анализ форм распорядительных документов по учету персонала, приведенный в Приложении 2 показывает, что трафаретным текстом снабжена значительная их часть.
В учебных пособиях отмечается, что «по структуре приказы по личному составу могут быть простыми и сложными. Простой приказ состоит из одного распорядительного раздела: принять, назначить, уволить и т.д. Если приказ касается одного лица, то он называется индивидуальным, если охватывает круг лиц – сводным. Объединение в приказе нескольких распорядительных разделов делает приказ сложным. Несмотря на широкую практику составления сложных приказов по личному составу, следует учитывать, что они не только не обеспечивают должной оперативности ручного поиска информации в процессе оперативной и контрольной работы, особенно при значительных объема этого вида документов, но и затрудняют использование автоматизированных систем обработки кадровой информации. Для обеспечения [функционирования] автоматизированных информационных кадровых систем все более интенсивно внедряются структурно простые приказы по личному составу и, как правило, индивидуальные».
Согласно данному высказыванию, настоящая тенденция такова, что с распространением систем автоматизации делопроизводства сложные приказы (представляемые таблицами) уступают место простым приказам (представляемым трафаретными текстами). В том же пособии говорится: «Схематически можно указать следующую постоянную информацию любого пункта приказа: распорядительное действие, фамилия, имя отчество лица, должность и структурное подразделение, дата вступления в силу данного пункта приказа, обязательные условия. В тексте пункта приказа не должно быть каких-либо сокращений (подразделений, должностей), опечаток, ошибок в информации, особенно в фамилиях. Составление текстовых традиционных приказов по личному составу, даже простых по структуре, сопровождается значительными трудозатратами работников отдела кадров за счет необходимости обработки множества дополнительных документов».
Упомянутые факты заставляют разработчиков информационных систем уделять все большее внимание автоматизации подготовки трафаретных текстов и искать пути преодоления сложностей, возникающих при этом.
1.3. Фрагменты трафаретного текста для автоматизированной подготовки русскоязычной распорядительной документации
Авторы, рассматривающие в своих работах трафаретный текст традиционных бумажных документов, сходятся на том, что он представляет собой последовательность постоянных и изменяемых участков текста. Общего названия для этих участков авторы не приводят. Так С. П. Кушнерук пишет об устойчивых или клишированных речевых отрезках и незаполненных участках , а Л. Р. Фионова упоминает постоянную информацию и «пробелы» . Для ясности дальнейшего изложения информации, мы сочли возможным ввести в рамках данной работы понятие фрагмента трафаретного текста. Фрагментом назовем непрерывную изменяемую или неизменяемую часть трафаретного текста. Следовательно, фрагменты трафаретного текста могут быть неизменяемыми и изменяемыми. Неизменяемые фрагменты трафаретного текста постоянны для всех документов данного вида (составляемых по определенной форме). Изменяемые фрагменты трафаретного текста индивидуальны для каждого документа.
Разделим изменяемые фрагменты трафаретного текста по типам содержащихся в них данных.
1. Абстрактно числовые (количества объектов и т.п.);
2. Финансовые (денежные суммы);
3. Хронологические (даты, временные интервалы);
4. Текстовые (наименование товарно-материальных ценностей, подразделений, организаций, физических лиц и т.п.);
Каждый из названных типов изменяемых фрагментов трафаретного текста требует отдельного способа обработки.
Самым простым для обработки является абстрактно-числовой фрагмент. Фрагменты этого типа обычно помещаются в трафаретный текст в неизменном виде. Несмотря на это, очевидным подводным камнем при обработке абстрактно-числовых фрагментов трафаретного текста является необходимость грамматического с ним согласования последующего дополнения в зависимости от значения числового фрагмента. Например, «1 календарный день», но «2 календарных дня». Таким образом, дополнение, следующее за числовым фрагментом, можно трактовать как зависимый изменяемый текстовый фрагмент.
Несколько более трудоемкой обработки требуют финансовые фрагменты трафаретного текста. Здесь часто требуется разбить денежную сумму, представленную действительным числом, на две части, разделив их наименованием единицы валюты. При этом сотые части денежной суммы обычно требуется дополнить лидирующими нулями. Например, «25.05»  “25 рублей 05 копеек». Кроме того, в финансовых документах очень часто требуется выразить денежную сумму прописью. Например, «25.05»  “двадцать пять рублей пять копеек». Заметим, что проблема грамматического согласования дополнений (наименования валюты и ее сотых частей) сохраняется, равно как и при обработке абстрактно-числовых фрагментов. С другой точки зрения, такой финансовый фрагмент можно выразить через комплекс взаимосвязанных числовых и текстовых фрагментов.
Хронологические фрагменты трафаретного текста также обычно требуют обработки. Часто дату требуется представить в виде трех субфрагментов (дня, месяца и года). При этом день требуется при необходимости дополнить лидирующими нулями до двух знаков, месяц представить в виде его русскоязычного наименования в родительном падеже, а год, при необходимости, дополнить веком. Изредка возникает необходимость представить интервал между датами в виде перечня ее компонентов с указанием грамматически согласованных наименований компонентов. Например, «25.10.2005 – 30.12.2006»  «1 год, 2 месяца, 5 дней». В этом случае хронологический фрагмент может трактоваться как набор взаимосвязанных числовых и текстовых фрагментов.
Наиболее сложным типом изменяемых фрагментов трафаретного текста являются текстовые фрагменты. Их многообразие таково, что они заслуживают отдельной классификации.
Далее разделим все текстовые изменяемые фрагменты трафаретного текста на стабильные и флективные.
Стабильные фрагменты представляют собой одно раз и навсегда определенное слово или словосочетание, грамматически согласуемое с другим изменяемым компонентом трафаретного текста (обычно, абстрактно-числовым). Синтаксически стабильный фрагмент обычно является дополнением. Примеры: [«рубль»/«рубля»/«рублей»], [«календарный день»/«календарных дня»/«календарных дней»].
Флективные текстовые фрагменты трафаретного текста представляют собой заранее неопределенное слово или словосочетание. Эта неопределенность заставляет использовать для обработки таких фрагментов разные алгоритмы. По этой причине такие фрагменты можно также подразделить на простые (состоящие из одного слова, обрабатываемые проще) и сложные (представляющие собой словосочетание или потенциальное словосочетание, обработка их сложнее).
Полностью составленная нами классификация фрагментов трафаретного текста показана на Рисунке 1.

Рис. 1. Классификация фрагментов трафаретного текста документа.
Из-за обилия и, зачастую, трудности выделения изменяемых фрагментов трафаретного текста, процесс подготовки таких документов является относительно трудоемким и предъявляет специфические требования к квалификации и внимательности персонала, составляющего документы. Очевидно, что в условиях современного общества и экономики выделение таких ресурсов не всегда возможно и оправдано, что заставляет искать пути автоматизации этой деятельности.
Общей проблемой, как для западной, так и для отечественной документальных традиций является «плавание» абсолютных позиций фрагментов трафаретного текста документа. Например, в тексте вида «Гражданин [ИмяРаботника] работает на предприятии [ИмяПредприятия] в отделе [ИмяОтдела] в должности [ИмяДолжности]», позиция изменяемого фрагмента «ИмяПредприятия» зависит от количества символов и кумулятивной ширины фрагмента «Имя работника». Позиция же фрагмента «ИмяДолжности» зависит от свойств всех предшествующих фрагментов. Таким образом, точно предсказать позицию каждого фрагмента трафаретного текста в общем случае представляется невозможным. Обратим внимание и на то обстоятельство, что позиция каждого неизменяемого фрагмента трафаретного текста, следующего за изменяемым фрагментом, также является плавающей. Описанная проблема делает традиционные средства генерации отчетов малопригодными для работы с документами этой группы. Как правило, в качестве выхода из этой ситуации применяется программная генерация всего индивидуализированного трафаретного текста документа в виде единого, с точки зрения генератора отчетов, реквизита. Однако такой прием применим ограниченно (например, часто существует ограничение на длину выводимого реквизита) и требует довольного существенных затрат дорогого труда программиста. В последнее время, особенно в нашей стране, появляется все возрастающее количество как платных, так и бесплатных генераторов отчетов, использующих потоковый метод расположения реквизитов (когда позиция каждого последующего реквизита рассчитывается на основе геометрических параметров предыдущих реквизитов).
Второй сугубо отечественной проблемой при автоматизации подготовки документов с трафаретным текстом является сильная флективность русского языка. Иными словами, каждый последующий фрагмент трафаретного текста требует грамматического согласования с предыдущими фрагментами. Поскольку наиболее значимые для западного делового мира языки (английский, французский, испанский, португальский) малофлективны или имеют легко предсказываемую флективность, при разработке существующих платформ для информационных систем этот фактор учтен не был. С данной проблемой при подготовке документов столкнулись не только русскоязычные разработчики информационных систем. Те же трудности вынуждены преодолевать и носители других флективных языков (значительной части германских и угро-финских языков, всех славянских, тюркских, семитских, алтайских и многих других языков). Разработчики информационных систем, связанных с одним из этих языков, выходят из положения сами по себе, не располагая единым стандартом или методическим руководством.
1.4. Классификация документов с точки зрения автоматизации их подготовки
С точки зрения автоматизации подготовки, изученные документы можно разделить на три группы:
1. Документы, подготовка которых не подлежит автоматизации. К этой группе относятся документы, в общем случае, не имеющие типового текста – большая часть организационных, нормативных и учредительных документов, некоторые распорядительные и справочные документы. Текст таких документов является результатом человеческого творчества и мало повторяется от одного документа к другому. Автоматизированные информационные системы для подготовки таких документов не применяются. Изредка фактографическая часть этих документов находит последующее отражение в виде определенных показателей информационной системы, вводимых вручную на основе готовых документов. Например, реквизиты организации (Название, Адрес, ИНН, Расчетный счет и т. п.) вручную вводятся в информационную систему оператором на основе учредительных документов (Учредительного договора, свидетельства о государственной регистрации и т. п.), а сами эти документы готовятся вне информационной системы и внутрь ее полностью обычно не вводятся.
2. Документы, подготовка которых происходит на основе данных информационной системы. Такие документы являются материальным отражением информации, содержащейся в базе данных автоматизированной информационной системы организации, имеющим форму типового документа. Необходимость в печатной копии документа обуславливается требованиями законодательства или практикой использования документов в конкретной организации (например, если документ необходим для работы сотрудникам, не имеющим доступа к информационной системе или не обладающим достаточной для работы с ней квалификацией). Обычно документы этой группы генерируются из самой информационной системы в виде печатного отчета одним нажатием. В хорошо развитых информационных системах, для поддержки вывода бумажных документов, помимо фактографических реквизитов документов (составляющих их объективное содержание), поддерживаются и реквизиты, необходимые только для бумажных копий документов (с точки зрения информационной системы такие реквизиты являются паразитными, так как они не нужны для работы системы). Данная группа документов, условно делится на две подгруппы, в зависимости от формы представления реквизита «текст документа»:
a) Документы, текст которых представлен таблицей, диаграммой и т.п. Документы этой подгруппы идеально подходят для автоматизации их подготовки. Существующие информационные системы по природе своей «заточены» под табличное представление информации. Документы этого типа являются классическими примерами отчетов в информационных системах. На Западе документы этой подгруппы составляют львиную долю всех автоматизированных документов. По этой причине, практически все существующие системы генерации отчетов (также разработанные для удовлетворения потребностей западных и, прежде всего, англоязычных, документальных традиций) ориентированы на генерацию документов именно такого типа. Эти средства превосходно подходят и для генерации печатных представлений бухгалтерских документов, так как эта сфера хозяйственной деятельности – одна из немногих в значительной мере копирующих западный подход.
b) Документы, текст которых представлен в виде грамматически связанного трафаретного текста, переменные части которого заменяются значениями из базы данных информационной системы. Из-за упоминавшейся ранее ориентации средств генерации отчетов на представление табличной информации, автоматизация подготовки таких документов сопряжена с определенными сложностями.
В рамках данной работы мы попытались определить наиболее острые потребности, стоящие перед русскоязычным разработчиком информационных систем. Определить, какие фрагменты трафаретных текстов документов меняют свой графический облик по сравнению с формой, хранимой в базе данных, и выработать несколько алгоритмов, наиболее важных для правильного вывода этих фрагментов.
В первой главе работы мы сделали попытку обозначить потребности, наиболее остро стоящие перед разработчиками русскоязычных корпоративных информационных систем в части автоматической подготовки распорядительной документации. Наиболее распространенные на рынке программные средства, предназначенные для выполнения этой задачи, разработаны для удовлетворения потребностей англоязычных разработчиков и не учитывают русскоязычных документных традиций, в частности, особенностей грамматической структуры русского языка.
Особенно пристального внимания заслуживает автоматизация подготовки основного носителя документальной информации – реквизита «текст документа». В рамках первой главы нами было показано, что наиболее сложной представляется автоматизация подготовки русскоязычных документов, содержание которых выражено трафаретным текстом. При этом документы с такими текстами составляют значительную часть унифицированных документов по учету труда и заработной платы.
Трафаретный текст был нами рассмотрен с точки зрения его автоматической генерации как набор изменяемых и неизменяемых фрагментов. Мы определили основные виды изменяемых фрагментов трафаретного текста и предложили их классификацию, в процессе составления которой перечислили наиболее характерные трудности, связанные с выводом фрагментов на печать.
По результатам классификации был определен состав базовых алгоритмов, реализация которых, в дополнение к существующим на рынке программным компонентам, необходима для успешного решения задач автоматизации подготовки документов с трафаретными текстами. Наиболее сложно реализуемой группой алгоритмов подобного рода являются алгоритмы получения косвенных форм именных конструкций, таких как антропонимы, наименования должностей и структурных подразделений.
В ходе дальнейшего исследования мы попытались определить, насколько полно выявленные потребности перекрываются доступными на рынке и в свободном сообществе специализированными программными решениями.
ГЛАВА 2. ОПРЕДЕЛЕНИЕ ВОЗМОЖНЫХ ПУТЕЙ И СПОСОБОВ ОПТИМИЗАЦИИ АВТОМАТИЧЕСКОЙ ПОДГОТОВКИ РАСПОРЯДИТЕЛЬНЫХ ДОКУМЕНТОВ В ОТЕЧЕСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
2.1. Обзор существующих подходов в оптимизации автоматической обработки распорядительной документации
2.1.1. Направления оптимизации автоматической подготовки документов
При ручной или компьютеризованной подготовке распорядительных документов на производительности труда отрицательно сказывается необходимость тщательного грамматического согласования как отдельных реквизитов документов, так и (в большей степени) фрагментов трафаретного текста. Из-за различного уровня подготовки персонала, необходима дополнительная проверка и вычитка подготовленных документов, а при обнаружении грамматических ошибок, проверку и вычитку документа приходится проводить снова.
Подход с применением автоматизированной подготовки документов свободен от перечисленных недостатков. Сами бумажные документы при этом представляют собой отчеты на основании содержащихся в информационной системе фактографических данных. Иными словами – печатный документ является материальным отражением уже существующей электронной информации.
Фактографические данные информационной системы предназначены, в первую очередь, для машинной обработки. По этой причине хранятся эти данные, как правило, в виде кодов, расшифровываемых из централизованных справочников системы. В свою очередь, в справочниках расшифровка кодовой информации представлена начальной грамматически нейтральной формой (например, именительным падежом) кодируемого объекта. Начальной формы вполне достаточно для обработки вводимой информации и представления ее в табличном виде (наиболее часто используемом при работе с электронными информационными системами). Вместе с тем, как отмечалось ранее, традиция и законодательство иногда требуют вывода печатных документов в виде грамматически связанного трафаретного текста, а это заставляет искать способы представления информации, содержащейся в информационной системе в виде специфических для конкретной ситуации грамматических форм. При этом разнообразие таких грамматических форм довольно ограничено. Так для наиболее востребованных для данной трансформации частей речи (существительных, прилагательных, местоимений и антропонимов) при подготовке документов применяются следующие падежи:
 Именительный ед. ч. – он же начальная нейтральная форма;
 Родительный – («на время отсутствия….»);
 Дательный – для адресования («поручить…»);
 Винительный – («направить …. в командировку»)
Вместе с тем, никто не может гарантировать того, что в определенный момент времени не возникнет необходимости использования и других косвенных падежей.
Специфика распорядительных документов определяет использование лишь единственного числа именных конструкций. Иными словами, потребности получения форм множественного числа из формы единственного числа на практике не возникает. Из этого правила возможны определенные исключения, например, когда наименование структурного подразделения изначально относится к множественному числу («биологические очистные сооружения»), однако, в таком случае, не требуется уже получения форм единственного числа.
Остальные части речи, применяемые при документировании (глаголы, причастия) в разных документах одного вида изменяются редко, что позволяет их отнести к неизменяемым фрагментам трафаретного текста.
Очевидным представляется один выход (если исключить возможную ревизию унифицированных форм, исключающую использование трафаретных текстов в пользу анкетных). Он состоит в адаптации программной части информационной системы, таким образом, чтобы можно было выводить изменяемые фрагменты трафаретного текста с помощью стандартных (классических) генераторов отчетов.
Иногда существующие автоматизированные системы обеспечивают данную функциональность лишь частично. Часто приходится сталкиваться с необходимостью вручную проводить грамматическое согласование фрагментов трафаретного текста документов. Дешевые, кустарные и доморощенные системы обычно решают эту проблему в недостаточной степени и также зачастую предоставляют согласование фрагментов оператору или заставляют отдельно вводить и хранить грамматические варианты изменяемых фрагментов. Более серьезные тиражируемые информационные системы, как правило, имеют средства для грамматической обработки фрагментов трафаретного текста, однако известно много случаев, когда такое средство неверно обрабатывало изменяемый фрагмент, не предоставляя никакой возможности провести ручную корректировку. Обычно в таких случаях результат автоматической подготовки документа игнорируется, а вместо него документ с теми же реквизитами набирается вручную с помощью текстового процессора. Такой подход, с одной стороны, вполне оправдан, поскольку удовлетворяет требованиям как информационной системы, получающей валидные регистрационные данные документа и достаточные для работы начальные формы фрагментов трафаретного текста, так и управляющего персонала, получающего технически правильный документ, отраженный в информационной системе. С другой стороны, этот метод открывает широкое поле для возникновения технических ошибок, несогласованностей, коррупции и т. п., то есть снова ставит подготовку документа в прямую зависимость от человека, чего традиционно пытается избежать автоматизация.
2.1.2. Существующие подходы в оптимизации
В настоящее время существует два подхода к решению данной проблемы:
1. Хранение косвенных форм изменяемых фрагментов трафаретного текста в базе данных наряду с основными формами, требующимися собственно для работы системы. Преимущества: крайняя простота реализации, определенная гибкость (есть возможность учета всех тонкостей в каждом конкретном случае). Недостаток: необходимость ввода, и поддержки значительного объема паразитной с точки зрения информационной системы информации (объем ввода при этом увеличивается в разы: например, вместо ввода фамилии только в именительном падеже требуется также ее ввод и в косвенных падежах, точно также требуется и синхронизация всех форм косвенных падежей при каждой корректировке основной формы). Такой подход применим для небольших объемов информации, там где затраты на обслуживание паразитных реквизитов не превзойдут затрат на разработку специализированного средства получения косвенных форм фрагментов трафаретного текста из начальной.
2. Использование программных компонентов, реализующих алгоритмы получения форм косвенных падежей фрагментов трафаретного текста из начальной формы, хранящейся в базе данных. Преимущества: отсутствие роста затрат на ввод и обслуживание информации, в ряде случаев облегченная интеграция с существующими информационными системами. Недостатки: высокие затраты на программирование, отсутствие возможности индивидуального указания конкретных форм конкретного фрагмента.
С нашей точки зрения, оптимальным путем является комбинирование этих двух подходов. Изначально косвенные формы фрагментов должны получаться автоматически с помощью специального программного модуля, но при этом следует сохранить возможность ручного указания конкретной косвенной формы в случае необходимости.
Поскольку способ реализации первого подхода тривиален, избыточен и однозначно гарантирует положительный результат (при известной добросовестности оператора), рассмотрим гораздо более интересный и академичный второй подход. Основная его черта – наличие работающего алгоритма автоматического получения форм косвенных падежей из начальной формы фрагмента. Наиболее частыми кандидатами на такую трансформацию являются антропонимы, наименования должностей и структурных подразделений. Проведем краткий обзор доступных алгоритмов с подобной функциональностью.
2.1.3. Алгоритмы склонения в информационных системах
Анализ сети Интернет показал, что большинство серьезных автоматизированных систем, содержащих модули для управления персоналом, имеют внутри себя то или иное программное решение для выполнения склонения антропонимов и наименований должностей и подразделений. Такие программные модули являются непременным атрибутом и развитых систем учета кадров (АйТи “БОСС-Кадровик”, KSoft “Отдел кадров», “1С:Зарплата и Кадры», 1C:HRM, “Firm 2.0”), а также систем по подготовке нотариальной («АвтоДок-Нотариус”), кадастровой (“ZemCad12»), приходно-расходной («Инфософт-Зарплата») и иной документации. Успешная реализация подобных алгоритмов рассматривается продавцами автоматизированных систем как несомненное конкурентное преимущество или даже ключевая особенность.
Отметим также, что отечественный лидер разработки платформ информационных систем, фирма 1С, включил в свою платформу «1С:Предприятие» модуль склонения ФИО только в 2006 году. Этот факт подтверждает рост (или объективное возникновение) потребности в подобных решениях.
Кроме того, в сети Интернет весьма часто можно встретить просьбы разработчиков корпоративных информационных систем о предоставлении им ссылки на программную библиотеку или алгоритм с подобной функциональностью.
В закрытых информационных системах способ получения флексий является коммерческой тайной и не публикуется. В лучшем случае можно встретить минимальное описание принципов их работы. Это не дает в полной мере оценить их достоинства и недостатки, а также предложить им для обработки набор тестовых данных. Следовательно, глубокий систематический анализ внутренних алгоритмов тиражируемых систем невозможен.
Для самостоятельно разрабатываемых организациями информационных систем в Сети предлагаются специальные закрытые и открытые компоненты для склонения фамилий, имен и отчеств, наименований должностей и структурных подразделений. Доступны как платные, так и бесплатные компоненты для различных архитектур.
Рассмотрим доступные программные средства склонения перечисленных именных конструкций, предназначенные для построения собственных информационных систем.
2.1.4. Обзор существующих решений
Библиотека «padeg.dll».
Де-факто, лидером среди готовых компонентов является библиотека «Склонение фамилий, имен и отчеств по падежам» («padeg.dll»), созданная С. В. Плаховым и Г. Л. Покаташкиным. Современная версия библиотеки предоставляет развитый сервис, обеспечивающий выполнение различных функций по манипуляциям с грамматическими формами антропонимов, названий структурных подразделений и должностей. Библиотека имеет довольно продолжительную историю развития и покрывает основной спектр потребностей разработчиков информационных систем, в том числе и многочисленные исключения.
Для предоставления оператору возможности настройки способа склонения отдельных антропонимов или их групп предусмотрено подключение к библиотеке специального файла исключений. Файл исключения помещается в определенное место на жестком диске или в локальной сети (путь к нему указывается в реестре Windows). Исключения в файл может записывать как администратор, так и сама библиотека, для чего в ней предусмотрены специальные методы. Файл содержит 16 секций, каждая из которых посвящена отдельной категории исключений:
1. [LastName] — помещенные в эту секцию фамилии не преобразуются для любого рода, в том числе и при использовании в качестве первых частей составных фамилий.
2. [LastNameW] — помещенные в эту секцию фамилии не преобразуются для женского рода, в том числе и при использовании в качестве первых частей составных женских фамилий.
3. [DependedLastNameW] — женские фамилии (как правило на «-ина») склонение которых зависит от склонения соответствующей мужской фамилии. Например, женской фамилии «Щербина» могут соответствовать мужские фамилии «Щербина» и «Щербин».
4. [FirstNameM] — несклоняемые мужские имена
5. [FirstNameW] — несклоняемые женские имена
6. [FirstPartLastName] — несклоняемые первые части составных фамилий обоих родов. При использовании в качестве отдельной фамилии, фамилии из этой секции могут изменяться, если это разрешено правилами, и они не входят в состав других секций.
7. [BaseNonRussian] — фамилии, имеющие не славянские (или не русские) корни на «-ов», «-ин», «-их» («Бюлов», «Рабин», «Либих» и т.д.), которые должны преобразовываться при склонении и при этом не присутствуют в других секциях.
8. [NonLeaveVocalic] — фамилии на «-ок», «-ец» при склонении которых не происходит выпадения гласной («Корешок» — «Корешока», ср. «Корешка»).
9. [FirstNameParallelForms] — список параллельных форм мужских имен на –«о(а)». («Михайло» — «Михайла»).
10. [Accent] — женские имена на «-ия», мужские фамилии на «-ец» и фамилии обоих родов на «-а» с предшествующей шипящей, у которых окончание в родительном, творительном и предложном падежах зависит от положения ударения.
11. [NonAdjective] — слова на «-ая», «-яя», «-ее», «-ие», «-ий», «-ое», «-ой», «-ые», «-ый» не являющиеся прилагательными. Как правило, это существительные в именительном и творительном падежах.
12. [NonDeclBeforeHyphen] — несклоняемые части составных слов.
13. [HyphenAbbreviation] — сокращения существительных дефисом.
14. [PointAbbreviation] — сокращения существительных точкой.
15. [Plural] — существительные во множественном числе.
16. [OfficeNoLowerCase] — первое слово в наименовании подразделения, которое не надо приводить к нижнему регистру при формировании полной должности.
Помимо использования файла исключений библиотека поддерживает, так называемый, символ ударения, который помогает ей уточнить способ склонения определенного класса антропонимов. Ударная гласная выделяется непосредственно в строке антропонима с помощью специального настраиваемого символа.
Библиотека позволяет склонять антропонимы, задаваемые как по отдельности, так и единой строкой, способна определять автоматически пол носителя антропонима, корректно обрабатывает инициалы и неверный регистр букв, позволяет получать формы косвенных падежей наименований должностей и структурных подразделений, а также восстанавливать начальные форм из форм косвенных падежей. В Таблице 2 перечислены функции, предоставляемые библиотекой.
Табл. 2. Функции, предоставляемые библиотекой «paged.dll»
Функция библиотеки Назначение функции
GetFIOPadeg Возвращает строку – результат склонения фамилии, имени и отчества заданного рода в заданный падеж
GetFIOPadegFS Возвращает результат склонения фамилии, имени и отчества, заданных одной строкой, заданного рода в заданный падеж
GetIFPadeg Возвращает результат склонения имени и фамилии заданного рода в заданный падеж
GetIFPadegFS Возвращает результат склонения имени и фамилии, записанных одной строкой, заданного рода в заданный падеж
GetNominativePadeg Функция выполняет восстановление именительного падежа для ФИО, заданного в произвольном падеже в формате “Фамилия Имя Отчество”
GetAppointmentPadeg Возвращает результат склонения наименования должности в заданный падеж
GetFullAppointmentPadeg Возвращает результат склонения объединения наименований должности и подразделения в заданный падеж
GetOfficePadeg Возвращает результат склонения наименования подразделения, записанного одной строкой, в заданный падеж
GetSex Возвращает число – род ФИО
GetPadegID Возвращает число, номер падежа ФИО, записанного в произвольном падеже одной строкой

Библиотека «padeg.dll» представляет собой как классическую динамически подключаемую библиотеку (DLL) Windows, так и COM-сервер, что дает возможность подключать ее к широкому спектру программного обеспечения, созданного для разнообразных версий операционных систем семейства Microsoft Windows. Использование библиотеки в других операционных системах не предусмотрено, хотя, при приобретении ее исходных кодов, решение этой задачи представляется вполне возможным.
На официальной странице библиотеки приводится довольно подробное описание функций библиотеки, принципов ее работы, а также даются примеры подключения ее к различным платформам. На сайте имеются примеры интеграции библиотеки со следующими технологиями программирования:
 Microsoft Visual Basic / Visual Basic for Applications (VB/VBA);
 Microsoft Visual FoxPro (VFP);
 Microsoft Excel;
 Microsoft Word;
 Oracle Database (интеграция через пакет PL/SQL);
 Языки C/C++ (файл заголовка для компоновки во время компиляции и для динамической компоновки);
 Oracle Forms (шлюз «*.pll», скомпилированный и исходные коды);
 Object Pascal/Delphi;
 Microsoft SQLServer 2000 (исходные файл шлюза, SQL-скрипты и специальная версия DLL);
 Шаблон Microsoft Word;
 .NET (обертка для библиотеки на языке C#);
 1С:Предприятие.
Помимо этого, в сети Интернет можно встретить довольно много примеров интеграции библиотеки с самыми разными технологиями разработки программного обеспечения.
В условиях доминирования на территории Российской Федерации продуктов фирмы «1С», весьма актуальной оказалась задача интеграции библиотеки «padeg.dll» с платформой «1С:Предприятие». Для решения этой задачи было разработано сразу несколько решений. Наиболее полным следует признать проект «Сервис поддержки склонений для 1С» («ndeclin.dll»). На страницах сайта проекта приводится два способа интеграции «paged.dll» с платформой «1С:Предприятие»:
1. Использование внешней компоненты 1С «Сервис поддержки склонений ФИО для V7» (V7 Name Declension Support, V7NDS), предоставляющей удобный доступ к функциям библиотеки изнутри платформы. Схематически этот способ показан на Рисунке 2.

Рис. 2. Схема взаимодействия платформы 1С:Предприятие
с библиотекой “padeg.dll” посредством шлюза “NDeclin.dll”
2. Использование самой «paged.dll» в качестве COM-сервера, как показано на Рисунке 3.

Рис. 3. Схема взаимодействия платформы 1С:Предприятие
с библиотекой “padeg.dll” в качестве COM-сервера
Отмечается, что первый способ предпочтительнее, поскольку позволяет корректно работать с клиент-серверными конфигурациями платформы, а также содержит удобные средства настройки работы библиотеки прямо из среды 1С. На Рисунке 4 показано окно настройки параметров работы библиотеки в среде 1С.

Рис. 4. Окно настройки параметров работы библиотеки “padeg.dll”
из среды 1С:Предприятие через шлюз “NDeclin.dll”
Ранее на сайте проекта имелся сервис для онлайн-тестирования библиотеки, однако в настоящее время он недоступен.
Файл библиотеки «padeg.dll» в различных комплектациях можно встретить во многих местах сети Интернет. На официальной страницы проекта имеется файл с текстом лицензии на использование библиотеки, а также прайс-лист, из которого можно узнать, что стоимость библиотеки для коммерческого использования составляет 500 рублей, а для корпоративного коммерческого использование – 1000 рублей. Корпоративное использование дает преимущество в обращении к авторам за технической поддержкой. Из приведенной информации можно сделать вывод, что для некоммерческого использования (без извлечения выгоды) библиотека предоставляется бесплатно. Возможно также приобретение исходных кодов библиотеки за 1000 рублей.
Библиотека «Morpher.NET».
Программа автоматического склонения «Morpher» представляет собой библиотеку платформы Microsoft.NET, реализующую функции склонения именных конструкций и вывода чисел прописью. Автор библиотеки Сергей Слепов. На сайте проекта приводятся временные характеристики работы библиотеки, а также исходные коды примеров ее интеграции с приложениями .NET. Исходных кодов библиотеки на сайте нет, как и информации о возможности их получения и стоимости как исходных кодов так и библиотеки. Имеется доступ к сервису онлайн-тестирования библиотеки. Даже неприцельное тестирование работы сервиса показывает недостаточную проработанность библиотеки, которая, возможно, является следствием ее относительной молодости. Автор решения пытается разработать алгоритм склонения для любого словосочетания, не запрашивая дополнительной информации о нем. С нашей точки зрения, существующий уровень развития вычислительной техники и уровень изученности русского языке недостаточны для общего решения данной задачи за приемлемую стоимость.
Алгоритм «Падеж» Юрия Железнякова.
Алгоритм склонения антропонимов «Падеж», созданный Юрием Железняковым, является старейшим алгоритмом подобного рода. Как признают авторы проекта NDecline, этот алгоритм послужил отправной точкой для разработки компоненты V7NDS. В сети Интернет приводится множество вариантов реализации данного алгоритма. На официальной странице автора имеются реализации для следующих технологий разработки программного обеспечения:
1. Object Pascal/Delphi,
2. Microsoft Visual Basic/Visual Basic for Applications,
3. 1C:Предприятие,
4. Microsoft FoxPro 2.6 (два варианта),
5. Microsoft Visual FoxPro.
Исходные коды для всех технологий абсолютно доступны и относительно компактны, хотя принцип их работы уловить трудно. Неясны также условия их использования, распространения и модификации.
Алгоритм «SQL.RU».
На форуме «Oracle-Склонение фамилий» сайта SQL.RU записан ход совместной разработки рядом авторов пакета для склонения антропонимов на языке Oracle PL/SQL. Различные версии исходного кода доступные на страницах форума. Использование данного пакета позволяет осуществлять склонение непосредственно внутри системы управления базами данных Oracle, работающей на любой операционной системе.
2.1.5. Сравнение рассмотренных решений
В Таблице 3 приводится формальное сравнения перечисленных решений.
Табл. 3. Сравнение программных компонентов
для склонения именных грамматических конструкций
Критерий padeg.dll Morpher Падеж SQL.RU
Признание сообществом Да Да
Технология Windows/
COM .NET Delphi, VB, FoxPro, 1C PL/SQL
Исходный код За плату Нет информации Имеется Имеется
Пример интеграции Word, Excel, VB, VBA, VFP, Delphi, C, C++, .NET, 1C, PL/SQL, Oracle Forms, MS SQL .NET (C#) Delphi, VB, FoxPro, 1C Oracle DBMS
Официальная страница Есть Есть Есть Нет
Операционные системы Windows .NET/Mono Windows Oracle
Склонение фамилий Да Да Да Да
Склонение отчеств Да Да Да Да
Склонение имен Да Да Да Да
Учет инициалов Да Нет Да Да
Склонение наборов антропонимов Да Да Да Да
Склонение наименований должностей Да Да Нет Нет
Склонение наименований подразделений Да Да Нет Нет
Определение пола носителя антропонима Да Нет Нет Нет
Определение падежа по строке Да Нет Нет Нет
Восстановление именительного падежа из косвенного Да Нет Нет Нет

В сети Интернет можно обнаружит еще несколько менее популярных программ, предназначенных только для решения задачи склонения антропонимов. Несмотря на это, можно прийти к выводу, что номенклатура таких средств сравнительно бедна. При этом имеется явный лидер – «padeg.dll», не обладающий таким важным в настоящее время качеством, как кроссплатформенность, хотя и предоставляющий для изучения исходный код за дополнительную плату.
К сожалению, нам не удалось ознакомиться с алгоритмами склонения именных конструкций встроенными в популярные отечественные платформы разработки информационных систем по причине их недоступности для тестирования.
2.1.6. Недостатки существующих решений
Решения, встроенные в коммерческие информационные системы, как правило, отличаются отсутствием гибкости в настройке для получения необычных форм для конкретных случаев. Этот недостаток обычно усугубляется невозможностью редактирования полученного печатного варианта документа, что создает дополнительные трудности при использовании в документах трудноизменяемых (склоняемых неочевидно или вопреки правилам) фрагментов.
Закрытые компоненты предоставляют большую гибкость и во многих случаях являются оптимальным решением. Однако наиболее подходящий из них – «padeg.dll» работоспособен исключительно в среде Microsoft Windows и не рассчитан на работу на других платформах, что особенно неприятно в свете наметившейся тенденции перехода крупных организаций на Unix-подобные системы. Кроме того, он жестко навязывает способ обработки исключений, требует модификации начальной формы антропонима для уточнения ударения и предполагает грамматическую уникальность фамилий (не отличает Федора Чаплина от Чарльза Чаплина). Эти особенности могут привести к отказу от использования библиотеки. Более или менее крупное предприятие, благодаря невысокой стоимости исходных кодов библиотеки, может разработать модифицированную версию библиотеки с учетом собственных потребностей.
Два обнаруженных нами открытых алгоритма могут послужить стартом для разработки собственного программного решения, однако не предусматривают обработки исключений и вообще не реализуют склонения наименований должностей и структурных подразделений.
Все остальные обнаруженные открыто опубликованные алгоритмы носят фрагментарный характер. Они работают лишь с отдельными категориями изменяемых фрагментов. Некоторые из них не позволяют получить всего спектра необходимых форм (например, выдают только родительный и винительный падеж). Значительная часть алгоритмов не имеет установившегося «места прописки» и встречается в разных вариантах в разных местах сети, что затрудняет определение среди них наиболее свежей версии и не дает возможности оперативно обратиться к автору за технической поддержкой. Исходный код некоторых из этих алгоритмов крайне слабо документирован, что крайне затрудняет понимание принципов их работы.
В свете сказанного нами были разработаны открытые и общедоступные алгоритмы склонения наиболее востребованных категорий изменяемых фрагментов трафаретного текста, применяемых в отечественном документировании. Знакомство с данными алгоритмами позволит разработчикам информационных систем снизить время и материальные расходы на программирование, а также избежать некоторых неочевидных «ловушек» при разработке своих компонентов. Эти алгоритмы специально создавались нами по «школьной» методике без использования специфических особенностей языков программирования и неочевидных эффектных приемов. Такой подход, на наш взгляд, допускает простой перевод алгоритмов на любой язык программирования. Перевод может быть легко осуществлен программистом средней квалификации в течение двух-трех рабочих дней. В качестве иллюстрации одного из возможных способов использования разработанных алгоритмов нами проведена интеграция его референтной реализации с подсистемой управления персоналом автоматизированной информационной системы ОАО «Акрон».
2.2. Разработка алгоритмов автоматического склонения антропонимов, наименований должностей и структурных подразделений с учетом русскоязычной традиции
2.2.1. Пакет «jz-decliner»
Области применения разработанного пакета.
Для облегчения разработки информационных систем, включающих функции автоматизированной подготовки документов с трафаретным текстом, нами был разработан набор базовых алгоритмов, позволяющих легко получать неосновные формы изменяемых фрагментов трафаретного текста. Алгоритмы реализованы в виде пакета Java под названием «jz-decliner». Исходные тексты пакета опубликованы под открытой лицензией типа BSD и помещены на один из web-сайтов, созданных для поддержки инициатив по разработке программного обеспечения с открытыми исходными кодами.
Пакет «jz-decliner» можно применять целиком или частично по своему усмотрению для поддержки корпоративных информационных систем, имеющих потребность в выводе печатных форм документов с трафаретным русскоязычным текстом. К таким системам относятся все системы, связанные с учетом персонала и предполагающие автоматизированную подготовку распорядительных документов по управлению персоналом. Полезным этот пакет может также оказаться для разработчиков систем генерирующих, списки почтовых рассылок и наклейки на конверты, где требуется указывать имя получателя в дательном падеже, и систем, связанных с выдачей доверенностей, учетом материальной ответственности и подготовкой других документов.
Пакет «jz-decliner»реализует следующие алгоритмы:
1. Получение форм всех падежей единственного числа русскоязычной фамилии с учетом пола ее носителя и наиболее важных особенностей, не определяемых на основании данных самой фамилии.
2. Получение форм всех падежей единственного числа русскоязычного имени с учетом пола его носителя и наиболее важных особенностей, не определяемых на основании данных самого имени.
3. Получение форм всех падежей единственного числа русскоязычного отчества с учетом пола его носителя и случаев несклоняемых «псевдоотчеств».
4. Получение форм всех падежей единственного числа наименования должности сотрудника с учетом особенностей, не определяемых самим наименованием должности.
5. Получение форм всех падежей единственного числа наименования структурного подразделения с учетом особенностей, не определяемых самим наименованием структурного подразделения.
В дальнейшем пакет планируется расширить реализациями следующих алгоритмов:
1. Разделение русскоязычной строки на части для «мягкого» переноса.
2. Получение всех падежей единственного числа местоимения в зависимости от пола его носителя.
3. Получение строкового представления произвольной даты, пригодного для использования в качестве реквизита документа.
4. Получение строкового представления числа, в виде, пригодном для использования в качестве реквизита документа, выражающего сумму прописью.
Особенности исходного кода пакета.
При разработке пакета «jz-decliner» мы стремились сделать исходный код максимально простым, понятным и очевидным (иногда в ущерб производительности). Мы избегали применения специфических особенностей языка, чтобы созданный код мог быть легко перенесен на любую платформу программистом средней квалификации. Исходный код снабжен обильными комментариями, что позволяет сравнительно легко разобраться в назначении и принципе работы любой части кода. В аннотацию к пакету включен своего рода путеводитель, позволяющий легко найти фрагмент кода, отвечающий за обработку конкретной категории фрагмента трафаретного текста. Это позволяет при переносе алгоритма на другую платформу сразу перейти к кодированию, не теряя времени на разбор и удаление синтаксической «шелухи» референтной реализации.
Преимущества языка Java.
Для базовой реализации алгоритмов был выбран язык Java. Основные причины выбора этого языка следующие:
 Значительное время нахождения языка на рынке (большая численность сообщества, использующего язык);
 Кроссплатформенность (программа на Java теоретически может выполняться в любой операционной системе, практически же количество совместимых с Java систем составляет несколько десятков);
 Классичность языка (язык не предусматривает «неожиданных» и специфических синтаксических конструкций, что дает возможность легкого построчного перевода программы на Java на любой другой классический язык программирования);
 Совместимость со значительным количеством платформ для разработки информационных систем масштаба предприятия.
 Распространенность платформы (реализации Java имеются для всех популярных настольных и серверных операционных систем общего назначения, кроме того, во всем мире растет использование открытых операционных систем и гетерогенных сред, в такой обстановке хорошо стандартизированная платформа Java является средой разработки корпоративных приложений практически не имеющей конкуренции).
Способы интеграции пакета с информационными системами.
Поскольку реализация разработанных алгоритмов оформлена в виде пакета Java, они могут быть легко интегрированы с любой системой, работающей на платформе Java. Кроме того, значительная часть крупных информационных систем использует в качестве хранилища данных СУБД Oracle, которая поддерживает среду выполнения классов Java прямо внутри базы данных. Это дает возможность использовать разработанный пакет внутри СУБД, совершенно не затрагивая программную часть системы.
Разработанный пакет можеть быть интегрирован с существующими информационными системами следующим образом:
1. Если информационная система работает на платформе Java, интеграция заключается в подгрузке к среде выполнения архива пакета и вызова классов пакета при необходимости из модуля генерации отчетов или из модуля подготовки данных для генерации отчетов;
2. Если информационная система использует СУБД Oracle, пакет может быть полностью или частично загружен прямо в базу данных и после создания специальных функций-оберток использоваться внутри нее при выполнении запросов на выборку информации;
3. В иных случаях алгоритмы, реализованные в пакете, могут быть построчно переведены на «родной» язык конкретной информационной системы. Для этого при разработке пакета были приняты определенные меры (использование простых конструкций, очевидность и тривиальность алгоритмов, открытость исходных кодов, обильные комментарии, наличие путеводителя). Практика показывает, что перевод всех алгоритмов, реализованных в пакете, занимает у программиста средней квалификации два-три рабочих дня. Кроме того, нами создана специальная тестовая база данных, содержащая образцы изменения большого количества фрагментов трафаретного текста различных категорий. Эта база данных выложена в свободный доступ и может использоваться для тестирования различных реализаций подобных алгоритмов. При переводе алгоритма на другие языки программирования эта база данных поможет быстро проверить корректность работы полученной реализации и, при необходимости, локализовать возникающие ошибки.
Способ распространения пакета.
Текущая версия пакета «jz-decliner» помещена для свободного доступа на сайт SourceForge (проект «russian-names-decliner») . На странице проекта имеется возможность получить как готовый двоичный файл пакета, так и его исходные коды, а также документацию, компоненты для создания инфраструктуры тестирования правильности работы пакета и сторонних программных решений сходной функциональности.
Пакет «jz-decliner» и все сопутствующие компоненты доступны всем желающим на условиях открытой лицензии типа BSD. Согласно этой лицензии допускается использование всех частей пакета вместе и по отдельности любым способом, коммерческим и некоммерческим. Также можно свободно модифицировать код модулей проекта и распространять его в начальной или измененной форме в составе собственных продуктов. При создании собственных модификаций модулей пакета требуется указывать изначальное авторство модуля, но при этом запрещается использовать имя разработчиков пакета для рекламы продуктов, созданных на основе пакета.
Лицензия типа BSD была выбрана нами, поскольку она налагает на пользователя гораздо меньше ограничений, чем распространенные Copyleft-лицензии (например, GPL и GPLv2), а также устраняет зависимость продукта от первоначального разработчика (в отличие от лицензий типа Apache и CDDL) .
Преимущества пакета «jz-decliner».
По сравнению с решениями, обнаруженными нами ранее в сети Интернет, разработанный нами пакет имеет следующие преимущества:
1. Абсолютная бесплатность;
2. Полная доступность исходных кодов;
3. Наличие лицензии, определяющей условия использования пакета;
4. Наличие постоянного адреса нахождения пакета в Сети;
5. Наличие готовой инфраструктуры для тестирования как самого пакета, так и сторонних реализаций на его основе;
6. Потенциальная возможность формирования сообщества пользователей для развития и тестирования пакета;
7. Наличие инфраструктуры для поддержки жизненного цикла пакета (предоставляемой сайтом SourceForge).
2.2.2. Разработка алгоритма автоматического склонения фамилий и личных имен (антропонимов)
Наиболее востребованным из предлагаемых пакетом «jz-decliner» решений является возможность получения косвенных форм русскоязычных фамилий и личных имен. Для реализации этой возможности нами были разработаны универсальные алгоритмы для решения следующих задач:
1. Получение всех форм единственного числа мужской фамилии;
2. Получение всех форм единственного числа женской фамилии;
3. Получение всех форм единственного числа мужского личного имени;
4. Получение всех форм единственного числа женского личного имени;
5. Получение всех форм единственного числа мужского отчества;
6. Получение всех форм единственного числа женского отчества.
Исходными данными для работы всех шести алгоритмов является форма именительного падежа единственного числа соответствующего антропонима и, при необходимости, дополнительная информация для определения неочевидных особенностей склоняемого антропонима. На выходе каждый алгоритм дает структуру, условно названную нами «парадигма» и состоящую из шести форм склоняемого антропонима, соответствующих основным падежам русского языка и дополнительных данных, несущих сведения о типе антропонима, определенном алгоритмом и используемых для отладки алгоритма.
Общей чертой рассматриваемых алгоритмов является то, что они работают с морфологически однородными монолитными конструкциями, которые состоят из одного слова или из группы аналогичных одинаково обрабатываемых слов. Следовательно, антропонимы не требуют отдельного синтаксического анализа, что существенно облегчает создание алгоритма и повышает его надежность и предсказуемость.
При тестировании разработанных алгоритмов на данных реальной информационной системы нами было отмечено крайне низкое качество входных данных. Так очень часто встречаются нарушения регистра символов (например, антропоним начинается со строчной буквы или имеет в своем составе несколько прописных букв). Кроме того, часто встречаются случаи гомоглифии – неверного использования сходных по начертанию знаков разных письменностей (например, латинских «ABCEHKMOPTXaceopxy» вместо соответствующих русских «АВСЕНКМОРТХасеорху»). Хотя для человека, читающего текст, наличие гомоглифия не имеет никакого значения, для информационной системы она представляет серьезную проблему, поскольку современные программы не учитывают сходство начертания символов, а оперируют исключительно их позициями в соответствующих алфавитах. Гомоглифия не обнаруживается визуально, и с трудом распознается даже специально разработанными компонентами самой информационной системой.
Данные особенности входных данных требуют предварительной их обработки перед подачей на вход рассматриваемых алгоритмов. Случаи неверного использования регистра букв нами решено было проигнорировать, поскольку его соблюдение – один из внешних признаков качества данных в информационной системе, заботиться о котором, несомненно, надлежит структурам, разрабатывающим и эксплуатирующим систему. Возможные же случаи гомоглифии учитываются нашими алгоритмами, поскольку не могут быть легко обнаружены эксплуатантами системы, а, кроме того, требуют проведения отдельных систематических мероприятий по их искоренению. Гомоглифия в антропонимах преодолевается сравнительно легко, поскольку мы предполагаем, что все антропонимы, в соответствии с текущим законодательством, кодируются буквами русского алфавита. В более сложных конструкциях, к которым относятся наименования должностей и подразделений, требуется более сложная обработка, поскольку в них могут встречаться правильные слова на основе латинского алфавита. В этом случае приходится искать слова, смешивающие символы разных алфавитов и определять, к какому алфавиту изначально относилось слово (сейчас это делается по наличию в слове уникальных для конкретных алфавитов (автохтонных) символов), после чего восстанавливать само слово. Такой способ не дает полной гарантии правильности обработки, поскольку могут встретиться слова, не содержащие автохтонных символов, особенно в аббревиатурах (например, «оператор BBC»). Экстремальный случай проявления гомоглифии можно видеть на Рисунке 5, отражающем состояние данных в информационной системе реального предприятия.

Рис. 5. Гомоглифия в справочнике групп персонала информационной системы
(инверсией выделены буквы латинского алфавита)
Каждый из рассматриваемых алгоритмов состоит из следующих частей:
1. Восстановление введенного значения путем подмены гомоглифов соответствующими символами русского алфавита;
2. Разбиение сложных антропонимов на набор более простых (границами простых антропонимов считаются пробелы и дефисы);
3. Получение форм косвенных падежей каждого простого антропонима, которое состоит из следующих этапов:
a) Определение типа склонения антропонима путем анализа его окончания и дополнительной информации, если она была получена вместе с антропонимом;
b) Формирование парадигмы каждого простого антропонима;
4. Объединение парадигм простых антропонимов в составную парадигму исходного антропонима.
Самый сложный шаг этой группы алгоритмов – шаг №3, реализация которого зависит от типа обрабатываемого антропонима.
Для реализации склонений фамилий и личных имен мы воспользовались классификацией антропонимов по типам склонения, предложенной Л. П. Калакуцкой . В своих работах она рассматривает и фамилии и личные имена совместно, выделяя и для тех и для других общие группы склонений. Мы же, с целью внесения ясности, рассматриваем группы склонений и имен и фамилий отдельно, даже если они дублируются. Кроме того, для удобства мы различаем мужские и женские антропонимы и, соответственно, рассматриваем отдельно группы склонения для женских и мужских личных имен и фамилий. Возможно, такой подход приводит к избыточности программного кода, иногда дублирующегося для различных категорий антропонимов, однако разобраться в нем, при этом, гораздо проще, чем, если бы он был общим для всех групп антропонимов.
Склонение отчеств, благодаря их однородности, трудностей не представляет.
В процессе работы нами был выявлены особенности, влияющие на способ склонения антропонимов, но не вычисляемые путем анализа написания антропонима. Рассмотрим такие особенности для каждой группы антропонимов:
Фамилии:
1. Несклоняемость. Принудительно определяет несклоняемость фамилии. Например, французские фамилии типа «Дюма» и «Ферма», должны иметь такой признак.
2. Ударение на последний слог. Отличает фамилии «Калач»  кем «Калачом» от «Томаш»  кем «Томашем»;
3. Отсутствие беглых гласных. Отличает западную фамилию типа «Кравец»  кого «Кравеца» от восточной «Кравец»  кого «Кравца»;
4. Иноязычное происхождение. Отличает фамилию кто «Чарльз Чаплин»  кем «Чарльзом Чаплином» от «Иван Чаплин»  кем «Иваном Чаплиным».
Личные имена:
1. Несклоняемость. Принудительно определяет несклоняемость личного имени.
2. Ударение на последний слог. Важно для некоторых женских имен, позволяет отличить «Зульфия»  кому «Зульфие» от «Мария»  кому «Марии».
3. Отсутствие беглых гласных.
Отчества:
1. Несклоняемость. Принудительно определяет несклоняемость отчества (может применяться для «псевдоотчеств» типа литовских «Прано», «Видманто» и т. п., хотя такие случаи должны определяться алгоритмом автоматически).
Способы получения форм косвенных падежей для каждого из выделенных нами классов антропонимов приводятся в приложениях к данной работе:
1. Получение всех форм единственного числа мужской фамилии (класс «SurnameMasculine») в Приложении 3.
2. Получение всех форм единственного числа женской фамилии (класс «SurnameFeminine») в Приложении 4.
3. Получение всех форм единственного числа мужского личного имени (класс «PersonalNameMasculine») в Приложении 5.
4. Получение всех форм единственного числа женского личного имени (класс «PersonalNameFeminine») в Приложении 6.
5. Получение всех форм единственного числа мужской или женского отчества (класс «Patroname») в Приложении 7.
Предполагается, что на вход каждого алгоритма поступает форма именительного падежа единственного числа антропонима, а также необходимые дополнительные особенности склонения. Для иллюстрации алгоритмов в приложениях нами используется специальный псевдокод, не столь точный и детальный, как классические языки программирования, но позволяющего понять основные шаги работы алгоритмов. Кроме того, мы считаем непосредственное формирование выходных форм антропонимов задачей тривиальной и зависящей от способа реализации программы, поэтому основное внимание в приведенных в приложениях листингах уделяется определению способа склонения соответствующего антропонима.
Мужская фамилия является наиболее сложным для склонения антропонимом. Причина этого в том, что фамилия носит выраженные черты сразу нескольких частей речи и, следовательно, склоняется по нескольким типам (иногда как существительное, иногда как прилагательное).
Женская фамилия, с точки зрения автоматического склонения, гораздо проще мужской. Л. П. Калакуцкая считает это следствием того, что она оформилась в языке гораздо позже мужской . Склоняются только фамилии, потенциальный род которых совпадает с полом носителя, то есть оканчивающиеся на «-а» и «-я». Остальные женские фамилии считаются грамматически неправильными и не склоняются.
Отчество является самым простым для автоматического склонения антропонимом. Отчество настолько специфично для русского языка, что имеет только по одному типу для каждого рода (оканчивающиеся на «-ич» для мужского и на «-на» для женского). Все слова, которые выходят за рамки этих двух типов, считаются несклоняемыми. Интересно, что отчество физического лица часто используется в автоматизированных системах для контроля правильности указания пола.
Для оценки качества разработанных алгоритмов нами применялась одна из методик экстремального программирования – разработка через тестирования. Суть этой методики состоит в том, что перед созданием кода, решающего задачу, следует подготовить специальную дополнительную программу, вызывающую разрабатываемый код и проверяющую правильность его работы на заранее известных значениях. Проверяющая программа, или тест-юнит, имеет в своем распоряжении список заранее подготовленных вручную тестовых значений, которые она передает тестируемому коду, а затем сравнивает полученные значения с также известными ей заранее эталонными результатами. Как только результат обработки всех входных данных, обрабатываемых тест-юнитом, совпадет с известными ему эталонными значениями, задача считается решенной. При каждой модификации алгоритма, для контроля его правильности, достаточно вновь выполнить тест-юнит и убедиться в его корректной работе. Такой способ контроля качества весьма затруднителен для программ, рассчитанных на интенсивный ввод данных пользователем, однако идеально подходит для случаев разработки программных модулей, работающих внутри системы и не общающихся с пользователем напрямую (что соответствует нашему случаю).
Для тестирования разработанных нами реализаций алгоритмов мы создали специальную тестовую базу данных, содержащую около 3000 фамилий, 600 личных имен и 1000 отчеств. Помимо форм именительного падежа всех перечисленных антропонимов, в базу данных включена также информация о биологическом поле носителя каждого антропонима и, в некоторых случаях, дополнительная информация о правилах склонения конкретных антропонимов. База данных была создана на основе данных информационной системы по учету персонала реально существующего предприятия, однако, поскольку перечисленные антропонимы не связаны между собой и не ассоциируются с какими-либо другими данными, правила работы с персональными сведениями при составлении базы данных нарушены не были. К каждому антропониму, в базе данных привязана парадигма, ожидаемая при выполнении автоматического склонения антропонима.
Для выполнения самого тестирования в дополнение к базе данных нами была разработана простое web-приложение, выполняющее функцию набора тест-юнитов. Приложение состоит из нескольких JSP-страниц, часть из которых позволяет получать результаты склонения антропонимов, вводимых пользователем вручную, а часть проверят правильность обработки пакетом всех записей в базе данных. JSP-страница перебирает записи в базе данных для определенного класса антропонимов и для каждой из их вызывает соответствующую функцию склонения из тестируемой версии пакета «jz-decliner». После получения от пакета результата обработки, JSP-станица сравнивает его с эталонными значениями, хранящимися в той же базе данных. Результат сравнения попадает в поток выходных данных. По окончании работы пользователь получает таблицу, в каждой строке которой отображается правильность обработки пакетом каждого антропонима из тестовой БД. Пример таблицы приведен на Рисунке 6. В конце таблицы приводятся статистические данные, собранные за время работы тест-юнита. Благодаря этим данным, пользователь может оценить сколько антропонимов было обработано, сколько из них пакет просклонял правильно, сколько неправильно, для скольких антропонимов не было обнаружено эталонных значений результатов, сколько антропонимов потребовали указания дополнительных правил склонения. Таким образом, разработчик наглядно может контролировать эффективность и правильность работы реализованного им алгоритма.

Рис. 6. Результат работы JSP-страницы для тестирования
правильности склонения фамилий
Тестовые прогоны разработанных алгоритмов на базе данных эталонных образцов дали результаты, показанные в Таблице 4. Образцы, обработать которые алгоритмы изначально оказались не в состоянии, были дополнены нами уточняющими сведениями, после чего их обработка произошла успешно.
Табл. 4. Результаты обработки алгоритмами склонения антропонимов базы данных эталонных образцов
Показатель Фамилии Личные имена Отчества
Количество в базе данных 5809 470 550
Обработано правильно 5809 470 550
Потребовало дополнительной настройки 50 9 0

Для сравнения разработанного пакета алгоритмов с аналогичными алгоритмами, заложенными в наиболее популярном программном компоненте для склонения антропонимов «padeg.dll» нами было проведено сравнительное тестирование на той же эталонной базе данных, результаты которого показаны в Таблице 5.
Табл. 5. Сравнение результатов работы алгоритмов
склонения антропонимов пакета «jz-decliner» и библиотеки «padeg.dll»
Показатель jz-decliner padeg.dll
Фамилии
Количество в базе данных 5809 5809
Обработано правильно 5809 5751
Потребовало дополнительной настройки 50
Имена
Количество в базе данных 470 470
Обработано правильно 470 460
Потребовало дополнительной настройки 9
Отчества
Количество в базе данных 550 550
Обработано правильно 550 547
Потребовало дополнительной настройки 0

Из приведенных данных можно сделать вывод, что разработанные нами алгоритмы, со своей задачей справляются, как минимум, не хуже некоторых распространенных платных аналогов.
2.2.3. Разработка алгоритма автоматического склонения наименований должностей
Помимо алгоритмов получения форм антропонимов, весьма востребованным является алгоритм получения форм наименований должностей. В отличие от грамматически простых (односоставных) антропонимов, наименование должности представляет собой сложную конструкцию, напоминающую словосочетание.
В общем случае наименование должности состоит из определения (обычно представляющего собой прилагательное или причастие), подлежащего (выраженного существительным) и дополнения. Например, «старший мастер котельного участка». Определение и дополнения в некоторых должностях могут быть опущены. При склонении наименования должности изменению подлежат только определение и подлежащее. Дополнение остается неизменным, поскольку изначально находится в родительном падеже. Таким образом, алгоритм склонения наименования должности должен представлять собой целый комплекс алгоритмов, способный склонять и прилагательные и существительные, а, кроме того, и определять границы составных частей наименования должности.
Иногда на практике приходится сталкиваться с наименованиями должностей, представляющими собой конструкцию из нескольких наименований более простых должностей, разделенных каким-либо способом (например, дефисом). Например, «Главный специалист-заместитель руководителя управления». В таких случаях от алгоритма склонения требуется корректное определение границ простых должностей. Забегая вперед, отметим, что нами было принято решение избавить наш алгоритм от решения этой задачи за счет более качественной подготовки данных. Простые должности, поступающие на вход нашего алгоритма, должны разделяться уникальной последовательностью символов, употребляющейся только для этой цели, например, « – ».
Кроме того, некоторые наименования должностей содержат внутри себя дополнительные конструкции, заключенные в скобки. Эти конструкции могут играть роль определения, дополнения или вообще не быть грамматически связанными с основной частью наименования. Примеры: «старший мастер (имеющий квалификацию главного специалиста)»; «старший мастер по обработке шкур (лошадиных)»; «водитель автомобиля (Москвич-412)». Очевидно, что приведенные примеры нарушают некоторые принципы использования русского языка и построения наименований должностей, однако они и им подобные в изобилии встречаются в реальной жизни.
Далее остановимся на проблеме полноты наименования должностей. Наименование должностей в документе может использоваться как в объективном контексте, так и в субъективном. В субъективном контексте наименование должности может использоваться в неполной форме. Например: «направить в командировку машиниста автокрана 6 разряда». В тоже время в субъективном контексте предпочтительно использовать полную форму наименование должности. Например, если указанный сотрудник будет выступать в качестве лица, подписывающего документ, его должность должна выглядеть как «машинист автокрана 6 разряда автотранспортного цеха», то есть к собственно наименованию должности прибавляет наименование подразделения, в котором работает сотрудник. Наименование подразделения, в этом случае, используется в качестве дополнения и употребляется в родительном падеже.
Проанализировав некоторое количество реальных наименований должностей, можно прийти к выводу, что наименования должностей с точки зрения полноты можно разделить на три группы:
1. Неполные – то есть те, которые для употребления в субъективном контексте обязательно должны дополняться наименованием структурного подразделения. Например, «старший мастер», «начальник смены», «машинист автокрана». Результат конкатенации: «Старший мастер котельного участка», «Начальник смены цеха аммиака», «Машинист автокрана ремонтно-строительного цеха»;
2. Полные – те, которые могут употребляться в субъективном контексте без каких-либо дополнений. Например, «Генеральный Директор», «Главный инженер», «Управляющий по производству», «Главный бухгалтер». Конкатенация с наименованием подразделения не валидна: «Генеральный директор совета директоров», «Главный инженер группы главного инженера», «Управляющий по производству управления по производству», «Главный бухгалтер бухгалтерии»;
3. Частично полные – те, которые для употребления в субъективном контексте требуют дополнения частью наименования структурного подразделения. Например, «Руководитель управления», «Начальник цеха». Результат механического добавления к таким должностям наименования подразделения, как правило, выглядит странно: «Руководитель управления юридического управления», «Начальник цеха цеха сухого льда», «Начальник цеха железнодорожного цеха». По тому перед конкатенацией требуется тем или иным способом урезать наименование должности: «Руководитель [управления] юридического управления», «Начальник [цеха] цеха сухого льда», «Начальник [цеха] железнодорожного цеха».
Соответственно, для обработки наименований должностей требуется и механизм корректного дополнения, в случае необходимости, должности наименованием структурного подразделения.
Поскольку учет всех вышеизложенных нюансов в именовании должностей затруднителен даже для человека, разработка автоматизированного алгоритма для определения всех особенностей практически невозможна или, по меньшей мере, малоэффективна. Исходя из этого, разработанный нами алгоритм работает в несколько «тепличных» условиях. Он ожидает, что сложные наименования должностей разделены на более простые составляющие дефисом, обрамленным с обеих сторон пробелами. Конструкции, заключенные в скобки, по умолчанию, трактуются как дополнительные определения и склоняются. Для отмены их склонения требуется передача алгоритму определенного признака. Все наименования должностей по умолчанию считаются неполными, для полных и частично полных наименований должностей требуется указать соответствующий параметр. Считается, что наименование должности имеет правильное строение и определение идет всегда перед подлежащим, а дополнение – после подлежащего.
Такой алгоритм требует предварительной подготовки массива обрабатываемых данных (ревизии базы данных информационной системы), что, несмотря не некоторые затраты ресурсов, является хорошей и полезной практикой, так как повышает качество информации, которой оперирует информационная система.
Алгоритм склонения наименований должностей, как и алгоритмы склонения антропонимов, результат своей работы представляет в виде парадигмы грамматического имени с формами единственного числа. Как отмечалось выше, весь алгоритм распадается на ряд более частных алгоритмов. Общая схема их взаимодействия такова:
1. Выполняется членение наименования сложной должности на наименования простых должностей;
2. Каждое наименование простой должности разбивается на лексемы;
3. Для каждой лексемы определяется ее часть речи и синтаксическая роль и, при необходимости, производится ее склонение.
4. Результаты склонения лексем собираются в парадигму наименования простой должности;
5. Парадигмы наименований простых должностей собираются в парадигму наименования сложной должности.
Составляющие данную последовательность алгоритмы подробно рассматриваются в Приложении 7. Поскольку реализация способа членения наименования сложной должности на наименования простых должностей, с учетом заранее известной граничной последовательности символов, трудностей не вызывает, обзор начинается сразу с алгоритма членения наименования простой должности на лексемы.
Для оценки качества разработанного алгоритма нами, как и в случае с антропонимами, применялась разработка через тестирования.
На основе данных реального предприятия была создана база данных эталонных значений наименований должностей и разработан тест-юнит для ее обработки с помощью реализации алгоритма. В эталонной базе данных содержалось около 1400 наименований должностей. Помимо форм именительного падежа в базу данных включена также дополнительная информация, помогающая корректно обработать наименование должности. Такой дополнительной настройки потребовали 134 должности. К каждому наименованию должности в базе данных привязана парадигма, ожидаемая при его склонении.
Тест-юнит в виде JSP-страницы перебирает записи в базе данных и для каждой из их вызывает функцию склонения из разрабатываемого пакета. После получения от пакета результата работы, программа сравнивает его со значениями, хранящимися в эталонной базе данных. Результат сравнения программа выводит в web-браузер, как показано на Рисунке 7. Разработчик, таким образом, наглядно может контролировать корректность реализованного им алгоритма.

Рис. 7. Результат работы JSP-страницы, проверяющей корректность работы
алгоритма склонения наименований должностей
Как и в случае с антропонимами, нами было проведено сравнение разработанного алгоритма склонения наименования должностей с аналогичным алгоритмом библиотеки «padeg.dll». В результате сравнения выявлены результаты, показанные в Таблице 6.
Табл. 6. Сравнение результатов работы алгоритмов
склонения наименования должностей пакета «jz-decliner»
и библиотеки «padeg.dll»
Показатель jz-decliner padeg.dll
Количество в базе данных 1400 1400
Обработано правильно 1400 1226
Потребовало дополнительной настройки 134

Из данных таблицы видно, что рассмотренный алгоритм справляется с работой не хуже единственного доступного нам аналога «padeg.dll».
2.2.4. Разработка алгоритма автоматического склонения наименований структурных подразделений
Третьим востребованным алгоритмом, кроме алгоритмов по склонению антропонимов и наименований должностей, является алгоритм склонения наименований структурных подразделений.
По структуре наименование подразделения сильно напоминает наименование должности. Точно также, оно, в общем случае, может содержать определение, подлежащее и дополнение, например, «механический участок по ремонту оборудования». Принцип склонения наименований структурных подразделений, в общих чертах, такой же, как и в случае наименований должностей.
Есть и небольшие отличия. Наиболее важное из них состоит в том, что подразделения, в отличие от должностей, могут принадлежать к среднему грамматическому роду. Второе существенное отличие состоит в том, что подразделения, в отличие от должностей, являются неодушевленными объектами. Кроме того, сложившаяся отечественная практика допускает существование подразделений, называемых в формально множественном числе. Например, «биологические очистные сооружения». Все эти особенности требуют для обработки подразделения использовать особые версии алгоритмов склонения имен существительных и прилагательных.
С другой стороны, нам не встретилось ни одного подразделения со сложным названием. Следовательно, отпадает необходимость в членении сложного наименования на более простые составляющие. Также отсутствует и необходимость дополнять наименования подразделений, как неполные и частично полные наименования должностей.
Алгоритм склонения наименований структурных подразделений состоит из тех же шагов, что и алгоритм склонения наименований должностей. Подробно наиболее характерные его составляющие рассматриваются в Приложении 8.
Для оценки качества разработанного алгоритма нами, как и в предыдущих случаях, применялась разработка через тестирования.
На основе данных реального предприятия была создана база данных эталонных значений наименований структурных подразделений и разработан тест-юнит для ее обработки с помощью реализации алгоритма. В эталонной базе данных содержалось около 880 наименований структурных подразделений. Помимо форм именительного падежа в базу данных включена также дополнительная информация, помогающая корректно обработать наименование подразделения. Такой дополнительной настройки потребовали всего 4 наименования подразделений. К каждому наименованию подразделения в базе данных привязана парадигма, ожидаемая при его склонении.
Тест-юнит в виде JSP-страницы перебирает записи в базе данных и для каждой из их вызывает функцию склонения из разрабатываемого пакета. После получения от пакета результата работы программа сравнивает его со значениями, хранящимися в эталонной базе данных. Результат сравнения программа выводит в web-браузер, как показано на Рисунке 8. Разработчик, таким образом, наглядно может контролировать корректность реализованного им алгоритма.

Рис. 8. Результат работы JSP-страницы, проверяющей корректность работы
алгоритма склонения наименований структурных подразделений
Как и в предыдущих случаях, мы провели сравнение разработанного алгоритма склонения наименования подразделения с аналогичным алгоритмом библиотеки «padeg.dll». Результаты сравнения показаны в Таблице 7.
Табл. 7. Сравнение результатов работы алгоритмов
склонения наименования структурных подразделений
пакета «jz-decliner» и библиотеки «padeg.dll»
Показатель jz-decliner padeg.dll
Количество в базе данных 881 881
Обработано правильно 881 751
Потребовало дополнительной настройки 4

Из данных таблицы видно, что разработанный алгоритм справляется с работой не хуже единственного доступного нам аналога из библиотеки «padeg.dll».
Во второй главе работы нами были изложены основы концепции генерации печатных документов на основе содержимого фактографической автоматизированной информационной системы. Был приведен краткий обзор двух основных подходов получения косвенных форм именных конструкций в информационных системах. Технологически простым подходом является хранение косвенных форм наименований объектов непосредственно в информационной системе. Более сложным подходом является программная генерация косвенных форм наименований с помощью специальных алгоритмов. Первый подход, при этом, создает повышенную нагрузку на эксплуатантов системы, а второй – на программистов-разработчиков системы.
Мы провели исследование сети Интернет для выявления ассортимента доступных программных компонентов для получения косвенных наименований объектов. Было обнаружено несколько программ с подобной функциональностью, следи которых наиболее развитой является библиотека «padeg.dll». Несмотря на ее технологическое совершенство, библиотека работает лишь под управлением операционных систем семейства Microsoft Windows, что ограничивает круг ее применения. Кроме того, исходные коды библиотеки доступны лишь за плату и на неизвестных условиях, что осложняет работы по переносу библиотеки на другие платформы.
В связи с вышеизложенным, нами была проведена разработка ряда алгоритмов для получения косвенных форм некоторых именных конструкций (антропонимов, наименований должностей и структурных подразделений). Разработанные алгоритмы были помещены для свободного доступа на web-сайт SourceForge вместе с референтной их реализацией в виде Java-пакета «jz-decliner». Мы полагаем, что данные алгоритмы послужат основой для разработки открытых программных компонентов аналогичной функциональности для других платформ.
В третьей главе будет рассмотрен опыт интеграции разработанного пакета с информационной системой ОАО «Акрон» для оптимизации автоматической подготовки распорядительной документации по учету персонала.
ГЛАВА 3. ОПТИМИЗАЦИЯ АВТОМАТИЧЕСКОЙ ПОДГОТОВКИ РАСПОРЯДИТЕЛЬНЫХ ДОКУМЕНТОВ В ИНФОРМАЦИОННОЙ СИСТЕМЕ НОВГОРОДСКОГО ОАО «АКРОН»
3.1. Информация о документообороте предприятия
Открытое Акционерное Общество «Акрон» является крупнейшим российским производителем азотно-фосфорно-калийных сельскохозяйственных удобрений. ОАО «Акрон» – один из крупнейших налогоплательщиков Новгородской Области. Предприятие было основано в 1967 году под названием НПО «Азот». В настоящее время на предприятии работает более 4 000 сотрудников. Кроме того, поддерживается связь более чем с 6 000 бывших и внештатных сотрудников и других физических лиц. Формализованный подход к управлению этими связями требует постоянного оформления значительного объема документации, который, вкупе с высокими объемами производства, интенсивными поставками и сбытом, вынуждает ОАО «Акрон» использовать развитую автоматизированную информационную систему, обрабатывающую информацию обо всех сферах деятельности предприятия.
Объемам решаемых на предприятии задач соответствует и объем его внутреннего документооборота. Учитывая недостаток на рынке труда низкооплачиваемого, но квалифицированного персонала, знакомого с принципами подготовки документов, задача автоматизации подготовки документов для ОАО «Акрон» в настоящее время является более чем актуальной. Несмотря на то, что львиную долю во внутреннем документообороте предприятия занимают документы, связанные с производственной деятельностью, сбытом и снабжением, весьма высок и уровень потока документации по учету персонала. В то время как тексты первой группы документов представлены, обычно, таблицами или произвольным текстом, документы последней группы очень часто передают свое содержание с помощью трафаретного текста, содержащего косвенные формы антропонимов, наименований должностей и структурных подразделений. Автоматизация подготовки таких документов является нетривиальной задачей и как нельзя лучше подходит для демонстрации возможностей разработанного нами пакета «jz-decliner».
3.2. Корпоративная информационная система предприятия
Первые попытки автоматизации управленческой деятельности на ОАО «Акрон» относятся к середине 70-х годов XX века. Тогдашний уровень развития отечественной вычислительной техники не позволял использовать ее для ведения документооборота или для целей оперативного управления. До 1990-х годов удавалось автоматизировать лишь некоторые «пакетные» регулярно выполняемые операции, например, начисление заработной платы. После появления в конце 1980-х годов в свободной продаже персональных компьютеров, совместимых с IBM PC AT, предприятие создало новую систему оперативного управления ресурсами предприятия, которая, помимо прочего, позволяла получать печатные формы разнообразных документов. К началу XXI века, ОАО «Акрон», отвечая вызовам времени, приступило к созданию новой корпоративной информационной системы, обеспечивающей не только управление ресурсами, но и планирование их использования, а также ведение внутреннего документооборота на новом уровне.
Таким образом, в настоящее время в качестве корпоративной информационной системы на ОАО «Акрон» используется собственная разработка на основе трехъярусной гетерогенной программной платформы ISA-2005. В качестве хранилища данных система использует СУБД Oracle 10g. Ярус бизнес-логики платформы предполагает использование технологий Java с элементами стандарта Java EE версии 5. Клиентский ярус системы представлен как «толстыми» клиентскими приложениями для платформ Microsoft Windows, Microsoft.NET и Java SE, так и тонкими клиентами, работающими внутри Web-браузеров.
Использование в качестве сервера бизнес-логики Java-приложения возможной легкую интеграцию пакета «jz-decliner» непосредственно в серверную часть системы. Кроме того, благодаря архитектуре системы, существует дополнительная возможность интегрировать разработанный нами пакет на уровне СУБД, поскольку Oracle 10g поддерживает выполнение классов Java внутри базы данных после создания несложных процедур-оберток на языке PL/SQL.
3.3. Обзор процесса интеграции пакета «jz-decliner»
В процессе интеграции нами были решены следующие задачи:
1. Противодействие отрицательным последствиям ситуаций, когда разработанный пакет не сможет по тем или иным причинам корректно выполнить возложенную на него задачу;
2. Обеспечение доступа к функциональности разработанного пакета из серверных приложений системы;
3. Модификация структуры базы данных для поддержки безопасного и наиболее полного функционирования пакета;
4. Разработка серверных приложений системы, предоставляющих легкий доступ к результатам работы пакета всем другим компонентам системы;
5. Разработка клиентских приложений, позволяющих гибко управлять работой компонентов пакета путем изменения информации, содержащейся в структурах базы данных специально созданных для поддержки работы пакета.
Вслед за знаменитым теоретиком реляционных базы данных К. Дейтом, назовем сведения о предмете реального мира, хранящиеся в информационной системе, объектом (object) . Приверженцы распространенной среди архитекторов программных систем сущностно-реляционной (entity-relationship) модели могут отождествлять применяемый нами термин «объект» с понятием «сущность» (entity). Объекты, корректные косвенные падежные формы наименований которых нельзя получить с помощью алгоритмов разработанного нами пакета, мы условно назвали трудносклоняемыми.
Решая задачу автоматизации части функциональности информационной системы, необходимо учитывать, что внедряемый алгоритм автоматизации в некоторых случаях может оказаться не в состоянии решить возложенную на него задачу. В таких экстренных ситуациях следует предусмотреть возможность выполнить решение автоматизируемой задачи вручную в обход алгоритма. Это требование весьма актуально и для рассматриваемой нами задачи, поскольку точность и корректность написания косвенных форм антропонимов, наименований должностей и структурных подразделений является важным компонентом юридической составляющей документа. В некоторых случаях может потребоваться и использование косвенных форм, прямо нарушающих правила языка или вообще грамматически не происходящих от исходных наименований, которыми оперирует информационная система.
С целью удовлетворения указанного требования мы остановились на двухступенчатой схеме получения косвенных падежных форм наименований объектов. В этой схеме каждый объект имеет индивидуальный набор особенностей склонения своего наименования, уточняющий работу алгоритмов пакета. Кроме того, каждый объект, если он является трудносклоняемым, может быть связан со специальной структурой данных, в которой хранятся явно указанные косвенные формы его наименования. Косвенные формы наименований трудносклоняемых объектов задаются вручную оператором в ходе эксплуатации информационной системы. Точно также задаются и индивидуальные особенности склонения наименования каждого объекта. Поскольку подавляющее большинство объектов (согласно нашим тестам, около 98 процентов) не требует явного указания особенностей склонения наименований и не относится к трудносклоняемым, нагрузка на операторов по настройке правил склонения прогнозируется невысокой.
Опираясь на описанную выше концепцию, можно кратко описать алгоритм получения косвенных форм наименований объектов. Схематически алгоритм изображен на Рисунке 9. Клиентское приложение информационной системы, желающее получить косвенную форму наименования какого-либо объекта, передает его системный идентификатор серверному приложению. Серверное приложение анализирует информацию, хранящуюся в базе данных, и извлекает из нее начальную форму наименования объекта, дополнительную информацию о правилах его склонения и определяет, является ли объект трудносклоняемым. Если является, серверное приложение извлекает из базы данных индивидуальные формы косвенных падежей его наименования, пользуясь полученным ранее системным идентификатором, если не является, серверное приложение передает полученные из базы данных сведения разработанному нами пакету и далее использует результат его работы. Затем серверное приложение отсылает информацию, полученную из базы данных или в результате работы пакета, назад вызывавшему его клиенту.

Рис. 9. Схема принципа работы компонентов серверного приложения
при получении косвенной формы наименования объекта
Очевидно, что для поддержки работы такой схемы требуется расширение структуры базы данных информационной системы. Конкретизируем изменения в структуры базы данных, произведенные нами для реализации рассмотренной концепции интеграции.
3.4. Модификация базы данных
Помимо существующих структур для хранения основных форм наименований всех обрабатываемых объектов, в базе данных было необходимо предусмотреть пространство для хранения дополнительных правил склонения наименования каждой конкретного объекта, а также места для хранения форм косвенных падежей наименований трудносклоняемых объектов.
В качестве места для хранения правил склонения наиболее удобным оказалось использование уже существующих в базе данных таблиц, содержащих системные идентификаторы и рабочие наименования самих объектов. Для антропонимов это таблица с установочной информацией о физических лицах, а для наименований должностей и структурных подразделений – соответствующие таблицы справочников информационной системы.
Для хранения информации о правилах склонения, в каждую из этих таблиц были добавлены поля целочисленного типа. В таблицу с данными о физических лицах – три поля (для фамилии, имени и отчества), в таблицы справочников должностей и структурных подразделений по одному полю. Кроме того, в таблицу справочника должностей было добавлено целочисленное поле, характеризующее наименование должности по степени полноты.
Каждое из полей для хранения особенностей склонения, имея целочисленный тип, внутри представляют собой битовую карту, каждый бит которой кодирует определенной правило склонения. Если поле имеет нулевое или неопределенное (null) значение, считается, что наименование объекта склоняется по простейшему пути без применения каких-либо дополнительных правил. Набор правил, кодируемых битами описанных полей, индивидуален для каждой категории именных конструкций и соответствует способу кодирования правил склонения, описанному нами ранее. Наборы правил склонения для всех рассматриваемых именных конструкций приводятся в Таблице 8.
Табл. 8. Дополнительные особенности склонения
обрабатываемых именных конструкций
Категория сущности Название особенности Назначение особенности Циф¬ро-вой код Номер бита
1 2 3 4 5
Фамилия DF_INDECLINABLE Не склоняется 2 2
DF_HAS_ACCENT_IN_TAIL Ударение на последний слог 8 3
DF_HAS_NO_UNSTABLE_VOWELS Отсутствие беглых гласных 16 4
DF_IS_FOREIGN Иноязычное происхождение 32 5
Личное имя DF_INDECLINABLE Не склоняется 2 2
DF_HAS_ACCENT_IN_TAIL Ударение на последний слог 8 3
DF_HAS_NO_UNSTABLE_VOWELS Отсутствие беглых гласных 16 4
DF_IS_FOREIGN Иноязычное происхождение 32 5

Табл. 8. (Продолжение)
1 2 3 4 5
Отчество DF_INDECLINABLE Не склоняется 2 2
Должность DF_INDECLINABLE Не склоняется 2 2
DF_INBRACES_INDECLINABLE Конструкция в скобках не склоняется 64 6
Подразделение DF_INDECLINABLE Не склоняется 2 2
DF_INBRACES_DECLINABLE Конструкция в скобках склоняется 128 7
DF_ATTRIBUTE_IN_TAIL Определение после подлежащего 512 8

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

Рис. 10. Фрагмент структуры базы данных информационной системы ОАО «Акрон», предназначенной для хранения правил склонения наименований объектов и падежных форм наименований трудносклоняемых объектов. Курсивом выделены поля и таблицы, добавленные к БД во время интеграции с пакетом «jz-decliner»
В системе, разработанной на платформе ISA-2005, информация из базы данных извлекается и обрабатывается расширяемым серверным приложением, олицетворяющим, согласно концепции трехъярусных информационных систем, слой бизнес-логики.
3.5. Модификация серверной части системы
Серверная часть системы ISA-2005 представляет собой набор однородных программных модулей, специально разрабатываемых для решения прикладных задач и называемых сервисами. Сервисы, в соответствии с потребностями клиентских приложений, запускаются серверным приложением (хостом сервисов).
В составе системы имеются как стандартные многоцелевые сервисы, так и сервисы, разрабатываемые прикладными программистами, для решения конкретных бизнес-задач. Все данные, которые информационная система принимает из базы данных, проходят через какой-либо стандартный или специализированный сервис, где могут подвергаться дополнительной обработке.
Поскольку сервисы создаются на языке Java, наиболее простым решением оказалось обращение к возможностям пакета «jz-decliner» непосредственно изнутри специально разработанного для этого сервиса. В системе ISA-2005 для обеспечения подобной интеграции предусмотрена возможность загрузки дополнительных пакетов одновременно с хостом сервисов.
Для интеграции разработанного пакета с автоматизированной информационной системой ОАО «Акрон» было разработано несколько специализированных сервисов. Среди них:
1. Сервис для получения форм косвенных падежей абстрактных антропонимов (JITNameDecliner);
2. Сервис для получения форм косвенных падежей антропонимов, связанных с конкретными персоналиями (NameDecliner);
3. Сервис для получения форм косвенных падежей абстрактных наименований должностей (JITOccupationDecliner);
4. Сервис для получения форм косвенных падежей наименований конкретных должностей ОАО «Акрон» (OccupationDecliner);
5. Сервис для получения форм косвенных падежей абстрактных наименований структурных подразделений (JITSubdivisionDecliner);
6. Сервис для получения форм косвенных падежей наименований конкретных структурных подразделений ОАО «Акрон» (SubdivisionDecliner);
Нетрудно заметить, что перечисленными сервисами решаются задачи склонения наименований трех разновидностей объектов. При этом для решения каждой задачи предусмотрено по два сервиса: для склонения абстрактных именных конструкций и для склонения наименования конкретного объекта. Сделано это для того, чтобы можно было вручную назначить способ склонения наименования конкретного объекта, используемого в информационной системе. Таким образом, сервис склонения наименования конкретной разновидности объекта определяет, нет ли особых правил склонения для его наименования и, в зависимости от результата обрабатывает наименование сам (если есть особые правила), или передает для обработки сервису склонения абстрактных именных конструкций (если особых правил нет).
Рассмотрим основные принципы работы сервисов двух групп на примере склонения наименования должности. Принцип работы схематически показан на Рисунке 11.

Рис. 11. Диаграмма взаимодействия компонентов информационной
системы ОАО «Акрон» при склонении наименования должности
Клиент, желающий получить один или несколько косвенных падежей наименования определенной должности, вызывает сервис склонения наименований конкретных должностей «OccupationDecliner» и передает ему системный идентификатор должности для обработки.
Сервис «OccupationDecliner» выполняет запрос к базе данных и принимает из нее начальную форму наименования должности по полученному системному идентификатору, особенности его склонения и формы косвенных падежей, если наименование должности отнесено в системе к трудносклоняемым. Для наименований должностей, склоняемым по общим принципам, поля форм косвенных падежей принимаются из базы данных пустыми. Далее, если наименование должности является трудносклоняемым, полученные из базы данных сведения (предполагается, что они уже достаточные) непосредственно возвращаются клиенту. Если же наименование должности склоняется по общим правилам, сервис передает полученные из базы данных начальную форму и правила склонения сервису для склонения абстрактных наименований должностей «JITOccupationDecliner».
Сервис «JITOccupationDecliner» вызывает класс «Occupation» пакета «jz-decliner» и передает ему полученные сведения. Класс «Occupation» выполняет склонение и возвращает сервису «JITOccupationDecliner» готовую парадигму или сообщение об ошибке. Сервис возвращает полученные сведения назад вызывавшему его сервису «OccupationDecliner», а тот, в свою очередь, вызывавшему его клиенту, который использует из полной парадигмы нужное ему количество косвенных форм.
Если же клиенту требуется получить косвенный падеж абстрактного наименования должности, он может обратиться непосредственно к сервису «JITOccupationDecliner» и передать ему начальную форму наименования и правила склонения. Ответ клиент, при этом также получает от сервиса «JITOccupationDecliner». Обращения к базе данных при такой схеме работы не происходит. Схема процесса приведена на Рисунке 12.

Рис. 12. Диаграмма последовательности работы компонентов информационной системы ОАО «Акрон» при склонении наименования абстрактной должности
Получение косвенных форм антропонимов происходит сходным способом, различается лишь объем и состав передаваемых данных. Так, сервису «JITNameDecliner» передаются три начальных формы (для фамилии, для имени и для отчества), три набора правил склонения (также для фамилии, для имени и для отчества) и пол носителя антропонимов. Назад же сервис «JITNameDecliner» возвращает сразу три парадигмы (также для фамилии, для имени и для отчества).
Наименования структурных подразделений склоняются точно также, как и наименования должностей. Отличие состоит лишь в названиях вызываемых сервисов.
Согласно концепции трехъярусных информационных систем, обработанная серверным приложением информация поступает для отображения или печати в верхний, презентационный или клиентский ярус системы.
3.6. Использование результатов работы пакета «jz-decliner»
Правильно спроектированные клиентские приложения системы на базе платформы ISA-2005 общаются с базой данных исключительно посредством серверной части платформы. Таким образом, поскольку встраивание в поток данных результатов работы пакета происходит на уровне серверных приложений, с точки зрения клиентов, эти данные никак не отличаются от остальных данных системы. Следовательно, для обработанных данных доступны все возможности клиентских приложений системы. Точно также, полученные данные могут выступать в качестве реквизитов или фрагментов трафаретного текста для формирования печатных отчетов стандартными для системы средствами. Отметим, что платформа ISA-2005 может использовать в качестве генератора печатных отчетов текстовый процессор Microsoft Word, что значительно упрощает процедуру генерации трафаретного текста по сравнению с классическими генераторами отчетов.
3.7. Оперативная настройка правил работы пакета
Для создания полностью работоспособного решения необходимо было дать операторам, обслуживающим модули системы, связанные с пакетом, возможность тонкой настройки индивидуальных особенностей склонения каждого наименования обрабатываемого объекта.
С этой целью нами было разработано три клиентских модуля системы:
1. Для настройки способа склонения антропонимов персонально для конкретного сотрудника;
2. Для настройки способа склонения наименований должностей;
3. Для настройки склонения способа наименований структурных подразделений.
Для удобства работы оператора клиентский модуль для настройки правил склонения антропонимов был тесно интегрирован с модулем регистрации и ведения персональных данных физических лиц. Поскольку, вероятность того, что какой-либо набор антропонимов потребует ручной настройки или окажется трудносклоняемыми, составляет около 2%, предполагается, что изначально антропонимы вновь вводимого в систему физического лица не потребуют специфической настройки. Потребность в настройке будет выявлена при подготовке каких-либо документов, связанных с данным лицом. Поскольку такие документы готовятся в службе по работе с персоналом, изменение способа склонения антропонимов для конкретного физического лица будет удобно проводить там же. При необходимости такой настройки оператору достаточно найти нужного сотрудника в списке и вызвать модуль настройки, внешний вид которого представлен на Рисунке 13.

Рис. 13. Внешний вид модуля для настройки
особенностей склонения антропонимов физического лица
Оператор, используя данный модуль, имеет возможность указать для каждого антропонима в отдельности дополнительные правила склонения (в верхней части окна) или вручную ввести падежные формы для трудносклоняемых антропонимов (в нижней части окна). Для облегчения работы оператора рядом с каждой падежной формой выводится грамматическая подсказка, формирующая с антропонимами более или менее целостное словосочетание, воспринимающееся оператором легче, чем отдельные падежные формы.
Модуль настройки способов склонения наименований должностей был интегрирован в модуль ведения справочника должностей. Таким образом, оператор может оперативно, в одном месте, изменять наименование должности и способ его склонения. Этот особенно важно в свете того, что справочник должностей в информационной системе по историческим причинам находится не в лучшей форме и требует эпизодической санации. Внешний вид модуля настройки способа склонения наименования должностей показан на Рисунке 14.

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

Рис. 15. Внешний вид модуля для настройки особенностей склонения
наименования конкретного структурного подразделения
В третьей главе работы нами был продемонстрирован процесс оптимизации автоматизации подготовки распорядительных документов на примере корпоративной информационной системы ОАО «Акрон». С этой целью нами была проведена интеграция свободно распространяемого пакета «jz-decliner» с серверным ярусом информационной системы, напрямую работающим с платформой Java. В ходе интеграции была незначительно расширена структура базы данных информационной системы, были разработаны специальные сервисные модули для бесшовной интеграции пакета. Для обеспечения определенной гибкости в работе пакета были созданы специальные клиентские приложения, предназначенные для тонкой настройки правил склонения наименования каждого отдельной взятого объекта.
Летом 2007 года была проведена опытная эксплуатация и настройка описанной связки, а с осени 2007 года начата промышленная эксплуатация решения. В настоящее время функциональность интегрированного пакета используется в подсистемах управления персонала, учета материальной ответственности, выдачи справок, подготовки рассылок. Несмотря на то, что интеграция потребовала относительно глубокого вторжение в информационную систему, нарушений принципов ее архитектуры это не повлекло, не пришлось также использовать и каких-либо обходных маневров и нестандартных решений.
ЗАКЛЮЧЕНИЕ
Автоматизация подготовки печатной распорядительной документации в настоящее время является весьма актуальной темой среди отечественных разработчиков корпоративных информационных систем. Несмотря на то, что возможность быстрого получения печатных документов на основе фактографических данных является одной из ключевых функцией подавляющего большинства платформ разработки информационных систем, печатные формы документов, применяемые в Российской Федерации, имеют особенности, обработка которых не обеспечивается стандартными средствами генерации отчетов.
В ходе дипломной работы ними были обозначены потребности, наиболее остро стоящие перед разработчиками русскоязычных корпоративных информационных систем в части автоматической подготовки распорядительной документации. Наиболее сложными, с точки зрения автоматизации оказались документы, содержание которых выражено посредством трафаретного текста. Подобные документы весьма часто применяются в деятельности по учету труда и заработной платы.
Трафаретный текст, как объект автоматизации, состоит из изменяемых и неизменяемых фрагментов. Изменяемые фрагменты часто представляют собой результат дополнительной программной обработки информации, содержащейся в базе данных. Среди многочисленных способов такой обработки, особенную сложность представляет получение форм косвенных падежей антропонимов, наименований должностей и структурных подразделений, в то время как в базе данных эти именные конструкции хранятся в начальной форме.
Нами был проведен обзор доступных в настоящее время дополнительных программных компонентов, предназначенных для решения этих задач. Несмотря на то, что удалось обнаружить довольно стабильно работающую и популярную библиотеку «padeg.dll», фундаментальные особенности ее реализации (работа только под Windows и ограничение на использование исходного кода), выяснилось, что единого подхода для решения перечисленных задач сред отечественного сообщества разработчиков нет.
Для частичного преодоления этой ситуации мы провели независимую разработку необходимых алгоритмов и их референтной реализации в виде пакета Java. Разработанные алгоритмы и программный пакет свободно доступны на Web-сайте «www.sourceforge.net» под лицензией BSD. Данные алгоритмы могут стать основой для разработки открытых и закрытых программных компонентов аналогичной функциональности для других платформ. Для облегчения процесса тестирования подобных разработок нами была составлена тестовая база данных, содержащая списки антропонимов, наименований должностей и структурных подразделений в начальной и косвенных формах. Кроме того, были созданы тестовые web-приложения, автоматически анализирующие правильность работы реализаций алгоритмов.
Референтная реализация алгоритмов была нами использована для оптимизации процесса автоматизированной подготовки распорядительных документов в корпоративной информационной системе ОАО «Акрон». С это целью нами был проведен комплекс мероприятий, затронувший все ярусы платформы информационной системы, но не нарушивший логику ее работы. С лета 2007 года проводилась опытная эксплуатация полученной связки. Осенью 2007 года предприятие приступило к промышленной эксплуатации разработанного решения в оперативной работе предприятия.
Несмотря на определенные успехи в автоматизации получения косвенных форм некоторых именных конструкций, остается широкое поле для дальнейшей работы в данном направлении. В частности, нами планируется постепенно реализовать в пакете поддержку всех типов изменяемых текстовых фрагментов, перечисленных в данной работе. Наиболее важными из них представляются сумма прописью, правильно текстовое представление дат и временных интервалов, грамматическое согласование наименований перечисляемых объектов с их количеством.
Планируемая разработка перечисленных алгоритмов будет нами осуществляться под открытой программной лицензией BSD. Это обеспечит доступность результатов разработок для всех желающих и, возможно, поможет выработке единой стратегии в решении проблем автоматизации подготовки русскоязычных документов.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ
1. Источники
1.1. Опубликованные

1. Конституция Российской Федерации: принята на всенародном голосовании 12 декабря 1993 года. — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
3. О языках народов Российской Федерации: закон РФ [от 25 октября 1991 г. № 1807-I (с изменениями от 24 июля 1998 г., 11 декабря 2002 г.)]. — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
4. О внесении дополнения в статью 3 Закона Российской Федерации “О языках народов Российской Федерации”: федеральный закон [от 11 декабря 2002 г. № 165-ФЗ]. – Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
5. О государственном языке Российской Федерации: федеральный закон [от 1 июня 2005 г. № 53-ФЗ]. — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
6. Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты: постановление Госкомстата РФ [от 5 января 2004 г. № 1] . — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.

1.2. Неопубликованные

7. Модуль для настройки склонения ФИО. // Компоненты для разработки клиентских модулей системы ИСА-2005. (Внутренняя документация ОАО «Акрон»).
8. Модуль для настройки склонения наименований должностей. // Компоненты для разработки клиентских модулей системы ИСА-2005. (Внутренняя документация ОАО «Акрон»).
9. Модуль для настройки склонения наименований структурных подразделений. // Компоненты для разработки клиентских модулей системы ИСА-2005. (Внутренняя документация ОАО «Акрон»).
10. Стандарт предприятия ОАО «Акрон». (Внутренняя документация ОАО «Акрон»).
2. Нормативно-методические издания
1. Государственная система документационного обеспечения управления. Основные положения. Общие требования к документам и службам документационного обеспечения: Приказ Главархива СССР [от 25 мая 1988 г. № 33 (Д*)]. — [Электронный ресурс]. – Режим доступа: http://www.businesspravo.ru/.
2. Государственный стандарт РФ ГОСТ Р 51141-98 «Делопроизводство и архивное дело. Термины и определения». — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
3. Государственный стандарт РФ ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» (принят и введен в действие постановлением Госстандарта РФ от 3 марта 2003 г. N 65-СТ) . — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
4. Государственный стандарт СССР ГОСТ 6.38-90. Система организационно-распорядительной документации. Требования к оформлению документов. — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
5. Общероссийский классификатор управленческой документации. ОК 011-93. — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
6. Общероссийский классификатор профессий рабочих, должностей служащих и тарифных разрядов. ОК 016-94 — Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
7. Перечень типовых управленческих документов, образующихся в деятельности организаций с указанием сроков хранения. — Росархив, ВНИИДАД. — М., 2001. — 107 с.
8. Типовая инструкция по делопроизводству в федеральных органах исполнительной власти. — М.: Научная книга, 2006. — 53 с.
3. Литература
1. Андреева В.И. Делопроизводство. Практическое пособие. / В.И. Андреева. М.: Управление персоналом, 2005. – 196 с. ISBN 5-95630-027-2.
2. Ауэр К. Экстремальное программирование: постановка процесса. С первых шагов и до победного конца. / Кен Ауэр, Рой Миллер. – СПб.: Питер, 2003. – 368 с.: ил. ISBN 5-318-00132-7.
3. Бек К. Экстремальное программирование: разработка через тестирование. / Кент Бек, Мартин Фаулер. – СПб.: Питер, 2003.
4. Бекаревич Ю.Б. Microsoft® Access 2000. / Ю.Б. Бекаревич, Н.В. Пушкина. – СПб.: БХВ-Санкт-Петербург, 1999. – 480 с., ил. – ISBN 5-8206-0033-9.
5. Бенвенист Э. Общая лингвистика. Лингвистическое наследие XX века. / Э. Бенвенист. М.: Едиториал УРСС, 2002. – 448 с. – ISBN 5-354-00066-1.
6. Борисов А.Н. Первичные документы: оформление, использование, хранение, выбытие. / А.Н. Борисов. – Справочно-информационная система «Гарант-Мастер Прайм» от 22.03.2008.
7. Быкова Т.А. Делопроизводство: Учебник для вузов. / Т. А. Быкова, Л. М. Вялова, Л. В. Санкина; Под общей ред. проф. Т. В. Кузнецовой. — М.: Международный центр финансово-экономического развития, 2006. — 560 с. ISBN 5-7709-0370-8.
8. Васильев Д.В. Делопроизводство на компьютере. Практические рекомендации. / Ю. В. Васильев. М.: Приор, 1997. – 224 с. ISBN 5-85572-129-9.
9. Вигерс К. Разработка требований к программному обеспечению / Карл Вигерс. Пер с англ. Microsoft Corporation. – М.: Издательство-торговый дом «Русская редакция», 2004. – 576с.: ил. – ISBN 0-7356-1879-8 (eng.), ISBN 5-7502-0240-2.
10. Галахов В.В. Делопроизводство: Образцы, документы. Организация и технология работы. Более 120 документов. – 2-е изд., перераб. и доп. / В.В. Галахов, И.К. Корнеев и др.; под ред. И.К. Корнеева, В.А. Кудряева. – М.: ТК Велби, Изд-во Проспект, 2007. – 456 с. – ISBN 978-5-482-01581-0.
11. Гамма Э. Приемы объектно-ориентированного проектирования. паттерны проектирования. / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. – СПб.: Питер, 2003. – 368 с.: ил. – ISBN 5-272-00355-1.
12. Головин Б.Н. Введение в языкознание. Лингвистическое наследие XX века. / Б. Н. Головин. М.: КомКнига, 2007. – 231 с. ISBN 5-484-00756-9.
13. Дейт К. Дж. Введение в системы баз данных.: Пер с англ. – 6-е изд. / К. Дж. Дейт. – К.: Диалектика, 1998. – 784 с.: ил. – ISBN 966-506-124-0 (рус.).
14. Зелковиц М. Принципы разработки программного обеспечения: Пер. с англ. / М. Зелковиц, А. Шоу, Дж. Гэннон. – М.:Мир, 1982. – 368 с., ил.
15. Калакуцкая Л.П. Склонение фамилий и личных имен в русском литературном языке. / Лариса Павловна Калакуцкая. — М.: Издательство «Наука», 1984. 220 с. (примерно).
16. Калакуцкая Л.П. Фамилии. Имена. Отчества. Написание и склонение. / Лариса Павловна Калакуцкая. — М.: ТОЛК, 1994. — 100 с. — ISBN 5-87607-003-3.
17. Кирсанова М.В. Курс делопроизводства: Документационное обеспечение управления: Учебное пособие. / М. В. Кирсанова, Ю. М. Аксенов. – М.: Инфра-М; Новосибирск: Сибирское соглашение, 2008. – 296 с.
18. Клобуков Е.В. Семантика падежных форм в современном русском литературном языке: ведение в методику позиционного анализа. / Евгений Васильевич Клобуков. — М.: Издательство Московского университета, 1986. — 118 с.
19. Компьютерные программы для службы кадров. // Справочник кадровика. – 2001. №1. Получено с сайта «kadrovik.ru».
20. Костомаров М.Н. Унификация и стандартизация документов управления. / М. Н. Костомаров. // Секретарское дело. – 2001. №4. С. 28-32.
21. Кузнецова Т.В. Делопроизводство. / Т.В. Кузнецова – М.: ЗАО «Бизнес-школа «Интел-Синтез»», 1999. – 292 с.
22. Кузнецова Т.В. Отражение вопросов документирования в законодательных актах РФ. / Кузнецова Т.В. // Делопроизводство. 2001. №2. С. 9-14.
23. Кушнерук С.П. Документная лингвистика (русский деловой текст): Учебное пособие. / С. П. Кушнерук. – Волгоград: Издательство Волгоградского государственного университета, 1999. – 96 с. – ISBN 5-85534-275-1.
24. Ларин М.В. Управление документацией и новые информационные технологии. / М. В. Ларин— М.: Научная книга, 2003. — 137 с.
25. Новак Б. Кадровый учет на компьютере. / Борис Новак. — Санкт-Петербург, 2007. — 208 с. — ISBN 5-91180-004-7, 978-5-91180-004-8.
26. Перри Б. Java сервлеты и JSP: сборник рецептов. Изд. 2-е / Брюс Перри. / Пер. с англ. — М.: КУДИЦ-ПРЕСС, 2006. — 768 с. — ISBN 5-9579-0073-7.
27. Петров В.Н. Информационные системы. Учебник для вузов. / В. Н. Петров. – Санкт-Петербург: Питер, 2002. – 688 с. – ISBN 5-318-00561-6 .
28. Портянкин И.А. Swing: Эффектные пользовательские интерфейсы. Библиотека программиста. / Иван Портянкин. – СПб.: Питер, 2005. – 524 с.: ил. – ISBN 5-469-00005-2.
29. Розенталь Д. И. Словарь трудностей русского языка. / Д. И. Розенталь, М. А. Теленкова. – М.: Рольф, 2005. – 832 с. – ISBN 5-8112-1151-1.
30. Санкина Л.В. Приказ по личному составу. // Справочник кадровика. – 2000. №7. Получено с сайта «kadrovik.ru».
31. Составление и оформление служебных документов. Практическое пособие для коммерческих фирм, общественных организаций и государственных структур. / Под ред. проф. Т.В. Кузнецовой. – М., 1999.
32. Стенюков М.В. Образцы документов по делопроизводству. / М. В. Стенюков. – М.: Приор, 2006. – 173 с. ISBN 5-9512-0017-2.
33. Суровцева И.А. О нормативно-методической базе современного делопроизводства. / И. А. Суровцева. // Документ. Архив. История. Современность: Сборник научных трудов. Вып. 2. – Екатеринбург: Издательство Уральского университета, 2002. – 327 с. – ISBN 5-7584-0081-5. С. 319-324.
34. Фионова Л.Р. Организация и технология документационного обеспечения управления. Методические указания по курсовому проектированию. / Л. Р. Фионова. — Пенза, 2006. — 23 с.
35. Хабибуллин И.Ш. Самоучитель Java 2. / И. Ш. Хабибуллин. – СПб.: БХВ-Петербург, 2005. – 720 с.: ил. – ISBN 5-94157-573-4.
36. Хабибуллин И.Ш. Создание распределенных приложений на Java 2. / И. Ш. Хабибуллин. – СПб.: БХВ-Петербург, 2002. – 704 с.: ил. – ISBN 5-94157-106-2.
4. Справочные и информационные издания
1. Лингвистический энциклопедический словарь. / Гл. ред. В.Н. Ярцева. – М.: Большая Российская энциклопедия, 2002. – 709 с. – ISBN 5-85270-239-0.
5. Адреса Интернет-ресурсов
1. Автоматизированная обработка текста. – [Электронный ресурс]. Режим доступа: www.aot.ru.
2. Еськова Н.А. Особенности склонения фамилий и личных имен. Получено с сайта www.gramota.ru.
3. Земская Е.А. Активные процессы в русском языке последнего десятилетия XX века / Е. А. Земская. — [Электронный ресурс]. — Режим доступа: http://www.gramota.ru/biblio/magazines/gramota/russianworld/28_46.
4. Кучер А. Клуб профессионалов 1С – Каталог разработок – Функция для склонения фамилии, имени, отчества. / А.Кучер. — [Электронный ресурс]. — Режим доступа: http://1c.proclub.ru/modules/mydownload/spersonal.php?cid=5&
lid=254.
5. Логинова А. БОСС-Кадровик – все функции работы с персоналом в одной системе. / Александра Логинова. — [Электронный ресурс]. — Режим доступа: http://www.ci.ru/inform/17_97/aiti/1.htm.
6. Интернет страница Юрия Железнякова. — [Электронный ресурс]. — Режим доступа: http://superjur.narod.ru/.
7. «Инфософт» Форумы. — [Электронный ресурс]. — Режим доступа: http://www.infosoft.ru/phpBB2/viewtopic.php?t=535&sid=ca0bc557f51299cbfc5ca6b435775536.
8. Королевство Дельфи — Склонение фамилий, имен и отчеств по падежам Библиотека функций. — [Электронный ресурс]. — Режим доступа: http://www.delphikingdom.com/aspviewitem.asp?catalogid=412.
9. Лавошникова Э.К.. Компьютерная лингвистика. О компьютерной проверке синтаксических конструкций в текстах на русском языке / Э. К. Лавошникова. // Информационные процессы, Том 5, № 3, 2005, стр. 201-212. — [Электронный ресурс]. — Режим доступа:. http://www.jip.ru/2005/201-212.pdf.
10. О программе АвтоДок-Нотариус. — [Электронный ресурс]. — Режим доступа: http://notary.auto-doc.ru/about.html.
11. Отдел кадров. Программное обеспечение для автоматизации кадрового учета. — [Электронный ресурс]. — Режим доступа: http://www.ksoft.ru/.
12. Правила русской орфографии и пунктуации. Утверждены в 1956 году Академией наук СССР, Министерством высшего образования СССР и Министерством просвещения РСФСР. Получено с сайта http://www.rusyaz.ru/pr/.
13. Сайт ООО “Вест-Холдерс”, белорусской компании, предлагающей программы для кадрового учета. — [Электронный ресурс]. — Режим доступа: http://a3soft.brest.by/.
14. Светова С. Опыт создания средств редактирования словаря пользователями. Системы машинного перевода семейства Промт (компания «Промт», С.-Петербург) / Светлана Светова // Международный семинар по компьютерной лингвистике «Диалог’ 99», Таруса, Россия, май 1999 г. — [Электронный ресурс]. – Режим доступа: http://www.promt.ru/ru/technology/articles/
svetova_may_1999.doc.
15. Склонение ФИО, должностей и подразделений в 1С? Это просто! — [Электронный ресурс]. – Режим доступа: http://ndeclin.narod.ru/core.htm.
16. Склонятель – программа автоматического склонения. — [Электронный ресурс]. – Режим доступа: http://www.morpher.ru/.
17. Страничка Козина Алексея — Набор функций, позволяющий изменять по падежам ФИО. — [Электронный ресурс]. – Режим доступа: http://kozin1.narod.ru/sqlfio.html.
18. Тяпкина Е. Сравнительный анализ основных лицензий Open Source: GPL, LGPL, BSD, MIT, Mozilla public license, Apache software license. – [Электронный ресурс]. – Режим доступа: http://www.libertarium.ru/libertarium/
18586/def_thread.
19. Форум программистов. — [Электронный ресурс]. – Режим доступа: http://forum.developing.ru/archive/index.php/t-1559.html.
20. Open Source Initiative. – [Электронный ресурс]. Режим доступа: www.opensource.org.
21. Russian Names Decliner – An algorithm set and open source Java package to decline Russian surnames, personal names, patronymic names, occupation and subdivision titles. [Электронный ресурс]. – Режим доступа: www.sourceforge.net/projects/jz-decliner.
22. SQL.RU Форум Oracle — Склонение фамилий. (Вариант решения). — [Электронный ресурс]. – Режим доступа: http://sql.ru/forum/actualthread.aspx?bid=3&tid=282734.
23. ZemCad12. — [Электронный ресурс]. – Режим доступа: http://www.geozemcad12-ru.1gb.ru/.
ПРИЛОЖЕНИЕ 1
ПРИЛОЖЕНИЯ
Виды документов, унифицированные формы которых утверждены
постановлением Госкомстата РФ от 5 января 2004 года
№ п.п. Код ОКУД Название Альт. ОКУД
2. Т-1 0301001 Приказ (распоряжение) о приеме работника на работу 0281151
3. Т-1а 0301015 Приказ (распоряжение) о приеме работников на работу
4. Т-2 0301002 Личная карточка работника +
5. Т-2ГС(МС) 0301016 Личная карточка государственного (муниципального) служащего
6. Т-3 0301017 Штатное расписание 0252251
7. Т-4 0301003 Учетная карточка научного, научно-педагогического работника +
8. Т-5 0301004 Приказ (распоряжение) о переводе работника на другую работу 0282151
9. Т-5а 0301018 Приказ (распоряжение) о переводе работников на другую работу
10. Т-6 0301005 Приказ (распоряжение) о предоставлении отпуска работнику 0284151
11. Т-6а 0301019 Приказ (распоряжение) о предоставлении отпуска работникам
12. Т-7 0301020 График отпусков 0284021
13. Т-8 0301006 Приказ (распоряжение) о прекращении (расторжении) трудового договора с работником (увольнении) 0283151
14. Т-8а 0301021 Приказ (распоряжение) о прекращении (расторжении) трудового договора с работниками (увольнении)
15. Т-9 0301022 Приказ (распоряжение) о направлении работника в командировку
16. Т-9а 0301023 Приказ (распоряжение) о направлении работников в командировку
17. Т-10 0301024 Командировочное удостоверение
18. Т-10а 0301025 Служебное задание для направления в командировку и отчет о его выполнении
19. Т-11 0301026 Приказ (распоряжение) о поощрении работника 0285151
20. Т-11а 0301027 Приказ (распоряжение) о поощрении работников
21. Т-12 0301007 Табель учета рабочего времени и расчета оплаты труда +
22. Т-13 0301008 Табель учета рабочего времени +
23. Т-49 0301009 Расчетно-платежная ведомость +
24. Т-51 0301010 Расчетная ведомость +
25. Т-53 0301011 Платежная ведомость +
26. Т-53а 0301050 Журнал регистрации платежных ведомостей
27. Т-54 0301012 Лицевой счет +
28. Т-54а 0301013 Лицевой счет (СВТ) +
29. Т-60 0301051 Записка-расчет о предоставлении отпуска работнику
30. Т-61 0301052 Записка-расчет при прекращении (расторжении) трудового договора с работником (увольнении)
31. Т-73 0301053 Акт о приеме работ, выполненных по срочному трудовому договору, заключенному на время выполнения определенной работы
ПРИЛОЖЕНИЕ 2
Способы представления реквизита «текст документа»
в унифицированных формах по учету труда и его оплаты
№ п.п. Код Название Способ предст. текста
1 2 3 4
2. Т-1 Приказ (распоряжение) о приеме работника на работу Трафаретный текст
3. Т-1а Приказ (распоряжение) о приеме работников на работу Таблица
4. Т-2 Личная карточка работника Анкета,
Таблица,
Таблица с псевдотаблицей-анкетой в каждой строке (образование)
5. Т-2ГС(МС) Личная карточка государственного (муниципального) служащего Анкета,
Таблица,
Таблица с псевдотаблицей-анкетой в каждой строке (образование)
6. Т-3 Штатное расписание Таблица
7. Т-4 Учетная карточка научного, научно-педагогического работника Анкета,
Таблица
8. Т-5 Приказ (распоряжение) о переводе работника на другую работу Трафаретный текст
9. Т-5а Приказ (распоряжение) о переводе работников на другую работу Таблица
10. Т-6 Приказ (распоряжение) о предоставлении отпуска работнику Трафаретный текст
11. Т-6а Приказ (распоряжение) о предоставлении отпуска работникам Таблица
12. Т-7 График отпусков Таблица
13. Т-8 Приказ (распоряжение) о прекращении (расторжении) трудового договора с работником (увольнении) Трафаретный текст
14. Т-8а Приказ (распоряжение) о прекращении (расторжении) трудового договора с работниками (увольнении) Таблица
15. Т-9 Приказ (распоряжение) о направлении работника в командировку Трафаретный текст
16. Т-9а Приказ (распоряжение) о направлении работников в командировку Псевдотаблица — «повернутая» таблица
17. Т-10 Командировочное удостоверение Трафаретный текст
18. Т-10а Служебное задание для направления в командировку и отчет о его выполнении Таблица
19. Т-11 Приказ (распоряжение) о поощрении работника Трафаретный текст
20. Т-11а Приказ (распоряжение) о поощрении работников Трафаретный текст,
Таблица

ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 2
1 2 3 4
21. Т-12 Табель учета рабочего времени и расчета оплаты труда Анкета,
Таблица с псевдотаблицей-анкетой в каждой строке (2 стр.),
Таблица
22. Т-13 Табель учета рабочего времени Анкета,
Таблица с псевдотаблицей-анкетой в каждой строке (2 стр.),
Таблица
23. Т-49 Расчетно-платежная ведомость Анкета,
Таблица
24. Т-51 Расчетная ведомость Анкета,
Таблица
25. Т-53 Платежная ведомость Анкета,
Таблица
26. Т-53а Журнал регистрации платежных ведомостей Анкета,
Таблица
27. Т-54 Лицевой счет Анкета,
Таблица
28. Т-54а Лицевой счет (СВТ) Анкета,
Таблица
29. Т-60 Записка-расчет о предоставлении отпуска работнику Трафаретный текст,
Таблица,
Псевдотаблица (Расчет оплаты)
30. Т-61 Записка-расчет при прекращении (расторжении) трудового договора с работником (увольнении) Трафаретный текст,
Таблица,
Псевдотаблица (Расчет оплаты)
31. Т-73 Акт о приеме работ, выполненных по срочному трудовому договору, заключенному на время выполнения определенной работы Трафаретный текст,
Таблица
ПРИЛОЖЕНИЕ 3
Алгоритм определения типа склонения мужской фамилии
если (ПРИЗНАК-НЕСКЛОНЯЕМОСТИ)
не склоняем по типу «Принудительно несклоняемая»
иначе если (фамилия оканчивается на -ов, -ев, -ёв)
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
склоняем по типу «Иностранная на -ов(-ев)» [Вирхов]
[Вирхов, Вирхова, Вирхову, Вирова, Вирховом, о Вирхове]
иначе
склоняем по типу «Русская на -ов(-ев)» [Иванов]
[Иванов, Иванова, Иванову, Иванова, Ивановым, об Иванове]
иначе если (фамилия оканчивается на -ин, -ын)
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
склоняем по типу «Иностранная на -ин» [Дарвин]
[Дарвин, Дарвина, Дарвину, Дарвина, Дарвином, о Дарвине]
иначе
склоняем по типу «Русская на -ин» [Куклин]
[Куклин, Куклина, Куклину, Куклина, Куклиным, о Куклине]
иначе если (фамилия оканчивается на -ен)
склоняем по типу «Иностранная на -ен» [Харконен]
[Харконен, Харконена, Харконену, Харконена, Харконеном, о Харконене]
иначе если (фамилия оканчивается на -ий, -ый, -ой)
если (фамилия оканчивается на -ский, -цкий, -ской, -цкой)
склоняем по типу «Польская на -с(ц)кий или русская -с(ц)кой» [Шуйский]
[Шуйский, Шуйского, Шуйскому, Шуйского, Шуйским ,о Шуйском]
иначе
если (ПРИЗНАК-ИНОЯЗЫЧНОГО ПРОИСХОЖДЕНИЯ)
склоняем по типу «Латинская на -ий» [Луций]
[Луций, Луция, Луцию, Луция, Луцием, о Луции]
иначе
склоняем по типу «Русская на -ий, -ый, ой» [Нагой]
[Нагой, Нагого, Нагому, Нагого, Нагим, о Нагом]
[в генетиве учитываем -ого/-его]
[в дативе учитываем -ому/-ему]
[в творительном учитываем -ым/-им]
иначе если (фамилия оканчивается на -их, -ых)
если (предпоследняя буква и, и третья с конца буква препалатальная)
склоняем по типу «Немецкая на -их» [Рерих]
[Рерих, Рериха, Рериху, Рериха, Рерихом, о Рерихе]
иначе
не склоняем по типу «Северная на -их, -ых (нескл.)» [Белых]
иначе если (фамилия оканчивается на -ь или -й)
склоняем по типу «С окончанием на -й или -ь» [Коваль]
[Коваль, Коваля, Ковалю, Коваля, Ковалем, о Ковале]
иначе если (фамилия оканчивается на согласную) [уже только твердую]
если (фамилия оканчивается на шипящую согласную)
если (ПРИЗНАК-УДАРЕНИЯ-НА-ПОСЛЕДНИЙ-СЛОГ)
склоняем по типу «С окончанием на твердую шипящую согласную с ударением
на последний слог» [Калач]
[Калач, Калача, Калачу, Калача, Калачом, о Калаче]
[основу обрабатываем на беглые гласные]
иначе
склоняем по типу «С окончанием на твердую шипящую согласную» [Этуш]
[Этуш, Этуша, Этушу, Этуша, Этушем, об Этуше]
иначе
склоняем по типу «С окончанием на твердую гласную» [Шлапак]
[Шлапак, Шлапака, Шлапаку, Шлапака, Шлапаком, о Шлапаке]
[основу обрабатываем на беглые гласные]
иначе если (фамилия оканчивается на -е, -э, и, -ы, -у, -ю, -о)
не склоняем по типу «На гласную -е, -э, -и, -ы, -у, -ю, -о (нескл.)» [Доде]
иначе если (фамилия оканчивается на -а, и вторая буква с конца – гласная)
не склоняем по типу «На -а после гласной – не склоняемая» [Моруа]
иначе если (фамилия оканчивается на -а) (уже только с предшествующей согласной)
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
не склоняем по типу «Оканчивающаяся на -а иностранного происхождения (нескл.)»
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 3
иначе если (предпоследняя буква шипящая)
склоняем по типу «На -а после шипящей» [Кваша]
[Кваша, Кваши, Кваше, Квашу, Квашой, о Кваше]
(в творительном падеже учитываем ПРИЗНАК-УДАРЕНИЯ-НА-ПОСЛЕДНИЙ-СЛОГ)
иначе если (предпоследняя буква специальная, порождающая -и- в генетиве)
склоняем по типу «На -а со специальной согласной перед ней» [Гулыга]
[Гулыга, Гулыги, Гулыге, Гулыгу, Гулыгой, о Гулыге]
иначе
склоняем по типу «На -а с согласной перед ней» [Бурда]
[Бурда, Бурды, Бурде, Бурду, Бурдой, о Бурде]
иначе если (фамилия оканчивается на -я)
если (фамилия оканчивается на -ия)
склоняем по типу «На -я после -и-» [Берия]
[Берия, Берии, Берии, Берию, Берией, о Берии]
иначе если (фамилия оканчивается на -йя)
склоняем по типу «На -я после -й-» [Гойя]
[Гойя, Гойи, Гойе, Гойю, Гойей, о Гойе]
иначе
склоняем по типу «На -я»
иначе
возбуждаем исключение «Мужская фамилия неопознанного типа»

В нескольких местах приведенного алгоритма имеется отсылка к обработке беглых гласных. Ниже приводится алгоритм для этой обработки. Предполагается, что ему на вход поступила основа фамилии.
Алгоритм обработки беглых гласных в основе мужской фамилии
если (ПРИЗНАК-ОТСУТСТВИЯ-БЕГЛЫХ-ГЛАСНЫХ)
возвращаем не измененную основу
иначе если (основа имеет только один гласный звук)
возвращаем не измененную основу
иначе если (основа имеет длину менее четырех букв)
возвращаем не измененную основу
иначе если (последняя буква основы – ц)
если (предпоследняя буква основы – е)
если (третья с конца буква основы – л)
возвращаем основу, заменив предпоследнюю букву на -ь-
[Шилец —> Шильц]
иначе если (третья с конца буква основы – и или е)
возвращаем основу, заменив предпоследнюю букву на -й-
[Коломиец —> Коломийц]
иначе
возвращаем основу, исключив из нее предпоследнюю букву
[Кравец —> Кравц]
иначе
возвращаем не измененную основу
иначе если (последняя буква основы – к)
если (предпоследняя буква основы – о)
возвращаем основу, исключив из нее предпоследнюю букву
[Козленок —> Козленк]
иначе
возвращаем не измененную основу
ПРИЛОЖЕНИЕ 4
Алгоритм определения склонения женской фамилии
если (ПРИЗНАК-НЕСКЛОНЯЕМОСТИ)
не склоняем по типу «Принудительно несклоняемая»
иначе если (фамилия оканчивается на -а)
если (фамилия оканчивается на -ова, -ева, -ёва)
склоняем по типу «Русская на -ова, -ева, -ёва» [Иванова]
[Иванова, Ивановой, Ивановой, Иванову, Ивановой, об Ивановой]
[в генетиве учитываем -ой/-ей]
[в дативе учитываем -ой/-ей]
[в творительном падеже учитываем -ой/-ей]
[в предложном падеже учитываем -ой/-ей]
иначе если (фамилия оканчивается на -ина, -ына)
склоняем по типу «Русская на -ина, -ина» [Куклина]
[Куклина, Куклиной, Куклиной, Куклину, Куклиной, о Куклиной]
[в генетиве учитываем -ой/-ей]
[в дативе учитываем -ой/-ей]
[в творительном падеже учитываем -ой/-ей]
[в предложном падеже учитываем -ой/-ей]
иначе если (фамилия оканчивается на -ска)
склоняем по типу «Польская на -ска» [Брыльска]
[Брыльска, Брыльски, Брыльске, Брыльску, Брыльской, о Брыльске]
иначе если (предпоследняя буква фамилии – гласная)
не склоняем по типу «Иностранная на -а с предшествующей гласной (нескл.)»
[Моруа]
иначе если (предпоследняя буква основы согласная, порождающая -и- в генетиве)
склоняем по типу «Русская на -а с предшествующей спец. согласной» [Книга]
[Книга, Книги, Книге, Книгу, Книгой, о Книге]
[в творительном падеже учитываем -ой/-ей]
иначе
склоняем по типу «Русская на -а с предшествующей согласной» [Бурда]
[Бурда, Бурды, Бурде, Бурду, Бурдой, о Бурде]
[в творительном падеже учитываем -ой/-ей]
иначе если (фамилия оканчивается на -я)
если (фамилия оканчивается на -ая)
склоняем по типу «Русская/польская на -ая» [Борецкая]
[Борецкая, Борецкой, Борецкой, Борецкую, Борецкой, о Борецкой]
[в генетиве учитываем -ой/-ей]
[в дативе учитываем -ой/-ей]
[в творительном падеже учитываем -ой/-ей]
[в предложном падеже учитываем -ой/-ей]
иначе
не склоняем по типу «Непонятная на -я (нескл.)»
иначе
не склоняем по типу «Фамилия не на -а и не на -я (нескл.)»
ПРИЛОЖЕНИЕ 5
Алгоритм определения типа склонения мужского личного имени
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (ПРИЗНАК-НЕСКЛОНЯЕМОСТИ)
не склоняем по типу «Принудительно несклоняемое»
иначе если (длина имени равна одному символу или последний его символ – точка)
не склоняем по типу «Инициал»
иначе если (имя оканчивается на -ий)
склоняем по типу «Обрусевшее на -ий» [Валерий]
[Валерий, Валерия, Валерию, Валерия, Валерием, о Валерии]
иначе если (имя оканчивается на -ой)
склоняем по типу «На -ой» [?]
[?, ?, ?, ?, ?, ?]
иначе если (имя оканчиватся на -ь или на -й)
склоняем по типу «Русское на -й, -ь» [Сергей]
[Сергей, Сергея, Сергею, Сергея, Сергеем, о Сергее]
иначе если (имя оканчивается на шипящую)
склоняем по типу «С окончанием на шипящую» [Челкаш]
[Челкаш, Челкаша, Челкашу, Челкаша, Челкашом, Челкаше]
иначе если (имя оканчивается на согласную) [уже только твердую]
склоняем по типу «С окончанием на твердую согласную» [Павел]
[Павел, Павла, Павлу, Павла, Павлом, о Павле]
[основу обрабатываем на беглые гласные]
иначе если (имя оканчивается на -е, -э, -и, -ы, -у, -ю, -о)
не склоняем по типу «На гласную -е, -э, -и, -ы, -у, -ю, -о (не скл.)» [Серго]
иначе если (имя оканчивается на -а и предпоследняя его буква – гласная)
не склоняем по типу «На -а после гласной (не скл.)»
иначе если (имя оканчивается на -а)
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
не склоняем по типу «Иноязычное на -а (не скл.)»
иначе
если (предпоследняя буква имени порождает -и- в генетиве)
склоняем по типу «На -а со специальной согласной перед ней» [?]
[?, ?, ?, ?, ?, ?]
иначе
склоняем по типу «На -а без специальной согласной перед ней» [Абдулла]
[Абдулла, Абдуллы, Абдулле, Абдуллу, Абдуллой, об Абдулле]
конец если
иначе если (имя оканчивается на -я)
если (ПРИЗНАК-УДАРЕНИЯ-НА-ПОСЛЕДНИЙ-СЛОГ)
склоняем его по типу «На -я с ударением последний слог» [?]
[?, ?, ?, ?, ?]
иначе
склоняем его по типу «На -я» [Гогия]
[Гогия, Гогии, Гогии, Гогию, Гогией, о Гогии]
иначе
возбуждаем исключение «Мужское имя неопознанного типа»

В одном месте приведенного алгоритма имеется отсылка на процедуру обработки беглых гласных в основе имени на твердую согласную. В отличие от фамилии, для имени проверка беглых гласных выполняется гораздо проще. Нам удалось обнаружить лишь два имени с беглой гласной в основе – «Лев» и «Павел». Обрабатываемая основа проверяется просто на соответствие с этими именами.
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 5
Алгоритм обработки беглых гласных в основе мужского личного имени
если (имя без учета регистра равно «Павел»)
возвращаем «Павл»
иначе если (имя без учета регистр равно «Лев»)
возвращаем «Льв»
иначе
возвращаем не измененную основу
ПРИЛОЖЕНИЕ 6
Алгоритм определения типа склонения женского личного имени
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (ПРИЗНАК-НЕСКЛОНЯЕМОСТИ)
не склоняем по типу «Принудительно несклоняемое»
иначе если (длина имени равна одному символу или последний его символ – точка)
не склоняем по типу «Инициал»
иначе если (имя оканчивается на -а)
если (предпоследняя буква имени – гласная)
не склоняем по типу «Иностранное на -а с предшествующей гласной (не скл.)»
иначе если (предпоследняя буква имени порождает -и- в генетиве)
склоняем по типу «Русское на -а с предшествующей спец. согласной» [Ольга]
[Ольга, Ольги, Ольге, Ольгу, Ольгой, об Ольге]
[в творительном падеже учитываем -ой/-ей]
иначе
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
не склоняем по типу «Иноязычное на -а (не скл.)»
иначе
склоняем по типу «Общее на -а» [Галина]
[Галина, Галины, Галине, Галину, Галиной, о Галине]
[в творительном падеже учитываем -ой/-ей]
иначе если (имя оканчивается на -я)
если (предпоследняя буква имени -ь-)
склоняем по типу «Русское на -ья» [Дарья]
[Дарья, Дарьи, Дарье, Дарью, Дарьей, о Дарье]
иначе если (предпоследняя буква имени -и-)
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
склоняем по типу «Иноязычное на -ия» [Зульфия]
[Зульфия, Зульфии, Зульфие, Зульфию, Зульфией, о Зульфие]
иначе
склоняем по типу «Русское на -ия» [Мария]
[Мария, Марии, Марие, Марию, Марией, о Марии]
иначе
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
не склоняем по типу «Иноязычное на -я (не скл.)»
иначе
склоняем по типу «Общее на -я» [Наталия]
[Наталия, Наталии, Наталии, Наталию, Наталией, о Наталии]
иначе если (имя оканчивается на -ь)
если (ПРИЗНАК-ИНОЯЗЫЧНОГО-ПРОИСХОЖДЕНИЯ)
не склоняем по типу «Иноязычное на -ь (не скл.)» [Эсфирь]
иначе
склоняем по типу «По третьему склонению на -ь» [Любовь]
[Любовь, Любови, Любови, Любовь, Любовью, о Любови]
иначе
не склоняем по типу «Имя не на -а и не на -я и не на -ь (не скл.)»
ПРИЛОЖЕНИЕ 7
Алгоритм определение типа склонения мужского и женского отчеств
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (ПРИЗНАК-НЕСКЛОНЯЕМОСТИ)
не склоняем по типу «Принудительно несклоняемое»
иначе если (длина отчества равна одному символу или последний его символ – точка)
не склоняем по типу «Инициал»
иначе если (мужской род)
если (отчество оканчивается на -ч)
склоняем по типу «Русское мужское на -ч» [Иванович]
[Иванович, Ивановича, Ивановичу, Ивановича, Ивановичем, об Ивановиче]
иначе
не склоняем по типу «Непонятно мужское (не скл.)»
иначе если (женский род)
если (отчество оканчивается на -на)
склоняем по типу «Русское женское на -на» [Ивановна]
[Ивановна, Ивановны, Ивановну, Ивановну Ивановной, об Ивановне]
иначе
не склоняем по типу «Непонятное женское (не скл.)»
иначе
не склоняем по типу «Непонятного рода»
ПРИЛОЖЕНИЕ 8
Алгоритм членения наименования подразделения на лексемы
сбрасываем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
сбрасываем признак ОТКРЫВАЮЩАЯ-СКОБКА-НАЙДЕНА
сбрасываем признак ОТКРЫВАЮЩАЯ-КАВЫЧКА-НАЙДЕНА
сбрасываем признак МНОЖЕСТВЕННОЕ-ЧИСЛО
устанавливаем признак РОД в состояние НЕИЗВЕСТЕН
разбиваем подразделение на лексемы по границам («пробел», «кавычка», ()[]<>{}.,)
цикл для каждой лексемы
если (лексема равна точке)
[предполагаем, что предыдущая лексема была сокращением]
присоединяем текущую лексему к предыдущей лексеме
если (длина лексемы меньше четырех символов) и (предыдущая лексема равна дефису)
[предполагаем, что это все части сокращения через дефис]
присоединяем текущую и предыдущую лексемы к предпредыдущей лексеме
конец цикла
цикл для каждой из оставшихся лексем
выполняем склонение лексемы
конец цикла
Алгоритм определения синтаксической роли лексемы
для наименования подразделения
если (лексема является пустой строкой)
выходим
если (лексема является открывающей скобкой)
устанавливаем признак ОТКРЫВАЮЩАЯ-СКОБКА-НАЙДЕНА
сбрасываем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
если (лексема является закрывающей скобкой)
сбрасываем признак ОТКРЫВАЮЩАЯ-СКОБКА-НАЙДЕНА
если (лексема является кавычкой)
инвертируем признак ОТКРЫВАЮЩАЯ-КАВЫЧКА-НАЙДЕНА
если (лексема является пробелом, кавычкой, «()[]<>{}.,»)
заносим ее в каждую форму выходной парадигмы неизменной
выходим
если (НАЙДЕНА-ОТКРЫВАЮЩАЯ-СКОБКА)
если (не установлен ПРИЗНАК-СКЛОНЯЕМОСТИ-СКОБОК)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является словом «по», «с», )
устанавливаем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема не является валидным словом)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является существительным)
устанавливаем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
выполняем восстановление гомоглифов лексемы
склоняем лексему, как неодушевленное существительное
[с учетом признака МНОЖЕСТВЕННОЕ-ЧИСЛО]
присоединяем парадигму лексемы к выходной парадигмы
иначе если (лексема является прилагательным)
выполняем восстановление гомоглифов лексемы
склоняем лексему, как неодушевленное прилагательное
присоединяем парадигму лексемы к выходной парадигмы
иначе
устанавливаем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (НАЙДЕНА-ОТКРЫВАЮЩАЯ-КАВЫЧКА)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (ПОДЛЕЖАЩЕЕ-НАЙДЕНО)
заносим лексему в каждую форму выходной парадигмы неизменной
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 8
иначе если (лексема является словом «по» или «с»)
устанавливаем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема не является валидным словом)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема не является кириллическим словом)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема оканчивается точкой) [лексема-сокращение]
если (лексема является оговоренным сокращением)
устанавливаем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является прилагательным)
выполняем восстановление гомоглифов лексемы
склоняем лексему, как неодушевленное прилагательное
присоединяем парадигму лексемы к выходной парадигмы
иначе если (лексема является существительным)
если (не установлен ПРИЗНАК-ОПРЕДЕЛЕНИЕ-В-КОНЦЕ)
устанавливаем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
выполняем восстановление гомоглифов лексемы
склоняем лексему, как неодушевленное существительное
[с учетом признака МНОЖЕСТВЕННОЕ-ЧИСЛО]
присоединяем парадигму лексемы к выходной парадигмы
иначе
заносим лексему в каждую форму выходной парадигмы неизменной

Рассмотрим также алгоритмы тестирования принадлежности лексемы к именам существительным и прилагательным, поскольку они несколько отличаются от аналогичных алгоритмов для должностей. Список валидных сокращений существительных здесь таков, «уч-к», «отд.», «лаб.», «маг.».
Алгоритм тестирования лексемы на принадлежность
к именам существительным для подразделения
выполняем восстановление гомоглифов лексемы
если (лексема относится к списку валидных сокращений)
возвращаем положительный ответ
иначе если (лексема короче трех символов)
возвращаем отрицательный ответ
иначе если (лексема оканчивается на -а)
возвращаем положительный ответ
иначе если (лексема оканчивается на -о)
возвращаем положительный ответ
иначе если (лексема оканчивается на -ая)
возвращаем положительный ответ
иначе если (лексема оканчивается на -е)
возвращаем положительный ответ
иначе если (лексема оканчивается на -ы) и (установлен признак МНОЖЕСТВЕННОЕ-ЧИСЛО)
возвращаем положительный ответ
иначе если (лексема оканчивается на гласную)
возвращаем отрицательный ответ
иначе если (лексема оканчивается на -й)
если (лексема оканчивается на -ый, -ой, -ий)
возвращаем отрицательный ответ
иначе
возвращаем положительный ответ
иначе
возвращаем положительный ответ
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 8
Алгоритм тестирования лексемы на принадлежность
к именам прилагательным для подразделения
выполняем восстановление гомоглифов лексемы
если (лексема оканчивается на -орий) [санаторий, профилакторий, крематорий]
возвращаем отрицательный ответ
иначе если (лексема оканчивается на -ый, -ий, -ой)
устанавливаем признак РОД в состояние МУЖСКОЙ
возвращаем положительный ответ
иначе если (лексема оканчивается на -ая, -яя)
устанавливаем признак РОД в состояние ЖЕНСКИЙ
возвращаем положительный ответ
иначе если (лексема оканчивается на -ое, -ье)
устанавливаем признак РОД в состояние СРЕДНИЙ
возвращаем положительный ответ
иначе если (лексема оканчивается на -ые)
устанавливаем признак МНОЖЕСТВЕНОЕ-ЧИСЛО
возвращаем положительный ответ
иначе если (лексема оканчивается на -кие)
устанавливаем признак МНОЖЕСТВЕНОЕ-ЧИСЛО
возвращаем положительный ответ
иначе иначе
возвращаем отрицательный ответ

Как уже было сказано выше, алгоритмы склонения имен существительных и прилагательных для наименований подразделений несколько отличаются от аналогичных алгоритмов для склонения должностей. Во-первых, подразделения неодушевленные, а во-вторых, могут относиться к среднему роду или именоваться формально множественным числом.
Алгоритм определения способа склонения
неодушевленного существительного
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (длина слова равна одному символу)
не склоняем по типу «Не склоняемое»
иначе если (последний символ слова – точка)
не склоняем по типу «Сокращение»
иначе если (слово оканчивается на -ь)
если (МУЖСКОЙ-РОД) или (слово в списке слов типа «лагерь», «контроль»)
склоняем по типу «Второе склонение на -ь» [лагерь]
[лагерь, лагеря, лагерю, лагерь, лагерем, о лагере]
иначе
склоняем по типу «Третье склонение на -ь» [печь]
[печь, печи, печи, печь, печью, о печи]
иначе если (слово оканчивается на -й)
если (слово оканчивается на -ий)
склоняем по типу «Отадъективное существительное на -ий» [?]
[?, ?, ?, ?, ?, ?]
иначе
склоняем по типу «На -й» [музей]
[музей, музея, музею, музей, музеем, о музее]
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 8
иначе если (слово оканчивается на согласную)
если (слово оканчивается на шипящую)
склоняем по типу «С окончанием на шипящую» [?]
[?, ?, ?, ?, ?, ?]
[основу обрабатываем на беглые гласные]
[в творительном падеже учитываем -ом/-ем]
иначе
склоняем по типу «С окончанием на твердую согласную» [центр]
[центр, центра, центру, центр, центром, о центре]
[основу обрабатываем на беглые гласные]
иначе если (имя оканчивается на -о)
если (имя содержится в списке несклоняемых слов «бюро», «депо»)
не склоняем по типу «Несклоняемое слово на -о (не скл.)» [Депо]
иначе
склоняем по типу «Средний род на -о» [правительство]
[правительство, правительства, правительству, правительство,
правительством, о правительстве]
иначе если (имя оканчивается на -а)
если (предпоследняя буква слова – шипящая)
склоняем по типу «На -а после шипящей» [гостиница]
[гостиница, гостиницы, гостинице, гостиницу, гостиницей, о гостинице]
[в генетиве учитываем -ы/-и]
[в творительном падеже учитываем -ой/-ей]
иначе если (предпоследняя буква слова порождает -и- в генетиве)
склоняем по типу «На -а со специальной согласной перед ней» [установка]
[установка, установки, установке, установку, установкой, об установке]
иначе
склоняем по типу «На -а с согласной перед ней» [смена]
[смена, смены, смене, смену, сменой, о смене]
иначе если (слово оканчивается на -я)
если (слово оканчивается на -ия)
если (ПРИЗНАК-МНОЖЕСТВЕННОГО-ЧИСЛА)
склоняем по типу «На -ия (множественное число)» [сооружения]
[сооружения, сооружений, сооружениям, сооружения, сооружениями,
о сооружениях]
иначе
склоняем по типу «На -ия (женский род)» [лаборатория]
[лаборатория, лаборатории, лаборатории, лабораторию, лабораторией,
о лаборатории]
иначе
склоняем по типу «На -я (женский род)» [башня]
[башня, башни, башне, башню, башней, о башне]
иначе если (слово оканчивается на -ы) и (ПРИЗНАК-МНОЖЕСТВЕННОГО-ЧИСЛА)
склоняем по типу «Множественное число на -ы» [смолы]
[смолы, смол, смолам, смолы, смолами, о смолах]
иначе если (слово оканчивается на -е)
если (предпоследняя буква слова -и-)
склоняем по типу «На -ие (средний род)» [управление]
[управление, управления, управлению, управление, управлением, об управлении]
иначе если (слово в списке несклоняемых слов на -е «кафе», «кабаре»)
не склоняем по типу «Особое несклоняемое на -е»
иначе
склоняем по типу «На -е (средний род)» [хранилище]
[хранилище, хранилища, хранилищу, хранилище, хранилищем, о хранилище]
иначе
не склоняем по типу «Неизвестное неодушевленное существительное»
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 8
Алгоритм определения способа склонения
неодушевленного прилагательного
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (длина слова равна одному символу)
не склоняем по типу «Не склоняемое»
иначе если (последний символ слова – точка)
не склоняем по типу «Сокращение»
иначе если (слово оканчивается на -о)
не склоняем по типу «Часть составного прилагательного (не скл.)» [абонентско]
иначе если (слово оканчивается на -ий)
если (третья с конца буква слова -к-)
склоняем по типу «На -кий (мужской род)» [детский]
[детский, детского, детскому, детский, детским, о детском]
иначе
склоняем по типу «На -ий (мужской род)» [старший]
[старший, старшего, старшему, старший, старшим, о старшем]
иначе если (слово оканчивается на -ый)
склоняем по типу «На -ый (мужской род)» [главный]
[главный, главного, главному, главный, главным, о главном]
иначе если (слово оканчивается на -ой)
склоняем по типу «На -ой (мужской род)» [пищевой]
[пищевой, пищевого, пищевому, пищевой, пищевым, о пищевом]
[в творительном падеже обрабатываем чередование -ым/-им]
иначе если (слово оканчивается на -ая)
если (третья с конца буква слова – шипящая)
склоняем по типу «На -ая после шипящей (женский род)» [старшая]
[старшая, старшей, старшей, старшую, старшей, о старшей]
иначе
склоняем по типу «На -ая (женский род)» [главная]
[главная, главной, главной, главную, главной, о главной]
иначе если (слово оканчивается на -яя)
склоняем по типу «На -яя (женский род)» [верхняя]
[верхняя, верхней, верхней, верхнюю, верхней, о верхней]
иначе если (слово оканчивается на -ое)
если (третья буква с конца слова -т- или -н-)
склоняем по типу «На -ое после т или н (средний род)» [ремонтное]
[ремонтное, ремонтного, ремонтному, ремонтное, ремонтным, о ремонтном]
иначе
склоняем по типу «На -ое (средний род)» [городское]
[городское, городского, городскому, городское, городским, о городском]
иначе если (слово оканчивается на -ье)
склоняем по типу «На -ье (средний род)» [охотничье]
[охотничье, охотничьего, охотничьему, охотничье, охотничьим, об охотничьем]
иначе если (слово оканчивается на -ые)
склоняем по типу «На -ые (множественное число)» [очистные]
[очистные, очистных, очистным, очистные, очистными, об очистных]
иначе если (слово оканчивается на -ие)
склоняем по типу «На -ие (множественное число)» [биологические]
[биологические, биологических, биологическим, биологические, биологическими,
о биологических]
иначе
не склоняем по типу «Неизвестное неодушевленное прилагательное»

ПРИЛОЖЕНИЕ 9
Алгоритм членения наименования должности на лексемы
сбрасываем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
сбрасываем признак ОТКРЫВАЮЩАЯ-СКОБКА-НАЙДЕНА
сбрасываем признак ОТКРЫВАЮЩАЯ-КАВЫЧКА-НАЙДЕНА
разбиваем должность на лексемы по границам-символам («пробел», «кавычка», ()[]<>{}.,)
цикл для каждой лексемы
если (лексема равна точке)
[предполагаем, что предыдущая лексема была сокращением]
присоединяем текущую лексему к предыдущей лексеме
если (длина лексемы меньше четырех символов) и (предыдущая лексема равна дефису)
[предполагаем, что это все части сокращения через дефис]
присоединяем текущую и предыдущую лексемы к предпредыдущей лексеме
конец цикла
цикл для каждой из оставшихся лексем
выполняем склонение лексемы
конец цикла

Получив лексемы, составляющие наименование должности, необходимо определить синтаксическую роль каждой лексемы. Синтаксическая роль лексемы определяется нами путем анализа ее местоположения в предложении и по визуальному сходству с той или иной частью речи.
Алгоритм определения синтаксической роли лексемы
в наименовании должности
если (лексема является пустой строкой)
выходим
если (лексема является открывающей скобкой)
устанавливаем признак ОТКРЫВАЮЩАЯ-СКОБКА-НАЙДЕНА
сбрасываем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
если (лексема является закрывающей скобкой)
сбрасываем признак ОТКРЫВАЮЩАЯ-СКОБКА-НАЙДЕНА
если (лексема является кавычкой)
инвертируем признак ОТКРЫВАЮЩАЯ-КАВЫЧКА-НАЙДЕНА
если (лексема является пробелом, кавычкой, «()[]<>{}.,»)
заносим ее в каждую форму выходной парадигмы неизменной
выходим
если (НАЙДЕНА-ОТКРЫВАЮЩАЯ-СКОБКА)
если (ПРИЗНАК-НЕСКЛОНЯЕМОСТИ-СКОБОК)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является словом «по», «с», )
устанавливаем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема не является валидным словом)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является существительным)
устанавливаем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
выполняем восстановление гомоглифов лексемы
склоняем лексему, как существительное
присоединяем парадигму лексемы к выходной парадигмы
иначе если (лексема является прилагательным)
выполняем восстановление гомоглифов лексемы
склоняем лексему, как прилагательное
присоединяем парадигму лексемы к выходной парадигмы
иначе
устанавливаем признак ПОДЛЕЖАЩЕЕ-В-СКОБКАХ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 9
иначе если (НАЙДЕНА-ОТКРЫВАЮЩАЯ-КАВЫЧКА)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (ПОДЛЕЖАЩЕЕ-НАЙДЕНО)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является словом «по» или «с»)
устанавливаем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема не является валидным словом)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема не является кириллическим словом)
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема оканчивается точкой) [лексема-сокращение]
если (лексема является оговоренным сокращением)
устанавливаем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
заносим лексему в каждую форму выходной парадигмы неизменной
иначе
заносим лексему в каждую форму выходной парадигмы неизменной
иначе если (лексема является существительным)
устанавливаем признак ПОДЛЕЖАЩЕЕ-НАЙДЕНО
выполняем восстановление гомоглифов лексемы
склоняем лексему, как существительное
присоединяем парадигму лексемы к выходной парадигмы
иначе если (лексема является прилагательным)
выполняем восстановление гомоглифов лексемы
склоняем лексему, как прилагательное
присоединяем парадигму лексемы к выходной парадигмы
иначе
заносим лексему в каждую форму выходной парадигмы неизменной

Далее рассмотрим алгоритмы, к которым обращается только что рассмотренный алгоритм. Наиболее интересными из них являются алгоритмы определения части речи. Тестирование лексемы на принадлежность к именам существительным осложняется тем, что в русском языке имеются так называемые отадъективные существительные – слова по форме похожие на прилагательные, но являющиеся существительными. Примеры таких слов: «рабочий», «заведующий». Неприятно то, что по внешним признакам такие существительные не определяются, поэтому каждую тестируемую лексему приходится предварительно сравнивать со всеми известными отадъективными существительными. На настоящий момент в этот список нами помещены следующие слова: «заведующий», «рабочий», «управляющий», «горничная», «дежурный». Очевидно, по мере эксплуатации алгоритма этот список будет пополняться.
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 9
Алгоритм тестирования лексемы на принадлежность
к именам существительным
выполняем восстановление гомоглифов лексемы
если (лексема принадлежит к списку отадъективных существительных)
возвращаем положительный ответ
иначе если (лексема относится к списку валидных сокращений)
возвращаем положительный ответ
иначе если (лексема короче трех символов)
возвращаем отрицательный ответ
иначе если (лексема оканчивается на -а)
возвращаем положительный ответ
иначе если (лексема оканчивается на -ая)
возвращаем отрицательный ответ
иначе если (лексема оканчивается на -я)
возвращаем положительный ответ
иначе если (лексема оканчивается на гласную)
возвращаем отрицательный ответ
иначе если (лексема оканчивается на -й)
возвращаем отрицательный ответ
иначе
возвращаем положительный ответ
Алгоритм тестирования лексемы на принадлежность
к именам прилагательным
выполняем восстановление гомоглифов лексемы
если (лексема оканчивается на -й) [может быть лучше набор -ый, -ий, -ой]
возвращаем положительный ответ
иначе если (лексема оканчивается на -ая)
возвращаем положительный ответ
иначе
возвращаем отрицательный ответ

Кратко рассмотрим принципы работы некоторых других алгоритмов, на которые ссылаются алгоритмы данной группы. Принадлежность лексеме к списку валидных сокращений определяется сравнением лексемы со списком из двух элементов: «зам.» и «зав.». Этот список также, как и список отадъективных существительных, будет расти по мере эксплуатации алгоритма. Принадлежность лексемы к валидным словам определяется отсутствием в ней цифр, длиной более дву символов и наличием хотя бы одной гласной буквы. Способы определения того, является ли лексема кириллическим словом и восстановления гомоглифов, на наш взгляд, отдельного описания не заслуживают.
В алгоритме определения синтаксической роли лексемы приводятся ссылки на алгоритмы получения парадигм имен существительных и прилагательных. Поскольку эти алгоритмы рассчитаны на сравнительно узкий круг имен, они просты и по структуре напоминают алгоритмы для получения парадигм фамилий и личных имен.
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 9
Алгоритм определения способа склонения одушевленного существительного
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (длина слова равна одному символу)
не склоняем по типу «Не склоняемое»
иначе если (последний символ слова – точка)
не склоняем по типу «Сокращение»
иначе если (слово оканчивается на -ь)
если (ЖЕНСКИЙ-РОД)
склоняем по типу «Третье склонение на -ь» [мышь]
[мышь, мыши, мыши, мышь, мышью, о мыши]
иначе
склоняем по типу «Второе склонение» [егерь]
[егерь, егеря, егерю, егеря, егерем, о егере]
иначе если (слово оканчивается на -й)
склоняем по типу «Отадъективное существительное» [рабочий]
[рабочий, рабочего, рабочему, рабочего, рабочим, о рабочем]
иначе если (слово оканчивается на шипящую)
склоняем по типу «С окончанием на шипящую» [кузнец]
[кузнец, кузнеца, кузнецу, кузнеца, кузнецом, о кузнеце]
[основу обрабатываем на беглые гласные]
иначе если (слово оканчивается на согласную) [уже только на твердую]
склоняем по типу «С окончанием на твердую согласную» [аппаратчик]
[аппаратчик, аппаратчика, аппаратчику, аппаратчика, аппаратчиком, об аппаратчике]
[основу обрабатываем на беглые гласные]
иначе если (имя оканчивается на -а)
если (предпоследняя буква слова – шипящая)
склоняем по типу «На -а после шипящей» [?]
[?, ?, ?, ?, ?, ?]
иначе если (предпоследняя буква слова порождает -и- в генетиве)
склоняем по типу «На -а со специальной согласной перед ней» [машинистка]
[машинистка, машинистки, машинистке, машинистку, машинисткой, о машинистке]
иначе
склоняем по типу «На -а с согласной перед ней» [медсестра]
[медсестра, медсестры, медсестре, медсестру, медсестрой, о медсестре]
иначе если (слово оканчивается на -я)
????
иначе
не склоняем по типу «Неизвестное одушевленное существительное»

Нижеприведенный листинг иллюстрирует способ определения способа склонения прилагательного. В отличие от версии этого же алгоритма, использованной нами для обработки наименований структурных подразделений, этот алгоритм не обрабатывает прилагательные среднего рода, а также прилагательные множественного числа.
ПРОДОЛЖЕНИЕ ПРИЛОЖЕНИЯ 9
Алгоритм определения способа склонения прилагательного
если (получена пустая строка)
не склоняем по типу «Пустая строка»
иначе если (длина слова равна одному символу)
не склоняем по типу «Не склоняемое»
иначе если (последний символ слова – точка)
не склоняем по типу «Сокращение»
иначе если (слово оканчивается на -о)
не склоняем по типу «Часть составного прилагательного (не скл.)» [абонентско]
иначе если (слово оканчивается на -ий)
если (третья с конца буква слова -к-)
склоняем по типу «На -кий (мужской род)» [детский]
[детский, детского, детскому, детского, детским, о детском]
иначе
склоняем по типу «На -ий (мужской род)» [старший]
[старший, старшего, старшему, старшего, старшим, о старшем]
иначе если (слово оканчивается на -ый)
склоняем по типу «На -ый (мужской род)» [главный]
[главный, главного, главному, главного, главным, о главном]
иначе если (слово оканчивается на -ой)
склоняем по типу «На -ой (мужской род)» [пищевой]
[пищевой, пищевого, пищевому, пищевого, пищевым, о пищевом]
[в творительном падеже обрабатываем чередование -ым/-им]
иначе если (слово оканчивается на -ая)
если (третья с конца буква слова – шипящая)
склоняем по типу «На -ая после шипящей (женский род)» [старшая]
[старшая, старшей, старшей, старшую, старшей, о старшей]
иначе
склоняем по типу «На -ая (женский род)» [главная]
[главная, главной, главной, главную, главной, о главной]
иначе если (слово оканчивается на -яя)
склоняем по типу «На -яя (женский род)» [верхняя]
[верхняя, верхней, верхней, верхнюю, верхней, о верхней]
иначе
не склоняем по типу «Неизвестное прилагательное»

Поделиться в соц. сетях

Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники

Яндекс.Метрика