С преподаватели доц д-р Боян Бончев и ас д-р Александър Димов на



Дата14.02.2017
Размер190.76 Kb.


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

по дисциплината „Софтуерни Архитектури и Разработка на Софтуер” с преподаватели доц. д-р Боян Бончев и ас. д-р Александър Димов

на тема:
Проектиране на архитектура за софтуерна система за крайни клиенти за извършване на сделки с валута на международния валутен пазар”


Разработили:

Моника Илиева, фак. номер 61003, спец. Софтуерно Инженерство, к. 3

Николина Шопова, фак. номер ..., спец. Софтуерно Инженерство, к. 3

Трифон Статков, фак. номер: 61152, спец. Софтуерно Инженерство, к. 3

Дата:


14.04.2009

Съдържание


Приложение А – Допълнителна документация

1. Въведение

1.1 Общ увод в системата

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

В последните години FOREX търговията се развива бурно. Това позволява пазарът да бъде отворен и за крайните потребители. За да се осъществи това е нужно да има лицензиран брокер, който да предостави нужния софтуер за опериране със сметки и поръчки на своите клиенти. Разработваната система е именно такава. Тя позволява на крайните клиенти да подават поръчки на брокера. Клиентския софтуер се инсталира при клиента, а сървърния - при брокера. Двете системи си комуникират при извършване на сделки, следене на състоянието на валутните курсове, следене на потребителските сметки и т.н.

Валутният пазар представлява мрежа от финансови институции, които обслужват международни бизнес сделки. На него се търгуват различни национални валути. FOREX не предполага лична среща между участниците, те се намират в непосредствен и постоянен контакт помежду си с помощта на различни технически средства. Сделките се извършват посредством компютърни терминали, с които са свързани в мрежа големите банки (търговски банки) и брокерски къщи. При съвременната разгърната и модерна световна информационна и комуникационна мрежа може да се говори за единен световен пазар на валута. С развитието на интернет и информационните технологии на FOREX пазара все повече се включват и дребните инвеститори, което допринася за увеличаването на ликвидността (оборотите) и стесняването на спредовете (spread - разликата между офертите за купуване и продаване). Пазар FOREX работи 24 часа на ден, пет дни в седмицата, валутен пазар се затваря само за държавните празници и почивните дни. Валутната търговия FOREX започва с отварянето на пазара в Нова Зеландия, малко по-късно Австралия и Сингапур, последвани от Япония, Европа и накрая САЩ. Така всеки търгуващ с валути на FOREX може незабавно да реагира на добрите или лошите съобщения и да отвори или затвори позиция в удобен за него момент.


Процесът на търговия протича по следния начин:

Пазарът работи 24 часа на ден в делничните дни;

Клиентът пожелава да купи или продаде валута. Това се нарича „отваряне на позиция”. Когато става въпрос за купуване, позицията се нарича „дълга”, а когато става въпрос за продаване, позицията се нарича „къса”;

В последствие, клиентът решава да продаде, съответно купи същото количество валута, при което в неговата сметка постъпва (или се отнема) печалба (загуба) отговаряща на разликата в курсовете. Това се нарича „затваряне на позиция”.


1.2 Нефункционални изисквания

Основните нефункционални изисквания на разработваната софтуерна система са real-time използваемостта (т.е от изключително голямо значение е системата да работи правилно във всеки един момент) и maintainability (възможност за лесна промяна спрямо динамично развиващия се валутен пазар).

При достъп за първи път до платформата за реална търговия е предвидено генерирането на ключ, който ключ предствлява ключ за сигурност за платформата. Клиентския терминал ще позволява да бъде инсталиран и използван на различни компютри чрез създаване на копие на ключа за сигурност. Възможността за създаване на копие на ключа за сигурност дава възможност на клиентите да имат достъп до сметката си от друг компютър, преинсталират операционната си ситема или други подобни случаи. Изградената система ще бъде съвместима с по-голяма част от версиите на операционните системи - Macintosh, Linux и Windows.
Архитектурата е разработена по този начин, защото така най-точно и ясно са дефинирани основните функции. Софтуерната архитектура удовлетворява всички функционални и нефункционални изисквания. Декомпозицията на модули е напревена до малки логически отделени части, което позволява лесна промяна, възможност за по-голяма яснота и по-малко използвани човеко-месеци при разработка. Връзките между модулите показват потока на данни, кой модул от къде взима информация и с кои други си взаимодейства.

