Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Разработка информационной системы смарт-контрактов для купли-продажи акций

Разработка информационной системы смарт-контрактов для купли-продажи акций

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 10.12.2019
Размер файла 1,2 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования

Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Кафедра информационных технологий

Образовательная программа «Бизнес-информатика»

Выпускная квалификационная работа

по направлению подготовки 38.03.05 Бизнес-информатика

Тема:

Разработка информационной системы смарт-контрактов для купли-продажи акций

Выполнил Храмухин П.Р.

Руководитель к.ф.-м.н.,

доцент, Е.Б. Замятина

Пермь - 2019 год

Аннотация

Тема выпускной квалификационной работы: «Разработка информационной системы смарт-контрактов для купли-продажи акций».

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

Работа состоит из введения, трёх глав и заключения. В первой главе «Анализ предметной области процесса купли-продажи акций и определение требований к программному решению» формируется круг заинтересованных лиц, рассматриваются их требования, рассматривается процесс купли-продажи акций, производится обзор технологии смарт-контрактов, а также осуществляется выбор фреймворка и подходящей блокчейн-платформы для реализации среди нескольких аналогов.

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

Третья глава «Реализация информационной системы» содержит описание пользовательских страниц системы, описание функций, применённых для взаимодействия со средой блокчейн, а также описание процесса тестирования.

Выпускная квалификационная работа была выполнена Храмухиным П.Р., студентом 4 курса группы БИ-15-1. Выполнение исследования выполнялось в рамках учебной программы.

Выпускная квалификационная работа включает 72 страницы, 22 рисунка, 22 таблицы, 15 библиографических источников и 4 приложения.

Оглавление

  • Введение
  • Глава 1. Анализ предметной области процесса купли-продажи акций и определение требований к программному решению
  • 1.1 Анализ предметной области
    • 1.1.1 Формирование круга акторов
      • 1.1.2 Интервьюирование заинтересованных лиц
      • 1.1.3 Сущность процесса покупки и продажи акций и выбор используемого метода заключения договора
      • 1.1.4 Выбор платформы для реализации информационной системы
      • 1.1.5 Выбор подходящей блокчейн-платформы для реализации
    • 1.2 Требования к разрабатываемому продукту
      • 1.2.1 Функциональные требования
      • 1.2.2 Нефункциональные требования
  • Глава 2. Проектирование программного решения
    • 2.1 Процесс заключения договора купли-продажи акций
    • 2.2 Определение списка прецедентов
    • 2.3 Формализация бизнес-процессов
      • 2.3.1 Прецедент «продажа акций»
      • 2.3.2 Прецедент «покупка акций»
      • 2.3.3 Прецедент «администрирование»
    • 2.4 Диаграмма классов
  • Глава 3. Реализация информационной системы
    • 3.1 Разработка интерфейса информационной системы
      • 3.1.1 Страница регистрации
      • 3.1.2 Личный кабинет
      • 3.1.3 Страница создания заявки на продажу акции
      • 3.1.4 Страница информации об акции
    • 3.2 Использование технологии смарт-контрактов
    • 3.3 Тестирование информационной системы
  • Заключение
  • Библиографический список
  • Приложение А. Договор купли-продажи акций
  • Приложение Б. Техническое задание на разработку
  • Приложение В. Листинг смарт-контракта
  • Приложение Г. Результаты тестирования

Введение

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

Частным случаем заключения контракта является купля и продажа акций, при которой две стороны договариваются о заключении сделки на покупку акций с привлечением биржевого брокера. Процесс заключения данных сделок на данный момент занимает большое количество времени, для их заключения может требоваться привлечение третьих сторон, а контроль за их выполнением усложнён. Из этого можно сделать вывод, что в настоящее время задача разработки и внедрения средств, позволяющих осуществлять автоматизированное заключение и контроль за исполнением контрактов по купле-продаже акций, является востребованной и актуальной, так как это позволит снизить временные и денежные издержки, возникающие при совершении сделок, исключит влияние третьих лиц, а также упростит получение отчётности по заключаемым сделкам. Наиболее перспективным средством, позволяющим это осуществлять, является технология смарт-контрактов, базирующаяся на технологии blockchain.

Объектом исследования будут выступать договоры по купле-продаже акций.

Предмет исследования, выполняемого в рамках данного проекта -- смарт-контракты по купле-продаже акций.

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

Для достижения поставленной цели необходимо выполнить следующие задачи:

