РАЗРАБОТКА КЛИЕНТСКОЙ СИСТЕМЫ ПОДДЕРЖКИ БИРЖЕВЫХ ТОРГОВ - Студенческий научный форум

X Международная студенческая научная конференция Студенческий научный форум - 2018

Личный портфель

РАЗРАБОТКА КЛИЕНТСКОЙ СИСТЕМЫ ПОДДЕРЖКИ БИРЖЕВЫХ ТОРГОВ

Григоренко В.Е. 1, Путивцева Н.П. 1
1Белгородский государственный национальный исследовательский университет
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF
ВВЕДЕНИЕ

Цель данной курсовой работы является проектирования информационной системы на тему «Разработка клиентской системы поддержки биржевых торгов». При помощи технологий моделирования бизнес-процессов таких как: IDEF0, DFD, IDEF3, а также ER-диаграммы на логическом и физическом уровне.

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

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

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

Вопросы, которые будут рассмотрены в курсовой работе:

  • Вопросы, описанные в теоретической части;

  1. Анализ предметной области, изучение основных понятий, выявление задач;

  2. Изучение основных понятий и функций различных популярных методологий;

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

  4. Общее сведения о проектировании базах данных, основные понятия и функциональные возможности;

  5. Информация о создании логической модели для баз данных;

  6. Информация о создании физической модели для баз данных;

  • Вопросы, рассмотренные в разделе проектировании информационной системы;

  1. Изучение проблем и поиск методов решения, анализ решений;

  2. Построение моделей при помощи методологии IDEF0;

  3. Построение моделей при помощи методологии IDEF3;

  4. Построение моделей при помощи методологии DFD;

  5. Построение моделей при помощи методологии UML;

  6. Определение основных сущностей, проектирование и разработка модели базы данных;

  7. Построение логической моделей для базы данных при помощи методологии UML;

  8. Проектирование физической модели для базы данных.

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

Данная работа состоит из 2 разделов, 34 страниц, 2 таблиц, 21 рисунка.


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

    2. Теоретическая часть

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

Биржа – юридическое лицо, предоставляющая доступ к рынкам ценных бумаг, валют, биржевых товаров, а также иных производных финансовых инструментов. [25]

Котировка – цена (курс, процентная ставка) товара, которую объявляет продавец или покупатель и по которой они готовы совершить покупку или продажу (предлагается оферта). [24]

Сделка – договор, заключаемый между участниками в ходе биржевых торгов.

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

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

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

Фьючерс (фьючерсный контракт) – производный финансовый инструмент, срочный биржевой контракт купли-продажи базового актива, при заключении которого стороны (продавец и покупатель) договариваются только об уровне цены. Остальные параметры актива (количество, сроки поставки, качество, упаковка, маркировка и т. п.) оговорены заранее в спецификации биржевого контракта. Бывают поставочные (базовый актив – акции, товары, сырье) и расчетные (фьючерсы на индексы). В расчетных контрактах между участниками производятся только денежные расчёты в сумме разницы между ценой открытия позиции и ценой ее закрытия без физической поставки базового актива. [24]

Виды сделок:

  1. Покупка финансового инструмента (long, длинная позиция) – сделка, осуществленная в расчёте на рост стоимости на финансовый актив.

  2. Продажа финансового инструмента (short, короткая позиция) – сделка, осуществленная в расчете на падения цен на финансовый актив.

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

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

  1.  

    1. Изучение методологий

Сущность методологии IDEF0

Методология функционального моделирования IDEF0 - это методология описания системы в целом как множества взаимозависимых действий или функций. Наиболее часто IDEF0 применяется как технология исследования и проектирования систем на логическом уровне [2]. По этой причине она, как правило, используется на ранних этапах разработки проекта. Результаты IDEF0 анализа могут применяться при проведении проектирования с использованием моделей IDEF3 и диаграмм потоков данных. [6]

Методология IDEF0 сочетает в себе небольшую по объему графическую нотацию. Она содержит только два обозначения: блоки и стрелки. Так же есть 4 возможных типа стрелок в IDEF0, каждый из типов соединяется со своей стороной функционального блока (стрелка входа, стрелка выхода, стрелка управления, стрелка механизма исполнения).

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

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

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

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

Стрелки механизма исполнения. Механизм исполнения является ресурсом, который непосредственно исполняет моделируемое действие. В качестве механизмов исполнения обычно выступают персонал или техника. Комбинированные стрелки.

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

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

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

Сущность методологии IDEF3

Методология IDEF3 – это методология описания процессов в виде упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.

