Файл: Проектирование реализации операций бизнес-процесса «Управление денежными потоками» (Выбор комплекса задач автоматизации).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 26.06.2023

Просмотров: 64

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Эксперты проводят приемку, агрегат и использование программных товаров в согласовании с намерениями становления информативных порядков банка. Аппарат программного снабжения будет сопровождаемым и учебой служащих отделения работы с ним.

От работы техники, программных средств и банкоматов зависит служба и самого банка. Потому подкрепление верной службы техники и программных средств – основная цель профессионалов. В нее вступает промышленное сопровождение и предупредительные службы по обеспечиванию службы промышленных частей информативных порядков.

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

2.3. Характеристика результатной информации

Диаграммы потоков данных (DFD – Data Flow Diagram) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. Важную специфическую роль в модели играет специальный вид DFD –

Контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана.

Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Для этого используется диаграммы декомпозиции. Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм.

Построю контекстную DFD диаграмму системы. Для этого необходимо изобразить основную функцию рассматриваемой системы «Управление денежными потоками» и внешние по отношению к ней сущности, а также взаимосвязи между внешними сущностями и функцией системы. Контекстная диаграмма будет выглядеть следующим образом.


Рисунок 2 - Контекстная диаграмма системы «Управление денежными потоками

Основным процессом является Электронный банкинг, т.к. вся деятельность системы направлена именно на это. Внешними сущностями являются Операционист и Клиент. Для регистрации в системе клиент вводит соответствующую информацию, после имеет возможность передавать операционисту электронные Документы и отправлять Запросы на отзыв документов, что отражено на диаграмме в виде информационных потоков. Получив документы заемщика, обработанные системой по формализованным правилам, операционист начинает их обработку по не формализованным правилам. Отправляет документы в РКЦ НБ, где решается вопрос об исполнении или неисполнении документа. Так же операционист может отказать в передаче последнего в РКЦ.

После создания контекстной диаграммы, я постаралась рассмотреть

функции системы более подробно и построить диаграмму детализации первого уровня.

В результате декомпозиции была получена диаграмма первого уровня.

Рисунок 3 - Диаграмма детализации первого уровня системы «Управление денежными потоками»

2.4. Общие положения (дерево функций и сценарий диалога)

Rational Rose — мощный инструмент анализа и проектирования объектно-ориентированных програм­мных систем. Он позволяет моделировать системы до написания кода, так что вы можете с самого на­чала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует еще значительных затрат. Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуа­лизации функциональных возможностей системы.

Use case diagram (диаграммы прецедентов) - позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые.


Исходя из поиска ответов на следующие вопросы:

Кто взаимодействует с системой или использует систему?

Кто передает или принимает информацию в/из системы?

Кто является внешним по отношению к системе?

Я выявила следующих субъектов.

Рисунок 4 - Субъекты системы

Прецедент представляет собой целостный набор функций, имеющих определенную ценность для субъекта. Прецеденты можно вывести в результате определения задач для субъекта. Для этого следует задаться вопросом: «Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?»

Каждый вариант использования (прецедент) определяет набор действий, совершаемых системой при диалоге с актером. При этом ничего не говорится о том, как конкретно будет реализовано взаимодействие актеров с системой и собственно выполнение вариантов использования.

Прецедент изображается в виде эллипса, внутри или ниже которого помещается имя прецедента.

Рисунок 5 - Прецеденты системы

Диаграмма прецедентов приписывает прецеденты к субъектам. Она также позволяет пользователю установить отношения между прецедентами, конечно, если такие отношения существуют.

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

Достоинства модели вариантов использования заключаются в том, что она:

  • определяет пользователей и границы системы;
  • определяет системный интерфейс;
  • удобна для общения пользователей с разработчиками;
  • используется для написания тестов;
  • является основой для написания пользовательской документации;
  • хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).

Рисунок 6.

Варианты использования и субъекты, выделенные для данной модели, можно представить в виде следующей диаграммы прецедентов:

Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы. Это вид диаграмм особенно важен при организации и моделирования поведения системы. На них представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Актер – это роль, которую пользователь играет по отношению к системе.


