6. Формализованное представление предметной области в процессе создания информационных систем управления
Основные аспекты формализованного представления предметной области при проектировании ИСУ рассмотрим на примере разработки муниципальной информационной системы.
В основе методов создания информационной системы города и области (края, республики) лежит моделирование предметной области. Под предметной областью понимается взаимосвязанная совокупность управляемых объектов организации, субъектов управления, автоматизируемых функции управления и программно-технических средств их реализации (рис. 5).
Рис. 5. Предметная область муниципальных органов власти
Формализованное представление предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность получения некачественной муниципальной информационной системы (МИС), в которой может быть допущено большое количество ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование системы [43].
Основные требования, предъявляемые к моделям предметной области, показаны на рис. 6.
Рис. 6. Требования к моделям предметной области
Для представления моделей используются нотации различных формальных языков моделирования. Например, унифицированный язык моделирования — Unified Modeling Language (UML) [34]. Понятность для заказчиков и разработчиков основывается на применении графических средств отображения модели. Реализуемость подразумевает наличие средств физической реализации модели предметной области в МИС. Обеспечение оценки эффективности реализации модели предметной области основывается на определенных методах оценки эффективности и вычислении показателей эффективности.
Для реализации перечисленных требований предлагается строить систему моделей, которая будет отражать структурные и оценочные аспекты функционирования предметной области. Структурный аспект функционирования МИС предполагает построение:
объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;
организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.
Для представления структурного аспекта моделей предметной области в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы [43].
Формализованное представление предметной области с использованием графических средств нередко оказывается наиболее емким способом представления информации. При этом проектировщикам следует учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации МИС. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и, в особенности, к программированию. Отдельная подсистема МИС может не быть результатом прямой декомпозиции некоторой функции системы: она может выполнять определенную обработку информации для нескольких функции в системе.
Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой МИС.
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся: время решения задач; стоимостные затраты на обработку данных; надежность процессов; время передачи электронных документов от одного отдела к другому и т.д.
В основе различных подходов формализованного представления предметной области информационной системы лежат принципы последовательной детализации абстрактных категорий. Обычно модели строятся на трех уровнях: на внешнем уровне (определение требований), на концептуальном уровне (спецификация требований) и на внутреннем уровне (реализация требований). Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств. На концептуальном уровне модель отвечает на вопрос: как должна функционировать система. Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов. На внутреннем уровне модель отвечает на вопрос, с помощью каких программно-технических средств реализуются требования к системе. С позиции жизненного цикла МИС [43] описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования.
Современным подходом к построению моделей анализа и проектирования информационных систем является объектно-ориентированный подход. Он предполагает представление окружающего мира в виде объектов, являющихся экземплярами соответствующих классов. Объектно-ориентированный подход продемонстрировал свою эффективность при построении систем в различных предметных областях и является наиболее популярным в настоящее время. Большинство инструментальных средств, операционных систем и современных языков программирования в той или иной мере являются объектно-ориентированными.
Промышленным объектно-ориентированным стандартом языка моделирования бизнес-процессов и систем с ориентацией на их дальнейшую реализацию в виде программного обеспечения является Unified Modeling Language (UML). Рынок современных программных продуктов предлагает ряд CASE-средств, поддерживающих UML, — Rational Rose, Paradigm Plus, Select Enterprise, Microsoft Visual Modeler for Visual Basic, Arena и др. Средства автоматической кодогенерации позволяют на основе разработанной визуальной модели программной системы получить исходный код на таких языках, как C++, Visual C++, Visual Basic, Java, Delphi, Smalltalk, Ada, а также PowerBuilder, COBRA/ 1DL и Oracle. Использование этих средств позволяет значительно упростить процесс кодирования, еще на этапе разработки проверить архитектурные решения, корректность и полноту модели.
Все представления о модели сложной системы фиксируются в UML в виде специальных графических конструкций — диаграмм. Интегрированная модель сложной системы может быть представлена в виде совокупности диаграмм (рис. 7) [34].
Рис. 7. Интегрированная модель сложной системы в нотации UML1[6]
Диаграмма прецедентов является наиболее общей концептуальной моделью сложной системы, исходной для построения всех остальных диаграмм.
Диаграмма классов представляет собой логическую модель, отражающую статические аспекты структурного построения сложной системы.
Диаграммы поведения также являются разновидностями логической модели и отражают динамические аспекты функционирования системы.
Диаграммы последовательностей отражают множество объектов и посланные или принятые ими сообщения, заостряя внимание на временной упорядоченности событий.
Диаграммы кооперации основное внимание уделяют структурной организации объектов, принимающих и отправляющих сообщения.
Диаграммы реализации относятся к физической модели системы и служат для представления физических компонентов сложной системы.
Построение объектно-ориентированных UML-моделей рассмотрим на примере проектирования информационной системы финансового менеджмента (ИСФМ) отдела финансового управления.
Для построения UML-моделей ИСФМ потребовалось решить следующие задачи:
выполнить структуризацию предметной области и спецификацию функциональных требований пользователей к ИСФМ с использованием диаграмм прецедентов;
осуществить проектирование логической схемы базы данных ИСФМ;
выполнить моделирование поведения, динамических аспектов функционирования ИСФМ для бюджетных организаций.
Для структуризации предметной области и спецификации функциональных требований пользователей к информационной системе финансового менеджмента следует использовать диаграммы прецедентов [54]. С помощью прецедентов можно описать поведение разрабатываемой системы, не определяя ее реализацию. Прецеденты позволяют проверить архитектуру системы в процессе ее разработки. Прецедент (Use case) специфицирует поведение системы или ее части и представляет собой описание множества последовательностей действий (включая варианты) — информационных процессов, выполняемых системой для того, чтобы пользователь мог получить определенный результат. Информационные процессы (ИП) отдела финансового управления можно разделить на ряд групп:
«Рассмотрение и составление проектов расчетов по соответствующим направлениям для проектов бюджета города, осуществление предварительного анализа»:
«Составление бюджетной росписи по главным распорядителям»;
«Формирование кассового плана»;
«Осуществление финансирования главных распорядителей и прямых получателей»;
«Разнесение ежедневного финансирования по кодам экономической классификации»;
«Контроль и анализ исполнения нормативных расходов главными распорядителями и прямыми бюджетополучателями»;
«Проверка договоров муниципального заказа» и др.
Рассмотрим построение информационной модели одной из этих групп ИП — «Формирование кассового плана». Технология формирования кассового плана включает ряд ИП:
формирование ведущим специалистом отдела финансового управления сводной заявки по заявкам главных распорядителей;
рассмотрение сводной заявки начальником отдела;
корректировка рассмотренной заявки;
передача заявки в отдел исполнения;
формирование заявки по всем отраслям;
утверждение сводной заявки начальником финансового управления и главой самоуправления;
получение утвержденного кассового плана главными распорядителями.
Построение диаграммы прецедентов начинается с моделирования контекста системы [54]. Необходимо определить пользователей (физических лиц или внешние системы), взаимодействующих с системой. Затем для каждого пользователя рассмотреть пути его взаимодействия с системой, выделить основные сервисы системы, которые будут им использоваться для получения желаемого результата.
Заключительным этапом разработки диаграмм прецедентов является спецификация отношений между пользователями и прецедентами.
На рис. 8 представлена диаграмма прецедентов для информационного процесса «Формирование кассового плана». В качестве пользователей были выделены следующие: «Главный распорядитель», «Ведущий специалист», «Начальник отдела отраслей ЖКХ», «Начальник отдела исполнения», «Начальник финансового управления», «Глава самоуправления». Основные сервисы, предоставляемые ИСФМ при реализации рассматриваемого процесса, представлены на диаграмме прецедентами: «Сформировать заявку для включения в кассовый план», «Сформировать сводную заявку», «Рассмотреть заявку», «Передать заявку в отдел исполнения». «Сформировать заявку по всем отраслям», «Утвердить сводную заявку» и «Получить утвержденный кассовый план». Прецедент «Рассмотреть заявку» детализирован с помощью прецедента «Корректировать заявку», который связан с исходным прецедентом отношением включения («include»).
Рис. 8. Диаграмма прецедентов для ИП «Формирование кассового плана»
Взаимодействие между пользователями и прецедентами описано с помощью отношений ассоциации. Для каждой ассоциации указана кратность входящих в нее компонентов. Например, для ассоциации между пользователем «Начальник отдела отраслей ЖКХ» и прецедентом «Рассмотреть заявку» проставлены кратности «1» и «*» соответственно. Данная запись означает, что начальник отдела может рассматривать несколько заявок (ассоциация «один ко многим»).
Рис. 9. Диаграмма прецедентов для ИП «Анализ договоров муниципального заказа»
На рис. 9 представлена диаграмма прецедентов для процесса «Анализ договоров муниципального заказа». Выделены основные сервисы, предоставляемые ИСФМ отдела финансового управления для реализации данного процесса. Следует отметить, что для указания взаимосвязи между прецедентами «Проверить договор, заявку» и «Корректировать договор» было использовано отношение расширения («extend»). При проверке договора корректировка осуществляется лишь и случае выявления ошибок. Поэтому, чтобы не перегружать налипшей логикой базовый прецедент, было принято решение о выделении обработки данной нестандартной ситуации в отдельный прецедент.
Для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования используются диаграммы классов [54].
Методика построения диаграмм классов включает этапы [34]:
идентификация реальных сущностей или некоторых абстракций, составляющих словарь предметной области;
спецификация атрибутов (свойств) и операций каждого класса;
указание отношений между классами.
Рис. 10. Диаграмма классов для ИП «Формирование отчетных данных»
На рисунке 10 представлена диаграмма классов, которая была разработана для процесса «Формирование отчетных данных». Для каждого класса указаны атрибуты, тип атрибутов и квантор видимости. Для спецификации связей между классами использовались отношения ассоциации, зависимости, агрегации и обобщения. Для ряда отношений указана кратность и специфические роли входящих в нее компонентов.
На рис. 11 представлена диаграмма классов схемы отделов Финансового управления.
Рис. 11. Моделирование схемы отделов Финансового управления с помощью диаграммы классов
Таким образом, диаграммы классов были использованы для описания взаимосвязи между отдельными сущностями предметной области, их внутренней структуры и типов отношений. Результатом данного этапа моделирования является логическая схема базы данных информационной системы финансового менеджмента для отдела финансового управления муниципального образования.
При проектировании сложной информационной системы недостаточно статического представления моделируемой системы. Важнейшим аспектом функционирования информационных систем является их поведение. Для отражения в модели динамических аспектов функционирования ИСФМ для отдела финансового управления были использованы диаграммы состояний, деятельности и последовательностей.
Диаграмма состояний строится для моделирования поведения реактивных объектов, т. е. объектов, поведение которых лучше всего описывается их реакцией на внешние события. Диаграмма этого типа была использована для описания поведения объекта «Сметы» в течение его жизненного цикла (рис. 12).
Рис. 12. Диаграмма состояния класса «Сметы»
Диаграмма состояний объекта «Инвестиционная программа» приведена на рис. 13.
Рис. 13. Диаграмма состояний объекта класса «Инвестиционная программа»
При построении этих диаграмм были выделены устойчивые состояния объектов «Сметы» и «Инвестиционная программа» и допустимые переходы из состояний.
При моделировании последовательности действий при реализации информационных процессов отдела финансового управления были использованы диаграммы деятельностей. На рис. 14-15 приведены диаграммы деятельностей процессов «Экспертиза смет» и «Формирование инвестиционной программы».
Для разграничения ответственности подразделений за реализацию отдельных действий в соответствующих процессах были использованы специальные конструкции языка UML — дорожки. Например, при построении диаграммы процесса «Формирование инвестиционной программы» были выделены следующие участники, влияющие на реализацию данного процесса: бюджетополучатели, ведущий специалист, начальник финансового управления, глава самоуправления, городская дума. Информационный процесс представлен на диаграмме в виде переходов действий от одного участника к другому.
Рис. 14. Диаграмма деятельности для ИП «Экспертиза смет»
Рис. 15. Диаграмма деятельности для ИП «Формирование инвестиционной программы
Таким образом, использование диаграмм деятельностей позволяет наглядно представить деятельность отдела в рамках рассматриваемых процессов финансового управления. Для моделирования взаимодействия объектов применяются диаграммы последовательностей.
Рис. 16. Диаграмма последовательности для процесса «Составление бюджетной росписи по главным распорядителям»
На рис. 16 приведена диаграмма последовательности для процесса «Составление бюджетной росписи по главным распорядителям».
Диаграммы этого типа позволяют представить временные особенности передачи и приема сообщений между объектами. Ключевым моментом диаграмм последовательностей является динамика взаимодействия объектов во времени.
Рис. 16. Продолжение
Для построения данной канонической диаграммы были выделены объекты, участвующие во взаимодействии. Их располагают в верхней части диаграммы. Для каждого объекта необходимо изобразить его линию жизни. Некоторые объекты создаются не в начальный момент, а в процессе взаимодействия. Прямоугольники таких объектов и соответствующие им линии жизни располагаются не в верхней части диаграммы, а в части, соответствующей моменту создания объектов. Следующим этапом разработки диаграммы последовательности является спецификация коммуникации между множеством взаимодействующих объектов. Для этого определяются сообщения, которыми объекты обмениваются между собой.
Построенные объектно-ориентированные модели наглядно демонстрируют желаемую структуру проектируемой ИС. Они описывают поведение и предоставляют шаблон, на основе которого с помощью средств автоматической кодогенерации современных CASE-инстру-ментариев, поддерживающих язык UML (Rational Rose, AllFusion ERwin Data Modeler и Arena), может быть получен исходный код для определенного языка программирования (C++, Visual C++, Delphi, Smalltalk, Ada, PowerBuilder, COBRA/IDL и Oracle).
Рассмотренные в примере модели могут быть использованы при разработке ИСФМ отдела финансового управления, а также для анализа существующих информационных систем данного класса (например, по функциональной полноте), т. к. они отражают требования к сервисам, желаемую структуру и поведение системы.