Конструирана по този начин системата удовлетворява напълно не само функционалните, но и нефункционалните изисквания. Дадената система е разделена на модули така, че няколко екипа да могат да работят паралелно по тях, което намалява времето за пускане на продукта на пазара. Чрез ясните връзки между модулите и добре конструираната споделена база данни, комуникацията в системата се извършва без никакви проблеми и възможности за объркване.

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

1.3 Изясняване на изискваните атрибути на качеството. Сценарии.

2. Структури

Следва описание на структурите, които са счетени за най-уместни с оглед постигане на качествените цели на системата.

2.1 Декомпозиция (Decomposition)

2.1.1 Графично представяне

2.1.1.1 Графично представяне на декомпозицията на клиентската част (CLIENT)

2.1.1.2 Графично представяне на декомпозицията на сървърната част (SERVER)



2.1.2 Таблично представяне


CLIENT Module

Security (SEC) Module

Authentication Module

Log-in

Log-out


Authorization Module

GUI (I/O) Module

Layout Manager Module

Event Dispatcher Module

Custom Components Module

Graphic Utils Module

Communication (COM) Module

Sender Module

Receiver Module

(send/receive methods)



Operation (OPT) Module

Order Manager Module

Direct Orders

Buy/Sell


Postponed Orders

Buy/Sell


Close Position Order

Open Position Order

Edit Order’s Level

Report Manager Module

Current Data Report

Account Data Report

Opened Positions Report

Closed Positions Report

Postponed Orders Report

Broker News Module

Graphics Module

Utils (UTL) Module

Mathematical and Statistical Functions Library Module

File Conversion Module

XML Convertor Module

PDF Convertor Module

HTML Convertor Module

Clock Module



Analysis (ANL) Module

Technical Analysis Module

Expert Analysis Module

Database Module

Analysis’ Logic Module


SERVER Module

Communication (COM) Module

Sender Module

Receiver Module

(send/receive methods)



Access (ACC) Module

Validation Module

Authentication Module

Authorization Module

Query Analysis and Dispatching Module

Audit Module



Kernel (KNL) Module

Operation Module

Direct Orders Module

(Open/Close Positions operations, etc.)

Postponed Orders Module

(Postponed Open/Close Positions operations, etc.)

Order Level Control Module

(Edit Orders’ Level)

Analyzer Module

Repository Module

Reports Module

Graphics Data Module

Broker News Module

Account Data Module



Logger (LGR) Module

(Logging Methods)

(Logging Access and Operations for each System User)

Load-Balancing (LBM) Module

Query AI Module

System Diagnostics Module

Resources Analysis Module



Back-Office Interface (BOI) Module

Translator Module

Time-Stamper Module

(Methods for communication with the Back-Office System)



2.2 Употреба (Uses)

2.1.1 Графично представяне

2.1.1.1 Графично представяне на структурата на употребата на клиентската част (CLIENT)

2.1.1.1 Графично представяне на структурата на употребата на сървърната част (SERVER)



2.1.2 Таблично представяне

2.1.1.1 Таблично представяне на структурата на употребата на клиентската част (CLIENT)
Client-Side:

Using procedures: A procedure in ... ... is allowed to use any procedure in ...

SEC: Security Module COM.SNM, COM.RCM

AUTHEN: Authentication Module

AUTHOR: Authorization Module

GUI: GUI (I/O) Module

LMM: Layout Manager Module GUI.CCM

EDM: Event Dispatcher Module OPT

CCM: Custom Components Module GUI.EDM, GUI.GUM

GUM: Graphic Utils Module UTL.MSFLM

COM: Communication Module

