Разработка программных комплексов с переменным
функционалом
С.П. Якимов
доцент, к.т.н., докторант
каф СТ,
СибГТУ, ysp@2005yandex.ru, г. Красноярск
Традиционно
в ООП под изменчивостью экземпляров объектов (классов) подразумевается возможность
их в процессе функционирования менять лишь свои атрибутивные свойства. Смена
какого-либо метода в соответствии с традиционным толкованием полиморфизма в ООП
приводит к необходимости создания нового дочернего класса, наследующего все
свойства и методы родительского и перекрывающего изменившийся метод.
Функциональная изменчивость самого объекта оказывается весьма ограниченной, что
неизбежно сказывается на результатах объектно-ориентированного анализа.
Остановимся
на нескольких характерных примерах изменчивости функционала объектов, с которыми
нам пришлось столкнуться на практике при разработке информационных систем,
предназначенных для поддержки самых различных технологических процессов
1. ИС «Холдинг
экспедиторских услуг на железнодорожном транспорте»
ИС
была разработана для компании «МТК-Центр», занимающейся организацией
железнодорожных перевозок. Основной технологический процесс компании
ориентирован на работу с постоянными клиентами, с которыми заключаются договора
на выполнение перевозок, и осуществляется мониторинг выполнения этих договоров.
Функционально разработанный комплекс состоит из 4 блоков, доступ к которым
полностью определяется ролью пользователя в жестко регламентированном
технологическом процессе: администратора, экспедитора, бухгалтера, финансового
директора
Опытная
эксплуатация выявила особенности технологического процесса, не предусмотренные
техническим заданием. Изначально проект был основан на предположении о его
жесткой регламентации. В целом такое предположение оказалось вполне
оправданным,, но в то же время, для компанири существенными оказались процессы
заключения договоров, отличающиеся гибким отношением к клиенту. Типовых
договоров оказалось достаточно много, и менялись они весьма часто. Для
нормальной работы информационной системы потребовалось создать блок формирования
редактируемых отчетов. Предложенная нами технология работы с договорами коротко
сводилась к следующему: подготовленный пользователь без помощи разработчика,
используя элементарные навыки работы с Microsoft Office, по мере возникновения
необходимости, готовит шаблоны типовых договоров и сохраняет их в базе данных.
Параметры договора, зависящие от данных, содержащихся в ИС, заменяются заранее
оговоренными кодовыми обозначениями непосредственно в тексте шаблона. Рядовые
пользователи ИС при работе с договорами и другими документами, предусмотренными
информационной системой, обращаются к этим шаблонам. Клиентская часть
программного комплекса выступает в роли интерпретатора: в режиме
полнотекстового поиска находит коды и заменяет их актуальными значениями.
2. ИС «Управление
муниципальным имуществом».
ИС
система «Управление муниципальным имуществом» [1] разрабатывалась в рамках
городской программы создания Единого муниципального кадастра для внедрения в
технологический процесс Департамента недвижимости Администрации г. Красноярска.
Во
время предпроектного обследования произошли существенные изменения в основном
технологическом процессеДепартамента: изменилась структура, расширился круг
решаемых им вопросов, первичной информации. Практика показывает, что подобные
изменения являются характерной особенностью государственных структур,
вынужденных работать в условиях постоянно меняющегося законодательства. Было
принято решение о необходимости использования объектных подходов при
проектировании баз данных – по сути дела, создание объектной БД на необъектной
СУБД. При реализации инфраструктуры, был применен шаблон проектирования «Object
Decoupling» на основе которого разработали информационную модель, получившая
условное рабочее название «реестровая» (см. рис. 1) [2]. Основная идея
«реестровой модели» заключается в том, что подверженный изменениям функционал
выносится в зону ответственности базы данных, хранится в ее таблицах либо
непосредственно в виде кода, подлежащего интерпретации в процессе исполнения,
либо в виде ссылок на хранимые процедуры. Использование такого подхода открыло
широкие возможности для использования методов реляционной алгебры для решения
задач кодогенерации при формировании сложных запросов и связей между различными
объектами реестра.
Рис. 1.
Диаграмма классов программного комплекса «Управление муниципальным имуществом»
В
настоящее время ПК «Управление муниципальным имуществом» представляет собой
настраиваемый тематический реестр, позволяющий организовать хранение сведений о
различных объектах недвижимости и динамике их изменения. Функционально можно
выделить несколько блоков - реестров: предприятий, зданий и строений, объектов
инженерной инфраструктуры, объектов незавершенного строительства, технических
паспортов, транспортных средств, основных средств, участия города в уставных
капиталах предприятий и обществ, информационных ресурсов по объектам землепользования,
договоров аренды, договоров оперативного управления, договоров хозяйственного
ведения, договоров безвозмездного пользования, договоров аренды движимого
имущества, договоров аренды площадей временно свободных от основной уставной деятельности,
договоров аренды рекламных мест, документов архивного хранения,блок
сопровождения договоров аренды, блок информационного обмена, блок
администрирования.
При
этом «Реестр договоров аренды рекламных мест», «Реестр технических паспортов»
были добавлены в состав программного комплекса по просьбе заказчика в связи с
очередным изменением технологического процесса уже непосредственно перед
началом опытной эксплуатации, что лишний раз подтвердило правильность решения о
необходимости использования объектных подходов с учетом изменчивости функционала
объекта автоматизации.
Другой
особенностью этой разработки является динамичность редактируемых отчетных форм.
Использование «реестровой модели» позволило разработать генератор редактируемых
отчетных форм в формате приложений Microsoft Office, использующий технологию
OLE. Разработанный при этом механизм хранения исполняемых данных оказался
весьма универсальным, и был доработан в проекте не только для подготовки редактируемых
отчетных форм, но и для разработки фильтров и функций конвертирования данных.
Это не только ускорило разработку информационной системы, но нашло применение и
в дальнейшем, когда произошло очередное изменение технологического процесса в
схеме обмена информацией между Департаментом и подотчетными ему
балансодержателями.
3. Распределенный
нейроимитатор
Концепция
распределённого нейроимитатора (проект «Нейропараллель») [3], имеющего параллельную
архитектуру, специализированную под структуру нейронной сети и основанную на
объектно-ориентированном представлении формального нейрона была разработана в
рамках специального исследовательского проекта. Представление каждого нейрона
(в общем случае – элемента нейронной сети) в виде объекта позволяет максимально
детализировать нейронную сеть с тем, чтобы в дальнейшем произвести условное
разделение нейронной сети на вычислительные сегменты, параллельное
функционирование которых допускается топологией нейронной сети и/или алгоритмом
её обучения – собственно, распараллеливание.
В
условиях отсутствия специализированных средств, концепция функциональной изменчивости
в данном проекте была реализована посредством механизма динамически загружаемых
библиотек Windows (первое клиентское приложение ориентировано именно на данную
платформу). Алгоритмы функционирования и обучения нейронов загружаются при
создании нейронной сети и, непосредственно, на этапе функционирования системы
могут быть переопределены посредством новой загрузки.
В
настоящее время в рамках проекта производятся исследования, посвящённые оценке
зависимости эффективности распараллеливания от вторичных условий, таких, как
структура вычислительного кластера, тип решаемой нейронной сетью задачи и т.д.,
а также решению задачи самоорганизации распределённого нейроимитатора.
4. Информационная система
«Электронная лаборатория»
Информационная
система «Электронная лаборатория» изначально задумывалась как средство автоматизации
учебного процесса и предназначалась для организации лабораторного практикума с
использованием в качестве стенда компьютера и комплекта обучающих, тестирующих
и прочих программ, моделирующих предметную область. С этой целью она должна
поддерживать следующие функции: формирование учебных планов; организация
учебного процесса; Обучение; Администрирование.
Структурно
«Электронная лаборатория» представляет собой иерархически упорядоченный набор
самостоятельных независимых исполняемых модулей учебной направленности,
хранение которых частично организовано средствами стандартной СУБД (см. рис.
2).
Рис. 2.
Организация изменения функциональности
Каждый
исполняемый модуль работает независимо от других и моделирует фрагмент
предметной области, предоставляя учащемуся возможность самостоятельного
изучения материала (электронный учебник, обучающая программа или программа,
моделирующая лабораторную установку и т.д.), контроля знаний (тестирующая
программа). Под термином «исполняемый модуль» понимаются не только традиционные
файлы загрузочных форматов, но и файлы, активация которых осуществляется другими
приложениями Windows, зарегистрированными в реестре операционной системы.
Возможность включения простых авторских разработок в качестве исполняемых
приложений делает курс независимым от разработчиков системы, создание отдельных
приложений может вестись силами преподавателей и самих учащихся.
В
данном проекте наиболее изменчивой частью является сам учебный процесс.
Введение объекта «исполняемый модуль», поддерживающего динамичность функционала
сделало систему «Электронная лаборатория» универсальной, дало возможность
пользователю самостоятельно разрабатывать учебно-методические модели. По сути
дела, «Электронная лаборатория» осуществляет логическую связку между
разрозненными программами учебного назначения, моделирующими предметную область,
с помощью учебного плана и упорядочивает процессы хранения и обработки результатов
работы учащихся, подверженные изменчивости в гораздо меньшей степени.
5. Программный комплекс
«Мониторинг профессиональной успешности работников образования»
Программный
комплекс «Мониторинг профессиональной успешности работников образования» предназначен
для организации процессов подготовки педагога к аттестационной процедуре, мониторинга
его профессионального роста, выработки программы совершенствования педагогического
мастерства на основе формализованных и унифицированных показателей. С этой
целью он должен поддерживать следующие функции: администрирование программного
комплекса общая диагностика; дополнительная диагностика; уточняющая
диагностика; подготовка аттестационной документации.
Различные
виды диагностики осуществляются на основе анализа результатов заполнения респондентом
тестов с набором фиксированных вариантов возможных ответов. Тесты делятся на
тесты частной (уточняющей) диагностики, диагностические карты и
профессиограммы. Тесты частной диагностики носят вспомогательный характер,
результаты их работы в базах данных не сохраняются, основное их назначение –
помочь работнику образования выявить причины возникающих у него проблем. В то
же время следует отметить высокую изменчивость этого блока – постоянно
появляются новые тесты, устаревают имеющиеся. Тесты общей и дополнительной
диагностики предназначены для интегральной оценки профессиональной успешности и
профессионального соответствия педагога. Эксплуатация первой версии
программного комплекса в школах Красноярского края показала, что изменениям
подвержен не только набор входящих в состав диагностики тестов, вопросов,
интерпретаций, как предполагалось изначально, но и способы интегральной оценки
их результатов. Изменчивость функционала обуславливается не в последнюю очередь
тем, что процесс оценки профессиональной успешности в настоящее время слабо
формализован и зависит от текущих целей, стоящих перед конкретным
образовательным заведением.
Во
второй версии программного комплекса указанные недостатки были устранены за
счет более глубокой проработки структуры данных и организации обновляемости
тестов частной диагностики по той же схеме, что и проекте «Электронная
лаборатория» (см. рис. 2). Линейная организация тестов была заменена системой иерархически
упорядоченных индексов, в состав которых могут входить обычные тесты. Введение
понятий индекса и фактора педагогической квалификации позволило организовать
настраиваемую интегральную обработку и взаимную увязку произвольного набора
тестов (см. рис. 3).
Рисунок
4. Расчет факторов педагогической квалификации
Из
приведенных примеров видно, что, зачастую условия эксплуатации программных
систем требуют от них способностей к функциональной изменчивости. Разумеется,
речь не идет о вырожденном случае – этапе опытной эксплуатации, когда
программный код системы в целом и входящих в ее состав объектов, по определению
претерпевает многократные изменения. Основным принципом, посредством которого
объекты системы могут быть способными менять свою функциональность является
полиморфизм, в частности, его вид, основанный на переопределении методов
классов при наследовании. Данный принцип, бесспорно, создаёт обширные
возможности для создания гибких систем, что многократно подтверждено успешными
проектами, реализованными в рамках объектно-ориентированного подхода. В то же
время, при проектировании ИС может оказаться полезным подход, при котором
объект мог бы изменять свои методы (свойства) в ходе эксплуатации, и даже в
ходе выполнения программы, независимо от того, были ли они известны на момент
написания. Существующие в настоящее время средства разработки вполне допускают
физическую реализацию этих подходов. Перечислим некоторые из них:
1.
1. Формализация возможных изменений. Это наиболее доступный и надежный
прием. Все возможные изменения представляются в виде формализованных процедур и
изменение функционала системы достигается за счет перенастройки справочников
системы без внесения в нее дополнительного исполняемого кода в каком бы то ни
было виде. Проблема изменчивости функционала полностью переносится в область изменчивости
атрибутов.
2.
2. Загрузка функций. Предполагается, что объект системы имеет методы,
реализация которых уже изначально вынесена в отдельные от исполняемого файла
источники, например, динамически загружаемые библиотеки. В качестве
обрабатываемых данных или, если таковые предусмотрены отдельно, данных
управления, в различных ситуациях системе передаются указания об используемых
методах (в рассматриваемом случае это могут быть непосредственно имена файлов
библиотек). Руководствуясь этими сведениями, система загружает нужные реализации
– с этого момента метод объекта исполняется иначе.
3.
3. Трансляция на этапе функционирования. Данный метод предусматривает
наличие встроенного в систему транслятора программного кода. Реализация
полиморфных методов объектов изначально хранится отдельно в виде исходных
кодов. Процесс изменения метода предполагает загрузку источника и трансляцию
реализации. Таким образом, он более продолжителен по сравнению с предыдущим
примером. Однако сам подход следует считать более доступным, поскольку он
предполагает использование специализированного языка для разработки полиморфных
реализаций, который, очевидно, является гораздо более удобным средством по
сравнению с универсальными системами разработки.
4.
4. Принципиально отличающийся метод, может быть использован в системах,
функционал которых частично выносится в базы данных. Современные серверы БД
(InterBase и клоны, Oracle, MS SQL и пр.) позволяют хранить в базах данных
помимо собственно данных и описаний их структуры ещё и некоторый функционал в
виде так называемых хранимых процедур. Для кодирования таких подпрограмм, как
правило, используется встроенный язык программирования, основанный на SQL, но,
тем не менее, реализующий все основные конструкции алгоритмических языков.
Выводы
5.
Таким образом, предлагается технология разработки больших программных
комплексов включающая в себя следующие моменты
6.
1. Проведение детального обследования информационных процессов
автоматизируемого предприятия, в результате которого не только снимается их
структура, вырабатываются предложения по реорганизации, но и выделяется часть
процессов, наиболее подверженных изменчивости.
7.
2. Разрабатывается модель деятельности предприятия в условиях
эксплуатации информационной системы, в которой часть подверженная изменениям
переносится в зону ответственности базы данных, встроенного интерпретатора или
динамически загружаемых библиотек.
8.
3. В случае изменения технологического процесса, адаптация программного
комплекса проводится одним из следующих путей
-
a) Настройка справочников без
привлечения квалифицированных специалистов.
-
b) Доработка несложных
процедур и регистрация их в базах данных информационной системы квалифицированным
пользователем (администратором базы данных), знакомым со структурой базы
данных.
-
c)Доработка процедур и
регистрация их в базах данных информационной системы разработчиком без внесения
существенных изменений в структуру базы данных. Выполняется в рамках договора
на сопровождение.
-
d) Доработка программного
комплекса разработчиком с внесением существенных изменений в структуру
программного комплекса. Выполняется в рамках отдельного договора на доработку
информационной системы
Использование
такого подхода к разработке информационных систем позволяет:
1.
1) Существенно сократить время адаптации программного комплекса к
изменениям в технологическом процессе
2.
2) Существенно сократить затраты на сопровождение разработок
3.
3) Сократить время разработки программного продукта за счет
использования универсальных составляющих, предназначенных для хранения
информации о компонентах информационной системы, касающихся отображения
информации, подготовки отчетных форм и файлов обмена данными со смежными информационными
системами.
Литература
4.
1. Сапожков И.И., Якимов С.П., Гилев В.В., Кузнецов Е.А. Типовые решения
для задач управления собственностью и жилищным фондом./ Сборник трудов III
межрегиональной конференции «Информационные технологии и решения для
Электронной России. Ханты-Мансийск, 20-23 мая
5.
2. Erich Gamma, Richard
Helm, Ralph Johnson, John Vlissides: Design Patterns, Elements of Reusable
Object-oriented Software, Addison-Wesley, 1995.
6.
3. Сиземов Д.Н., Степаненко Н.А., Якимова Л.Д., Якимов С.П. Метод
распределенной нейросетевой обработки, реализованный в проекте
"Нейросервер". – М.: ВИНИТИ, 2004.