IDEF3 не имеет жестких синтаксических или семантических ограничений.

Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или процессов анализируемой системы. [8]

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

Таблица 1

Типы соединений в модели IDEF3

Графическое обозначение

Название

Вид

Правила инициации

 

Соединение «И»

Разворачивающее

Каждое конечное действие обязательно инициируется

Сворачивающее

Каждое исходное действие обязательно должно завершиться

 

Соединение «ИЛИ»

Разворачивающее

Одно (или более) конечное действие инициируется

Сворачивающее

Одно (или более) исходное действие должно завершиться

 

Соединение «Исключающее ИЛИ»

Разворачивающее

Одно и только одно конечное действие инициируется

Сворачивающее

Одно и только одно исходное действие должно завершиться

Однако есть случаи, когда время начала или окончания параллельно выполняемых действий должно быть одинаковым, т.е. действия должны выполняться синхронно. Для моделирования такого поведения системы используются синхронные соединения. В модели IDEF3 определены два вида синхронных соединений (табл. 2).

Таблица 2

Синхронные соединения модели IDEF3

Графическое обозначение

Название

Вид

Правила инициации

 

Соединение «И»

Разворачивающее

Все действия начнутся одновременно

Сворачивающее

Все действия закончатся одновременно

 

Соединение «ИЛИ»

Разворачивающее

Может быть, несколько действий начнутся одновременно

Сворачивающее

Может быть, несколько действий закончатся одновременно

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

Методология DFD или диаграмм потоков данных это методология описания системы, позволяющая отражать такие характеристики, как движение объектов (потоки данных), хранение объектов (хранилища данных), источники и потребители объектов (внешние сущности). [6]

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

Стрелки в DFD показывают, как данные перемещаются от одного действия к другому.

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

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

Внешние сущности обеспечивают необходимые входы для системы и/или являются приемниками для ее выходов. Одна внешняя сущность может одновременно предоставлять входы (функционируя как поставщик) и принимать выходы (функционируя как получатель).

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

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

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

Диаграммы UML

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

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

В UML выделяют следующие типы диаграмм:

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

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

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

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

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

  1.  

    1. Теоретические сведенья о пользовательском интерфейсе

Интерфейс – в широком смысле слова, это способ (стандарт) взаимодействия между объектами. Интерфейс в техническом смысле слова задаёт параметры, процедуры и характеристики взаимодействия объектов.

Интерфейс пользователя – набор методов взаимодействия компьютерной программы и пользователя этой программы.

Программный интерфейс – набор методов для взаимодействия между программами.

Физический интерфейс – способ взаимодействия физических устройств. Чаще всего речь идёт о компьютерных портах.

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

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

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

  1.  

    1. Общие сведения о проектировании баз данных

База данных – набор сведений, хранящихся некоторым упорядоченным способом. Можно сравнить базу данных со шкафом, в котором хранятся документы. Иными словами, база данных – это хранилище данных. Сами по себе базы данных не представляли бы интереса, если бы не было систем управления базами данных (СУБД). [1]

Система управления базами данных - это совокупность языковых и программных средств, которая осуществляет доступ к данным, позволяет их создавать, менять и удалять, обеспечивает безопасность данных и т.д. В общем СУБД – это система, позволяющая создавать базы данных и манипулировать сведениями из них.

В теории реляционных баз данных синоним таблицы – отношение в котором строка называется кортежем, а столбец называется атрибутом.

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

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

Связь – функциональная зависимость между объектами. В реляционных базах данных между таблицами устанавливаются связи по ключам, один из которых в главной (parent, родительской) таблице - первичный, второй - внешний ключ - во внешней (child, дочерней) таблице, как правило, первичным не является и образует связь "один ко многим" (1:N). В случае первичного внешнего ключа связь между таблицами имеет тип "один к одному" (1:1). Информация о связях сохраняется в базе данных.

  1.  
    1.  

      1. Логическая модель

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Логическая модель данных является начальным прототипом будущей базы данных. Она строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).

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

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

  1.  
    1.  

      1. Физическая модель

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

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

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


    1. Предпроектное обследование предметной области

    2. Проектирование информационной системы

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

Биржа является посредником между клиентами, совершающими покупку и продажу, соответственно данная информационная система должна осуществлять функции посредника, принимать и отправлять сделки.

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

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

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

  1.  
    1.  

      1. Построение моделей IDEF0

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

Рисунок 2.1 – Моделирование контекстной диаграммы

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

Рисунок 2.2 – Построение декомпозиции контекстной диаграммы

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

Рисунок 2.3 – Моделирование декомпозиции «Исполнение заявок»

