Курсова работа по Софтуерни архитектури и разработка на софтуер



Дата17.11.2017
Размер126.64 Kb.
Размер126.64 Kb.



Курсова работа

по

Софтуерни архитектури и разработка на софтуер


Система за електронна търговия с валута

Изготвили:

Мартина Николаева Колева,

спец. Софтуерно инженерство, III курс, Ф№ 61042

Соня Дамянова Сидерова,

Спец. Софтуерно инженерство, III курс, Ф№ 61004

София, 2009

Съдържание:



  1. Описание на проекта;

    1. Цел на проекта;

    2. Функционални изисквания;

    3. Нефункционални изисквания;

  2. Сървърна част

    1. Описание на логиката на процесите в сървъра

      1. диаграма, описание

    2. Архитектурна структура - декомпозиция на модули на сървъра

      1. диаграма, описание

    3. Архитектурна структура - процеси в сървъра

      1. диаграма, описание

  3. Клиентска част

    1. Изисквания към клиентския терминален софтуер:

    2. Описание на логиката в клиентската част

      1. диаграма

    3. Архитектурна структура - декомпозиция на модули

      1. диаграма, описание

    4. Ахритектурна структура - употреба

      1. диаграма, описание


1.Описание на проекта

А. Цел на проекта:

Целта на проекта е да се изработи архитектура на софтуерна система за електронна търговия с валута. Софтуерната система е предназначена за крайни клиенти и извършване на сделки с валута на международния валутен пазар.



B. Функционални изисквания:
Функционалности, предоставени на крайните клиенти:

Крайният потребител сключва договор с брокер (предоставя софтуер – терминал за извършване на сделки). Чрез софтуера КП отправя поръчки за купуване/продаване на валута. Брокера осигурява котировки на валутите в реално време (трябва да има възможност за справка). Брокера изпълнява съответните поръчки, чрез които го представя на пазара.


Функционалности, предоставени на системата:

Печалбите и загубите се формират от разликите в курса на съответната валута между момента на купуването и продаването. Двата компонента си комуникират за извършване на сделки, следене на състоянието на валутните курсове, следене на потребителските сметки. Пазарът работи 24 часа на ден в делничните дни; Отворените в 00:00 позиции автоматично се затварят, начислява се лихва (положителна или отрицателна) и позициите се отварят наново по курс към 00:00 на новия ден, който може да е различен от курса „затваря” на предишния ден;


Внедряване:

Част от софтуера се инсталира при крайния потребител, а друга част – при брокера.


C. Нефункционални изисквания
Изисквания към софтуера:

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


Изисквания към сървърния софтуер:

Сървърният софтуер се инсталира на сървърна машина на брокера и обслужва заявките от клиенската част. За целта е свързан с бек-офис системата на брокера (повече или по-малко стандартизирана система, която всеки брокер има и в която се пази информация за потребителските сметки и чрез която се извършва самата търговия). Основните изисквания на сървърният софтуер са следните:



  • Интеграция с колкото се може повече стандартни бек-офис системи (тъй като не знаем брокерите, на които ще продаваме софтуера каква бек-офис система имат).

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

  • Висока надеждност през работни дни – 24 часа на ден през работните дни системата трябва да е функционираща. Най-малката авария може да доведе до големи загуби на крайните клиенти;

  • Бързодействие – бързо-ликвидният FOREX пазар предполага всички действия по търговията да се извършват в рамките на секунди. Затова сървърният софтуер трябва да реагира на заявките възможно най-бързо. Обработката на всяка една заявка не трябва да отнема повече от 1 сек.


2. Сървърна част
A. Описание на логиката на процесите в сървъра

Функционалността на сърверния софтуер е следната:



  • да позволява достъп на легитимни клиенти и да отказва такъв на нелегитимни;

  • да обработва валидни заявки, постъпили от клиентския терминал;

  • да пренебрегва, регистрира и предупреждава за невалидни заявки;

  • да преобразува заявките във вид, удобен за бек-офис системата и да ги праща там за изпълнение;

  • да очаква отговори от бек-офис системата, да ги преобразува до удобен за клиентския терминал вид и да ги праща натам;

  • да има механизъм за конфигурация на основните параметри;



Фиг.1. Логика на процесите в сървърната част

B. Архитектурна структура - декомпозиция на модули на сървъра


Фиг.2. Декомпозиция на Сървър

Системата е разделена на три основни функционални модула. Това са:



  • Identification

В този модул се осъществява идентификацията на потребителите при вход в системата. Проверява се легитимността на потребителя.