SNM: Sender Module

RCM: Receiver Module OPT

OPT: Operation Module GUI.EDM, GUI.LMM, COM.SNM

OMM: Order Manager Module SEC

RMM: Report Manager Module UTL.FCM

BNM: Broker News Module UTL.FCM

GRM: Graphics Module UTL.MSFLM, GUI.GUM

AAM: Analysis Access Module ANL

TAAM: Technical Analysis Access Module

EAAM: Expert Analysis Access Module

UTL: Utils Module None

MSFLM: Mathematical and Statistical Functions Library Module

FCM: File Conversion Module

CLM: Clock Module

ANL: Analysis Module

TAM: Technical Analysis Module UTL.MSFLM, OPT.AAM.TAAM

EAM: Expert Analysis Module UTL.MSFLM, OPT.AAM.EAAM


2.1.1.2 Таблично представяне на структурата на употребата на сървърната част (SERVER)
Server-Side:

Using procedures: A procedure in ... ... is allowed to use any procedure in ...

COM: Communication Module

SNM: Sender Module

RCM: Receiver Module ACC.VLM

ACC: Access Module

VLM: Validation Module ACC.AUTHEN, ACC.AUTHOR, ACC.QADM, LGR

AUTHEN: Authentication Module

AUTHOR: Authorization Module

QADM: Query Analysis and Dispatching Module KNL.OPM, KNL.RPM, LGR

KNL: Kernel Module BOI, COM.SNM

OPM: Operation Module KNL.ALM

DOM: Direct Orders Module

POM: Postponed Orders Module

OLCM: Order Level Control Module KNL.ALM

ALM: Analyzer Module KNL.OPM

REPM: Repository Module KNL.ALM

RPM: Reports Module

GDM: Graphics Data Module

BNM: Broker News Module

ADM: Account Data Module

LGR: Logger Module None

BOI: Back-Office Interface Module KNL

TSM: Translator Module

TIM: Timestamper Module
2.3 Процеси/Дейности (Process)

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

Този модел също така спомага и за по-ясното разбиране на бизнес-логиката, тъй като дава реална представа за стъпките, през който протичат процесите, за възможните изходи от дадена дейност и кога точно започва и приключва даден процес. Това би спомогнало за евентуално спестяване на много време и усилия ако по-късно в процеса на разработка на софтуера бъдат установени дадени неясноти или грешки в начина, по който разработчиците на системата възприемат бизнес процесите, които тя трябва да изпълнява.
1. Първият описан процес е процесът – Login. Чрез него потребителят се идентифицира пред системата. Това е и първият процес, който започва още при стартирането. Идентификацията, която изисква е от изключителна важност по отношение на сигурността. Чрез него потребителят получава достъп до личните си данни и права, в следствие на което има възможност да взаимодейства с останалата част от системата. Преди цялостното завършване на този процес е невъзможно започването на който и да е друг процес.
Процесът стартира със стартирането на системата и протича през изпращане на искане за идентификация, проверка на данните и евентуално преминава в извършване на действието Login. Ако обаче проверката даде отрицателен резултат и не успее да идентифицира потребителя, процесът се прекратява преждевременно. Ако процесът бъде прекратен по този начин, единственият възможен процес, който потребителят може да започне е отново Login. Ако проверката е положителна и потребителят се идентифицира („логне”) успешно, то следват дейностите по зареждането на първоначалните данни – потребителския му профил, състоянието на сметките му, състоянието на отворените и затворените му позиции, статуса на отложените заявки и други. След това тези данни биват запазени във временна база(cashe), което позволява по-късно да бъдат достъпени от клиента след евентуално прекратяване на връзката му със сървъра. Едновременно с това започват и други две дейности – сверяване на часовника и зареждане на новините от брокера. Първият процес осигурява синхронно взаимодействие на потребителя със системата, като го снабдява със сверен със сървърното време часовник. По този начин потребителят става независим от възможните неточности от ръчното сверяване на час и дата на компютърната си система. Вторият процес доставя новините, изпратени от брокера. Трите процеса са независими и редът, по който се изпълняват няма значение. Те могат и да се изпълняват паралелно. След като те (всичките) приключат, процесът приключва, клиентът се е идентифицирал в системата и има възможност да започне друг процес.