1. Проанализировать предметную область.

2. Осуществить выбор blockchain-платформы, поддерживающей механизм смарт-контрактов.

3. Описать и доработать существующий сценарий покупки и продажи акций.

4. Спроектировать пользовательские сценарии, позволяющие осуществлять заключение и исполнение сделок по купле-продаже акций.

5. Спроектировать диаграмму классов.

Используемыми методами научного исследования будут:

1. Объектно-ориентированный анализ -- в основу разработки сайта ляжет представление предметной области в виде диаграмм нотации UML, которые отражают взаимосвязи предметов и сущностей.

2. Моделирование -- в процессе разработки будут созданы графические модели, отражающие поведение объектов реального мира.

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

Глава 1. Анализ предметной области процесса купли-продажи акций и определение требований к программному решению

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

1.1 Анализ предметной области

На этапе анализа предметной области будет проведено формирование общего видения проектируемого программного решения. Сам этап анализа разделён на несколько последующих стадий:

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

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

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

4. Выбор наиболее благоприятной для реализации планируемого функционала системы blockchain-платформы.

5. Анализ механизма взаимодействия сторон при заключении сделок по купле-продаже акций с законодательной и практической точек зрения.

1.1.1 Формирование круга акторов

Проектирование программного решения в рамках данной работы осуществляется по запросу преподавателей и студентов кафедры гражданского и предпринимательского права НИУ ВШЭ-Пермь. Проектируемый веб-сайт предназначается для автоматизации процесса купли и продажи акций, осуществляемого физическими и юридическими лицами. Важным уточнением является то, что сами заключаемые сделки должны записываться в определённый «лог» с целью будущего просмотра, так как проектируемое программное решение является перспективным и требуется определить его эффективность и применимость в реальном мире. Исходя из вышесказанного, у веб-сайта имеется 3 категории пользователей, а именно:

· физическое лицо;

· юридическое лицо;

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

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

1.1.2 Интервьюирование заинтересованных лиц

С целью выявления существующих недостатков при заключении договоров о купле-продаже акций, а также определения и формализации списка пользовательских требований к проектируемому решению было проведено интервьюирование заинтересованных в реализации веб-сайта лиц, а именно преподавателей кафедры гражданского и предпринимательского права и студентов образовательной программы «Юриспруденция» НИУ ВШЭ-Пермь. Основной методикой для проведения интервью была очная встреча в формате круглого стола, которая предполагала представление заинтересованными лицами процесса взаимодействия между физическими и юридическими лицами в процессе купли-продажи акций, а также представление собственного видения системы как самими заинтересованными лицами, так и непосредственно исполнителем проектируемой системы с предоставлением возможности для задания и ответа на уточняющие вопросы. Результатом проведения интервью является следующее:

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

· при существующей практике осуществления процесса покупки и продажи акций обязательно участие посредников;

· на данный момент практика заключения договоров на продажу или покупку акций при помощи электронных средств не распространена на территории Российской Федерации.

Заинтересованные в реализации информационной системы лица выделили список недостатков, который можно увидеть на таблице 1.1.

Таблица 1.1

Выделенные заинтересованными лицами недостатки

Порядковый номер

Описание недостатка

1

Большое количество времени, затрачиваемого на процесс заключения договора

2

Большое количество времени, затрачиваемого на процесс исполнения договора

3

Сложность контроля за исполнением договора

4

Необходимость обязательного привлечения посредников

Исходя из результатов проведения интервью, в существующей практике осуществления сделок по продаже и покупке акций выделяется ряд определённых недостатков. Выделенные недостатки усложняют процесс обмена акциями и денежными средствами и увеличивают временные и денежные издержки, возникающие во время реализации самого процесса. Из вышеприведённой информации можно сделать вывод, что задача разработки и внедрения средства, позволяющего осуществлять автоматизированное заключение и контроль за исполнением договоров по купле-продаже акций, является востребованной и актуальной, так как это:

· позволит исключить необходимость прибегать к услугам третьих лиц, используемых в качестве посредников;

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

· уменьшит временные и денежные издержки, возникающие у сторон договора;

· уменьшит риски, что позволит сторонам договора договариваться на более выгодных для обеих сторон условиях;

· позволит избавиться от большого количества аналоговой документации.

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

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

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

Договор купли-продажи акций составляется по общим правилам. Его содержание должно включать в себя все существенные условия соглашения:

· стороны сделки, полные имена, контактные данные, адреса;