Между субъектами и вариантами использования могут быть различные виды взаимодействия. Так, из построенной диаграммы видно, что Клиент банка инициирует различные варианты использования: Регистрация, Аутентификация, Получение выписки, Отзыв документа, Создание нового письма и так далее.. Операционист также может инициировать варианты использования, например, Проверка новых поступлений, Регистрация, Аутентификация, Обработка документа и т.д.

Рисунок 7 - Диаграмма прецедентов для субъекта Клиент банка

Остановлюсь подробнее на некоторых отношениях между вариантами использования.

Следует прокомментировать некоторые особенно «привлекательные» отношения между вариантами использования.

Так, смысл отношения «include» состоит в том, что Создание платежного документа включает в себя Создание платежного поручения и Создание платежного требования. Также, прецедент Подписать документ ЭЦП выполняется только в рамках Создания платежного документа, Создания нового письма или Отзыва документа.

Смысл же связи <<extend>> в том, что прецедент, например, Создание платежного документа «расширяется» вариантом использования Сохранение документа, которой в свою очередь расширяется прецедентом Проверка реквизитов документа. Я объясняю это тем, что сохранить документ можно только проверенный системой на наличие ошибок. Распечатка перечня документов за определенный период «расширяет» прецедент Получение выписки. Таким образом, связь <<extend>> говорит о выполнении того или иного прецедента в зависимости от определенных условий.

2.6. Структурная схема пакета (дерево вызова программных модулей)

Модели видов деятельности (Activity Diagram) строятся для описания общей последовательности действий для нескольких объектов и вариантов использования. На диаграммах этого типа представляются переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами.

Основным элементом диаграммы видов деятельности является деятельность. Интерпретация этого термина зависит от той точки зрения, с которой строится данная диаграмма. На концептуальной диаграмме деятельность – это некоторая задача, которую необходимо выполнить вручную или автоматизированным способом. На диаграмме, построенной в аспекте спецификации или реализации, деятельность представляет собой некоторый метод над классом.


Диаграмма деятельностей предоставляет свободу выбора порядка выполнения. Другими словами, она только устанавливает основные правила последовательности, которым необходимо следовать. Такая возможность важна при моделировании бизнес-процессов. Среди бизнес-процессов нередко встречаются такие, которые не обязаны выполняться последовательно. В таких ситуациях данный метод хорошо работает, так как он позволяет реализовывать процессы параллельно.

Диаграммы видов деятельности являются также полезными при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать.

Если при описании поведения системы имеются параллельные деятельности, то их необходимо синхронизировать. Простая линейка синхронизации показывает, что ее выходная деятельность активизируется только тогда, когда выполнены обе входные деятельности.

Диаграммы видов деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы видов деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме.

Рассмотрим теперь модели видов деятельности, построенные для проектируемой системы.

Рисунок 8 - Диаграмма видов деятельности для прецедента распечатка перечня денежных потоков за определенный период

Клиент имеет возможность распечатать любой документ по форме. Для этого ему необходимо войти в систему. Из дерева документов выбрать Выписка. Сформировать ее. В окне документа отображается перечень всех документов, удовлетворяющих требованию клиента. Клиент банка может выбрать документ(документы) из списка. Документ, отобразившийся в окне клиента банка, может быть распечатан.

Рисунок 9 - Диаграмма видов деятельности для прецедента Аутентификация пользователя

Для входа в систему «Управление денежными потоками» должна произойти аутентификация клиента. Для этого клиенту необходимо открыть программу. Автоматически появляется форма аутентификации. Далее Клиент системы должен указать путь на файл с Хранилищем ключей ЭЦП клиента. В результате в окне отобразиться список ключей ЭЦП клиента, содержащиеся в Хранилище ключей. Клиент должен выбрать необходимый ключ и ввести пароль для доступа к ключу. Если проверка сведений проходит успешно, то открывается доступ в систему. Иначе выводится сообщение об ошибке и предлагается возможность повторить попытку аутентификации.