1. Login

2. Поцесът на отваряне на позиция започва задължително с искане на актуални котировки. Чак след като те се извлекат и получат потребителят има право да направи заявка за отваряне на позиция. Ако не го направи, след изтичане на максимум 10сек. /времето до промяна на котировките/, процесът се прекратява. Заявка и получаване на котировки не е конкурентен процес. Възможно е няколко потребителя в системата да едновременно да получават актуалните за даден момент котировки. След получаване на котировките има два типа заявка за отвряне на позиции – за директно и отложено отваряне. Процесът се различава в двата случая. Ако се направи заявка за директно отваряне, следва проверка на баланса на сметката на потребителя. Ако проверката е неуспешна и покаже по-малка наличност, то процесът спира. В противен случай се преминава към отваряне на нова позиция. При евентуален неуспех (възможни са едновременни заявки от много потребители, сривове,...) процесът моментално бива прекратен.Ако премине успешно, данните за позициите на потребителя се актуализират и част от наличността в сметката му бива блокирана. Тези две действия могат да се извършват паралелно, но се изисква и двете да приключат, за да може целия процес да приключи. В случая, когато потребителят подава отложена заявка, първо се проверява дали е изпълнено условието и. След това се изчаква време от 9сек. И се актуализират последните данни за котировки и състояние на позиции. Едва когато условието бъде изпълнено се преминава към проверка на сметка и изпълнение. Проверката на сметката се извършва едва на този етап, защото от момента на заявката до момента на изпълнение на условието и може да е минало много време и състоянието на сметката вече да е променено.


2. Отваряне на позиция

3.Процесът редакция на започва отново с подпроцесът на взимане на актуална котировка. Ако не се отреагира до изтичане на времето на котировката, тя става невалидна и процесът прекъсва. Ако потребителят реши да промени вече отворена позиция, той изпраща заявката, след което следва проверка на сметката му. При тази проверка процесът може да бъде спрян поради невлидност на данните в заявката. Ако обаче продължи и промяната е успешна следва актуализиране на данните за сметката му, позицията, както и условията и /ако е отложена/.


3.Промяна на позиция

4. При затварянето на позиция има отново искане, изтегляне и получаване на котировки. При изтичане на тяхната актуалност процесът бива прекратен. При отложена поръчка се следи състовнието на условията и, и се актуализират данните за отворената позиция и за актуалните котировка на всеки 9сек. Една секунда е оставена за отреагиране. При достигане на някое нейно условие или при директна поръчка се преминава към изпълнение. Ако е успешно, данните за позициите и сметката се актуализират, блокираната сума се отблокира и процесът приключва. Този процес обаче протича паралелно с друг процес – за всяка отворена позиция се следи дали не е надминала максималната възможна загуба от 1%. Ако това се случи, както и всяка вечер в 24:00 часа сметката бива автоматично затваряна. Затова ако Потребителят сам подаде заявка за затваряне на сметка, този процес трябва да бъде прекратен за неговата /вече затворена сметка/.


4. Зтваряне на позиция



Легенда:

Един потребител може да направи заявка за отваряне/затваряне/

редакция на позиция само след като последната директа поръчка бъде изпълнена. Отварянето на позиции обаче става последователно в рамките на заявки от един потребител. Т.е. потребителят може да подаде една или няколко отложени заявки и/или една директна заявка, но стъпките по проверка на баланса на сметка, отваряне на позиция и регистриране на успешно отворена позиция се извършват последователно за всяка позиция. Това не е така, когато става въпрос за много потребители. Процесът може да се осъществява и паралелно за много различни потребители, защото проверката и промяната на сметката на един от тях не би повлияло на останалите сметки. Процесите при различните потребители са независими и дори не знаят един за друг. Това осигурява нужната защита на потребителските данни.
3. Детайлно описание на елементите и връзките в системата