· предмет соглашения подразумевает подробное описание - количество акций, их тип, номинальная цена, дата и номер выпуска;

· стоимость приобретения - прописывается цена каждой бумаги и итоговая сумма, порядок оплаты, форма расчета, сроки;

· учитываются индивидуальные условия сделки и порядок передачи собственности новому владельцу;

· ответственность сторон, порядок разрешения разногласий.

В процессе интервьюирования не было получено точных данных о том, в каком виде должен заключаться договор о покупке-продаже акций. Следовательно, следует осуществить выбор метода заключения договора, который будет использоваться в проектируемом решении. На данный момент широко используется 2 основные разновидности заключения договора в электронном виде [8], а именно:

· письменный договор с последующей загрузкой условий и данных договора в информационную систему;

· «click-wrap» заключение договора.

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

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

1.1.4 Выбор платформы для реализации информационной системы

Проектируемое программное решение, согласно требованиям заинтересованных лиц, требуется реализовать в формате веб-сайта, таким образом, требуется выбрать фреймворк или технологию, которая позволит реализовать функциональность программного продукта. В качестве базовой подплатформы, которая позволяет реализовывать веб-сайты, была выбрана подплатформа «ASP.NET» платформы «Microsoft.NET». Данная подплатформа выбрана из-за имеющегося опыта разработки с её применением, а также из-за её общей гибкости и простоты разработки.

Подплатформой ASP.NET предоставляется возможность создания веб-приложений на базе двух основных технологий:

1. MVC [13], представляет собой связь модель-представление-контроллер, разделяющую данные приложения, его интерфейс и логику.

2. Web Forms [14], представляет собой сочетание автогенерируемых HTML элементов, для управления которыми используется «code-behind» подход.

Для сравнения двух альтернативных технологий применяется метод взвешенной оценки технологий по списку критериев, определённых заранее. Оценка дифференцируется от 0 до 10 баллов. Критерии и веса критериев были определены, исходя из предпочтений разработчика. Критерии представлены ниже:

1. Сложность использования -- какое минимальное количество времени требуется на освоение разработки с использованием технологии.

2. Производительность -- скорость работы ресурса, реализованного с использованием технологии.

3. Опыт разработки -- оценка опыта разработки с применением данной технологии.

4. Расширяемость -- возможность расширения функциональности веб-сайта, реализованного с применением данной технологии.

5. Количество документации -- количество эксплуатационной документации, предоставляемой компанией-разработчиком и сообществом пользователей.

Для каждого из критериев были определены и выставлены оценки. Оценки по вышеуказанным критериям для каждой из технологий приведены в таблице 1.1.

Таблица 1.1

Взвешенная оценка у технологий по реализации веб-сайта

Критерий

Вес критерия

Оценка у Web Forms

Произведение веса на оценку у WebForms

Оценка у MVC

Произведение веса на оценку у MVC

Сложность использования

0,2

10

2

4

0,8

Производительность

0,1

6

0,6

9

0,9

Опыт

0,2

10

2

5

1

Расширяемость

0,1

6

0,6

8

0,8

Количество документации

0,3

8

2,4

6

1,8

Взвешенная оценка у Web Forms:

7,6

Взвешенная оценка у MVC:

5,3

Как можно увидеть по результатам взвешенной оценки двух сравниваемых технологий, являющихся альтернативами друг другу, взвешенная оценка у Web Forms оказывается выше на 2,3 взвешенной оценки у MVC. Следовательно, наиболее благоприятной альтернативой является «ASP.NET Web Forms».

1.1.5 Выбор подходящей блокчейн-платформы для реализации

Применение блокчейн-платформ не широко распространено в сфере права, однако на данный момент одним из самых многообещающих и развивающихся подходов к применению технологии блокчейн и автоматизированных транзакций является технология «смарт-контрактов», позволяющая заключать и контролировать договоры и соглашения между двумя и более сторонами [1]. Как сообщают в своей работе [1] Д. Голдфейн и А. Лейтер, первое применение данная технология нашла на базе блокчейн-платформы «Ethereum», которая обеспечивает стабильность, анонимность и защищённость процесса исполнения договора. Специалисты заключают «смарт-контракты», которые позволяют обмениваться информацией, деньгами и прочими материальными ценностями. В конечном счёте, автоматизированные транзакции позволят судам, государству, организациям или частным лицам заключать и исполнять договоры без риска потери личных данных или нарушения условий договора одной из сторон. Как отмечает в своей работе Э. Мик [2], весь процесс заключения «смарт-контрактов» основывается на трёх принципах: «Надёжность», «Валидация» и «Самоисполняемость». Проще говоря, стороны договора не обязаны прибегать к привлечению третьих лиц, все транзакции записываются и подтверждаются, а «смарт-контракты» автоматически переводят токены в случае неуплаты, долга или неисполнения условий договора. Смарт-контракты упрощают процесс исполнения договора и снижают затраты на его проведение путём избавления от необходимости привлечения доверенных лиц и необходимости защиты со стороны традиционных государственных институтов [2].

