CC BY
49
ВЕСТНИК САНКТ-ПЕТЕРБУРГСКОГО УНИВЕРСИТЕТА
Сер. 10. 2012. Вып. 4
УДК 004.434:004.42
Д. В. Кознов, А. В. Азарсков, А. В. Самочадин, Ю. А. Шевцова, К. Ю. Романовский
МОДЕЛЬНО-ОРИЕНТИРОВАННЫЙ МЕТОД СПЕЦИФИКАЦИИ ГОСУДАРСТВЕННЫХ УСЛУГ
1. Введение. Современный человек, живя в социальном мире, должен следовать большому количеству различных формальных процедур. И речь идет не только о правилах и элементарных нормах поведения в обществе в целом или о различных психологических и социальных «программах». Человек все больше уподобляется некоторому вычислителю и должен весьма эффективно выполнять конкретные процедуры - правильно обходиться со своей кредитной картой, осуществить нужную последовательность шагов при оформлении кредита в банке, получении страховки или визы, при поступлении в университет и т. д. Подобные процедуры невозможно полностью автоматизировать, они требуют разнообразных действий человека и вместе с тем следуют определенным регламентам. В целом количество таких процедур в нашей жизни увеличивается, их сложность растет - они включают в себя все новые и новые случаи и возможности. Достоинства данной тенденции очевидны: общество и бизнес становятся более организованными и управляемыми, люди получают все более качественные сервисы, возрастают гарантии в безопасности и пр. Но в связи с этим возникают и проблемы. Подобные процедуры часто оказываются очень объемными, содержат большое количество формальных шагов и различных ветвлений, активно взаимодействуют друг с другом, часто изменяются (так как меняются законы, правила работы компаний
Кознов Дмитрий Владимирович — кандидат физико-математических наук, доцент кафедры системного программирования математико-механического факультета Санкт-Петербургского государственного университета. Количество опубликованных работ: более 50. Научные направления: визуальное моделирование (UML-подобные языки и программные средства), разработка технической документации, электронное образование. E-mail: dkoznov@gmail.com.
Азарсков Алексей Вольдемарович — директор проекта «Информационное общество» макрорегио-нального филиала «Северо-Запад» ОАО «Ростелеком». Предыдущая должность — заместитель председателя Комитета по информатизации и связи Правительства Санкт-Петербурга. Область практических и научных интересов — телекоммуникации, электронное правительство, электронные государственные услуги. E-mail: vazarskov@gmail.com.
Самочадин Александр Викторович — профессор Санкт-Петербургского политехнического университета, генеральный директор компании «СОФТ-КОНСАЛТ». Количество опубликованных работ: более 50. Научные направления: имитационное моделирование, программная инженерия, электронное правительство. E-mail: samochadin@soft-consult.ru.
Шевцова Юлия Александровна — студентка математико-механичес^го факультета Санкт-Петербургского государственного университета, специальность «Информатика в международных отношениях». E-mail: ShevtsovaUlia-mm@yandex.ru.
Романовский Константин Юрьевич — кандидат физико-математических наук, старший преподаватель кафедры системного программирования математико-механического факультета Санкт-Петербургского государственного университета, руководитель Научно-технического центра «Системы управления аналитическим оборудованием» компании ЗАО ЛАНИТ-ТЕРКОМ. Количество опубликованных работ: 15. Научные направления: технологии разработки электронной документации, управление разработкой программного обеспечения. E-mail: kromanovsky@yandex.ru.
© Д. В. Кознов, А. В. Азарсков, А. В. Самочадин, Ю. А. Шевцова, К. Ю. Романовский, 2012
и т. д.). Поэтому, с одной стороны, обычным людям оказывается непросто разобраться в них и выбрать из различных цепочек формальных шагов и множества условий только те, которые касаются именно их ситуаций. С другой стороны, в спецификации таких процедур закрадывается большое количество ошибок и противоречий, существует проблема сопровождения и обновления их описаний.
Особым видом формальных процедур, с которыми сталкивается каждый из нас, являются государственные и муниципальные услуги, например получение водительского удостоверения, паспорта, заграничного паспорта, регистрация купленной/построенной недвижимости, оформление и получение различных льгот. В настоящее время в мире государственные услуги исследуются преимущественно в контексте обеспечения к ним электронного доступа. Общие концепции электронного правительства и электронных государственных услуг изложены в [1—3]. В разных странах изучаются особенности, текущее положение и перспективы электронных государственных услуг, например в Европе [4-6], Чили [7], на Тайване [8], в Малазии [9], Африке в целом [10] и, в частности, в Танзании [11]. Существуют также подходы, нацеленные на отдельные предметные области (тоже в основном в рамках отдельных стран), например электронные платежи [12], туристический бизнес [13], налоги [9], межнациональные отношения (cross border communications) [14]. Но в настоящее время отсутствуют развитые подходы для формальной спецификации государственных услуг. По сути единственным методом в этой области является OntoGov [5], который основывается на онтологическом подходе, но является, скорее, общим руководством, чем хорошо определенным методом, и не содержит удобных средств для моделирования государственных услуг. Однако переход от обычных государственных услуг к электронным означает существенное повышение степени их формализации. Промежуточным шагом здесь могли бы быть модели: они удобны при изучении предметной области, их легче, например, по сравнению с текстами обсуждать со специалистами, изменять и корректировать. Также возможны автоматическая верификация моделей, генерация по ним программного кода и другие преимущества модельно-ориентированного подхода к разработке программного обеспечения (ПО) (Model-Driven Development) [15-17]. Однако непосредственное использование модельно-ориентированного подхода - языка, методик, программных средств поддержки - затруднительно в виду особенностей области государственных сервисов.
В настоящей работе предлагается адаптация модельно-ориентированного подхода к формализации государственных услуг. Представлен метод, который состоит из следующих частей: 1) общая концепция модельно-ориентированной спецификации государственных услуг; 2) расширение онтологии OWL-S понятиями из области государственных услуг РФ; 3) нотация для описания процесса оказания государственной услуги, расширяющая нотацию BPMN [18]; 4) нотация для моделирования иерархической модели документов, основанная на диаграммах возможностей [19] и подходе DocLine [20, 21]; 5) нотация для информационной модели, основанная на XML. Мы модифицируем нотацию BPMN, расширяя ее ссылками на пакеты документов и фрагменты текстовой информации. Модель возможностей адаптируем для описания вариативных пакетов документов, вводя в нее группы элементов с логическими ограничениями, разные типы узлов - промежуточные (ситуации) и терминальные (документы), а также конструкцию InfoBlock (форматированный комментарий). Кроме того, в работе обсуждается возможность автоматической генерации Web-описания услуги на конкретном примере. Идеи и методы демонстрируются на примере получения заграничного паспорта. Представлена также апробация метода в проекте «Improving Social Services», посвященном формализации государственных услуг Финляндии, используемых
русскими туристами, а также российских государственных услуг, востребованных финскими туристами.
2. Обзор используемых подходов. Для описания государственных услуг были использованы следующие средства: OWL-S*)/OntoGov Ontologies [5] для создания онтологии предметной области, BPMN [18] для спецификации модели процессов, диаграммы возможностей (feature diagrams) [19] для описания модели документов. Рассмотрим эти подходы более подробно.
2.1. Проект OntoGov. Этот проект направлен на усовершенствование жизненного цикла электронных государственных сервисов, в частности механизмов для их изменения и обновления, проводя изменения от законов до software. В частности, в рамках проекта используется подход метаонтологий (Meta Ontology Approach), т. е. создается набор связанных между собой онтологий для описания различных аспектов электронных государственных сервисов. Представим список онтологий OntoGov:
1. Профайл-онтология (profile ontology) - определяет верхнеуровневое описание программной реализации услуги: имя соответствующего электронного сервиса, его краткое текстовое описание, версию, дату создания, текущее состояние, имя автора и пр.
2. Онтология процесса (process ontology) - моделирует поток действий и данных, задавая алгоритм работы электронной услуги.
3. Классификационная онтология (life-event ontology) - содержит классификацию электронных государственных услуг.
4. Онтология предметной области (domain ontology) - описывает терминологию, используемую в данной предметной области.
5. Организационная онтология (organisational ontology) - описывает роли и зоны ответственности организации, реализующей данную услугу (предполагается, что такая организация одна!).
6. Онтология жизненного цикла (lifecycle ontology) - описывает процесс принятия решения об изменении услуги. Это нужно для того, чтобы поддержать трассировку изменений от законов и административных регламентов до программной реализации сервиса.
7. Онтология законодательных актов (legal ontology) - моделирует структуру нормативных документов (разделы, подразделы и пр.), на которых основывается услуга.
8. Онтология федерального законодательства (legal-federal ontology) - базируется на онтологии законодательных актов и содержит описание федеральных законов, на которых основывается данная услуга.
9. Онтология регионального законодательства (legal-state ontology) - является специализацией онтологии федерального законодательства, расширяя последнюю региональными инструкциями и административными регламентами.
10. Онтология муниципального законодательства (legal-municipality ontology) - расширяет онтологию регионального законодательства: добавляется информация муниципального уровня.
2.2. BPMN. В настоящее время существует значительное количество подходов к формальному описанию бизнес-процессов (см., например, обзор [22]). Среди этих подходов BPMN является наиболее зрелым. Его достоинствами являются большая выразительная сила графической нотации и наличие строгой исполняемой семантики для
*) URL: http://www.daml.org/services/owl-s/.
конструкций. Процесс в BPMN может состоять из таких элементов:
1. Сущности (flows objects), которые могут быть действием (activity), портом (gateway), событием (event).
2. Связи (connecting objects), которые соединяют действия и данные в единый поток исполнения; они могут быть следующих видов: (i) поток исполнения (sequence flow) - переход от одного действия к другому; (ii) поток сообщений (message flow) - обмен сообщениями между разными участниками процесса; (iii) ассоциация (association) - для определения переходов между действиями (например, при возникновении исключений), а также для «прикрепления» комментариев к действиям и данным и т. д.
3. Участники процесса (swimlanes), которые могут быть: (i) внешними по отношению к процессу (pools); (ii) внутренними (lanes) - например, функциональные отделы, по которым проходит процесс.
4. Артефакты (artifacts) процесса: данные (data object), группы (groups), комментарии (annotations).
2.3. Диаграммы возможностей. Этот вид диаграмм (feature diagrams) представляет набор возможностей (features) и иерархические связи между ними с явно выделенным корнем иерархии, который называется концептом (concept) [19]. Основная цель диаграмм возможностей - в наглядном виде формализовать вариативные свойства системы. Возможность (feature) - это обособленное свойство системы, значимое с точки зрения пользователя или разработчика. Иерархические связи отображают декомпозицию концепта и/или возможностей и являются отношениями включения. Включения бывают обязательные и необязательные, а также возможны специальные свойства у группы связей, выходящих из одной вершины: 1) можно выбрать любое подмножество возможностей, в которые ведут линии, попавшие в данный сектор; 2) можно выбрать только одну из возможностей. Диаграммы возможностей были предложены в контексте разработки линеек программных продуктов (software product lines) [23].
2.4. Технология DocLine. Разработка и сопровождение больших пакетов электронной документации, включающих в себя многочисленные документы, является сложной задачей. Для обеспечения более эффективной сопровождаемости таких пакетов предложена технология DocLine [20, 21, 24-29], поддерживающая гибкое повторное использование как самих документов, так и их фрагментов. Для наглядного изображения схемы повторного использования документации в DocLine применяются диаграммы возможностей. Иерархия включения используется для изображения вхождения документов и фрагментов, вариативные конструкции - для обозначения возможных вариантов вхождения документов и их фрагментов в то или иное место пакета документации. Таким образом, задается пакет документации/документ с вариациями. Эти вариации разрешаются (т. е. делается тот или иной выбор в точках вариативности) с тем, чтобы получить конкретный пакет документов/документ.
3. Описание метода. Рассмотрим представленный в статье метод.
3.1. Мотивация. Предлагаемый метод нацелен на создание формальных спецификаций государственных услуг в рамках некоторой предметной области (domain) на основе общей онтологии этой предметной области и ряда моделей. Предметные области государственных услуг могут быть разными и строиться «вертикальным» делением - отдельный регион, какое-то одно муниципальное образование в рамках некоторого региона. Их можно строить также «горизонтально», например выделение различных подобластей государственных услуг Санкт-Петербурга (жилищная сфера, социальное обеспечение и т. д.). Возможность сфокусироваться на одной предметной
области позволяет масштабировать метод, что очень важно, имея в виду распределенную структуру правительственных, региональных и муниципальных подразделений.
Предлагаемый метод предназначается для: 1) упрощения процедуры создания, проверки и сопровождения административных регламентов; 2) облегчения доступа конечных пользователей к информации об услугах; 3) облегчения сопровождения и обновления этих описаний.
Административные регламенты, являющиеся официальными описаниями государственных услуг, создаются разными правительственными учреждениями, поэтому нередка ситуация, когда они противоречат друг другу, используют различные термины для обозначения одних и тех же понятий и т. д. Кроме того, в них порой содержатся ошибки из-за сложности описываемых процедур: государственные услуги обычно имеют большую разветвленную структуру для того, чтобы охватить разнообразные категории граждан. Например, при оформлении в РФ заграничного паспорта на ребенка последний может прийти с одним из родителей, а может - с человеком, уполномоченным родителями на данное действие. И в этих случаях необходимо предоставлять разные документы на ребенка. Сложность описаний услуг как раз и происходит из-за необходимости специфицировать подобные случаи и подслучаи. Именно в редко встречающихся «боковых» ветках регламентов часто кроются ошибки и неточности, из-за которых люди теряют время при получении той или иной государственной услуги. Более того, информация о многочисленных частных ситуациях часто оказывается непонятной конечным пользователям, которых она касается.
Также существуют проблемы доступности описаний государственных услуг. Общепринятые способы здесь следующие : 1) либо публикация полной информации (например, исходных регламентов), но в виде многостраничного «плоского» текста, имеющего ряд гиперссылок на другие подобные документы; 2) либо наглядные, но очень упрощенные описания.
Наконец, существует большая проблема сопровождения и обновления больших объемов информации, в частности описания государственных услуг. Изменяются законы и административные регламенты, меняются адреса и расписание офисов и другая информация. Все эти изменения необходимо вносить в описания государственных услуг, в том числе и в Web-описания.
3.2. Обзор. Решению перечисленных выше проблем может помочь предлагаемый нами формальный метод описания государственных услуг. Его схема представлена на рис. 1.
По нашему мнению, основной моделью описания государственной услуги является модель бизнес-процесса. Она должна описывать последовательность шагов заявителя, начиная от предварительной подготовки и подачи документов и заканчивая полным получением самой услуги. К модели бизнес-процессов должна быть приложена вариативная модель документов, описывающая весь пакет входных-выходных документов услуги. Наконец, модель бизнес-процессов и модель документов должны содержать текстовые пояснения - адреса и расписание работы соответствующих государственных органов, варианты цен и пр. Эта информация задается в описательной модели. Кроме того, все модели и описания должны использовать единую систему терминов и понятий для всех государственных услуг данной предметной области. Такая информация помещается нами в онтологию данной предметной области. Необходимо отметить, что предлагаемые нами средства формального описания государственных услуг не предназначаются напрямую для конечного пользователя. Многочисленные исследования показывают, что визуальные спецификации трудны для восприятия
неподготовленными людьми. Целевые описания должны строиться на основе предложенных моделей в полуавтоматическом режиме, с использованием специальных метафор, обозначаемых на рис. 1 как Web-Content Metaphors (WCMs).
Рис. 1. Схема метода
Рассмотрим более подробно предлагаемые модели.
3.3. Онтология предметной области. Наш подход к описанию государственных сервисов основывается на разработке онтологии предметной области. В этой онтологии должны быть тщательно определены общие понятия рассматриваемой предметной области, которые будут применяться при моделировании услуг, а также при составлении регламентов. Не вдаваясь в синтаксические детали, перечислим те базовые понятия, которыми мы расширили OWL-S и которые характерны, например, для государственных услуг РФ (рис. 2): 1) список исполнительных органов и организаций, участвующих в оказании услуг (Authorities); 2) получатели и заявители данной услуги -категории граждан, виды юридических лиц (Receivers) и пр.; 3) нормативно-правовые акты, регламентирующие данную предметную область (Laws and regulations); 4) документы, используемые в государственных услугах этой предметной области, включая альтернативные варианты, ссылки на шаблоны в Интернете, дополнительные пояснения и пр. (Documents); 5) результаты оказания государственных услуг (Results); 6) основания для отказа в предоставлении услуг (Reasons for rejections ); 7) различные описания и понятия - так, для сферы жилищных услуг это виды жилья, виды льгот и льготных категорий граждан и пр. (Terms).
Мы не стали, подобно OntoGov, задавать несколько онтологий, так как ориентируемся пока на небольшие предметные области - в частности, один комитет правительства региона (например, жилищный комитет Санкт-Петербурга). Но, безусловно, если предметная область оказывается значительной (например, все государственные
Рис. 2. Онтология предметной области
услуги Санкт-Петербурга), то требуется более сложная онтология. Другим отличием от OWL-S/OntoGov является то, что часть информации о государственных сервисах мы вынесли из онтологии в модели.
3.4. Модель процесса. Для каждой услуги с помощью модели процесса предлагается строить ее пошаговое описание. Под шагами подразумеваются действия пользователя, которые он должен выполнить для получения данной услуги. Для задания поведенческой модели государственной услуги мы используем нотацию BPMN с небольшими добавлениями. Мы вводим две новые конструкции - блок документации ^осВ1оск) для ссылки на фрагмент модели документов и инфоблок (ШоВ1оск) для ссылки на текстовую информацию. Эти конструкции введены для удобства и будут подробно рассмотрены в рамках модели документов и описательной модели соответственно.
Рис. 3. Пример модели процессов
На рис. 3 представлен пример поведенческой модели для процедуры получения загранпаспорта с помощью электронного сервиса на федеральном государственном портале госуслуг РФ*). Вначале проверяется, зарегистрирован ли пользователь на портале или нет, и если нет, то он перенаправляется на регистрацию. С состоянием «Регистрация» связан инфоблок «Правила регистрации», где подробно изложены правила регистрации на портале**). Следующий шаг - заполнение анкеты. Особенности заполнения анкеты для разных видов паспортов скрыты в соответствующем инфоблоке «Правила заполнения анкеты». Важно не загромождать поведенческую модель обилием мелких шагов, и наличие информационной модели, а также модели документов предоставляет такую возможность. Следующий шаг происходит после получения пользователем приглашения в УФМС. С ним связано соответствующее описание, помещенное в инфоблок «Приглашение в УФМС». После этого выполняется шаг «Сдача документов в УФМС». С этим шагом связывается ссылка на блок документации «Документы на загранпаспорт». Вариативные детали (в данном случае касающиеся документов, которые могут потребоваться получателю/заявителю) вынесены из поведенческой модели для ее упрощения и повышения удобства работы с ней. Последний шаг - «Получение загранпаспорта в УФМС» предваряется событием «Приглашение в УФМС».
3.5. Модель документов. Как правило, государственные услуги используют множество различных документов. Если все их изображать на модели процессов так, как это предлагается в BPMN, т. е. с помощью конструкции data object, то модель окажется совершенно нечитаемой, так как каждой такой конструкции соответствует один документ. Кроме того, в зависимости от индивидуальных особенностей своей ситуации пользователь должен предоставлять разные документы для получения одной и той же услуги, и это вообще не выразить средствами BPMN. Таким образом, оказывается целесообразным создать отдельную модель для задания всех возможных документов, необходимых при получении данной услуги, а в модели процессов использовать ссылки на ее фрагменты. Следуя подходу DocLine [20, 21, 24-29], для построения модели документов мы используем модифицированную модель возможностей [19]. С ее помощью можно задать все возможные варианты документов, которые могут понадобиться при получении данной услуги. В зависимости от особенностей ситуации заявителя/получателя «разрешается» вариативность в этой модели - выбирается то или иное поддерево модели. Однако в отличие от DocLine мы акцентируемся не на вариативном вхождении одинаковых фрагментов текста в один или несколько документов, а варьируем вхождение целых документов в итоговый пакет, необходимый для получателя/заявителя услуги. На рис. 4 показан фрагмент такой модели для модели процессов, приведенных на рис. 3, - дерево документов «Документы на загранпаспорт».
Каждое дерево в модели документов содержит корень (название), промежуточные
вершины (названия вариативных ситуаций) и терминальные вершины - названия до)
кументов ):
<DocBlock>::=<Root> <IntermidiateNode>*<Leaf>*
*) URL: http://www.gosuslugi.ru/ru/.
**) Содержание этого инфоблока отображено на странице портала URL: https://esia.gosuslugi.ru/sia-web/rf/registration/lp/Index.spr.
***) Для формального описания модели документов использована грамматика в форме Бэкуса— Науэра, широко применяемая для формальной спецификации языков программирования.
Рис. 4- Пример модели документов
Корень и промежуточная вершина могут содержать набор групп, а также терминальные вершины и ссылки на инфоблоки с информацией, имеющей отношение к данному узлу:
<Root>|<IntermidiateNode> ::= <Leaf>*<Group>*<InfoBlock>*
Документы, непосредственно связанные с узлом модели, являются обязательными в том смысле, что если этот узел выбран, то и все его документы считаются тоже выбранными. Например, если мы выбрали группу «От 18 лет», то выбрали тем самым и документы «Паспорт гражданина РФ», «Копия паспорта гражданина РФ». Документ «Заверенная по месту работы копия трудовой книжки» является примером условно
входящего документа - он нужен, только если получатель загранпаспорта имеет постоянную работу. Это одна из вариативных конструкций модели документов.
Группа есть еще одна вариативная конструкция. Она может содержать логическое условие и/или вариативный оператор. Например, группа узлов «До 18 лет», «От 18 лет» содержит только логическое условие «Возраст», в зависимости от значения которого выбирается тот или иной узел группы. Группа узлов «Отслуживший», «Военнослужащий», «Призывник» имеет как логическое условие - «Мужчины в возрасте от 18 до 27 лет», которое в данном случае отвечает не за выбор одного из узлов группы, как в предыдущем примере, а за вхождение в группу. Вариативный оператор xor0 указывает на то, что должен быть выбран только один из вариантов, но может быть не выбран ни один (например, человек не годен к воинской службе по состоянию здоровья; этот вариант тоже нужно было бы определить в нашей модели, но мы опустили его, а также множество других вариантов из-за ограничений размеров статьи) оператор. Спецификация группы выглядит следующим образом:
<Group>::= {<IntermidiateNode>|<Leaf>}* [<Adornment>] [<Condition>],
где <Adornment> является вариативным оператором, а <Condition> - логическим условием*).
Мы включили в нашу модель следующие виды вариативных операторов**):
<Adornment>::= <Xor>|<Xor0>,
где <Xor> обозначает исключающее или, а <Xor0> - исключающее или с возможностью пустого выбора.
3.6. Описательная модель. Эта модель предназначена для структуризации разной полезной текстовой информации, которая может понадобиться пользователю данной услуги и которую удобно разбить на части, связав их с различными элементами модели. Если такую информацию изображать на модели процессов так, как предлагается в BPMN, т. е. с помощью конструкции annotation, то для просмотра и редактирования этой информации все равно понадобятся дополнительные средства, так как ее объем оказывается значительным (т. е. это не короткий комментарий, для задания которого, собственно, и предназначена конструкция annotation). Кроме того, данная информация может иметь дополнительную структуру, которую невозможно задать в рамках BPMN. Наконец, хотелось бы, чтобы описательная модель была самостоятельной и могла использоваться и без поведенческой модели - например, в модели документов.
Описательную модель мы предлагаем специфицировать с помощью XML, а для работы с ней должен быть создан специальный текстовый редактор. Описательная модель строится для всей рассматриваемой предметной области и состоит из разделов, соответствующих отдельным сервисам***^
<xs:comlpexType name = "InformationModel">
<xs:attribute name = "ModelName" type = "xs:string"/>
*) В дальнейшем мы планируем определить переменные, по значению которых в условии должно происходить ветвление. Таким образом, логическое условие превратится в обычное логическое выражение.
**) В дальнейшем мы планируем расширить этот список после дополнительных экспериментов с моделью документов.
***) Здесь использован в качестве средства спецификации XML-формат под названием XML Schema [30].
<xs:sequence>
<xs:element name = "Service" type = "Service" maxOccurs = "unbounded"/> </xs:sequence> </xs:comlpexType>
Сервис состоит из инфоблоков, ссылки на которые можно использовать в поведенческой модели и модели документов:
<xs:comlpexType name = "Service"> <xs:sequence>
<xs:element name = "InfoBlock" type = "InfoBlock" maxOccurs = "unbounded"/> </xs:sequence> </xs:comlpexType>
Инфоблок, в свою очередь, состоит из разделов, а внутри последних уже находится неструктурированный текст:
<xs:comlpexType name = "InfoBlock"> <xs:sequence>
<xs:element name = "Section" type = "Section" maxOccurs = "unbounded"/> </xs:sequence> </xs:comlpexType>
<xs:comlpexType name = "Section"> <xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name = "Name" type = "xs:string"/> </xs:extension> </xs:simpleContent> </xs:comlpexType>
На разделы инфоблоков, так же как и на сами инфоблоки, можно ссылаться из поведенческой модели и модели документов. Ссылка должна выглядеть следующим образом - имя_инфоблока.имя_раздела.
3.7. Автоматизированная разработка Web-контента. Модели государственных услуг полезны не только при разработке и проверке административных регламентов. Они также могут и должны применяться для автоматизированного порождения Web-контента, описывающего порядок использования государственных услуг для пользователей. Рассмотрим, как можно автоматически генерировать формы описания ситуаций при определении пользователем точного пакета документов, которые необходимо подать для получения услуги. Исходной информацией является модель документации.
На рис. 5 показана Web-форма, в которой пользователь должен ответить на вопросы, и в соответствии с ответами ему будет предложено продолжение. Фактически, отвечая на вопросы, он обходит дерево модели документации с рис. 4 и когда добирается до конца, то ему выдается список документов, соответствующих его ситуации.
Вся информация в этих экранных формах берется из дерева модели документов. В частности, вопросы - это логические условия. Дизайн форм и правила их оформления можно задавать отдельно. Возможность автоматической генерации в данном случае очевидна.
Отметим, что представленный пример - один из возможных вариантов метафоры Web-контента, упомянутых на рис. 1. В дальнейшем мы предполагаем искать другие
подобные метафоры и после того, как их наберется некоторое количество, планируем реализовать генератор.
|]=| Документы для с
1:/ и 5ег5/$Иеу150уа I |уау 0\р1 от/ Кеиг
Документы иа загранпаспорт
Ответьте, пожалуйста, на предложенные ниже вопрось}.
Вид загранпаспорта: О Старого образца | • Биометрический
Возрост?;
• дс 18 лет | о от 18 лет
Рис. 5. Фрагмент сайта, сгенерированного по модели документов
4. Апробация. Пользуясь данным методом, мы в сотрудничестве с коллегами из правительства Санкт-Петербурга сделали спецификацию пяти государственных услуг: получение загранпаспорта, регистрация иностранного гражданина, получение разрешения на работу для иностранного гражданина, разбор ДТП, получение/продление российской визы иностранному гражданину. Модель процессов в среднем занимала 1-2 А4-листа, модель документов - 1 А4-лист, описательная модель -5-10 страниц. Полученные спецификации были проверены специалистами правительства Санкт-Петербурга и исправлены по их замечаниям. Также мы создали несколько пилотных Web-сайтов, пытаясь представить информацию из моделей в виде, удобном для конечных пользователей.
Выяснилось, что не всю информацию, необходимую для пользователей, удается формализовать в моделях. В частности, остается еще неформальный опыт тех, кто пользовался данными услугами, и он тоже может быть полезен другим. Потому в дальнейшем мы планируем интегрировать с этими Web-ресурсами специальные форумы, где люди делятся опытом получения соответствующих услуг.
5. Заключение. Предложенный метод нацелен на спецификацию государственных услуг с точки зрения их предоставления конечным пользователям. Он является концепцией и набором языковых средств - онтологией, графическими нотациями и специализированным XML-форматом. Если смотреть на государственные услуги с точки зрения их исполнения государственными органами, то модели будут более сложными,
а область применения - иная (например, оценка регламентов на совместимость, полноту и пр.). Тем не менее в этом направлении метод также можно развивать.
Однако в любом случае возникает проблема, связанная с тем, что предложенный метод требует от пользователей умения строить и понимать визуальные модели. Для того чтобы государственные служащие могли его использовать, требуется разработка упрощенного интерфейса, облегчающего ввод моделей. Быть может, часть модельной информации удастся вводить не в виде схемы, а в диалоговом режиме, что будет удобнее, например, для пользователей модельно-ориентированного решения REAL-IT [31], посвященного разработке пользовательских интерфейсов для систем, интенсивно работающих с данными (data-intensive systems).
Наличие единой модели для спецификации государственных услуг поможет создать унифицированные удобные метафоры Web-визуализации информации, так как они будут опираться на однозначную, единую модель. Однако здесь есть проблемы, касающиеся того, что не для всех государственных услуг подходит предложенный набор моделей. Уже сейчас понятно, что существуют следующие «крайние» варианты государственных услуг - ориентированные на документы, имеющие сложное поведение и состоящие из большого количества ограничений. В реальности каждая государственная услуга является смесью этих вариантов. Скорее всего, существуют и иные варианты. Мы будем рассматривать этот вопрос в дальнейшем, расширяя наш метод.
Мы намерены исследовать также вопросы сопровождения и обновления Web-описаний, основывающихся на моделях. Кажется, что использование моделей может оказать помощь и здесь: информацию, структурированную унифицированным способом, легче сопровождать, чем неструктурированную. Например, возможно, что можно будет связать InfoBlocks, описывающие расписание работы и адреса офисов государственных учреждений, участвующих в оказании услуг, с существующими Интернет-ресурсами, описывающими правила работы этих офисов, и таким образом, всегда отображать актуальную информацию.
Необходимо также точнее определиться, насколько разработанные нами модели должны быть ориентированы на конкретный способ предоставления государственных услуг. С одной стороны, это целесообразно, так как тогда они могут быть полезны при создании информационных сайтов о порядке предоставления услуг гражданам. С другой стороны, могут существовать много разных способов получения одной и той же услуги.
Наконец, мы намерены развивать ту часть метода, которая применяет онтологии: необходимо уточнить ту информацию, которая будет содержаться в онтологии и использоваться всеми услугами данной предметной области. Нужно также понять механизмы применения этой информации, включая средства программной поддержки.
Мы также намереваемся использовать предлагаемый метод для спецификации государственных услуг РФ. В настоящий момент в РФ в рамках административной реформы [32] создается большое количество новых регламентов и новых государственных услуг. Активно развиваются и электронные сервисы (например, портал gosuslugi.ru). Однако данная деятельность нуждается в дополнительной поддержке в связи с многочисленными проблемами - унификации описаний государственных услуг, создания единой классификации, повышения доступности услуг гражданам РФ и др. [33]. Рассмотренный метод мог бы оказаться здесь существенно полезен.
Литература
1. Shareef M. A, Archer N., Dutta S. E-Government Service Maturity and Development: Cultural, Organizational and Technological Perspectives. Information Science Publ. 2011. 356 p.
2. Al Ajeeli A. T., Al Bastaki Y. A. L. Handbook of Research on E-Services in the Public Sector: E-Government Strategies and Advancements. 2010. 576 p.
3. Mitrakas A., Hengeveld P., Polemi D., Gamper J. Secure E-Government Web Services. 2007. 340 p.
4. Hogrebe F., Blinn N., Nottgens M. Survey of E-Government Portals in European Capitals and Large Cities: A Benchmarking Study of G2B-Services // EGOV. 2009. P. 188-197.
5. Tambouris E., Gorilas S., Kavadias G. e. a. Ontology-Enabled E-gov Service Configuration: An Overview of the OntoGov Project // KMGov. 2004. P. 122-127.
6. Peristeras V., Loutas N., Goudos S. K., Tarabanis K. A. A conceptual analysis of semantic conflicts in pan-European e-government services //J. Information Science (JIS). 2008. Vol. 34(6). P. 877-891.
7. Smith M. L. Limitations to building institutional trustworthiness through e-government: a comparative study of two e-services in Chile // JIT. 2011. Vol. 26(1). P. 78-93.
8. Nung Chu C. N. Requirements of the Vision Impairments for E-Government Services in Taiwan from Accessibility to Efficiency // ICCHP. 2010. P. 464-467.
9. Dorasamy M., Marimuthu M., Raman M., Kaliannan M. E-Government Services Online: An Exploratory Study on Tax E-Filing in Malaysia // IJEGR. 2010. Vol. 6(4). P. 12-24.
10. Rorissa A., Demissie D. The State of the Art of E-Government Services in Africa: An Analysis of Relevant Websites // HICSS. 2009. P. 1-8.
11. Kaaya J. Determining Types of Services and Targeted Users of Emerging E-Government Strategies: The Case of Tanzania // IJEGR. 2009. Vol. 5(2). P. 16-36.
12. Stefan V., Stefan A. Live Services for Citizens with Live Technologies - e-Payment in Romania as First Step to an Effective e-Government // WEBIST. 2008. P. 503-506.
13. Al-hassan M., Lu H., Lu J. A Framework for Delivering Personalized e-Government Tourism Services // WEBIST. 2010. P. 263-270.
14. Mocan A., Facca F. M., Loutas N. e. a. Solving Semantic Interoperability Conflicts in Cross-Border E-Government Services // Intern. J. Semantic Web Inf. Syst. (IJSWIS). 2009. Vol. 5(1). P. 1-47.
15. Буч Г., Максимчук Р. А., Энгл М. и др. Объектно-ориентированный анализ и проектирование с примерами приложений. 3-е изд. М.: Изд-во «Вильямс», 2008. 721 с.
16. Terekhov A. N., Romanovskii K. Yu., Koznov D. V. e. a. RTST++: Methodology and CASE-tool for development of information systems and software for real-time systems // Programming and Computer Software. 1999. Vol. 25(5). P. 276-281.
17. Павлинов А. А., Кознов Д. В., Перегудов А. Ф. и др. О средствах разработки проблемно-ориентированных визуальных языков // Системное программирование. 2006. Т. 2, № 1. С. 116-141.
18. Business Process Model and Notation (BPMN). Version 1.2. OMG formal/2009-01-03. 2009. 316 p. // URL: http://www.omg.org/spec/BPMN/1.2.
19. Kang K., Cohen S., Hess J. e. a. Feature-Oriented Domain Analysis (FODA) Feasibility Study: technical Report, CMU/SEI-90-TR-21. Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 1990.
20. Koznov D. V., Romanovsky K. Yu. DocLine: A method for software product line documentation development // Programming and Computer Software. 2008. Vol. 34(4). P. 216-224.
21. Кознов Д. В., Романовский К. Ю. DocLine: Метод разработки документации семейств программных продуктов // Программирование. 2008. Т. 34, № 4. С. 41-53.
22. Lu R., Sadiq S. W. A Survey of Comparative Business Process Modeling Approaches // BIS. 2007. P. 82-94.
23. Van der Linden F. J, Schmid K., Rommes E. Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Springer, 2010. 353 p.
24. Кознов Д. В., Романовский К. Ю. Автоматизированный рефакторинг документации семейств программных продуктов // Системное программирование. 2009. Т. 4. С. 128-150.
25. Кознов Д. В., Смирнов М. Н., Дорохов В. А., Романовский К. Ю. WebMLDoc: подход к автоматическому отслеживанию изменений в пользовательской документации Web-приложений // Вестн. С.-Петерб. ун-та. Сер. 10: Прикладная математика, информатика, процессы управления. 2011. Вып. 3. С. 112-126.
26. Романовский К. Ю., Кознов Д. В. Язык DRL для проектирования и разработки документации семейств программных продуктов // Вестн. С.-Петерб. ун-та. Сер. 10: Прикладная математика, информатика, процессы управления. 2007. Вып. 4. С. 1-16.
27. Романовский К. Ю. Разработка повторно используемой документации семейства программных продуктов средствами технологии DocLine // Вестн. С.-Петерб. ун-та. Сер. 10: Прикладная математика, информатика, процессы управления. 2009. Вып. 2. С. 166—180.
28. Романовский К. Ю. Метод разработки документации семейств программных продуктов // Системное программирование. 2006. Т. 2, № 1. С. 191—218.
29. Смирнов М. Н., Кознов Д. В., Дорохов В. А., Романовский К. Ю. Программная среда WebMLDoc для автоматизированного отслеживания изменений пользовательской документации Web-приложений // Системное программирование. 2010. Т. 5, № 1. С. 32—51.
30. URL: http://www.w3.org/ XML/Schema.
31. Ivanov A., Koznov D. REAL-IT: Model-Based User Interface Development Environment // Proc. of IEEE/NASA ISoLA 2005. Workshop on Leveraging Applications of Formal Methods, Verification, and Validation. Loyola College Graduate Center Columbia. Maryland, USA, 23-24 September 2005. P. 31-41.
32. Концепция административной реформы в Российской федерации в 2006-2010 годах. В ред. распоряжения Правительства РФ от 09.02.2008 № 157-р, Постановления Правительства РФ от 28.03.2008 № 221.
33. Азарсков А. В., Самочадин А. В. Формирование понятийной структуры для онтологии государственных услуг // Науч.-технич. ведомости С.-Петерб. гос. политехн. ун-та. 2011. № 121. С. 270-274.
Статья рекомендована к печати проф. А. Н. Тереховым. Статья принята к печати 21 июня 2012 г.