Има един подмодул:



    • Check

Прави се проверка, която да даде достъп на легитимни клиенти и да отказва такъв на нелегитимни.

  • Configration – този модул предоставя възможност за работа e-mail:

    • Mail – системата дава възможност за комуникация с брокера – поща

      • Receive – получаване на информация;

      • Send – изпращане на съобщение;

      • Mark – маркиратне на съобщение;

      • Move - преместване на съобщение;

      • Delete – изтриване на съобщение;

    • ModifyParameters – конфигуруране на основните параметри;

  • Processing – в този модул се обработват заявките на клиента:

    • Check – след получаване на заявката се прави проверка за валидност на заявката, този модул определя дали тя е коректна или некоректна;

    • Process – използва резултата от Check модула за обработка на заявката. Ако тя е невалидна се пренебрегва, регистрира се като невалидна и се изпраща предупреждение към клиента за невалидна заявка. В противен случай се преобразува във вид, удобен за backoffice-а, изпраща се към него, системата очаква отговор и при получаване на такъв преобразува заявката до вид, удобен за клиента като му я изпраща;

C. Архитектурна структура - процеси в сървъра


Фиг 3. Sequence diagram – Server

Описание на архитектурната структура – Process на Server-a
Identificationтук се проверява за легитмността на потребителя, след което се пренасочва към

DefaultPage – това е мястото където се разклоняват различните функционалности; прави се избор накъде са се продължи – към модула поща или да се изчаква получаване на заявка

Mail – възможностите тук са няколко, но за да има по-голяма яснота в диаграмата са пропуснати. Действията, които могат да се извършват тук са независимо едно от друго – получаване, изпращане, маркиране, изтриване, преместване.

ExpectQuery – изчакваме заявка

CheckQueryправи се проверка за коректността на заявката с синтактичен и семантичен смисъл

IgnoreWarnRegisterв случай че заявката не е коректна, тя се пренебрегва, регистрира се и се изпраща предупреждаващо съобщение към клиента, за това има връзка с пощенския модул

CommunicationBO – в случай че заявката е коректна, се преминава към комуникация с Back office системата, за да може заявката да бъде изпънена. Отново за да не натоварваме диаграмата, подробностите са пропуснати. Тук се осъществява връзката с Back office системата, първо заявката се преобразува във вид удобен за БО системата, след това се изпраща за изпълнение, после се очаква отговор, който отново пребразуваме, този път във вид удобрен за клиента. Накрая изпращаме отговор към клиента, затова има връзка към пощенския модул.


3. Клиентска част

A. Изисквания към клиентския терминален софтуер:

Клиентския терминал се инсталира на компютъра на крайния клиент и чрез него той извършва сделки. За целта е свързан със сърверната част на софтуера, който е инсталиран на сървър на брокера.