Анонимность и надёжность самоисполняемых контрактов достигается при помощи использования комбинации публичного и приватного ключей. Согласно работе М. Абрамовича [3], один из ключей используется для того, чтобы зашифровать исходные данные, а другой для того, чтобы исходные данные дешифровать. Таким образом, каждая транзакция подписывается приватным ключом, который соответствует публичному ключу, который доступен каждому. Угадать один из ключей, либо отличить приватный ключ от публичного невозможно без знания верных алгоритмов их формирования [3]. Таким образом, данная технология является безопасной и практически анонимной. Вдобавок к анонимности и безопасности, самой важной особенностью протоколов смарт-контрактов является таймер, который ведёт отсчёт и не позволяет ни одной из сторон избежать уплаты суммы, указанной в договоре [4]. Однако, несмотря на все преимущества, технология смарт-контрактов имеет и некоторые недостатки, к примеру, в работе К. Кристидис и др. отмечается [5], что смарт-контракты испытывают так называемую «проблему производительности». Более того, использование смарт-контрактов поднимает глобальные вопросы, связанные с государственным регулированием, так как электронный договор, заключённый при помощи них, не может быть отслежен или раскрыт [1]. Тем не менее, новые подходы к применению смарт-контрактов (фреймворк Hawk [4] или Bitcoin NG [5]) показывают многообещающие результаты, расширяя базовые принципы блокчейна Ethereum путём ввода новых ролей в процесс исполнения контракта и путём использования новых протоколов безопасности, которые позволяют нивелировать «проблему производительности».

Смарт-контракты позволяют обеспечить высокую производительность и снизить затраты на заключение и исполнение договоров в связи с электронной формой существования жизненного цикла договора, удалением из процесса посредников, однако сама система должна быть доработана для применения во всех сферах права. Но даже на текущий момент смарт-контракты готовы для применения в финансовой сфере. Как отмечает в своей работе Питер У. и др. [6], технология смарт-контрактов имеет потенциал для применения в процессе покупки акций и облигаций, а также для поддержки избирательной системы, хотя, по словам Марка Гианкаспаро [7], для перехода на использование данных технологий потребуется много времени, так как существующий коммерческий рынок располагает большим количеством устоявшихся посредников и игроков.

Таким образом, на данный момент технология смарт-контрактов применима для обеспечения процесса покупки и продажи акций физическими и юридическими лицами. Следовательно, требуется осуществить выбор подходящей блокчейн-платформы для реализации системы по покупке-продаже акций. Потенциально, исходя из работы К. Клэк [8], смарт-контракты поддерживаются следующими платформами: Ethereum [11], Corda [10], Hyperledeger Fabric [9] и EOS [12]. Основным языком для разработки на Ethereum является Solidity, а основными преимуществами являются гибкость, низкий порог вхождения и большое сообщество пользователей. Hyperledger Fabric же поддерживает разработку на языках Go, Java и Javascript, однако он более ориентирован на корпоративный сегмент и является растущей платформой с небольшим количеством пользователей и высоким порогом вхождения. Corda является надстройкой над Ethereum и является узкоспециализированным средством для финансовых организаций, разработка ведётся с применением языков Java или Kotlin.

Сравнение вышеперечисленных блокчейн-платформ будет производиться методом взвешенной оценки по следующим критериям [15]:

1. Применяемый язык программирования (по данному критерию оценка выставляться не будет)

2. Применяемый язык программирования для исполнения контрактов (по данному критерию оценка выставляться не будет).

3. Количество справочной информации, созданной сообществом пользователей.

4. Трудоёмкость использования -- определяет то, за какое минимальное количество времени может быть освоено применение платформы (выше оценка -- ниже трудоёмкость).

5. Расширяемость.

6. Гибкость настройки приватности транзакций.