Далее изображена декомпозиция блока «Исполнение заявок» на рисунке 2.3 на котором можно наблюдать последовательность выполнения процесса исполнение заявки.

Рисунок 2.4 – Результат построения декомпозиции «Тестирование инвестиционных стратегий»

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

Рисунок 2.5 – Результат построения декомпозиции «Формирование отчётов»

В ходе работы была смоделирована диаграмма IDEF0 "Информационная система поддержки биржевых торгов". На изображениях видно как по этапно проходит процес декомпозиций. Для дальнейшей детализации функциональных блоков будем использовать диаграммы IDEF3, которые будут разработаны в пункте (2.1.2.).

  1.  
    1.  

      1. Построение моделей IDEF3

Декомпозиция отдельных процессов при помощи нотации IDEF3. Таких процессов как «Обработка котировок» и «Тестирование инвестиционных стратегий» которые представленны на рисунках 2.6 и 2.7.

Рисунок 2.6 – Декомпозиция процесса «Принятие и исполнение заявок»

На данном рисунке 2.6 построена декомпозиции блока «Принятие и исполнение заявок» при помощи нотации IDEF3.

Рисунок 2.7 – Результат построения декомпозиции IDEF3 «Тестирование инвестиционных стратегий»

В ходе работы была смоделирована диаграмма IDEF3 "Информационная система поддержки биржевых торгов". Выполнена детализация отдельных процессов на диаграммах IDEF0, полученных при выполнении предыдущего пункта (2.1.1.) с помощью диаграмм IDEF3.

  1.  
    1.  

      1. Построение моделей DFD

На рисунках 2.8 и 2.9 были составлены отдельные модели при помощи методологии DFD.

Рисунок 2.8 – Построение контекстной диаграммы DFD

На рисунке 2.8 изображена контекстная диаграмма "Информационная система поддержки биржевых торгов" при помощи нотаций DFD.

Рисунок 2.9 – Построение декомпозиции контекстной диаграммы при помощи DFD

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

  1.  
    1.  

      1. Построение моделей UML

В данном разделе представлено моделирование при помощи UML моделей.

Рисунок 2.10 – Созданная диаграммы последовательностей

На данной картинке показано как взаимодействуют процессы с объектами.

Рисунок 2.11 – Спроектированная блок-схема процессов

На рисунке 2.11 показанна блок-схема процессов. На данной моделе изображенна работа системы с запросами и возврат результатов запросов пользователям.

Рисунок 2.12 – Создание диаграммы последовательностей процессов

На рисунке 2.12 показанно как работает система и взаимодействие её с обьектами.

Рисунок 2.13 – Созданная диаграма классов

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

  1.  

      1. Построение логической модели в нотации IDEF1X

      2. Разработка базы данных

Программный продукт ERwin позволяет создавать модель данных в виде ERD-диаграмм. Такая модель может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки ИС. В ERwin существуют уровень представления логический. Реализация логической модели изображена на рисунке 2.14.

Рисунок 2.14 - Построение логической модели в нотации IDEF1X

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

  1.  
    1.  

      1. Физическое проектирование базы данных

Физический уровень модели ERwin составляют целевая СУБД, имена объектов, типы данных и индексы.

Рисунок 2.15 – Результат построения физической модели в нотации IDEF1X

Так же, как и в пункте (2.2.1.) было выполнено информационное моделирование бизнес-процессов. Только моделирование база данных осуществлялось на физический уровень. Созданы 7 таблиц только уже на английском языке и построены связи между таблицами. Так же определены первичные и вторичные ключи, и установлены типы данных. Использовались такие типы данных как (INTEGER, VARCHAR, DATE).

  1.  

    1. Проектирование пользовательского интерфейса

В данном разделе была проведена работа по проектированию пользовательского интерфейса. Проектирование информационной системы осуществлялось в программной среде Microsoft Visual Studio.

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

Рисунок 2.16 – Изображение окна авторизации

На изображении 2.17 представлено основное меню “Торговля”, оно предназначено для совершения торговых операций. Слева расположено поле для выбора финансового инструмента, слева верху необходимо указать цену и объем для совершения сделки. В центре поле для отображения графика котировок и индикаторов. Остальные три кнопки “Просмотр активов”, “История торгов”, “Тестирование стратегий” предназначены для перехода в одноименные меню. Данные страницы будут рассмотрены позже.

Рисунок 2.17 – Окно “Торговли”

На рисунке 2.18 странице отображены все активы, имеющиеся у пользователя. Весь список активов можно экспортировать при нажатии на кнопку "Экспорт”.