Функционалността на клиентския софтуер е следната:

  • При стартиране да изисква легитимация от клиента. Едва след потвърждаване от страна на сървъра, че клиента е легитимен, терминала дава достъп на клиента до данните и функционалността си;

  • Да има възможност за показване на:

    • Настоящите валутни курсове за определени валутни двойки. Конкретните двойки, за които се показват курсовете се определят от конфигурационен параметър;

    • Сметките на клиента, отворени при брокера. За всяка сметка се поддържа баланс, свободен ресурс, използван депозит, дневна печалба/загуба;

    • Отворени позиции. За всяка позиция се поддържа: време на отваряне, сметка от която е направена, валутна двойка, сума на сделката, купува/продава, на каква цена е отворена, каква е настоящата цена, какви са установените stop loss и take profit нива, каква е печалбата към момента;

    • Затворени позиции. За всяка позиция се поддържа: време на отваряне, време на затваряне, сметка от която е направена, валутна двойка, сума на сделката, купува/продава, на каква цена е отворена, на каква цена е затворена, печалба;

    • Отложени поръчки. За всяка отложена поръчка се поддържа: сметка, от която е направена, валутна двойка, сума на сделката, купува, продава, stop и limit нива, време на поставяне, време на изпълнение, статус (чакаща, изпълнена);

    • Новини от брокера. Поддържа се функционалността, типична за news клиент – дървовидна организация на папките, получаване на новини в кутията, четенето на новина, изтриването на новина, маркирането на новина като важна, преместването на новина между папките;

    • Графики – трябва да се поддържат графики на движението на курсовете:

      • Възможност за указване на валутната двойка;

      • Възможност за определяне на времевия интервал на графиката;

      • Възможност за определяне на типа на графиката;

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

      • Показване на дати/часове по хоризонтала и валутен курс по вертикала;

      • Автоматично скалиране на графиката съобразно мин. И макс. Валутен курс за показания интервал;

      • Възможност за поставяне на маркери, хоризонтални, вертикални и наклонени линии;

      • Възможност за показване на обема на търговията;

    • Индикатори за технически анализ – системата трябва да поддържа дефиницията и показването на индикатори за технически анализ:

      • Индикаторите да могат да се дефинират чрез въвеждане на формули за тяхното пресмятане и набор от други параметри;

      • Системата трябва да поддържа набор от готови стандартни математически/статистически функции, които да се използват за дефиницията на индикаторите;

      • Да могат да се показват върху графиката и под нея, в зависимост от вида на индикатора;

      • Параметрите на индикаторите да могат да бъдат въвеждани преди показването им;

      • Да могат да се създават индикатори както върху основната графика, така и върху графиката за обема на търговията;

    • Да има възможност за избор и изтриване на всички прибавени артефакти (линии, маркери, индикатори и т.н.)

  • Да може да се поставя пазарна поръчка за купуване, съответно продаване на валута, като се указва валутната двойка, курсът и броя лотове (които в зависимост от сметката са 10000 или 100000 единици);

  • Да могат да се поставят отложени поръчки от типа stop и limit за покупка и продажба на валута;

  • Да могат да се затварят позиции;

  • Да могат да се поставят stop loss и take profit нива за отворените позиции;

  • Да могат да се правят предефинирани справки за състоянието на сметката, в HTML, PDF и XLS формати

  • Да е възможно дефинирането и изпълнението на експертни анализатори – процеси, които следят състоянието на пазара и при настъпване на подходящи условия изпълняват определена активност. Тя може да бъде:

    • Автоматично отваряне и затваряне на позиции;

    • Сигнализация (изпращане на e-mail);

  • Експертните анализатори могат да приемат параметри и трябва да могат да се описват чрез формули и чрез използването на вградените в системата математически, статистически и др. функции;

  • Системата трябва да може да поддържа пускане, спиране и постъпково изпълнение (за дебъг цели) на експертните анализатори, както и конфигурирането и изтриването им;

  • Системата трябва да може да позволява правенето на анализи и при липса на свързаност. За целта е необходимо да се пази временно копие на всички свалени от сървера данни, което да се използва при ситуация на липса на свързаност;


B. Описание на логиката на процесите в клиентската част



Фиг.4. Логика на процесите
C. Архитектурна структура - декомпозиция на модули




Фиг. 5. Декомпозиция на модули

Описание на декомпозицията на модули
Системата е разделена на четири основни функционални модула. Това са:

  • Identification

В този модул се осъществява идентификацията на потребителите при вход в системата. Проверява се легитимността на потребителя.

Има един подмодул:



    • Check

Прави се проверка, която да даде достъп на на легитимни клиенти и да отказва такъв на нелегитимни.

  • Deal

Модулът Deal се отнася за всичко, свързано със сделките. Състои се от следните подмодули:

    • OpenPosition - В тоз и модул се отварят позиции

      • ChoosePosType - в този подмодул се прави избор дали да се купува или продава валутата, има възможност да се постави отложена поръчка и да се определи дали тя се отнася за купуване или продаване;

      • ChooseParameters оказва се валутна двойка, курс, на който клиента е склонен да купува/продава и броя лотове в зависимост от сметката;

    • ClosePosition - Функционалността на този подмодул е свързана с поставянето на отложени поръчки за купуване и продаване на валута при отваряне и затваряне на позиции

      • TakeStopLevel – в този подмодул се поставят нивата за Stop Loss и Take Profit при затваряне на позиции;

    • ExpertAnalyser – Модулът, свързан с функцоналността на експертните аланлизатори. Разделя се на следните подмодули:

      • Executingосъществвява пускането, спирането, конфигурирането, изтриването и постъпковото изпълнение.

      • Analysingанализира данните

      • Interpretingинтерпретатор на това, което клиента подава като данни

      • Computingизчислява

  • CheckUp