7. Шифрование транзакций.

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

Таблица 1.2

Таблица оценок блокчейн-платформ по критериям

Критерий/Платформа

Ethereum

Corda

Hyperledger Fabric

EOS

Язык разработки

GO, C++, Rust

Kotlin, Java

Go

C++

Язык смарт-контрактов

Solidity

Kotlin, Java

JavaScript, Golang

C, C++

Количество справочной информации

10

5

6

5

Трудоёмкость использования

10

7

6

5

Расширяемость

6

3

5

6

Гибкость настройки приватности

8

0

0

0

Шифрование транзакций

0

10

10

10

Общий балл

6,8

5

5,4

5,2

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

1.2 Требования к разрабатываемому продукту

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

1.2.1 Функциональные требования

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

1. Общие требования.

a. Возможность авторизации при помощи пары логин-пароль.

b. Возможность ввода информации о пользователе.

c. Возможность взаимодействия с другими пользователями.

2. Требования по работе с акциями.

a. Возможность прикрепления документов.

b. Возможность просмотра реестра предлагаемых акций.

c. Возможность просмотра информации о предлагаемой акции.

d. Возможность заключения договора на покупку акций.

e. Возможность выставления акций на продажу.

f. Возможность просмотра поступивших предложений на покупку акций.

g. Возможность заключения договора на продажу акций.

h. Возможность просмотра информации об исполняемом договоре.

3. Требования администратора.

a. Возможность просмотра реестра заключённых договоров.

b. Возможность очистки реестра заключённых договоров.

1.2.2 Нефункциональные требования

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

1. Система должна поддерживать использование двумя и более пользователями.

2. Система должна иметь удалённый доступ со множества персональных компьютеров, подключённых к сети Интернет.

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

4. Возникающие во время работы ИС исключительные ситуации должны обрабатываться и сопровождаться соответствующим сообщением об ошибке.

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

6. Веб-сайт должен обладать высоким уровнем стабильности.

7. Данные веб-сайта должны надёжно храниться в соответствующей базе данных.

8. Транзакции при процессе купли-продажи акций должны быть анонимны.

9. Данные, участвующие в процессе купли-продажи акций должны быть зашифрованы.

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

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

Глава 2. Проектирование программного решения

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

2.1 Процесс заключения договора купли-продажи акций

Процесс заключения контракта купли-продажи акций состоит из нескольких последовательных шагов, выполняемых сторонами договора и посредником. В текущий момент данные сделки совершаются при помощи заключения договора купли-продажи при опциональном привлечении посредника для заверения договора. Весь процесс купли-продажи в перспективе «AS IS» отражён на рисунке 2.1.

Рисунок 2.1 Процесс заключения договора на продажу акций «AS IS»

Как можно заметить из схемы функционирования бизнес-процесса, приведённой выше, на текущий момент процесс заключения договора купли-продажи акций акционерного общества (далее - АО) располагает несколькими недостатками, а именно:

1. Уведомление других участников АО производится в письменной форме.

2. Составление договора купли-продажи производится в очной форме.

3. Может потребоваться привлечение третьих сторон.

4. Оплата покупателем суммы по договору производится до подписания продавцом передаточного распоряжения, что, может привести к злоупотреблениям со стороны продавца.

Перечисленный список недостатков приводит к временным затратам в процессе купли-продажи акций. Данные недостатки могут быть решены при помощи доработки существующего процесса заключения договора с учётом привлечения разрабатываемой системы по заключению смарт-контрактов. Доработанный бизнес-процесс в перспективе «TO BE» представлен на рисунке 2.2.

Рисунок 2.2 Процесс заключения договора на продажу акций «TO BE»

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

2.2 Определение списка прецедентов

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

1. Администрирование.

a. Просмотр совершённых сделок.

b. Очистка реестра сделок.

c. Получение отчётности по сделкам.

d. Просмотр страницы продажи акции.

2. Продажа акций.

a. Создание заявки на продажу.

b. Просмотр страницы продажи акции.

c. Прикрепление документов.

d. Просмотр предложений о покупке.

e. Прекращение продажи акции.

f. Редактирование предложения о продаже акции.

g. Уточнение условий.

h. Получение средств.

3. Покупка акций.

a. Просмотр реестра акций.

b. Создание заявки на покупку.

c. Просмотр страницы продажи акции.

d. Уточнение условий.

e. Перечисление средств.

f. Прикрепление документов.