3.1 Декомпозиция

3.1.1 Елементи

Декомпозицията съдържа в себе си модули и техните подмодули, като релацията родител – дъщерен обект се изразява в това, че едните се съдържат в другите (когато релацията е визуализирана графично) и, че едните са йерархически разположени под другите, когато визуализацията на взаимоотношенията им е осъществена чрез табличен/йерархичен модел. Един модул представлява отделна имплементационна единица от цялата система, а подмодулите са структурните единици, от които той самия се изгражда. Сега ще се спрем на отделните модули, които участват в изграждането на системата:

3.1.1.1 Име на модул: GUI Module

Това е модула за графичния потребителски интерфейс или представянето. В модул се осъществява взаимодействието с крайните потребители на системата. В първия му подмодул Layout Manager се съдържа кода за визуалната подредба и дизайн на компонентите, изграждащи потребителския интерфейс. Подмодула Event Dispatcher служи като връзка между външно-видимия за потребителя слой на графичния потребителски интерфейс и слоя на логиката чрез възможност за изпълнение на определени команди от логическата част при възникване на определени входно-изходни събития. В модула Custom Components се съдържат елементите, за събитията с които слуша предишноспоменатия модул Event Dispatcher. Тези елементи могат да бъдат различни елементи на потребителския графичен интерфейс.

3.1.1.2 Име на модул: Security

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

3.1.1.3 Име на модул: Operation