Рисунок 2.18 – Просмотр активов пользователя

На рисунке 2.19 изображена страница “История торгов” данная страница предназначена для отображения осуществленных торгов пользователя, в верхней таблице происходит отображения исполненных и покрытых заявок. В нижнем графике показано изменение баланса пользователя.

Рисунок 2.19 – Страница “История торгов”

Страница “Тестирование стратегий” изображена на рисунке 2.20. Кнопка “Настройки” описана ниже. После запуска тестирования, на графике сделок отображаются сделки. Внизу страницы имеется три основных вкладки: “График доходности”, “История торгов”, “Отчёт”, на графике доходности показан баланс стратегии за все время.

Рисунок 2.20 – Страница “Тестирование стратегий”

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

Рисунок 2.21 – Настройки тестера стратегий

Заключение

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

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

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

Главные вопросы, которые были рассмотрены в данной курсовой работе:

  1. Проанализирована предметная область, изучены основные понятии;

  2. Были изучены основные методологии;

  3. Изучена информация для построения пользовательского интерфейса;

  4. Была изучена информация для проектирования баз данных;

  5. Изучена информация о создании логической и физической модели баз данных;

  6. Были построены модели IDEF0, IDEF3, DFD, UML;

  7. Были определенны основные сущности для проектирования и разработки базы данных;

  8. Построены логическая и физическая модель для базы данных при помощи методологии UML;

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

Список использованных источников

  1. Кузин А.В., Левонисова С.В. Базы данных [Текст], Издательство Академия, 2012г.

  2. Зыков С. Основы проектирования информационных систем [Текст], Издательство дом Высшей школы экономики. 2012г.

  3. Купер А. Интерфейс. Основы проектирования и взаимодействия (четвертое издание) [Текст], 2017г.

  4. Фаулер М. Шаблоны корпоративных приложений [Текс], Издательство Вильямс 2016г. – 544с.

  5. Коваленко В.В. Проектирование информационных систем [Текс], Издательство Форум 2014г.

  6. Учебно-практическое пособие по "Проектировании информационных систем".

  7. Исаева Г. Проектирование информационных систем [Текс]. Издательство Омега-Л 2012г. – 432с.

  8. Зиборов В.В.MS Visual C++ 2010 в среде .NET Год издания:2012 Страниц:320

  9. Алексеев А.А.Основы параллельного программирования с использованием Visual Studio 2010. 2-е изд. 2016г.332с.

  10. Бодров, О.А. Предметно-ориентированные экономические информационные системы: Учебник для вузов / О.А. Бодров. - М.: Гор. линия-Телеком, 2013г. - 244 c

  11. Бодров, О.А Предметно-ориентированные экономические информационные системы / О.А Бодров. - М.: ГЛТ, 2013г. - 244 c.

  12. Уткин, В.Б. Информационные системы в экономике: Учебник для студентов высших учебных заведений / В.Б. Уткин, К.В. Балдин. - М.: ИЦ Академия, 2012г. - 288 c.

  13. Информационные системы и технологии: Научное издание. / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2016г. - 303 c.

  14. Учебное пособие по "Теории систем и системный анализ" и Глоссарий.

  15. Мезенцев, К.Н. Автоматизированные информационные системы: Учебник для студентов учреждений среднего профессионального образования / К.Н. Мезенцев. - М.: ИЦ Академия, 2013. - 176 c.

  16. Джон К. Халл. Опционы, фьючерсы и другие производные финансовые инструменты. Издательство Вильямс 1072с. 2013г.

  17. Саймон Вайн. Опционы. Полный курс для профессионалов. Издательство Альпина Паблишер 2017г. 438с.

  18. Сергей Силантьев. Логика опционной торговли. Учебное пособие. Издательство И-Трейд. 2015г. 336с.

  19. Фрэнк Дж. Фабоцци, Ричард С. Уилсон. Корпоративные облигации. Структура и анализ. Издательство Альпина Паблишер. 2016г. 444с.

  20. Джон Дж. Мэрфи. Технический анализ фьючерсных рынков. Теория и практика. Издательство Альпина Паблишер. 2017г. 610с.

  21. Джон Дж. Мэрфи. Технический анализ финансовых рынков. Полный справочник по методам и практике трейдинга. Издательство Вильямс. 2016г. 496с.

  22. Джеф Раскин. Интерфейс: новые направления в проектировании компьютерных систем. Издательство Символ-Плюс. 2015г. 272с.

  23. Уитни Кесенбери, Кевин Брукс. Сторителлинг в проектировании интерфейсов. Как создавать истории, улучшающие дизайн. Издательство Манн, Иванов и Фербер. 2013г.

  24. Словарь трейдера. Основные понятия [Электронный ресурс] / Режим доступа: http://success-everywhere.ru/finansi/birzha-i-rinok/slovar_trejdera, свободный. — Загл. с экрана. — Яз. рус., англ и другие.

  25. Свободная энциклопедия [Электронный ресурс] / Режим доступа: https://ru.wikipedia.org/, свободный. — Загл. с экрана. — Яз. рус., англ и другие.

