За търговия на forex

Архитектура на Сървър

Декомпозиция на подмодули

1. 
   Backend Integration Layer (Бекенд интеграционен слой) – Този модул осигурява връзката и интегрирането на съществуващата бекенд система със системата. Модулът има функцията на фасада пред бекенд ситемата.
   

• 
  Change Notification (Известяване за промяна) – този модул сигнализира системата за значителни промени в данните от бекенд системата
  
  • 
    Polling (Поискване) – реализация на мехнизма на известяване чрез поискване на промените от бекенд системи, които не поддържат механизъм за незабавно известяване
    
  • 
    Push (Предоставяне) – реализация на механизма за незабавно известяване за промени от бекенд ситемата
    
• 
  Trade Integration (Търговска интеграция) – осигурява програмен интерфейс за търговските операции предоставени от бекенд системата
  
• 
  Data Integration (Интеграция по данни) – осигурява програмен интерфейс за достъп до данни за конкретна сметка и друга помощна информация
  
• 
  Backend Communication (Комуникация с бекенд системата) – това е вътрешен модул, който се грижи за комуникацията между основния модул и действителната бекенд система
  

2. 
   Process monitor (Монитор на процеси) – следи за техническите показатели на системата и осигурява инструменти за административна поддръжка
   
   • 
     Heartbeat Listener (Импулсен наблюдател) - следи за състоянието на системата чрез постоянни импулси получавани от наблюдаваните подмодули
     
   • 
     Events Journal (Дневник на събитията) – записва промените в техническите показатели на системата и ги съхранява в дневника на събитията. Имплементиран е чрез инструментите за админстративна поддръжка.
     
3. 
   Client Communication Layer (Клиентски комуникационен слой) – управлява комуникацията между сървъра и клиента. Комуникацията се осъществява чрез обмен на съобщения между клиента и сървъра. Този модул се грижи за предаването на съобщенията, включително преобразуване до елементарен формат, и предоставянето им на Network I/O (Мрежовия входно-изходен) модул, който е отговорен за действителното предаване
   

• 
  Network I/O (Мрежов В/И) – подмодул, който имплементира мрежовия протокол и простите комуникации. Главният модул се изгражда върху този модул.
  
• 
  Authentication serviceс (Удостоверителни услуги) – предоставя криптографски услуги на Мрежовия В/И за криптиране на трафика; осигурява сертификационни услуги за главния комуникационен модул. Информация за Сертификационни услуги се предоставя от трети страни - доставчи на удостоверителни услуги.
  

4. 
   Data Layer (Слой за данни) – този модул предоставя уеднаквен достъп до данните на Обработчика на Съобщенията в средния слой (Middleware)
   
5. 
   DBMS (СУБД) – представя сървърът на базата данни, съхраняващ информацията необходима за функционирането на системата
   
6. 
   Middleware (Среден слой) – този модул имплементира бизнес логиката и процесите
   

• 
  Client Notification (Известяване от клиента) – този модул препредава изходящите съобщения от Message Processor (Обработчика на Съобщения) обратно към клиентското приложение
  
• 
  Message Aggregator – този модул поддържа опашката от заявки към Message Processor (Обработчика на Съобщения) като агрегира съобщения от разнородни източници.
  
• 
  Message Processor (Обработчика на Съобщения) – това е основният изпълнителен модул ръководещ и обработващ входящите съобщения от клиента и известията за промяна от бекенд системата.
  

7. 
   Auxiliary services – помощни модули
   

• 
  News Feeds – модулът изпраща информация за новини и съобщения от брокера до клиента.
  
• 
  Administration tools - инструменти за административна поддръжка
  

8. 
   Context Node – този компонент предоставя среда за изпълнение на активните компоненти. Предоставя услуги за откриване, синхронизиране, комуникация, балансиране между активните компоненти.
   

Server Use & Layer Structure

Server use and layer структурата описва кой модул кого използва (на кой друг модул разчита). Една от идеите в диаграмата е, че даден модул не знае за съществуването на използващите го модули, т.е. може да работи независимо от тях.

Client Communication Layer не зависи от никой от останалите модули и не знае за тяхното съществуване.

Client Notification модулът е директно зависим от модула за комуникация с клиента.

Message Aggregator модулът е зависим от модула за комуникация с клиента, както и е абониран към Change Notification модула.

Message Processor модулът е зависим от модулите Client Notification – за обратна връзка, Message Aggregator – за входни данни, и Data Layer – за данни.

Data Layer модулът е зависим единствено от DBMS (Системата за управление на база от данни (СУБД)) модула.

Backend Integration Layer е назависим от останалите модули и играе ролята на фасада за достъп до Backend системата.

Server Communicating Processes structure

Active: - елементът е активна инстанция на съответният компонент (компонентът, който работи и информира еднаквите на него пасивни инстанции с нужната информация)

Passive: - елементът е пасивна инстанция на съответният компонент (компонентът, който бива информиран от активната инстанция)

Service - активни компоненти-услуги

Context Node - указва съвкупността от услуги, работещи в един и същи контекст (на една машина)

Database - указва системата за управление на база от данни, която приложението използва

Диаграмата описва потока на съобщения и данни между компонентите. По-долу заедно с интерфейсите са описани и конкретните данни и съобщения.

При дизайна на приложението е възможно доразбиване на нивото от услуги осигуряващи обработването на съобщенията (Message Processor) на съставящи подкомпоненти, обособени по функционалност (например осигуряващи услуги като отваряне/затваряне на позиция).

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