Данный список прецедентов напрямую привязан к выделенным в процессе анализа предметной области функциональным требованиям. Таблица 2.1 отражает взаимосвязи между функциональными требованиями и прецедентами.

Таблица 2.1

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

№

Требование

Прецедент

1

Возможность просмотра информации об исполняемом договоре

Администрирование

2

Возможность просмотра реестра заключённых договоров

3

Возможность прикрепления документов

Продажа акций

4

Возможность заключения договора на продажу акций

5

Возможность выставления акций на продажу

6

Возможность просмотра поступивших предложений на покупку акций

7

Возможность просмотра реестра предлагаемых акций

Покупка акций

8

Возможность просмотра информации о предлагаемой акции

9

Возможность заключения договора на покупку акций

4

Возможность прикрепления документов

На рисунке 2.3 схематически отображены взаимосвязи между сформированными прецедентами и потенциальными пользователями Системы.

Рисунок 2.3 Диаграмма прецедентов веб-сайта по купле-продаже акций

2.3 Формализация бизнес-процессов

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

2.3.1 Прецедент «Продажа акций»

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

Список включаемых или расширяющих прецедент подпроцессов:

1. Создание заявки на продажу.

2. Просмотр страницы продажи акции.

3. Прикрепление документов.

4. Просмотр предложений о покупке.

5. Прекращение продажи акции.

6. Редактирование предложения о продаже акции.

7. Уточнение условий.

8. Получение средств.

Выделенные выше подпроцессы описаны при помощи таблиц, а также при помощи диаграмм последовательности в нотации UML. Подпроцесс «Создание заявки на продажу» обладает последовательностью действий, отражённой в таблице (см. табл. 2.2). В рамках данного прецедента осуществляется создание пользователем заявки на продажу акции.

Таблица 2.2

Описание прецедента «Создание заявки на продажу»

Название процесса

Создание заявки на продажу

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

Основной поток

№ действия

Описание действия

Наименование действия

1

Начало прецедента происходит при нажатии пользователем кнопки «Создание заявки на продажу акций»

Переадресация на страницу «Создать заявку на продажу», Вывод окна создания заявки на продажу.

2

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

Загрузка данных об акциях,

Отображение данных об акциях

3

Пользователь выбирает тип акций, которые планирует продать

Выбор акций

4

Пользователь осуществляет ввод начальных условий договора

Ввод условий договора

5

Пользователь осуществляет нажатие на клавишу «Создать заявку»

Нажатие клавиши «Создать заявку»

6

Системой создаётся заявка на продажу

Создание заявки на продажу

Альтернативный поток

№ действия

Описание действия

Наименование действия

1

При некорректно заданных в полях ввода значениях Система выводит пользователю сообщение об ошибке

Вывод ошибки

2

Система осуществляет сброс введённых неверно данных

Сброс введённых неверно данных

Завершающее событие

№ события

Описание события

1

Сохранение данных

2

Переадресация на страницу созданной заявки на Закупку

Выделенная в данном подпроцессе последовательность действий была отражена графически при помощи диаграммы последовательностей, что отображено на рисунке (см. рис. 2.4).

Рисунок 2.4 Диаграмма последовательностей прецедента «Создание заявки на продажу»

информационный blockchain платформа бизнес процесс

Подпроцесс «Просмотр страницы продажи акции» обладает последовательностью действий, отражённой в таблице 2.3. В рамках данного прецедента осуществляется просмотр пользователем данных об акции, которая выставлена на продажу.

Таблица 2.3

Описание прецедента «Просмотр страницы продажи акции»

Название процесса

Просмотр страницы продажи акции

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь осуществил выбор акции, информацию о которой он хочет просмотреть

Основной поток

№ действия

Описание действия

Наименование действия

1

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

Загрузка данных об акции и условиях договора, Загрузка данных о пользователе

2

Система отображает данные об акции и пользователе, который создал заявку на продажу

Отображение данных об акции и условиях договора, Отображение данных о пользователе

Альтернативный поток

Отсутствует

Завершающее событие

Отсутствует

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

Подпроцесс «Прикрепление документов» обладает последовательностью действий, отражённой в таблице 2.4. В рамках данного прецедента осуществляется прикрепление пользователем документа на странице продажи акции. Данный документ может иметь следующие форматы:

· растровое изображение с расширением JPG;

· текстовый документ с расширением DOCX;

· текстовый документ с расширением PDF.