ПРИЛОЖЕНИЕ

ТЗ на разработку приложений и компонент информационной системы поддержки биржевых торгов

1.Введение

Под информационной системой поддержки биржевых торгов подразумевается решение следующих задач: отображение котировок акций, фьючерсов, индексов и др., возможности отправки приказов на покупку или продажу, отображение значений индикаторов. Таким образом, при реализации информационной системы необходимо решить ряд задач, возникающих в получениях доступа к котировкам различных бирж (ММВБ, NYSE, NASDAQ), рекомендуется использовать одну из данных бирж. Данная система поможет в тестировании различных инвестиционных проектах.

2.Основание для разработки

Основанием для разработки является задание в рамках курса «Проектирование информационных систем».

3.Назначение разработки

ИС поддержки биржевых торгов предназначена для решения следующих задач:

  • Хранения информации о котировках;

  • Реализация технических индикаторов;

  • Возможность отправлять различные приказы;

  • Разработка отчётов по проведенным приказам в течении указанного периода;

  • Реализация пользовательского интерфейса.

4.Требования к программному изделию

4.1. Требования к функциональным характеристикам

Система должна обеспечивать следующие функции:

  1. Экспорт, импорт, хранение данных о котировках, вид которых должен соответствовать виду:

  • Цена открытия;

  • Цена максимума дня;

  • Цена минимума дня;

  • Цена закрытия;

  • Объем торгов.

  1. Пользовательский интерфейс, который должен в себе содержать основные функции такие как:

  • Отображение исторических котировок;

  • Кнопки для отправки приказов на исполнение;

  • Меню с списком индикаторов;

  • Поле для ввода краткого наименования актива;

  • Набор кнопок для получения отчётов;

  • Набор кнопок для импорта и экспорта котировок.

  1. Раздел для возможности тестирования инвестиционных проектов в котором должны быть реализованы возможности:

  • Указания периода тестирования;

  • Выбора актива, на котором будет осуществляется тестирование;

  • Выводиться график результатов.

  1. Раздел для выбора набора индикаторов, которые в свою очередь должны делиться на:

  • Трендовые;

  • Осцилляторы;

  • Другие.

4.2. Требования к надежности

Система должна:

  • проводить контроль вводимой информации;

  • блокировать некорректные действия пользователя при работе с системой;

  • обеспечивать целостность данных.

4.3. Условия эксплуатации

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

4.4. Требования к составу и параметрам технических средств

Настоящая система должна работать на компьютерах IBM PC. Оперативная память на каждом компьютере, не менее 512 Мб. Свободное место на жестком диске не менее 20Гб.

4.5. Требования к информационной и программной совместимости

Система должна работать под управлением ОС семейства Win32. Другое ПО выбирается по решению разработчика. Основным критерием является низкая стоимость.

4.6. Требования к маркировке и упаковке

Готовое программное изделие и документация поставляется на компакт-дисках в стандартной упаковке. Один комплект программной документации должен быть распечатан с помощью лазерного принтера на листах формата А4 и иметь типографский переплет.

4.7. Требования к транспортированию и хранению

Требования к транспортированию и хранению программного изделия совпадают с аналогичными требованиями, предъявляемыми к компакт-дискам.

5.Требования к программной документации

Программная документация должна содержать следующие документы (см. ГОСТ 19.101-77):

1.Программные документы:

  • Спецификация (ГОСТ 19.202-78);

  • Текст программы (ГОСТ 19.401-78);

  • Описание программы (ГОСТ 19.402-78);

  • Пояснительная записка (ГОСТ 19.404-79);

2.Эксплуатационные документы:

  • Ведомость эксплуатационных документов (ГОСТ 19.507-79);

  • Формуляр (ГОСТ 19.501-78);

  • Описание применения (ГОСТ 19.502-78);

  • Руководство системного программиста (ГОСТ 19.503-79);

  • Руководство программиста (ГОСТ 19.504-79);

  • Руководство оператора (ГОСТ 19.505-79);

Требования к перечисленным документам не отличаются от требований, определенных в ЕСПД.

Просмотров работы: 503