Това е модулът, който има достъп до голяма част от логиката на клиентската част. В него се намират подмодулите за осъществяване на функционалността (поне клиентската й част) Купуване/Продаване (Buy/Sell), Подаване на заявка за отложена поръчка (Postponed Orders), Отваряне (Open) и Затваряне (Close) на позиция и т.н. Той може да комуникира с Графичния Потребителски Интерфейс (‘намиращ’ се в модула GUI и така да изпълнява определени свои функции, когато това е необходимо. Този модул също така комуникира и с Комуникационния модул (Communication Module) като му предава данните/заявките, които да изпрати на сървърната (SERVER) част. В случай на употреба на анализаторските функционалности на системата модула има двупосочна връзка също така и с модула за Анализ (Analysis).

3.1.1.4 Име на модул: Utils

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

3.1.4.5 Име на модул: Analysis

В него се съдържат два подмодула: Technical и Expert. Двата служат за имплементиране на този тип функционалност, зададен от спецификацията на системата. Този модул има връзка с подмодула за Библиотека за Математически и Статистически Функции (Mathematical and Statistical Functions Library) в модула Utils.

3.1.4.6 Модула Communication служи като връзка между клиентската и сървърната част и поддържа методи за изпращане и получаване на информация. Може да се достъпва от множество модули в клиентската част, сред които Operation, Security и т.н.

3.1.2 Връзки
3.1.3 Интерфейси

3.2 Употреба

3.1.1 Елементи

Елементите на тази структура са модулите и взаимодействията между тях. Релацията, която е дефинирана по-конкретно е ‘може да използва’ или ‘uses’. Чрез тази използването на тази структура при обмислянето на дизайна се цели да се осъществи слабо свързване и скриване на информация между различните елементи, което позволява адаптивност на системата към различни имплементации на отделните модули и независимост между тях. Тази структура може да служи и като отправна точка за определяне на екипите и тяхното разположение. Чрез дефинирането на модули, които са слабо свързани се постига и възможност за лесно добавяне на нова функционалност без това да повлияе на специфични части от системата и по-лесно локализиране на грешките, дефектите, сривовете и причините за тях.

3.1.2 Връзки

3.1.3 Интерфейси

3.3 Процеси (Дейности)

3.1.1 Елементи

3.1.2 Връзки

3.1.3 Интерфейси



4. Описание на обкръжението

4.1 Комуникация с Back-Office система

В изискванията към системата е зададено и такова, че Back-Office системата, с която работи брокера не трябва да е от някакъв конкретен стандарт. Текущото решение в предложената архитектура позволява да се избегне подобно ограничение, като се реализира т.нар. виртуална машина, която дава възможност за комуникация с различни Back-Office система без съответните модули, които го правят да е необходимо да знаят типа на Back-Office системата. Тази комуникация до голяма степен се определя от лицето ‘брокер’.


4.2 Комуникация между клиента и сървъра

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



5. Тактики за постигане на атрибутите на качеството на системата

5.1 Тактики за сигурност (Security)

5.1.1 Тактики за устояване на атаки

5.1.1.1 Автентификация и оторизация - Първата тактика, към която трябва да се придържа системата с цел постигане на качеството Сигурност е имплементиране на Автентификация и Оторизация на потребителите. Както е описано чрез структурата Процес при тази архитектура това е реализирано чрез използването на специални модули, които контролират достъпа и проверяват самоличността на клиента/лицето, което оказва някакво влияние на системата.

5.1.1.2 Конфиденциалност на информацията - Едно от основните изисквания към системата е да има конфиденциалност на информацията (това изискване като цяло се налага и от закона). За да се получи това трябва да се използват достатъчно сигурни методи за защита на информацията, докато тя ‘пътува’ от клиента към сървъра и обратно (напр. Virtual Private Network (VPN) или Secure Sockets Layer (SSL)).

5.1.1.3 Ограничаване на достъпа – за целта сървърната част трябва да бъде добре защитена чрез Firewall и да приема заявки само на определен порт. Едно от ефективните решения е и алокацията/разполагането на определени типове услуги само на определени виртуални/физически машини.

5.1.2 Тактики за засичане на атаки

5.1.2.1 Създаване на модул (в контекста на тази архитектура, например в модул Access), в който да се засичат неправомерни/влизания с взлом от страна на външни лица. Възможно е този модул да изолира понататъшното взаимодействие на подобни лица срещу системата.

5.1.3 Тактики за възстановяване от атаки

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

5.2 Тактики за наличност (Availability)

5.2.1 Тактики за засичане на дефекти

5.2.1.1 Системата ще използва метода ping/echo, с чиято помощ ще се установява дали дадени компоненти от нея (най-вече хардуерни) са в изправност.

5.2.1.2 На базата на механизма на изключенията или т.нар. Exceptions ще се засичат и анализират дефекти в области, които в бъдещ момент биха могли да доведат до срив.

5.2.2 Тактики за избягване на дефекти

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

5.2.2.2 Използване на метода Checkpoint/rollback – чрез този метод може да се гарантира, че системата по всяко време може да се върне към последното си ‘стабилно’ състояние

5.2.3 Тактики за възстановяване от дефекти

5.2.3.1 Използване на метода Active Redundancy (Hot Restart) – това е често използван метод при системите от тип клиент/сървър, като тази, чиято архитектура се дефинира и осигурява възможност за пренасочване на определена информация към друга част системата, в случай, че е невъзможно тя да се обработи в момента.

5.3 Тактики за производителност (Performance)

5.3.1 Управление на ресурсите

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

5.3.1.2 Репликация на данните – стига това действие да се изпълнява на сървърната страна, то няма чак до такава степен да повлияе на качеството Сигурност на системата и ще позволи значително подобряване на производителността чрез избягване на ситуациите на конкуриране за достъп до дадени данни (в контекста на системата репликация може да се зададе например за текущия валутен курс, т.е. той да бъде достъпен за повече от един компонент).

5.3.2 Арбитриране на ресурсите

5.3.2.1 Системата ще използва метода на динамично планиране на изпълнението на потребителските заявките на базата на приоритет Round Robin, при който заявките се подреждат и в даден момент се изпълнява втората поред. Така се избягват до голяма степен задръстванията (bottlenecks) и т.нар. deadlocks.

5.3.3 Подобряване на ресурсите

5.3.3.1 Естествено условие за по-бързото функциониране на системата е тя да бъде снабдена с достатъчно бърза физическа инфраструктура (процесори и т.н.)



6. Архитектурна обосновка

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





Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©obuch.info 2019
отнасят до администрацията

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