Interface Specification

Формат на съобщенията: точна спецификация по време на дизайн

Име на компонент:	Client Communication Layer
Входящи типове съобщения:
Client Message – заявка от потребителя
Communication Resynchronization Message – съобщение за ресинхронизация на текущият модул
Server Message – съобщение от сървъра за терминала

Име на компонент:	Message Aggregator
Входящи типове съобщения:
Job Request Message – заявка за извършване на работа
Update Trade Info Message – съобщение за обновяване на търговска информация
Aggregator Resynchronization Message – съобщение за ресинхронизация на текущия модул

Име на компонент:	Message Processor
Входящи типове съобщения:
Job Request Message – заявка за извършване на работа

Име на компонент:	Backend Integration Layer
Входящи типове съобщения:
Account Info Request Message – заявка за информация за сметка
Trade Operation Request Message – заявка за търговска операция

Име на компонент:	Client Notification
Входящи типове съобщения:
Client Notification Message – съобщение за промяна в информацията към терминала

Име на компонент:	DBMS
Стандартен интерфейс към SQL база данни.

Архитектура на Клиентски терминал

Client Decomposition Structure

1. 
   UI Module (GUI) – модул за основния графичен потребителски интерфейс. Основна входна точка за изпълнение.
   
2. 
   Configuration – модул управляващ конфигурационните параметри на терминала.
   
3. 
   Communication Gateway – модул реализиращ комуникацията със сървъра
   
4. 
   Account Manager (AM) – модул управляващ информацията за потребителските сметки.
   

• 
  Export account information module – модул за трансформиране и експортиране на информация за сметка в различни формати.
  

5. 
   Chart Module (CM) – модул за създаване на графики
   

• 
  Viewer – модул за визуализиране на графики
  
• 
  Indicator Module – модул отговарящ за индикаторите на графика, както и за стандартните индикатори
  
• 
  Graphical Module – модул за графични елементи върху графиката
  

6. 
   Market Watch (MW) – модул управляващ котировките на двойките валути, включително текущите
   

• 
  Historical currency rates module – модул обслужващ историческите данни за котировките.
  

7. 
   Login authentication module – модул извършващ автентификация на потребителя
   
8. 
   Trade management module (TM) – модул управляващ търговията и позициите на потребителя
   
9. 
   Expert analyzer management module (EA) – модул управляващ експертните анализатори
   
10. 
    Notification Module – модул за нотификация на потребителя
    

• 
  News management module – модул за новини от брокера
  

11. 
    Scripting module (SCR) – модул за създаване на скриптове
    

• 
  Interpreter module – интерпретатор на скриптовете
  
• 
  Script editor module – редактор и debugger на скриптове
  

Client Use & Layer Structure

GUI е основата на приложението. В него са интегрирани останалите модули. Потребителските индикатори се реализират като скриптове. Експертните анализатори също. Графиките и ЕА работят върху данни за котировките (текущи и исторически). ЕА имат възможност да управляват търговията. Графиките показват важни нива на котировки, базирани на позициите на потребителя.

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

Обосновка на използваните тактики

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

Системата идентифицира потребителите, чрез усъвършенстван електронен подпис издаден от брокера. По този начин се предпазва от промяна и „подслушване” от трети лица на потока от данни между клиента и сървъра. Входната точка за клиентският терминал е единствената точка отворена към Интернет. Съобщенията, които се получават при нея са ограничени до конкретен набор от типове и формат, което ограничава възможните заявки от страна на потребителя до тези разрешени за него.

Обработката на заявки към сървъра става конкурентно, като позволява скалируемост на ниво Message Processor и на ниво Context Node. Скалируемостта позволява и увеличаване на производителността, чрез увеличаване на ресурсите. Входящата опашка със съобщения е ограничена до определен размер. Входящите заявки при пълна опашка се отхвърлят. Това предпазва сървъра от задръстване.

За отчитане на състоянието на системата се използва тактиката Heartbeat. Има Log на събитията, където компонентите регистрират изключенията настъпили при тях. Поддържа се failover node, където работят резервни пасивни инстанции на Client Communication Layer и Message Aggregator. Пасивните инстанции се поддържат частично синхронни с активните инстанции, чрез поддържане на състояние на съобщение. Състоянията на съобщение са получено, изпратено, потвърдено. При срив на активните инстанции, пасивните преминават в активни и се ресинхронизират с останалите модули – с цел синхронизиране на неконсистентност на състоянието на съобщения преди срива.

Терминологичен речник

• 
  услуга – сравнително автономен компонент, имащ единствената задача да достави определена услуга
  
• 
  активен компонент – компонент, който не споделя директно контекста на изпълнението си с останалите активни компоненти. В някакъв смисъл, компонента се явява входна точка за една логическа процесорна нишка.
  
• 
  фасада – софтуерен шаблон за проектиране
  
• 
  агрегиране – събиране, обединяване
  

Каталог: file -> view
view -> Търсене и предлагане – основа на пазарния механизъм
view -> Тема: Дж. Р. Р. Толкин
view -> Достоверността на един летопис и на един роман
view -> Бизнес план за развитие на интернет клуб „The Net”
view -> Как да улесним учениците с обучителни трудности (дислексия) в процеса на учене на английски език
view -> Тематичен обхват на проектните идеи: България-Румъния
view -> Project overview for
view -> Безжична революция
view -> Курсова работа

Изтегляне 88.28 Kb.

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