Рисунок 2.5 Диаграмма последовательностей прецедента «Просмотр страницы продажи акции»

Таблица 2.4

Описание прецедента «Прикрепление документов»

Название процесса

Прикрепление документов

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь находится на странице заявки на продажу

3

Пользователь является участником сделки

Основной поток

№ действия

Описание действия

Наименование действия

1

Пользователь осуществляет нажатие на клавишу «Загрузка документа»

Нажатие на клавишу «загрузка документа», Отображение окна для загрузки файлов

2

Пользователь выбирает файлы для загрузки

Выбор файлов для загрузки

3

Пользователем осуществляется нажатие на клавишу «Подтвердить»

Подтверждение загрузки, Закрытие окна для загрузки файлов, Загрузка файлов

Альтернативный поток

1

При неверном размере файла или расширении одного из файлов система отображает сообщение об ошибке

Вывод ошибки

2

Система сбрасывает выбранные файлы

Сброс выбора

Завершающее событие

1

Сохранение изменений

Сохранение

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

Рисунок 2.6 Диаграмма последовательностей прецедента «Прикрепление документов»

Подпроцесс «Просмотр предложений о покупке» обладает последовательностью действий, отражённой в таблице 2.5. В рамках данного прецедента осуществляется просмотр продавцом поступивших заявок на покупку акции.

Таблица 2.5

Описание прецедента «Просмотр предложений о покупке»

Название процесса

Просмотр предложений о покупке

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь находится на странице заявки на продажу

3

Пользователь является создателем данной заявки

Основной поток

№ действия

Описание действия

Наименование действия

1

Пользователь осуществляет нажатие на клавишу «Просмотр предложений на покупку»

Нажатие на клавишу «Просмотр предложений на покупку»,

Переадресация на страницу просмотра предложений на покупку

2

Система загружает список предложений

Загрузка списка предложений

3

Система отображает список предложений в виде реестра

Отображение списка предложений

Альтернативный поток

Отсутствует

Завершающее событие

Отсутствует

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

Рисунок 2.7 Диаграмма последовательностей прецедента «Просмотр предложений о покупке»

Подпроцесс «Прекращение продажи акции» обладает последовательностью действий, отражённой в таблице 2.6. В рамках данного прецедента осуществляется просмотр продавцом поступивших заявок на покупку акции.

Таблица 2.6

Описание прецедента «Прекращение продажи акции»

Название процесса

Просмотр предложений о покупке

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь находится на странице заявки на продажу

3

Пользователь является создателем данной заявки

Основной поток

№ действия

Описание действия

Наименование действия

1

Пользователь осуществляет нажатие на клавишу «Отменить заявку»

Нажатие на клавишу «Отменить заявку»

2

Система отображает окно подтверждения

Отображение окна подтверждения

3

Пользователь подтверждает удаление

Подтверждение

4

Системой осуществляется удаление данных о продаже

Удаление данных о продаже

5

Производится переадресация на главную страницу

Переадресация на главную страницу

Альтернативный поток

1

Если пользователь нажал в подтверждении удаления клавишу «Нет», то диалоговое окно закрывается и дальнейших изменений не происходит

Закрытие диалогового окна

Завершающее событие

1

Сохранение изменений

Сохранение

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

Рисунок 2.8 Диаграмма последовательностей прецедента «Прекращение продажи акции»

Подпроцесс «Редактирование предложения о продаже акции» обладает последовательностью действий, отражённой в таблице (см. табл. 2.7). В рамках данного прецедента осуществляется просмотр продавцом поступивших заявок на покупку акции.

Таблица 2.7

Описание прецедента «Редактирование предложения о продаже акции»

Название процесса

Редактирование предложения о продаже акции

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь находится на странице заявки на продажу

3

Пользователь является создателем данной заявки

Основной поток

№ действия

Описание действия

Наименование действия

1

Пользователь осуществляет нажатие на клавишу «Редактировать заявку»

Нажатие на клавишу «Редактировать заявку»

2

Система разблокирует поля для ввода

Разблокировка полей для ввода

3

Пользователь вводит новые данные в поля

Ввод данных

4

Пользователь нажимает на клавишу «Сохранить»

Нажатие на клавишу «Сохранить»

5

Система сохраняет изменения

Сохранение

6

Поля для ввода блокируются

Блокировка полей для ввода

Альтернативный поток

1

Если пользователь ввёл некорректное значение в поля для ввода, выводится сообщение об ошибке

