Развитие Муниципальной информационной системы c использованием инструментов IBM Rational Software
© И.В. Максимов,
Начальник Отдел Информационных Систем органов местного самоуправления
© МУ Центр Информационных Технологий и Ресурсов, г. Череповец
Введение
Программное обеспечение не всегда бывает сложным. Существует множество программных систем, которые задумываются, реализуются, сопровождаются и используются одним и тем же человеком. Обычно это начинающий программист или профессионал, работающий изолированно. Такие системы, как правило, имеют очень ограниченную область использования и короткое время жизни. Обычно их легче и дешевле заменить новыми, чем пытаться повторно использовать или расширить, а разработка подобных систем скорее утомительна, чем сложна.
Основная задача нашего подхода - это создание промышленных программных продуктов. Одними из особенностей промышленного ПО является то, что они имеют большое время жизни и обслуживают большое количество пользователей. Существенная черта промышленной программной системы - это ее сложность. Один разработчик не в состоянии создать такую систему. Иными словами, сложность промышленной системы превышает интеллектуальные возможности одного человека.
Мы разработали комплекс мероприятий и инструментов для развития существующей Муниципальной информационной системы. Как нам представляется, они позволят эффективно организовать работу команды разработчиков. Главной задачей было создание недорогой методики и комплекса инструментов, позволяющей не только создавать, но и развивать Муниципальную информационную систему (МИС).
Определение Муниципальной информационной системы
Муниципальная информационная система относится к категории сложных систем. Невозможно написать программу с условным названием МИС.EXE. Вот основные требования, которые учитывались при разработке нашего подхода к реализации Муниципальной информационной системы.
- Данные, накапливаемые со временем в системе, должны надежно храниться и эффективно обрабатываться независимо от происходящих изменений в политической, экономической или технологической сфере.
- Систему невозможно построить сразу. Сначала необходимо создать ядро системы, которое затем используется для ее дальнейшего развития.
- Необходима разработка эффективных инструментов для создания Информационной системы. Классические средства программирования - такие, как языки высокого уровня, используемые для реализации бизнес функций недостаточно эффективны, поскольку заставляют программиста заниматься разработкой не только бизнес функций, но и системным программированием. Кроме того, высококвалифицированные программисты, как правило, дорогостоящий ресурс.
Помимо этих, основных требований у нас существует определенный порядок подхода к построению и развитию Муниципальной информационной системы - это:
- Определение требований к системе типа "ЧТО" система должна делать. Для этого мы используем специальный документ "ОБЗОР". "ОБЗОР" представляет собой просто организованный документ определенной структуры, в котором кратко и четко сформулированы требования, "ЧТО", заказчик хочет получить от системы, и какие ограничения на систему накладываются заказчиком и исполнителем. Документ не содержит никаких утверждений или рекомендаций, "КАК" это должно быть сделано. За этот документ "Обзор" отвечает специальный человек не являющийся программистом. Этот документ подлежит согласованию, как с заказчиком, так и с исполнителем. Этот документ дает ясное представление заказчику и исполнителю, что они правильно поняли друг друга. Если в процессе реализации системы появляются дополнительные требования, то они откладываются до реализации следующего выпуска системы. Если требования таковы, что текущая реализация системы без них невозможна, то тогда они конечно реализуются. Однако мы должны понимать, что такие изменения могут привести к выходу за рамки бюджета. Это касается как денег, так и сроков. По этому все изменения к системе, возникшие в процессе реализации текущего выпуска, обязательно подлежат согласованию с оформлением дополнительных, к "обзору", документов. Для работы с обзором мы используем инструмент IBM Rational RequisitePro от компании IBM Rational Software.
- На основе "ОБЗОРА" формируются требования к программному обеспечению, отражающие другую точку зрения или "КАК" это может быть реализовано с использованием наших инструментов и готового ядра системы. Каждое требование типа "ЧТО" из обзора обязательно имеет свою часть типа "КАК". Когда мы определяем "КАК" это будет реализовано, существует ряд так называемых, не функциональных ограничений которые отражают специфику реализации. Не путать эти ограничения с недостатками:
- Системное программирование у нас отделено от функционального, это значит, что группа системного программирования, разрабатывая программные модули и компоненты так называемого системного ядра, никак не связана с требованиями документов типа "ОБЗОР" и никак не реализует специфические требования заказчика. Хотя некоторые новые требования заказчика типа "ЧТО" могут оказывать влияние на разработку системного кода, о чем принимается специальное решение после тщательного анализа, почему существующими программными модулями это требование не реализовать. Системное ядро, таким образом, является общим, или иначе одинаковым для любой подсистемы МИС. Преимущества очевидны. Интерфейс пользователя любой системы подобен или имеет одинаковую структуру и поведение. Как следствие этого сокращаются затраты на обучения пользователей системам и соответственно пользователи легко могут подменять друг друга в случае производственной необходимости.
- Группа функционального программирования занимается исключительно реализацией бизнес требований типа "ЧТО" и ее не волнуют вопросы, связанные с системным программированием. Для этой группы был разработан механизм описания требований заказчика в виде специальных записей - метаданных, хранящихся в СУБД. Метаданные используются системным ядром для динамической генерации интерфейса пользователя и выполнения операций в СУБД.
- Следующим этапом нашего подхода является этап тестирования системы. Для соответствующих реализованных или находящихся на стадии реализации пар "ЧТО" - "КАК" всегда создается контрольный пример, детально описывающий поведение системы на основе описания из "ОБЗОРА". Для каждого примера или его части формируются начальные условия, которые затем являются входными данными для тестируемой подсистемы. Полученные ожидаемые результаты потом используются для проверки достоверности результатов, полученных из системы. Контрольный пример всегда сначала просчитывается вручную, если это возможно. Кроме функции тестирования контрольный пример выступает в роли показателя или доказательства того факта, что система удовлетворяет заказчика данной версии и данного выпуска программного обеспечения. В дальнейшем контрольный пример используется пользователями для обучения работы с системой.
Краткий обзор о состояние дел муниципальной информационной системы
В настоящее время нами создано ядро городской информационной системы, которое состоит из следующих подсистем.
- Земельный кадастр.
- Аренда Земельных Участков
- Аренда помещений
- Адресный реестр.
- Подсистема БТИ. Подсистема БТИ создана и развивается независимо от нас, но на нашей технологии специалистами БТИ.
Каждая из подсистем находится на своем уровне развития. Развитие той или иной подсистемы определяется требованиями, которые формируются муниципалитетом. Необходимо подчеркнуть, что это не набор систем, а именно подсистемы единой МИС, поскольку все они связаны. Например, Адресный реестр является источником адресной информации для всех подсистем.
В настоящий момент развитие МИС идет в сторону создания подсистем "Расчеты за предоставленные услуги ДЖКХ" далее "ДЖКХ" и подсистемы "Реестр населения". Подсистема ЖДКХ в настоящий момент находится в стадии внедрения, реестр населения находится в стадии опытной эксплуатации.
Для демонстрации нашего подхода к развитию и созданию МИС рассмотрим реальные модели и внешний вид приложений на примере подсистемы "ДЖКХ".
Опускаем требующий определенного времени и наименее формализуемый этап описания формирования "ОБЗОРА". Для построения моделей используем хорошо известный продукт IBM Rational Rose, для которого был разработан специальный встраиваемый модуль, позволяющий автоматически на основе визуальной модели генерировать метаданные и записывать их в СУБД. Ранее мы отмечали, что метаданные представляют собой специальное описание предметной области, интерпретируемое нашим системным ядром. Возможно описание и генерация метаданных с использованием Excel, но это более сложная и менее эффективная методика. На рисунке показана часть МИС с подсистемами "ДЖКХ" и "реестра населения":
МИС представлена очень крупными блокам или так называемыми пакетами, в нотации UML.
Общие подсистемы - это подсистемы, используемые в других подсистемах МИС и, как правило, не имеющие самостоятельного прикладного использования.
Остальные названия пакетов соответствуют подсистемам МИС.
Рассмотрим детальную структуру этой подсистемы пакета ДЖКХ:
Подсистема ДЖКХ включает в себя следующие внутренние подсистемы, используемые только в ней.
- Жильцы. Это специальное представление данных по жильцам, которые оплачивают услуги ДЖКХ. Подсистема "Жильцы" не просто связана с реестром населения - это специальное представление данных о жителях г. Череповца в подсистеме ДЖКХ. Представление содержит только те атрибуты, которые необходимы для ДЖКХ и не представляет доступ к другим атрибутам. Например, таким как является ли этот житель избирателем и к какому участку он относится и т.д.
- Льгота по лицевому счету. Это специальная модель, описывающая, каким образом предоставляется льгота на услуги ДЖКХ.
- НСИ ДЖКХ. Это нормативно справочная информация. Различные справочники тарифов и т.д.
- Объекты ДЖКХ. Это основная модель подсистемы, содержащая такие объекты как лицевой счет, секция, учреждение (муп), обслуживаемый адрес и т.д.
- ХО. Это подсистема, отвечающая за хозяйственные операции с деньгами. Она включает модель выполнения таких финансовых операций как начисления и оплаты.
- ДЖКХ Реестры. Это подсистема также отвечает за финансы в системе ДЖКХ, только содержит модели различных реестров оплат и начислений. Реестры - это специальные документы, которые фиксируют факты финансовых операций. Например, реестр оплаты из банков, реестр субсидий или реестр различных ручных начислений, оплат, списаний и т.д.
Поскольку модель подсистемы ДЖКХ очень объемная, подсистема ДЖКХ разбита на категории или пакеты. Если этого не сделать, то общую модель невозможно воспринять в силу ее сложности. Для примера соберем на одну диаграмму классов часть подсистемы ДЖКХ. Это будет только примерно половина объектов модели. Следующий рисунок демонстрирует ее сложность:
Разбиение общей модели на отдельные пакеты позволяет нам справиться со сложностью системы.
На следующем рис. представлена часть реальной модели из пакета Объекты ДЖКХ.
Это модель объекта Лицевой счет. В состав лицевого счета входят следующие объекты, имеющие самостоятельную структуру:
- Услуги по ЛС
- Секция, к которой относится ЛС
- Льготы по ЛС
- Жилец, которому оказываются услуги.
- Журнал ХО, содержащий все денежные операции, проходящие по данному ЛС
На модели видны также связи с другими подсистемами. Объекты (назовем их чужими или находящимися в других подсистемах) изображены символами интерфейсов. Например, такие:
- Документ
- Дом на улице. Это ссылка на подсистему адресный реестр.
Это не просто картинка - это модель, которая с помощью специального встроенного в Rose инструмента, о котором мы уже упоминали, позволяет генерировать и записывать метаданные в СУБД. Модель строится с использованием нотации UML в Rose, что позволяет в несколько раз увеличить скорость разработки, а самое главное - позволяет на основе модели принимать решение об изменении или развитии подсистемы. Поскольку гораздо проще принимать решения, опираясь на графическое представление. Генерация метаданных - это последовательный обход элементов модели и формирование SQL скриптов для записи метаданных в СУБД. На рисунке ниже представлен фрагмент генерации метаданных только для объекта ЛС:
Напомним, что существующий инструмент позволяет сгенерировать скрипты не только для одного выделенного объекта, как на рисунке, но и для всей модели целиком. Таким образом, пользуясь только Rose, мы можем, сгенерировав скрипты, сразу получить клиентское приложение. На следующих рисунках показаны фрагменты интерфейса пользователя, которые получаются в результате работы с метаданными нашего ядра.
Это представление лицевого счета, фрагмент модели которого приводится выше. Все элементы этого представления - дерево объектов, группы свойств и карточка генерируются автоматически на основе метаданных, полученных из модели.
Это журнал хозяйственных операций, который естественно связан с данным лицевым счетом.
Таким образом, развитие, сопровождение и изменение подсистемы осуществляется на основе моделирования и изменения моделей, а не жесткого кодирования на языке высокого уровня. Кроме того, специальные возможности механизма описания позволяют нам интегрировать МИС с такими системами как Geomedia и Gframme известной фирмы Intergraph. Эти продукты позволяют объединить в единое информационное пространство семантическую информацию МИС и пространственные данные, которые хранятся и обрабатываются в указанных системах. Иначе говоря, применительно к подсистеме ДЖКХ, мы можем показать на карте, например, адреса, обслуживаемые конкретным МУП, на каких земельных участках они расположены. В стадии реализации находится проект, показывающий, например, сегменты теплотрассы, которые снабжают теплом эти обслуживаемые адреса. И, как следствие, можем заранее узнать, какие дома останутся без услуги по теплоснабжению, вовремя известить жителей и выполнить перерасчеты. Поскольку в МУП используется такой продукт как 1С, а подсистема ДЖКХ является источником первичной информации об оплатах и начислениях, имеется связь и с этой системой для ведения общего бухгалтерского учета.
Выводы
- Модель информационной системы должна строиться по строгим правилам и быть частью ее реализации, а не набором красивых концептуальных картинок из учебников по ООП.
- У команды разработчиков должна быть четкая методология разработки, что позволит гарантированно осуществить выпуск системы, сделать реализацию проекта управляемой и предсказуемой, сэкономит самые дорогие ресурсы - нервы и деньги. Следует сказать, что даже плохая методология лучше ее отсутствия.
- Информационная система должна жить и развиваться независимо от ее создателей. Этот принцип был положен в основу нашей методологии создания и развития подсистем МИС.
- На примере создания подсистемы ДЖКХ мы показали, каким образом наш подход реализует постепенное создание и развитие муниципальной информационной системы.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Обсудить на форуме Rational Software