Модулът CheckUp служи за справка на клиента. Чрез него се дава достъп до:

    • View – този подмодул дава подробна справка за Отворени и Затворени позиции, Отложени поръчки и Сметка на клиента. Той съдържа следните подмодули:

  • CheckOpenPosition – съдържа информация за отворени позиции – време на отваряне, цена на отваряне, купува/продава, сума на сделка, текуща сметка на сделката, валутна двойка на сметката, печалба към момента, настояща цена;

  • CheckClosePosition – съдържа информация за затворени позиции – време на отваряне/затваряне, цена на отваряне/затваряне, купува/продава, сума на сделка, текуща сметка на сделката, валутна двойка на сметката, печалба към момента;

  • CheckPostponedOrder – съдържа информация за статуса на поръчката, време на изпълнение, време на поставяне, Stop Loss и Take Profit нива, купува/продава, сума на сделка, текуща сметка на сделката, валутна двойка на сметката;

  • CheckAccount – съдържа информация за сметката на клиента – дневна печалба/загуба, свободен ресурс, използване депозит;

  • CheckCurrency – съдържа информация за настоящия валутен курс;

    • Choose – прави се избор от клиента

  • Currency – избира се валутна двойка;

    • Print – дава възможност за експортиране на данните

      • ExportPDFBalance – принтира данните по баланса в PDF формат

      • ExportXMLBalance – принтира данните по баланса в XML формат

      • ExportHTMLBalance – принтира данните по баланса в HTML формат

  • Configration – този модул предоставя възможност за работа с индикатори за технически анализ, графики, e-mail и работа в offline mode:

    • Indicator – този модул съдържа индикаторите за технически анализ

      • Define - индикаторите могат да се дефинират като се въвеждат формули, параметри, инициализират се индикаторите

      • Modify - прибавените артефакти могат да бъдат изтрити, използват се готови математически/статистически функции, показват се индикаторите в графиката;

    • Graphic – съдържа информация за графиките в системата

      • CheckParameters - извлича се информация за обем на търговията, часовете спрямо валутните курсове, min/max валутен курс за даден интервал;

      • InsertMarkers - поставят се маркери, показват се индикаторите върху графиката;

      • EditParameters - графиките могат да се редактират чрез промяна на валутната двойка, времевия интервал, типа на графиката, броя интервали;

    • Mail – системата предоставя средство за комуникация с брокера – поща

      • Receive – получаване на информация;

      • Send – изпращане на съобщение;

      • Mark – маркиратне на съобщение;

      • Move - преместване на съобщение;

      • Delete – изтриване на съобщение;

    • Offline Mode – прави се анализ при липса на свързаност и се запазва временно копие на всички свалени от сървъра данни;



C. Архитектурна структура - употреба



Фиг.6. Uses diagram
Uses диаграмата изобразява връзките между модулите в системата на клиента и системата на сервъра.

В Client System модул Identification прави проверка за валидна идентификация на потребителя – при коректна такава се дава достъп до останалите модули в системата. Подмодул Choose в CheckUp дава възможност за избиране на валутна двойка – той използва подмодул View за достъп до информация за настоящия валутен курс за определени валутни двойки. View използва подмодул Process от Processing в Сървърната система, откъдето получава информация за обработени отворени позиции, затворени позиции и отложени поръчки. Подмодула Print използва View за извличане на информацията за експорт, той получава достъп до състояните на всяка сметка. Configuration Graphic взима данни от Indicator за показване на индикаторите на и под графиката. Graphic дава възможност за избор на валутна двойка, чрез подмодул Choose в CheckUp. Mail си комуникира с Mail в сървърния софтуер за получаване и изпращане на съобщения. В Deal Отворените и Затворените позиции се извличат данни от View и Choose в модул CheckUp относно цялата необходима информация за заявките към пазара. ExpertAnalyser използва Indicator за своието описание чрез вградените в него формули и математически и статистически фунцкии. Mail, OpenPosition и ClosePosition използват ExpertAnalyser за автоматично отваряне и затваряне на позиции, както и за сигнализация чрез изпращане на съобщение.



В сървърната система модул Identification прави проверка за валидна идентификация на потребителя – при коректна такава се дава достъп до останалите модули в системата. Mail предоставя възможност за изпращане и получаване на съобщения към клиентския Mail. Модул Process взима резултата от Check за валидност на заявката и като използва подмодулите на Deal в клиентската част - OpenPosition и ClosePosition извлича заявката – при невалидна такава се свързва с Mail и се изпраща предупреждение за невалидна заявка към клиента. Process използва Check за да получи резултата от проверката – в случай, че е коректна я обработва и изпраща към клиента, където става достъпна за проверка във View в модул CheckUp.




Сподели с приятели:


©zdrasti.info 2017
отнасят до администрацията

    Начална страница