Вывод сообщения об ошибке

Завершающее событие

Отсутствует

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

Рисунок 2.9. Диаграмма последовательностей прецедента «Редактирование предложения о продаже акции»

Подпроцесс «Уточнение условий» обладает последовательностью действий, отражённой в таблице 2.8. В рамках данного прецедента осуществляется просмотр продавцом поступивших заявок на покупку акции.

Таблица 2.8

Описание прецедента «Уточнение условий»

Название процесса

Редактирование предложения о продаже акции

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь находится на странице заявки на продажу

3

Пользователь является участником сделки

4

Начальные условия согласованы

Основной поток

№ действия

Описание действия

Наименование действия

1

Пользователь проставляет галки и вводит значения в поля, которые задают дополнительные условия договора

Ввод дополнительных условий

2

Пользователь подтверждает ввод нажатием клавиши «Сохранить условия договора»

Нажатие на клавишу «Сохранить условия договора»

3

Система сохраняет изменения и блокирует поля для ввода

Сохранение изменений, блокировка полей для ввода

4

Система при наличии данных загружает данные о введённых второй стороной договора условиях

Загрузка данных второй стороны, Отображение данных второй стороны

5

Пользователь жмёт клавишу «Согласен с условиями»

Нажатие на клавишу «Согласен с условиями»

6

Система сохраняет изменения и блокирует заявку полностью

Сохранение изменений, блокировка заявки

Альтернативный поток

1

Если пользователь ввёл некорректное значение в поля для ввода, выводится сообщение об ошибке

Вывод сообщения об ошибке

2

Если пользователь не согласен с условиями, заданными второй стороной, он нажимает на клавишу «Не согласен с условиями»

Нажатие на клавишу «Не согласен с условиями»

2.1

Система разблокирует поле для ввода замечаний

Разблокировка поля для ввода замечаний

2.2

Пользователь вводит замечания и жмёт клавишу «Сохранить замечания»

Ввод замечания, Нажатие на клавишу «Не согласен с условиями»

2.3

Система сохраняет изменения

Сохранение изменений

Завершающее событие

Отсутствует

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

Рисунок 2.10 Диаграмма последовательностей прецедента «Уточнение условий»

Подпроцесс «Получение средств» обладает последовательностью действий, отражённой в таблице 2.9. В рамках данного прецедента осуществляется просмотр продавцом поступивших заявок на покупку акции.

Таблица 2.9

Описание прецедента «Получение средств»

Название процесса

Редактирование предложения о продаже акции

Предшествующее событие

№ события

Описание события

1

Пользователь авторизован в информационной системе

2

Пользователь находится на странице заявки на продажу

3

Пользователь является участником сделки

4

Начальные и дополнительные условия согласованы

5

Покупатель перечислил средства

Основной поток

№ действия

Описание действия

Наименование действия

1

Пользователь составляет в системе передаточное распоряжение путём ввода соответствующих данных

Ввод данных передаточного распоряжения

2

Пользователь подтверждает ввод нажатием клавиши «Отправить распоряжение»

Нажатие на клавишу «Отправить распоряжение»

3

Система сохраняет изменения и блокирует поля для ввода

Сохранение изменений, блокировка полей для ввода

4

Система отправляет передаточное распоряжение регистратору

Отправление передаточного распоряжения регистратору

5

Средства внутри системы перечисляются продавцу

Перечисление средств продавцу

6

Система сохраняет изменения и блокирует заявку полностью

Сохранение изменений, блокировка заявки

Альтернативный поток

1

Если пользователь ввёл некорректное значение в поля для ввода, выводится сообщение об ошибке

Вывод сообщения об ошибке

Завершающее событие

Отсутствует

Рисунок 2.11. Диаграмма последовательностей прецедента «Получение средств»

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

2.3.2 Прецедент «Покупка акций»

Прецедент «Покупка акций» задействуется в том случае, если пользователь проектируемой системы имеет намерения осуществить покупку акций АО. Стандартный вариант использования выглядит следующим образом: пользователь открывает реестр заявок на продажу, выбирает подходящую для него, отправляет заявку на покупку, далее, после подтверждения заявки продавцом, уточняются условия договора, перечисляются средства за акцию, после чего права на акцию передаются покупателю от продавца.

Список включаемых или расширяющих прецедент подпроцессов:

1. Просмотр страницы продажи акции.

2. Прикрепление документов.

3. Уточнение условий.

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены