35198

ПРОГРАМНА СИСТЕМА ДЛЯ АВТОМАТИЗАЦІЇ БРОКЕРСЬКОГО ОБСЛУГОВУВАННЯ НА ВАЛЮТНІЙ БІРЖІ. КЛІЄНТСЬКА ЧАСТИНА

Дипломная

Информатика, кибернетика и программирование

JSF JavaServer Faces – це каркас програмування технологія для вебзастосунків що написані на Java. AJAX Asynchronous JavaScript And XML – підхід до побудови користувацьких інтерфейсів вебзастосувань за яких вебсторінка не перезавантажуючись у фоновому режимі відправляє запити на сервер і сама звідти довантажує потрібні користувачу дані. – Інструменти для створення персональних вебсторінок – скриптова мова програмування загального призначення інтенсивно застосовується для розробки вебдодатків. PHP PHP – Інструменти для...

Украинкский

2013-09-09

1.55 MB

10 чел.

Факультет прикладної математики

Кафедра програмного забезпечення комп’ютерних систем

“ЗАТВЕРДЖЕНО”

Завідувач кафедри

__________ І.А. Дичка

“___” ____________ 2012 р.

ПРОГРАМНА СИСТЕМА ДЛЯ АВТОМАТИЗАЦІЇ БРОКЕРСЬКОГО ОБСЛУГОВУВАННЯ НА ВАЛЮТНІЙ БІРЖІ. КЛІЄНТСЬКА ЧАСТИНА

Пояснювальна записка

ПЗКС.045440-03-81

“ПОГОДЖЕНО”

Керівник проекту:

__________ Т.М. Заболотня

Нормоконтроль:                Виконавець:  

   

__________М.В. Онай                 __________А.В. Сапіга

2012

ЗМІСТ

ВСТУП 4

СПИСОК ТЕРМІНІВ, СКОРОЧЕНЬ ТА ПОЗНАЧЕНЬ 6

1. РИНОК FOREX 7

1.1. Класифікація торгових систем за рівнем автоматизації 7

1.2. Класифікація торгових систем за способом торгівлі 8

2. ІСНУЮЧІ ПРОГРАМНІ РІШЕННЯ 18

2.1. Relative Strengh 18

2.2. Система Forex Profit 23

3. ОБГРУНТУВАННЯ ВИБОРУ ТЕХНОЛОГІЙ ДЛЯ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ 30

3.1. PHP 30

3.2. Adobe Flash 35

3.3. Spring Framework 38

3.4. JavaServer Faces 43

3.5. Model-View-Controller 45

3.6. AJAX 47

3.7. Enterprise JavaBeans 49

4. СТРУКТУРНІ ТА АЛГОТИТМІЧНІ ОСОБЛИВОСТІ РОЗРОБЛЕНОГО ПРОГРАМНОГО ПРОДУКТУ 51

4.1. Загальна характеристика програмного продукту 51

4.2. Внутрішні процеси 53

4.3. Декодування запитів 54

4.4. Життєвий цикл сторінки 54

4.5. Навігація 57

4.6. Організація перенаправлень 59

4.7. Параметри перегляду сторінок 63

4.8. Використання тегів Facelets 66

5. ОХОРОНА ПРАЦІ 69

5.1. Виявлення та аналіз ШНВШ. Заходи з охорони праці 70

5.2. Пожежна безпека 74

5.3. Блискавкозахист 75

ВИСНОВОК 78

СПИСОК ВИКОРИСТАНИХ ЛІТЕРАТУРНИХ ДЖЕРЕЛ 79

ДОДАТКИ 81


СПИСОК ТЕРМІНІВ, СКОРОЧЕНЬ ТА ПОЗНАЧЕНЬ

Форекс (Forex, іноді FX) – від англ. FOReign EXchange – обмін іноземної валюти (ринок міжбанківського обміну валюти за вільними цінами).

МТС – Механічні торгові системи (вид торговельних систем, при якій втручання людини в процес торгівлі мінімальний).

JSF (JavaServer Faces ) – це каркас програмування, технологія для веб-застосунків, що написані на Java.

MVC (Моде́ль-вид-контро́лер або Модель-вигляд-контролер, англ. Model-view-controller, ) – архітектурний шаблон, який використовується під час проектування та розробки програмного забезпечення.

AJAX (Asynchronous JavaScript And XML) підхід до побудови користувацьких інтерфейсів веб-застосувань, за яких веб-сторінка, не перезавантажуючись, у фоновому режимі відправляє запити на сервер і сама звідти довантажує потрібні користувачу дані.

EJB (Enterprise JavaBeans) специфікація технології написання і підтримки серверних компонентів, що містять бізнес-логіку. Є частиною Java EE.

Java EE (Java Platform, Enterprise Edition) набір специфікацій і відповідної документації для мови Java, який описує архітектуру серверної платформи для задач середніх і великих підприємств.

PHP (англ. PHP: Hypertext Preprocessor, «PHP: препроцесор гіпертексту», англ. Personal Home Page Tools (устар.) – «Інструменти для створення персональних веб-сторінок») – скриптова мова  програмування загального призначення, інтенсивно застосовується для розробки веб-додатків.

GUI (Графі́чний інтерфе́йс користувача, ГІК, англ. GUI, Graphical user interface) інтерфейс між комп'ютером і його користувачем, що використовує піктограми, меню, і вказівний засіб для вибору функцій та виконання команд.

ВСТУП

Форекс – ринок міжбанківського обміну валюти за вільними цінами. На сьогодні – це ринок, який має найшвидші та наймасштабніші темпи росту. Щоденний обіг грошей на ринку зріс з одного трильйона доларів в 1992 році до 4 трильйонів доларів в 2010 році. Кількість трейдерів росте в геометричній прогресії.

Через таку ситуацію виникає необхідність створення програмного продукту для торгівлі на ринку, підтримка якого буде легшою та дешевшою в порівнянні з наявними десктопними продуктами. Рішенням проблеми є створення web-орієнтованої платформи.

Перевагами даного продукту, в порівнянні з існуючими, є:

  1.  легкість підтримки та оновлення;
  2.  доступність даних;
  3.  незалежність логіки від ОС;
  4.  відсутність необхідності в інсталяції;
  5.  можливість паралельного доступу до даних;
  6.  централізоване збереження даних;
  7.  легкість здійснення операцій резервного копіювання;
  8.  кросплатформеність;
  9.  низька вартість підтримки та обслуговування.

В ході розробки клієнтської частини програми особливу увагу було приділено:

  1.  Архітектурі модель-вигляд-контролер. Підтримка чіткої розділеності бізнес процесів, бази даних та методів відображення.
  2.  Перетворення даних. Перетворення введених користувачем даних в потрібний для робот из ними формат.
  3.   Перевірка та обробка помилок. Програмний продукт виконує ряд перевірок таких, як "це поле обов’язкове для заповнення" або "в цьому полі мають бути тільки числа". Звичайно, коли користувач вводить неправильні дані, відображається відповідне повідомлення про помилку.
  4.  Клієнтська чатина продукту включає в себе підтримку Ajax. За домогою Ajax непомітно для користувача програмний продукт виклика серверні дії та оновлює сторінки.
  5.  Кодування та декодування запитів. Передача введеної користувачем інформації на сервер, отримання від нього відповіді та відображення отриманого результату користувачеві.
  6.  Життєвому циклу сторінки. Чітка робота та відображення всіх етапів від отримання запиту до виведення відповіді.


1. РИНОК FOREX

1.1. Класифікація торговий систем за рівнем автоматизації

На ринку Форекс виділяють кілька сегментів.

Ринок спот поставка валюти відбувається на другий робочий банківський день після дня проведення операції. Безпосередньо ринок Форекс ринок міжбанківських операцій без єдиного центру торгівлі.

Форвардний сегмент оставка валюти відбувається більш ніж через два робочих дні. Операції з похідними інструментами, реєструються на біржових та позабіржових організованих торговельних.

Угоди своп проведення відразу двох операцій (купівлі та продажу, одна з яких угода спот, інша форвардна). Комбіновані операції на безпосередньому ринку та/або з похідними інструментами [7].

Рис. 1. Сегменти валютного ринку

Торгова система – це певний набір правил, продумана система прийняття торгівельних рішень, згідно з якою трейдер відкриває або закриває свої позиції.

Торгові системи поділяються на такі основні класи:

  1.  Механічні торгові системи (МТС).
  2.  Напівмеханічними торговельні системи.
  3.  Немеханічні торговельні системи.

МТС – вид торговельних систем, при якій втручання людини в процес торгівлі мінімальний. Тобто система сама віддає накази на відкриття і закриття позицій, сама визначає рівні збитку і прибутку, рівні підтримай і опору і так далі. Одним словом, система діє у відповідності із закладеним в неї алгоритмом. МТС – мрія багатьох трейдерів, особливо новачків, адже що може бути краще, коли бот заробляє для тебе гроші, а ти просто займаєшся своїми справами і періодично перевіряєш рахунок.

Такі системи допомагають трейдерам приймати рішення і заощаджують час на аналіз ринку.

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

Немеханічні торговельні системи. Серед усіх видів торговельних систем, цей найбільш складний. Адже при немеханічного торгівлі всі рішення приймаються трейдером, таким чином психологічна складова в торгівлі знаходиться на максимальному рівні, в порівнянні з МТС і напів-мтс. Тут однозначно необхідна самодисципліна і вміння себе контролювати. Якщо ви не володієте цими якостями, то краще не використовуйте немеханічні торговельні системи взагалі [7].

1.2. Класифікація торгових систем за способом торгівлі

Поділ торговельних систем форекс на аналітичні і механічні, припускає, що перші торгують по якимось не жорстким принципам, що допускає творче трактування, а другі за жорсткими правилами без будь-яких відступів. При цьому торгівля механічних систем може бути як ручна, так і автоматична. Ми будемо розуміти під механічної торговою системою (МТС) систему, яка торгує автоматично за жорстко заданими правилами.

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

З точки зору побудови МТС найбільшу складність представляють системи на основі хвильового аналізу, оскільки розрізнити й проаналізувати хвилі на графіках ціни інструменту часом буває не під силу людському мозку, не кажучи вже про програмне середовище. Важко віддати перевагу якому-небудь класу торгових систем. Кожна система буде прибутковою при певних, характерних для неї ринкових умовах і збитковою, коли цих умов немає. Наприклад, трендові системи заробляють в тренді, але зливають в флеті, а флетові системи навпаки заробляють в флеті але зливають в тренді і нічого з цим не зробити.

Здавалося б все зрозуміло: тренд на ринку – торгуємо трендовую систему, флет – торгуємо флетовую. Приблизно так пишуть у багатьох книгах, у тому числі і зовсім нових. Але насправді все не зовсім так просто. Справа в тому, що на Форексі, як і на будь-якому іншому ринку, ніколи не знаєш точно, коли почався тренд, а коли флет. Їх видно тоді, коли вони вже сформувалися. Причому як тренд так і флет можуть закінчитися в будь-який момент, а можуть і продовжитися рівноймовірно.

Тому не варто намагатися визначити трендову ділянку або флетову, торгуємо або не торгуємо. Просто має виконуватися одна умова. Якщо ваша система трендова треба, щоб вона в тренді заробляла більше, ніж зливає в флеті і, відповідно, якщо системи флетова, треба, щоб вона в флеті заробляла більше, ніж зливає в тренді. Теж саме відноситься і до інших торгових системам. В ідеалі потрібен портфель з декількох типів систем, тоді ви зможете «зловити» максимальну кількість ринкових рухів і заробити на них.

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

Трендова торгова система будується на припущенні, що тенденція ринку до зростання або падіння, якщо вона почалася, є стійкою і має вагомі підстави для продовження. Це, мабуть, найпоширеніший тип торгової стратегії. Тренд зазвичай розглядають стосовно до конкретного часового інтервалу. Наприклад, те що є трендом на денному графіку, на місячному може виявитися невеликою корекцією. Традиційно трендові стратегії будуються на основі ковзних середніх і їх комбінацій. Приклад роботи однієї з таких стратегій приведений на рис. 2.

В інших ринкових умовах (відмінних від вираженого тренду) такі торговельні системи даватимуть збитки, зважаючи на велику кількість помилкових входів. Тому використання у своїй стратегії лише ковзають середніх навряд чи дозволить вам добитися прибуткової торгівлі.

Тим не менш, трендові стратегії можуть і повинні бути об'єктом дослідження, оскільки, незважаючи на істотні зміни характеру ринку в останні кілька років, тренди продовжують представляти собою найбільш суттєві цінові руху, з яких можна й потрібно мати зиск.

Для ідентифікації сили тренда розроблено велику кількість індикаторів. Однак використовувати стандартні індикатори необхідно обережно, оскільки всі вони запізнюються і сигналізують про силу тренда, коли він вже закінчується. У протилежному (більше чутливому) варіанті настройки, ці індикатори будуть давати велику кількість помилкових входів.

Рис. 2. Приклад тренду

Побудова і функціонування трендових торгових систем включає в себе наступні етапи:

  1.  Визначення глобальної тенденції, тобто визначення наявності тренда. Виробляється на старших тимчасових таймфреймах Н4 або D1. Ідентифікація тренду здійснюється за ознакою перевищення кожного наступного піку ціни попереднього. При цьому ковзне середнє знаходиться нижче графіка ціни (рис. 3).
  2.  Визначення початку відкату ціни. Первинне визначення відкату виробляється на старшому тимчасове таймфрейме Н4 або D1. Ідентифікація здійснюється з перетинання графіком ціни лінії ковзної середньої в напрямку, протилежному глобальної тенденції.
  3.  Визначення завершення відкоту ціни. Виробляється на молодших тимчасових таймфреймах H1, M30 або М15. Як правило, для цієї мети використовують осцилятори, наприклад MACD або стохастик. У разі застосування MACD визначають бичаче або ведмеже розбіжність, у разі застосування стохастика-зони перекупленності або перепроданності.
  4.  Входження в угоду, виставлення ордерів стоп-тосс і тейк-профіт. Стоп-лосс ставиться не ближче 15-20 пунктів від рівня ціни. Близько розташовані стопи з високою ймовірністю будуть вибиті ринковим шумом. Тейк-профіт виставляється на відстані не менше 3-5 розмірів стоп-лосс, оскільки завдання трендової системи – взяти максимально можливе ціновий рух.
  5.  Супровід позиції – установка стежать ордерів трейлінг-стоп у міру руху ціни. Найбільш відповідні моменти установки ордерів трейлінг-стоп, це локальні мінімуми ціни в процесі її руху. Ідентифікація локальних мінімумів проводиться або по фракталам (спосіб, запропонований Біллом Вільямсом), або з перетинання графіком ціни ковзної середньої, або за осцилятора на молодших тимчасових таймфреймах. Зручним способом Трейлінг є також використання смуг Болінждера (рис. 2). У разі висхідного тренда рівень стоп-лосс визначається по нижній лінії індикатора, у разі спадного тренда-по верхній лініі. Вихід виробляється або по досягненню ціною рівня тейк-профіт, або за трейлінг-стопу, або з перетинання графіком ціни лінії ковзної середньої в напрямку, протилежному напрямку тренда.

Це найзагальніша схема роботи трендовой торгової системи, вона не гарантує абсолютної прибутковості, але допоможе вам уникнути зайвих збитків [8].

Флетова торгова система будується на припущенні, що більшу частину часу на ринку присутня бічний рух, при якому ціна рухається всередині деякого коридору (каналу), обмеженого рівнями підтримки знизу і опору зверху. У зв'язку з цим флетові системи іноді називають «канальними». Флетовая торгова система повинна купувати поблизу рівня підтримки і продавати поблизу рівня опору. Можлива побудова флетових систем та без визначення чітких між каналу, тим більше, що визначення цих кордонів не завжди можливо. Наприклад, система може бути побудована на основі осциляторів, що, втім, не заважає комбінувати їх з рівнями опору і підтримки.

Приклад роботи однієї з таких стратегій, заснованої на індикаторі стохастик і лініяхрівнів наведено на рис. 3.

Рис. 3. Приклад флету

У тренді така система буде давати збиток, тому необхідно подбати про те, щоб у флеті вона заробляла більше ніж втрачає в тренді. З точки зору автоматизації флетовие системи досить прості за виключенням, мабуть, випадку, коли торгівля ведеться від рівнів.

Побудова і функціонування трендових торгових систем включає в себе наступні етапи:

  1.  Визначення наявності флет. Виробляється на старших тимчасових таймфреймах Н4 або D1. Ідентифікація флет здійснюється за наявності сформованого цінового каналу шириною 150-200 пунктів. Канал формується шляхом з'єднання декількох глобальних максимумів (лінія опору) і декількох глобальних мінімумів (лінія підтримки) (див. малюнок).
  2.  Визначення початку відскоку. Первинне визначення відскоку здійснюється на старшому тимчасове таймфрейме Н4 або D1. Ідентифікація проводиться за торкання графіка ціни лінії опору (відскік від верхньої межі каналу) або лінії підтримки (відскік від нижньої межі каналу).
  3.  Визначення завершення відскоку. Виробляється на молодших тимчасових таймфреймах H1, M30 або М15. Як правило, для цієї мети використовують осцилятори, наприклад MACD або стохастик. У разі застосування MACD визначають бичаче ними ведмеже розбіжність, у разі застосування стохастика-зони перекупленності або перепроданності, момент входження в угоду при цьому визначається з перетинання сигнальної лінією стохастика рівня 20 (покупка) або 80 (продаж).
  4.  Входження в угоду, виставлення ордерів стоп-тосс і тейк-профіт. Стоп-лосс ставиться відразу за кордоном каналу, на відстані 15-20 пунктів. Стопи, розташовані ближче з високою ймовірністю будуть вибиті ринковим шумом. Тейк-профіт виставляється на рівні, близькому до протилежної сторони каналу. Відповідно до класифікації, запропонованої Олександром Елдером «відмінним» вважається результат, при якому ви берете прибуток, що дорівнює 30% ширини каналу і більше, 10% ширини каналу – «задовільно».
  5.  Супровід позиції – установка стежать ордерів трейлінг-стоп у міру руху ціни. Найбільш відповідні моменти установки ордерів трейлінг-стоп, це локальні мінімуми ціни в процесі її руху. Ідентифікація локальних мінімумів проводиться, наприклад, по фракталам (спосіб, запропонований Біллом Вільямсом). Зважаючи на високу цінової волатильності в флете, розташовувати рівні трейлінг-стопів треба не дуже близько, інакше виходи з угод будуть передчасні.
  6.  Вихід з угоди. Вихід виробляється або по досягненню ціною рівня протилежної межі каналу (тейк-профіт), або по трейлінг-стопу.

Канал, в якому проводиться торгівля, може бути горизонтальним, висхідним або низхідним. У висхідних і спадних каналах рекомендується відкривати позиції в напрямку нахилу каналу, по є у висхідному каналі купувати, в низхідному – продавати. Модифікації флетових (канальних) торгових систем стосуються, в основному, ідентіфікакціі моментів відскоків ціни від кордонів каналу і їх підтверджень, для цієї мети, наприклад, використовують дивергенції осциляторів і свічкові моделі розвороту [9].

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

Приклад роботи однієї з таких стратегій, побудованої з використанням свічкової моделі розвороту, наведено на рис 4.

Рис. 4. Приклад контртренду

Відмінною особливістю цієї системи є дуже близький стоп-лосс і велика кількість помилкових входів, які пов'язані з незначними втратами в кожній окремій угоді. Часті й дрібні втрати компенсуються великим прибутком при правильному входженні на розвороті тренда.

Побудова і функціонування контртрендових торгових систем включає в себе наступні етапи:

  1.  Визначення моменту кульмінації тренда. Ідентифікація кульмінації здійснюється за ознакою глибокого пробиття рівня опору (підтримки) і параболічного відхилення графіка ціни від лінії ковзної середньої. При цьому ковзне середнє знаходиться істотно нижче графіка ціни.
  2.  Підтвердження розвороту. Момент підтвердження розвороту визначають, наприклад, за свічковим комбінаціям розвороту (див. малюнок). При використанні свічкових моделей розвороту доцільно використовувати старші або середні тимчасові таймфрейм Н1, Н4 або D1. Використання молодших таймфрейм небажано зважаючи на велику кількість хибних сигналів.
  3.  Входження в угоду, виставлення ордерів стоп-тосс і тейк-профіт. При використанні свічкових моделей розвороту, стоп-лосс ставлять на кілька пунктів вище (нижче) тіні свічки, що сигналізує про розворот. Тейк-профіт виставляється в районі значущих рівнів, які визначають по лініях сопротовленія / підтримки, або, наприклад, по індикатору Pivot Point. Розмір тейк-профіт повинен бути значним, оскільки мета контртрендовой системи – великі цінові руху, а вони трапляються не часто.
  4.  Супровід позиції – установка стежать ордерів трейлінг-стоп у міру руху ціни. Найбільш відповідні моменти установки ордерів трейлінг-стоп, це локальні мінімуми (максимуми) ціни в процесі її руху (див. малюнок). Зручним способом Трейлінг є, також як і в трендових системах, використання смуг Болінждера. У разі висхідного тренда рівень стоп-лосс визначається по нижній лінії індикатора, у разі спадного тренда – по верхній лінії.
  5.  Вихід з угоди. Вихід виробляється або по досягненню ціною рівня тейк-профіт, або за трейлінг-стопу.

Цей приклад пояснює найзагальніші принципи роботи контртрендових систем. Модифікацій може бути безліч. Зокрема однією з популярних моделей розвороту є дивергенція осциляторів.


2. ІСНУЮЧІ ПРОГРАМНІ РІШЕННЯ

2.1. Relative Strenght

Торгова система Relative strenght заснована на оцінці руху ціни. Використовується один індикатор CCfp, який визначає силу тренда валютних пар.

Чим ближче стовпчик діаграми домаксимуму, тим більшу силу має валюта і навпаки. Колір вказує напрям тренда: зелений – бичачий, червоний – ведмежий.

Рис. 5. Робоча область Relative Strenght

Перевага даного методу полягає в тому, що ви використовуєте в торгівлі тільки ту валюту, яка має максимальну силу. А також застосовується хеджування іншими валютними парами.

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

Індекс відносної сили – Relative Strength Index (RSI)

Індикатор розроблений Дж. Уоллесом Уайлдером. Вперше Relative Strength Index був представлений в червні 1978 року в журналі Commodities (тепер відомий як Futures), а потім вийшов в його книзі "Нові концепції в технічних торгових системах" і з тих по став одним з найбільш популярних осциляторів, які оцінюють силу руху. Relative Strength Index порівнює величину підйомів ціни активу за останній час з величиною її падінь та надає цю інформацію у вигляді числа яке знаходиться в діапазоні від 0 до 100. Єдиний параметр індексу відносної сили – часовий період, який використовується в розрахунку.

Формула:

;     (1)

.      (2)

де

CU (n) – середнє значення позитивних змін ціни закриття;

CD (n) – середнє значення негативних змін ціни закриття;

     (3)

якщо .

     (4)

якщо .

Середнє значення позитивних змін ціни закриття і середнє значення негативних змін ціни закриття не є справжніми ковзаючими середніми. Замість поділу на кількість позитивнихі негативних змін обидва показники в знаменнику мають загальну кількість періодів длярозрахунку RSI.

Рис. 6. Побудова кривої RSI

Коли середнє значення позитивних змін ціни закриття більш ніж середнє значення негативних змін ціни закриття RSI зростає, оскільки значення RS більше одиниці, відповідно, коли середнє значення позитивних змін ціни закриття менше, ніж середнє значення негативних змін ціни закриття RSI падає, оскільки RS менше одиниці.

Як і у більшості осциляторів, чим більше даних використовується для розрахунку RSI (більше період RSI), тим більш точними будуть результати. У більшості випадків для аналізу ринку по RSI використовується типовий метод зон перекупленності і перепроданності осциляторів. Автор (Уайлдер) рекомендує використовувати для визначення зон перекупленності і перепроданності відповідно зони вище 70 і нижче 30. Зона вище 70 таким чином по автору показує, що ринок перекуплений (тобто подальший рух вгору скоро вичерпає себе), а зона нижче 30 вважається зоною перепроданості (тобто подальший рух вниз скоро вичерпає себе). Однак існує багато інших варіація щодо співвідношення цих рівнів: 75/25 або 80/20. На ринку Forex частіше використовується останнє співвідношення рівнів. В якості центральної, зазвичай розглядають рівень 50. Однак і тут існують варіації. Так, іноді на висхідному тренді центральну лінію і рівні перекупленності перепроданості зміщують вгору, а на низхідному тренді – вниз.

Relative Strength Index в основному використовується на ринках, що знаходяться в бічному тренді, оскільки на ринках, які перебувають в направленому тренді, він може використовуватися лише для визначення точок входу і виходу всередині тренда, тобтодля прогнозування локальних максимумів і мінімумів. Використання Relative Strength Index в якості основного індикатора на трендовом ринку може привести до великої кількості хибних сигналів.

Використання

Як випереджаючий індикатор без сигналів. Максимуми за рівнем 70 і мінімуми нижче 30 часто випереджають максимуми і мінімуми на графіку ціни.

Трендова стратегія: деякі трейдери сприймають перетин індикатором на трендовому ринку точки 50 вгору як висхідний тренд, а падіння нижче 50 як спадний тренд. Тому перетин рівня 50, коли ринок є трендовим, само по собі є сигналом для входу в ринок. Однак при формуванні ненаправленного бічного тренда така стратегія буде давати дуже багато помилкових сигналів, так як RSI буде часто перетинати рівень 50.

Контртрендова стратегія. Як сигнальні рівнів використовують 70 і 30, 75 і 25, 80 і 20 або інші. При цьому сигнал на продаж подається коли RSI виходить із зони перекупленності тобто перетинає рівень 70% вниз, а сигнал на покупку подається, коли RSI виходить із зони перепроданості, тобто перетинає рівень 30 знизу вгору. Однак ця стратегія працює тільки в нетрендовий період ринку. У період тренда індикатор зайде в одну із зон (при висхідному тренді в перекупленість, при низхідному в перепроданность) і буде подавати в цій зоні безліч помилкових сигналів постійно перетинаючи лінію, яка відокремлює зону.

Сигнал на продаж з'являється в разі якщо RSI утворює подвійну вершину (фігуру типу / \ / \ – букву М) в зоні перекупленності (наприклад над 70), причому друга вершина нижче першої. Сигнал на продаж з'являється при пробитті підстави подвійної вершини. І навпаки, якщо RSI створює в зоні перепроданості (наприклад нижче 30) фігуру подвійного підстави (фігуру типу \ / \ / або букву W), де другий мінімум вище першого, то сигнал на покупку подається, якщо RSI пробиває рівень середнього максимуму вгору. Вважається, що чим вище в зоні перекупленності і чим нижче в зоні перепроданості виникає сигнал, тим він сильніший.

Сигнал дивергенції. Як і на інших осцилляторах сигнал дивергенції надходить у разі невідповідності співвідношення нових максимумів або мінімумів на графіку осцилятора і ціни. Якщо на графіку осцилятора новий максимум нижче попереднього, а на графіку ціни новий максимум вище попереднього, то виникає "розбіжність свідчень" осцилятора і ціни. Це сигнал до продажу. Якщо ціна робить новий мінімум нижче попереднього, а осцилятор робить новий мінімум вище попереднього, це означає, що відносна сила спадного тренда зменшилася, наближається розворот вгору і надходить сигнал на покупку. При цьому вважається, що відстань між мінімумами і максимумами на осцилляторе повинно бути від 7 до 50 періодів, інакше дивергенція буде занадто "сира" (якщо менше 7) або вже "перегоріла" (якщо більше 50).

Графічні патерни. На графіку RSI часто з'являються графічні патерни, які трейдери використовують в аналізі цінових графіків (такі як голова-плечі, трикутники і т.д.).

Рівні підтримки і опору на графіку індексу відносної сили часто показують більш явно рівні підтримки і опору, ніж на самому графіку ціни.

Недоліки:

  1.  Погано працює в період тренда на ринку (подає багато хибних сигналів).
  2.  Попередження про ризики: не варто використовувати якісь індикатори на реальних рахунках без попереднього тестування їхньої роботи на демонстраційному рахунку або тестування в якості торгової стратегії. Будь-який, навіть найкращий індикатор, що застосовується неправильно, дає безліч помилкових сигналів і як наслідок, може принести значні збитки в процесі торгівлі.

2.2. Система Forex Profit

Система "Forex Profit" (Forex Profit SystemFPS) використовує 2 види технічнихіндикаторів, щоб показати, де Ви повинні входити в угоду і виходити з неї. Це Parabolic SAR і експоненціальні ковзаючі середні – Exponential Moving Average 10, 25 і 50

Рис. 7. Робоча область Forex Profit

Ось, як виглядає Ваш графік. Це індикатори FPS, які я використовую в торгівлі. EMA 10 показана фіолетовим кольором, EMA 25 темно-жовтим, а EMA 50 блакитним. Параболик SAR відзначений точками вище і нижче графіка ціни.

Індикатори FPS говорять вам, що потрібно входити в угоду, коли EMA 10 перетинає 25 і 50. Якщо 10 перетинає 25 і 50 знизу вгору, відкривається довга угода бай. Якщо 10 перетинає 25 і 50 зверху вниз, ви йдете в коротку селл. Переконайтеся, що параболик SAR розташований знизу від ціни, коли ви йдете в довгу, і зверху – коли ви відкриваєте коротку угоду.

У прикладі на графіку вище, 15 жовтня була прекрасна можливість відкртися вгору по парі USD / CHF, яку я позначив гуртком і словом "Enter". Відмітьте, як EMA 10 перетнула 25 і 50, а параболик SAR був знизу.

Якщо ви торгуєте за годинними графіками, як показано на прикладі, переконайтеся, що на 15-хвилинному графіку параболик SAR розташований таким же чином. Ніколи не торгуйте проти 15-хвилинної параболи!

Кращий час для виходу з угоди настає тоді, коли ціна перетинає назад вниз всі 3 EMA на графіку. Зверніть увагу, як у вищезгаданому прикладі темно-синя лінія фактична ціна USD / CHF  перетнула вниз всі три індикатори в місці, яке я обвів гуртком і позначив, як "Exit" вихід. Якщо ви утримали цю позицію протягом усього тижня, ви могли б узяти 275 піпсов прибутку.

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

При використанні FPS ви завжди повинні встановлювати свій рівень відразу нижче EMA 50. У міру того, як ваша позиція рухається в потрібному напрямку, слід відповідно переміщати свій стоп. Потім, якщо ваша позиція рушить проти вас, стоп-ордер зафіксує вашу прибуток. Важливо, щоб, як тільки ціна перетне 10,25 і 50 ЕМА, ваша позиція закрилася.

Приклад того, як FPS працює на 15-хвилинних графіках проілюстровано на рис. 8.

Рис. 8. Приклад роботи на 15-хвилинних графіках

Використання FPS на 15-хвилинних графіках більш мінливе, але воно дасть вам більше угод всередині дня. В наведеному вище прикладі ви могли б продати USD / CHF за 1.5060 і закрити позиція по 1.5000 з прибутком в 60 піпсов.

Одне застереження при торгівлі на 15-хвилинних графіках: часто буває, що ціна малює "пилу" вгору і вниз, крізь 10, 25 і 50 середні. Якщо трапиться незабаром після того, як ви увійшли в угоду, закрийте позицію і почекайте, поки середні не розійдуться, а параболик SAR не дасть сильний сигнал.

У нашому першому прикладі ми торгували технічними індикаторами на годинних графіках, що називається свінг Трейдін-угода триває протягом декількох днів, а іноді навіть тижнів. У нашому другому прикладі ми розглядали 15-хвилинні графіки, на яких торгують дейтрейдерів, тримаючи позиції всередині дня. Скальпування називається трейдинг, коли Ви використовуєте 1-5-хвилинні графіки для невеликих прибутків "скальп". Тут зазвичай тримають угоду від декількох хвилин до години.

Ви можете використовувати FPS для скальпування Forex на хвилинному графіку ось як:

  1.  Замість використання 10, 25, 50 EMA, як ми робили вище, проведіть 25, 50 і 100 EMA.
  2.  Часто кращим часом для скальпування виявляється відкриття Лондона (11:00 МСК) або Нью-Йорка (16:00 МСК), тому що в цей час пари валюти починають рухатися в одному напрямку.
  3.  Коли ціна перетинає всі три індикатори, ви відкриваєте свою угоду, довгу або коротку. Якщо ціна проходить 100 EMA вниз, входите в коротку, якщо ціна перетинає 100 EMA вгору в довгу.
  4.  Переконайтеся, що у вас є 5-10 піпсов прибутку. Це $ 50 - $ 100 доларів на регулярному рахунку, більше, якщо ви купили більше лотів. Не намагайтеся занадто довго утримувати виграшну позицію, тому що ціна може відкотитися назад і ви можете втратити гроші. Візьміть 5-10 піпсов прибутку, як тільки зможете. Ось приклад на 1-хвилинному графіку (рис. 9).

Рис. 9. Робота на 1-хвилинному графіку

Зауважте, що на 10:30 (на графіку час EST – це 18:30 МСК) ви могли б увійти в довгу позицію по USD / JPY (велике коло), коли ціна перетнула 100 EMA вгору, а о 10:45 ви могли б закрити свою позицію (маленький коло) і взяти 10 піпсов прибутку. Потім ціна перетнула 100 EMA вниз в 11:30 EST. Ви могли б продати ієну (велике коло) і десятьма хвилинами пізніше зробити ще 10 піпсов прибутку (маленький круг).

Тепер, коли ви знаєте, як працює FPS, вам слід знайти онлайн-брокера Forex, який надає безкоштовні демонстраційні торгові рахунки. Тут ви можете застосувати систему FPS, не ризикуючи реальними грошима.

Тепер все в ваших руках. У вас в руках є інструменти для роботи, і ви можете практикувати все, що хочете, на демонстраційному рахунку. Коли ви відчуєте себе готовим, побачите, що торгуєте з прибутком, саме час відкривати реальний рахунок.

Торговий метод «Forex Profit» розроблений на основі трендових індикаторів EMA (експоненціальна змінна середня) і Porabolic Sar. Для торгівлі підходить період графіка M15, однак, чим вище аналізований період, тим менше вірогідність виникнення помилкових торгових сигналів. Розглянемо варіанти укладання угод на прикладі валютної пари EUR / USD .

Отже, розміщуємо на ціновому графіку такі індикатори Forex: EMA 10 червоного кольору, EMA 25 (жовтий колір), EMA 50 (синій колір), Porabolic Sar з оригінальними налаштуваннями. Тепер, звернемо увагу на рис. 10, який вказує на розвиток висхідної тенденції, судячи по розташуванню ковзних середніх і Porabolic Sar, який формується знизу від ціни. Таким чином, при невеликому ціновому відкат на максимумі свічки потрійного перетину ліній укладають угоду на покупку. Захисний Stop Loss завжди нижче EMA 50, закриття угоди може здійснюватися або по Take Profit, або в результаті пробою ціною EMA 50, як в даному прикладі.

Рис. 10. Висхідна тенденція

При наявності зворотного розташування ковзних і Porabolic Sar (рис. 11) на мінімумівідкатної свічки слід укладати угоду на продаж. Stop Loss – вище EMA 50, закриття угоди відбувається при пробої ціною знизу вгору EMA 50.

Рис. 11. Нисхідна тенденція

Прибутковість даної торгової системи залежить від дотримання чітких правил та умов для укладання угод.

Недоліки:

  1.  десктопний програмний продукт;
  2.  мінлива поведінка індикаторів при короткостроковій торгівлі (часте відкриття та закриття угод).


3. ОБГРУНТУВАННЯ ВИБОРУ ТЕХНОЛОГІЙ ДЛЯ РОЗРОБКИ ПРОГРАМНОГО ПРОДУТУ

3.1. PHP

PHP – «Інструменти для створення персональних веб-сторінок») – скриптова мова  програмування загального призначення, інтенсивно застосовується для розробки веб-додатків. В даний час підтримується переважною більшістю хостинг-провайдерів і є одним з лідерів серед мов програмування, що застосовуються для створення динамічних веб-сайтів.

Мова та її інтерпретатор розробляються групою ентузіастів в рамках проекту з відкритим кодом. Проект поширюється під власною ліцензією, несумісною з GNU GPL [9]. 

У області програмування для мережі Інтернет PHP – один з популярних скриптових мов (разом з JSP, Perl і мовами, використовуваними вASP.NET) завдяки своїй простоті, швидкості виконання, багатій функціональності, платформ і розповсюдженню початкових кодів на основі ліцензії PHP.

Популярність у галузі побудови веб-сайтів визначається наявністю великого набору вбудованих засобів для розробки веб-додатків

Переваги:

  1.  автоматичне вилучення POST і GET-параметрів, а також змінних оточення веб-сервера в зумовлені масиви;
  2.  взаємодія з великою кількістю різних систем управління базами даних (MySQL, MySQLi, SQLite, PostgreSQL, Oracle (OCI8), Oracle, Microsoft SQL Server, Sybase, ODBC, mSQL, IBM DB2, Cloudscape і Apache Derby, Informix, Ovrimos SQL, Lotus Notes, DB + +, DBM, dBase, DBX, FrontBase, FilePro, Ingres II, SESAM, Firebird / InterBase, Paradox File Access, MaxDB, Інтерфейс PDO);
  3.  автоматизована відправка HTTP-заголовків;
  4.  робота з HTTP-авторизацією;
  5.  робота з cookies і сесіями;
  6.  робота з локальними і віддаленими файлами, сонетами;
  7.  обробка файлів, що завантажуються на сервер;
  8.  робота з XForms.

В даний час PHP використовується сотнями тисяч розробників. Згідно з рейтингом корпорації TIOBE, що базується на даних пошукових систем, у квітні 2011 року PHP знаходився на 5 місці серед мов програмування. До найбільших сайтів, які використовують PHP, відносяться Facebook, Вконтакте, Wikipedia та ін

Входить в LAMP – поширений набір програмного забезпечення для створення та хостингу веб-сайтів (Linux, Apache, MySQL, PHP).

Створення GUI-додатків

Хоча PHP і не дуже поширений в даній якості, його можна використовувати і для створення GUI-додатків.

Для створення кроссплатформенних програм служать пакети PHP-GTK і PHP-Qt, що представляють собою обгортки для відповідних популярних бібліотек віджетів.

Рис. 12. Скріншот редактора форм WinBinder

Для тих, кого цікавить програмування з використанням Windows API існує дві альтернативи. По-перше це open source пакет WinBinder. Його ядро являє собою написане на C розширення phpphp_winbinder.dll. До складу WinBinder включений також візуальний редактор форм (рис. 13), написаний з використанням самого WinBinder. Але, по суті, WinBinder є простою обгорткою до WinAPI і програмування з його використанням – досить низькорівневе.

Рис. 13. Середовище програмування DevelStudio

Другий альтернативою є інтегрована середовище Devel Studio, орієнтована, перш за все, на початківців програмістів.

Різні частини DevelStudio поширюються під різними ліцензіями. Інтерфейс до графічних і системним можливостям Windows являє собою ряд модулів розширення PHP, і являетсяпропріетарним ПЗ, поширюваним у вигляді скомпільованих DLL на умовах freeware. (Автори планують також випуск платній Pro версії DevelStudio, в якій набір таких, базових, бібліотек буде ширше).

Поверх цих розширень існує написана на PHP відкрита бібліотека компонентів, яка, разом сIDE, також написаному на PHP, поширюється на умовах GPL. Разом вони утворюють середовище візуального програмування з Delphi-подібної архітектурою. Програміст може розширювати DevelStudio власними, написаними на PHP компонентами, які, можливо, будуть використовувати функціонал написаних ним, або ким то іншим, додаткових бінарних розширень PHP. DevelStudio включає засоби упаковки і установки таких пакетів.

Для роботи DevelStudio додатків необхідний також soulEngine.exe – міні-сервер, що запускає веб-додатки (використовує php5ts.dll версії 5.2). Він також написаний на PHP, і ліцензується на умовах BSDL.

Для програмування під Windows можна також використовувати Phalanger – реалізацію PHP для платформи. NET. Результатом компіляції PHP коду в Phalanger може бути будь-який .NET-додаток, будь то серверне ASP.NET або десктопной Windows Forms / Windows Presentation Foundation (WPF)

Недоліки

Неузгоджені синтаксис функцій і не ортогональних

PHP надає розробникам велику кількість найрізноманітніших функцій, які потрапили в мову з розширень, створюваних різними групами програмістів. У результаті синтаксис мови не узгоджений, наприклад, частина функцій для роботи з масивами починається з префікса array_, інша частина цим префіксом не володіє. Назви частини строкових функцій починається з префікса str, інші функції таким префіксом не володіють. У тих же строкових функціях оброблювана рядок може передаватися як в якості першого, так і в якості останнього аргументу, що викликає плутанину у програмістів, і, отже, вимагає постійного звернення до документації. Деякі завдання, наприклад, розбиття рядка на масив або підрядка, вирішуються кількома функціями.

Інша причина відсутності ортогональності в PHP полягає в особливостях появи цієї мови на світло. На відміну від переважної більшості інших мов програмування, PHP не був спочатку задуманий як повноцінна мова програмування, а поступово виріс із шаблонізатора для Perl. Це призвело як до появи в первинному варіанті мови деяких спірних рішень, так і до відсутності контролю з боку творця мови, який би стежив за стрункістю його архітектури.

Відсутність зворотної сумісності між версіями мови

Код, створений для більш ранніх версій мови, часто не працює або працює некоректно з більш пізніми версіями мови. У більш пізніх версіях виключаються конструкції, методики, функції, що застосовувалися раніше. В результаті, додатки, створені кілька років тому, практично втрачають працездатність для сучасних версій мови і вимагають значної модифікації. Такі зміни зумовлені двома факторами: усуненням неузгодженого синтаксису і усуненням конструкцій, що заохочують створення небезпечного коду.

У нових версіях лінійки 5.3.x велику кількість функцій було визнано застарілими, їхня підтримка не планується в нових версіях мови , що викликає несумісність зі скриптами, які використовують застарілі функції. Також для версії 5.3 на даний момент відсутня програмне забезпечення Zend Optimizer. Однак розробники планували випустити його в 2010 році

Треба зазначити, що протиріччя між зворотною сумісністю і процесом розвитку – одна з ключових проблем в розробці програмного та апаратного забезпечення. При роботі надскріптовимі мовами час від часу відбувається різка зміна його архітектури (а часом і парадигми), що зазвичай супроводжується зміною першої цифри в номері версії. Так, в даний час йде поступовий перехід на нову гілку мови Python – 3.x, у стадії тестування знаходиться Perl 6, що є, по суті, новим perl-подібним мовою. При цьому прийнято випускати перехідні версії, в яких поступово вводяться нові конструкції, а використання застарілих викликає висновок попереджень. До таких перехідним версіями відноситься і PHP 5.3.

Відсутність підтримки мультибайтних символів в ядрі мови

Підтримка рядків з мультибайтних кодуваннями, такими як UTF-8 реалізується через окреме розширення mbstring, на рівні ядра підтримка відсутня, проте з виходом версії 5.4 підтримка мультібайтових рядків реалізована у всіх стандартних функціях роботи з рядками, без префікса mb_

Відсутність підтримки багато поточності

У мові не передбачена можливість створення багатопоточних додатків і відсутня підтримка синхронізованого доступу до ресурсів, однак це можна реалізувати за допомогою розширення PCNTL.

3.2. Adobe Flash

Flash – продукт компанії «Macromedia», що дозволяє розробляті інтерактівні мультімедійні програм. Сфера використання Flash різна, Це можут буті ігри, веб-сайти, презентації, банер и простомультфільмі. При створенні продукту можна вікорістаті медіа, звукові та графічні файли, можна створюваті інтерактівні інтерфейсі та повноцінні веб-програми Із використання PHP та XML.

Adobe Flash – це середовище для створення застосунків під Flash платформу (Flash Platform), разом з нею існують й інші інструменти (середовища): Adobe Flex Builder, Flash Development Tool (FDT), та інші.

Flash-файли мают розширення. Swf и для переглядання вімагають наявності Adobe Flash Player, Що Може буті встановлених Як плагін у браузер. Flash Player пошірюється безплатно через сайт Adobe. Вихідні файли з розширенням .fla створюються в середовіщі Розробка Macromedia Flash, а потім компілюються в зрозумілій для Flash Player формат – .Swf.

В Основі Flash лежить векторний морфінг, тобто плавні «перетікання» одного ключового кадру в інший. Це дозволяє робіті Досить складні мультіплікаційні сцени, задаючі Лише кілька ключовими кадрів для шкірного персонажа.

Другий «кит» Flash'а – Повна програмованість. Flash вікорістовує мову програмування ActionScript, яка за синтаксисом є схожу на JavaScript. Остання версія мови (ActionScript 3.0) є повноцінною об'єктно-орієнтованою мовою.

Порівняно з іншімі плагінамі, такими як Java, Acrobat Reader, QuickTime або Windows Media Player, Flash Player має достатності малий Розмір файлу інсталяції, малий годину завантаження та ініціалізації. Альо потрібно пріділіті Увага, додаючі Flash об'єкт до (X) HTML Відповідно до Вимоги W3C. Простий и найпошіренішій Спосіб наведено нижче:

<object data="movie.swf" type="application/x-shockwave-flash" width="500" height="500">

<param name="movie" value="movie.swf" />

</ Object>

Використання векторної графікі разом з програмним кодом забезпечує малі розмірі файлів Flash, що надає можлівість економити трафік и зменшити час завантаження сторінки. Для відображення тексту, відео альтернативні додатки можут надаті кращу продуктівність и спожити менше ресурсів процесора ніж Flash-об'єкти.

На додаток до рушія побудова векторної графікі, Flash Player включає віртуальну машину, Що має назву ActionScript Virtual Machine (AVM) для Створення механізму бізнес-логіки додатка годині виконання, підтрімку відео, MP3 аудіо, графікі формату BMP. Починаючим з версії 8, введена Підтримка двох відео кодеків: On2 Technologies VP6 и Sorenson Spark, а кож Підтримка годині виконання формату JPEG, Progressive JPEG, PNG и GIF. А починаючих з наступної версії, введена Підтримка компіляції на льоту для мови ActionScript.

Існують 3D рушії, Що використовуються Як основу Flash. Їхня швідкість и Якість роботи Досить низько. Основна причина цього – неможлівість вікорістовуваті засоби DirectX або OpenGL, тому віконується Повна емуляція всіх 3D-алгорітмів. Немає підтрімкі апаратного прискорення, багатоядерніх процесорів, Що кож зніжує швідкість роботи рушія. Зараз відбувається деяки поліпшення в ЯКОСТІ й швідкості роботи 3D, Тому що сама Adobe включила застосування 3D-ефектів у новому Adobe Flash Player 10.

Papervision3D (англ.)найвідомішій Open Source рушій.

Away3D (англ.) – Створення Олександром Задорожним з Києва на Основі проекту Papervision3D. У цею момент – Провідний Open Source рушій. Кож векторні промальовування.

FFilmation AS3 Flash Isometric Engine (англ.) – Ізометрічній рушій. Open Source.

Ігрова платформа Alternativa Platform (рос.) – Платформа для трівімірніх Ігор, розроблювана групою з Пермі. За флеш відповідає Антон Волков. Векторні промальовування по трикутнику. На даній платформі створена гра Танки Онлайн.

Недоліки

Головний недолік Flash-додатків – надмірна вімоглівість до ресурсів процесора. Недостатня потужність комп'ютера може впліваті на продуктівність операційної системи вцілому, або прізвесті до вікрівлення результатів роботи Flash-додатка, пов'язаних з відображенням анімації або підрахунком годині. Іноді це пов'язано з недолікамі програмного забезпечення, відповідального за обробка Flash-компонентів, або низько якістю самого Flash-додатка.

Інший недолік полягає в важливими тому, що не завжди є можлівість запустіті Flash-додаток, або вон пов'язана з деяки труднощамі (наприклад, необхідно встановити плагін або обновіті йо до останньої версії). Деякі корістувачі (або сістемні адміністраторі в платформах цілої Мережі) відключають у налаштуваннях браузера можлівість завантажуваті контент, оброблюваній плагінами або, що завантажується у фреймах з метою інформаційної безопасности (у зв'язку з можливого загроза з боку контенту, наприклад, перехоплення буфера обміну), економії системних ресурсів, або для порятунку від обрідлої реклами.

Це робіть технологію в цілому ненадійною кож для розробніків, яким Ніхто не гарантує, що веб-додаток на основі Flash буде взагалі відтворено. Тому Flash, в основному, вікорістовується для написання ігор, невеликих напівінтерактівніх анімацій и для красиво оформленої реклами, тобто в сфері розваг и дизайну. Для серйозніх веб-додатків, де взаємодія з користувачем повинна буті без шкоди красі, звичайна вікорістовується Javascript, або взагалі не використовуються ніякі технології крім тих, що 100% працюють (HTML, CGI).

В інтернеті можна знайте сайти, повністю оформлені у вігляді Flash-додатка (увесь контент, а кож Елементи навігації). Зазвічай це сайти, що прісвячені іграм, дізайнерські студії, особісті сторінки та інші сайти, метою яких є вразити відвідувача красою й незвічайністю реалізації. Великі порталу ї Інформаційні ресурси намагаються унікаті використання Flash (за винятком вставки рекламних банерів, неможлівість виводу якіх не викликає незручностей для користувачів).

Використання Flash для розміщення текстової інформації перешкоджає її індексуванню пошуково системами. Однак існує безліч способів розв'язати цю проблему. Одним зі способів розв'язку даної проблеми є використання тексту у форматі HTML, у футері сторінки.

3.3. Spring Framework

Spring Framework володіє наступними особливостями:

  1.  Простота і потужність: у той час як простота використання є однією з основних особливостей Spring Framework, досягнута була вона без найменшої втрати можливостей. Хорошим прикладом є Spring JDBC: у той час як надано можливість виконувати запити до бази даних взагалі без використання JDBC API, у той же час можливо звернутися до будь-якої функції цього інтерфейсу без втрати переваги у вигляді автоматичної обробки помилок. Можливо навіть використовувати без втрат розширення, властивою тільки однієї конкретної бази даних – особливість, яку важко виконати без Spring Framework.
    1.  Гнучкість: замість використання монолітного підходу, Spring містить кілька модулів, які незалежні один від одного. Завдяки цьому можливе використання цього фреймворку тільки в тих частинах реалізованої системи, де це принесе найбільшу користь, і він може бути впроваджений крок за кроком, а не разом, як це буває у випадку серверів додатків.
      1.  Вибір: ця особливість характеризує, що немає нічого в світі універсального, яке може бути використане у всіх випадках життя. Spring Framework не вимагає від розробника використовувати якогось специфічного продукту або технології. Наприклад, підтримується робота з більшістю існуючих фреймворків працюють з базами даних (JDBC, JPA, Hibernate, JDO, Apache OJB та інших). Аналогічно в області веб можливо як використання продукту, запропонованого самим Spring, так і інших широко використовуваних продуктів: JSF, Struts, Tapestry, WebWork. Spring також пропонує різні підходи до конфігурації програм: від використання конфігураційних XML файлів до використання Java анотацій.

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

Рис. 14. Архітектура Spring Framework

Архітектура Spring Framework створена для використання простих об'єктів (simple objects). Часто в світі Java ці об'єкти також мають назву прості старі java об'єкти (plain old java objects або POJO). Основною особливістю цих об'єктів є незалежність від будь-то не було технології. Незалежність від технології є відомим правилом хорошого стилю в розробці програмного забезпечення. У цьому є наступні переваги:

  1.  Розроблена на основі простих об'єктів бізнес логіка не змінюється в разі зміни технології, тобто зберігаються інвестиції в програмний код. Наприклад, якщо прийнято рішення перенести додаток на нову платформу або новий сервер додатків, немає необхідності переписувати реалізовану бізнес логіку.
    1.  Розробники можуть сконцентровані на реалізації функцій бізнес логіки, замість того щоб постійно мати справу з технологіями сервера додатків або аналогічних продуктів. У результаті реалізація бізнес логіки, а з нею і всього проекту йде набагато швидше.
      1.  Тестування функціональності може відбуватися ізольовано від оточення. Замість того, щоб розгортати оточення відтворює умови реальної експлуатації, всі виклики службових сервісів оточення можуть бути замінені якимись «заглушками», що імітують реальні служби, але істотно простіше. Це дозволяє швидше тестувати створені програми та моделювати виняткові ситуації, які в інших підходах до реалізації бізнес логіки вкрай важко відтворити.
      2.  Очевидно, проте, що система для того, щоб мати можливість працювати, все одно повинна мати якесь оточення. У Spring Framework є три відмітних особливості, які дозволяють створення додатків з простих об'єктів:
      3.  Конфігурування залежностей (dependency injection-DI або inversion of control-IoC) означає, що взаємодіючі об'єкти не зашиті і не жорстко задаються на етапі програмування, а конфігуруються. Таким чином, об'єкти не залежать від будь-якої технології та Spring Framework забезпечує необхідні взаємозв'язки. Завдяки цьому на етапі тестування не складає труднощів замінити деякі залежні від нижчого шару об'єкти заглушками.
      4.  Аспектно-орієнтоване програмування – АОП (Aspect Oriented Programming або AOP) є парадигмою розробки програмного забезпечення, яка існує і перевіреної протягом більше 10 років, для додавання в код таких аспектів як безпека, транзакційна цілісність, логгінг та ін Без АОП кожен метод в коді, який реалізує бізнес-логіку, повинен був би доповнений такими аспектами і тому бути залежним наприклад від технології транзакционной цілісності. Крім того, важко супровід такого коду, тому що зміни повинні бути зроблені у всіх місцях, де йде звернення до бази даних. Використовуючи АОП весь код, який реалізує такі аспекти може бути розташований в одному місці. Бізнес логіка таким чином відокремлена від сервісного, технологічного коду.
      5.  Абстракція сервісів (Enterprise Service Abstraction) дозволяє використання загальноприйнятих API таких як JDBC або JMS істотно спрощеним і менш схильним до помилок чином. Зазвичай навіть найпростіші завдання, такі як запит до бази даних або надсилання повідомлення через JMS займає не менше 10 рядків коду. Таким чином обробка помилок стає не зовсім тривіальним завданням, деякі навчальні посібників навіть не стосуються цієї теми. Абстракція сервісів, існуюча в Spring Framework дозволяє значно спростити цю задачу і дозволяє розробник виконувати запити до бази даних або посилати повідомлення через Spring Framework буквально одним рядком коду, при цьому фреймворк бере на себе обробку помилок уніфікованим, де можливо чином – наприклад, всі помилки, генеруються різними серверами баз даних трансформуються в єдину ієрархію винятків (exceptions).

Завдяки таким достоїнствам Spring Framework як гнучкість і можливість вибору, кожна з цих відмітних особливостей може бути використана без застосування інших [2, 5, 15, 14].

Spring Framework не можна порівнювати з Java EE. У той час як Java EE визначає платформу реалізовану сервером додатків, Spring Framework визначає модель програмування, яка може бути реалізована як на Java EE платформі, так і на інших. Звичайно, в Java EE існує своя модель програмування теж, але вона ме може запропонувати такий рівень абстракції як Spring.

EJB спочатку був призначений як кращий варіант реалізації бізнес логіки в додатках Java EE. Але досвід практичного використання показав, що краще уникати застосування як EJB 1.x, так і EJB 2.x – зокрема цей підхід пропагував засновник Spring Рід Джонсон у своїй книзі «J2EE without EJB". Вже назва книги означає, що J2EE сам по собі розумний підхід. Spring Framework навіть включає можливість використання простих об'єктів як EJB, так само як і використання EJB схожим чином як прості об'єкти.

Таким чином видно, що EJB до цих пір не відповідає Spring Framework по своїм можливостям в областях, описаних вище і крім того містить інші недоліки. Наприклад, код системи, написаний з використанням EJB тісно пов'язаний зі специфічних API і оточенням, яким є сервер додатків. Оскільки Spring Framework підтримує значну частину програмної моделі EJB 3.x виникає питання навіщо взагалі навіть розглядати використання EJB, коли Spring пропонує більшу кількість можливостей, причому відсутні недоліки властиві EJB.

Проте якщо в результаті було вирішено використовувати EJB, код з використанням Spring може без проблем бути інтегрованим в проект.

Недоліки:

EJB спочатку був призначений як кращий варіант реалізації бізнес логіки в додатках Java EE. Дана система була створена, щоб підлаштоввуватися до існуючого рішення

3.4. Java Server Faces

JavaServer Faces (JSF) – це каркас програмування, технологія для веб-застосунків, що написані на Java. Він служить для того, щоб полегшувати розробку користувацьких інтерфейсів для Java EE застосунків. На відміну від більшості MVC фреймворків, які керуються запитами, підхід JSF ґрунтується на використанні компонентів. Стан компонентів користувацького інтерфейсу зберігається, коли користувач запитує нову сторінку й потім відновлюється, якщо запит повторюється. Для відображення даних звичайно використовується JSP, але JSF можна пристосувати й під інші технології, наприклад XUL.

Переваги:

  1.  генерація серверної частини інтерфейса користувача;
  2.  базується на компонентах(ніякого HTML);
  3.  наявна обробка подій(event) та станів(states);
  4.  різноманітні view-технолгії – не тільки HTML та JavaScript;
  5.  розробка з урахуванням доступного інструментарію;
  6.  наявний стандарт і він включений до Java EE;
  7.  рольова модель розробки веб.

Недоліки:

  1.  потрібно багато часу для вивчення та освоєння технології;
  2.  повинні потужні обчислювальні можливості серверу;
  3.  обмежені можливості.

Користь технології JSF обумовлена, в першу чергу, наявністю специфікації JSF. Специфікація дозволяє розробляти JSF фреймворки з різним призначенням та різною внутрішньою структурою. Вона лиш гарантує, що фреймворк буде підпорядкований певній структурі. Але з іншого боку специфікація дуже обмежує еталонну реалізацію в освоєнні нових можливостей. Тобто наприклад ajax-технології такі як Ajax4JSF включають дуже багато інтеграційного коду який виникає через потребу в узгодженні еталонної реалізації з основними вимогами специфікації. Можна відмітити, що сама специфікація розроблена досить неоднорідно. Плюсами специфікації є: дерево компонентів, підтримка різних технологій представлення(JSP, Facelets), підтримка різноманітних рендерерів – класів, що відповідають за відображення компоненту, підтримка обробки подій і перевіркою інформації, що вводиться, визначення навігації, а також підтримку інтернаціоналізації (і18n) і доступності (accessibility). Але є й недоліки: дуже великий обсяг коду для реалізації ітераційних компонентів, відсутності обробки повідомлень в середині ітераційного компоненту, великий обсяг шаблонного коду, який можна було б опустити, при реалізації власних компонентів(custom component), непродуманість певних архітектурних рішень в специфікації, щодо реалізації ajax, управління станом дерева компонентів, пошуку по дереву компонентів [3, 4, 16, 17].

Еталонна реалізація.

Група експертів підтримує в актуальному стані еталонну реалізацію(reference implementation) JSF. Це дозволяє, як використовувати її в реальних веб-застосунках, так і розвивати інші реалізації конкурентів. Гарними сферами застосування еталонної реалізації JSF є корпоративні веб-сайти, та маленькі веб-сайти, на зразок веб-магазину. Для великих веб-сайтів з великою кількістю компонентів JSF не підійде. Це обумовлено тим що еталонна реалізація має деякі проблеми, що пов'язанні із надлінійним зменшенням швидкодії при збільшенні компонентного дерева. Різні експерти пов'язують це з непродуманість підсистеми збереження стану та з непродуманістю системи зв'язування компонентів.

За специфікацією реалізація JSF повинна підтримувати багато різноманітних точок розширення, що дозволяють змінити поведінку JSF-застосунку. Такими точкам розширення є: 5 етапів циклу обробки запиту(JSF life cycle), навігаційна логіка(navigation handler), абстрактна система інтерпретації виразів(EL) JSF. Також розробнику веб-застосунків дозволяється розробляти свої компоненти, свої рендерери, валідаційні компоненти, компоненти перетворювачі, будувати дерева компонентів програмним шляхом. Це все свідчить на користь того, що JSF являє собою вельми абстрактну платформу для реалізації різноманітних веб-застосунків, але певні перепони із швидкістю заважають використовувати її в великих веб-проектах, що мають певні вимоги по швидкості виконання запитів.

3.5. Model-view-controller

Моде́ль-вид-контро́лер – архітектурний шаблон, який використовується під час проектування та розробки програмного забезпечення.

Цей шаблон поділяє систему на три частини: модель даних, вигляд даних та керування. Застосовується для відокремлення даних (модель) відінтерфейсу користувача (вигляду) так, щоб зміни інтерфейсу користувача мінімально впливали на роботу з даними, а зміни в моделі даних могли здійснюватися без змін інтерфейсу користувача.

Рис. 15. Шаблон Модель-Вид-Контролер

Мета шаблону – гнучкий дизайн програмного забезпечення, який повинен полегшувати подальші зміни чи розширення програм, а також надавати можливість повторного використання окремих компонент програми. Крім того використання цього шаблону у великих системах призводить до певної впорядкованості їх структури і робить їх зрозумілішими завдяки зменшенню складності [10, 17].

Архітектурний шаблон Модель-Вид-Контролер (MVC) поділяє програму на три частини. У тріаді до обов'язків компоненту Модель (Model) входить зберігання даних і забезпечення інтерфейсу до них. Вигляд (View) відповідальний за представлення цих даних користувачеві. Контролер (Controller) керує компонентами, отримує сигнали у вигляді реакції на дії користувача, і повідомляє про зміни компоненту Модель. Така внутрішня структура в цілому поділяє систему на самостійні частини і розподіляє відповідальність між різними компонентами.

MVC поділяє цю частину системи на три самостійні частини: введення даних, компонент обробки даних і виведення інформації. Модель, як вже було відмічено, інкапсулює ядро даних і основний функціонал з їх обробки. Також компонент Модель не залежить від процесу введення або виведення даних. Компонент виводу Вигляд може мати декілька взаємопов'язаних областей, наприклад, різні таблиці і поля форм, в яких відображається інформація. У функції Контролера входить моніторинг за подіями, що виникають в результаті дій користувача (зміна положення курсора миші, натиснення кнопки або введення даних в текстове поле).

Зареєстровані події транслюються в різні запити, що спрямовуються компонентам Моделі або об'єктам, відповідальним за відображення даних. Відокремлення моделі від вигляду даних дозволяє незалежно використовувати різні компоненти для відображення інформації. Таким чином, якщо користувач через Контролер внесе зміни до Моделі даних, то інформація, подана одним або декількома візуальними компонентами, буде автоматично відкоригована відповідно до змін, що відбулися.

3.6. AJAX

AJAX – підхід до побудови користувацьких інтерфейсів веб-застосувань, за яких веб-сторінка, не перезавантажуючись, у фоновому режимі відправляє запити на сервер і сама звідти довантажує потрібні користувачу дані. AJAX – один з компонентів концепції DHTML.

AJAX підхід до розробки призначених для користувача інтерфейсів комбінує кілька основних методів і прийомів:

  1.  використання DHTML для динамічної зміни змісту сторінки;
  2.  використання XMLHttpRequest для звернення до сервера «на льоту», не перезавантажуючи всю сторінку повністю;
  3.  альтернативний метод – динамічне підвантаження коду JavaScript в тег <SCRIPT> з використанням DOM, що здійснюється із використанням формату JSON;
  4.  динамічне створення дочірніх фреймів.

Використання цих підходів дозволяє створювати набагато зручніші веб-інтерфейси користувача на тих сторінках сайтів, де необхідна активна взаємодія з користувачем. AJAX – асинхронний, тому користувач може переглядати далі контент сайту, поки сервер все ще обробляє запит. Браузер не перезавантажує web-сторінку і дані посилаються на сервер без візуального підтвердження (крім випадків, коли ми самі захочемо показати процес з’єднання з сервером). Використання AJAX стало найбільш популярне після того, як компанія Googleпочала активно використовувати його при створенні своїх сайтів, таких як Gmail, Google Maps і Google Suggest. Створення цих сайтів підтвердило ефективність використання даного підходу.

Класична модель веб-застосування:

  1.  Користувач заходить на веб-сторінку і натискає на який-небудь її елемент.
  2.  Браузер надсилає запит серверу.
  3.  У відповідь сервер генерує повністю нову веб-сторінку і відправляє її браузеру і т. д.

З боку сервера можлива генерація не всієї сторінки наново, а тільки деяких її частин, з подальшою передачею користувачу.

Модель AJAX:

  1.  Користувач заходить на веб-сторінку і натискає на який-небудь її елемент.
  2.  Браузер відправляє відповідний запит на сервер.
  3.  Сервер віддає тільки ту частину документа, яка змінилася.

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

AHAH (Asynchronous HTML and HTTP) – це споріднений AJAX підхід для динамічного оновлення веб-сторінок, використовуючи JavaScript. Основною його відмінністю від AJAX є те, що відповіді сервера повинні бути звичайним HTML. Перевага підходу полягає в більшій сумісності і функціональності (підтримка навігаційних кнопок браузера, аплоад файлів тощо). Реалізується у вигляді звичайних фреймів, що автоматично міняють свій розмір під розмір вмісту, або у вигляді прихованих фреймів, що виконують тільки функції завантаження даних [11].

Asynchronous XHTML and HTTP, або абревіатура AXAH – це майже те ж саме що і AHAH. Різниця тільки в тому, що в AHAH сервер клієнтові повертає HTML, а в AXAH вже XHTML.

3.7. Enterprise JavaBeans

Enterprise JavaBeans – специфікація технології написання та підтримки серверних компонентів, що містять бізнес-логіку. Є частиною Java EE.

Рис. 16. Проста архітектура EJB

Ця технологія зазвичай застосовується, коли бізнес-логіка вимагає як мінімум один з таких сервісів, а часто всі з них:

  1.  підтримка збереження даних (persistence); дані повинні бути в цілості навіть після зупинки програми, найчастіше досягається за допомогою використання бази даних;
  2.  підтримка розподілених транзакцій;
  3.  підтримка конкурентного зміни даних і багато поточність;
  4.  підтримка подій;
  5.  підтримка іменування і каталогів (JNDI) ;
  6.  безпека і обмеження доступу до даних;
  7.  підтримка автоматизованої установки на сервер додатків;
  8.  віддалений доступ.

Кожна EJB компонента є набором Java класів зі строго регламентованими правилами іменування методів. Існує три основних типів:

  1.  об'єктні (Entity Bean);
  2.  сесійні (Session Beans), які бувають без стану (stateless), і з підтримкою поточного стану сесії (stateful) ;
  3.  керовані повідомленнями (Message Driven Beans) – їх логіка є реакцією на події в системі.


4. СТРУКТУРНІ ТА ПРОГРАМНІ ОСОБЛИВОСТІ РОЗРОБЛЕНОГО ПРОГРАМНОГО ПРОДУКТУ

4.1. Загальна характеристика програмного продукту

На малюнку показано взаємодію платформи JSF з клієнтською та серверною частинами. Також наведено інструменти дзя зв’язку рівнів візуального представлення, прикладної логіки та бізнес-логіки web-застосунку.

Рис. 17. Загальна структура програмного продукту

Ось найбільш важливі послуги, які забезпечує програмний продукт:

  1.  Архітектра модель-вигляд-контролер всі програмні додатки дозволяють користувачам маніпулювати певними даними, наприклад, журнал всіх дій, або всі дані, необхідних у конкретній предметній області. Ці дані називається моделлю. Подібно до того, як художники створюють картини моделі в студії, веб-додаток відображає вигляд моделі даних. JSF з'єднує представлення та модель. Як ви бачили, компонент подання може бути підключений до біна об'єкта моделі таким чином: <h:inputText value="#{user.name}"/> Реалізація JSF працює як контролер, який реагує на дії користувача, обробляючи налідки цих дій та дій по зміні значень, а потім відправляє отримані результати в код, який обновляє модель або вид. Наприклад, потрібно викликати метод, який перевіряє, чи дозволено перному кристувачу вхід в систему. Для цього використано JSF тег:  <h:commandButton value="Login" action="#{user.check}"/> Коли користувач натискає на кнопку і форма передається на сервер, викликається метод check біна user. В данному методі виконуються всі необхідні дії по оновленню моделі, після чого повертається ідентифікатор наступної сторінки. Таким чином, програмний продукт реалізує модель-подання-контролер архітектури.
  2.  Перетворення даних. Користувачі вводити дані у веб-форми у вигляді тексту. Для бізнес-об'єктів дані мають бути представлені у вигляді чисел, дат та інших типів даних. Розроблена система дозволяє легко ставити і настроювати правила перетворення.
  3.  Перевірка та обробка помилок. Програмний продукт виконує ряд перевірок таких, як "це поле обов’язкове для заповнення" або "в цьому полі мають бути тільки числа". Звичайно, коли користувач вводить неправильні дані, відображається відповідне повідомлення про помилку.
  4.  Інтернаціоналізація. Платформа дозволяє вирішити такі проблеми інтернаціоналізації, як проблем из кодуванням.
  5.  Компоненти користувача. Розробники створюють складні компоненти, а дизайнери їх просто додають до контенту сторінки за допомогою простого тегу. Нижче наведено приклад тегу, який додає календар: <acme:calendar value="#{flight.departure}" startOfWeek = "Mon"/>
  6.  Клієнтська чатина продукту включає в себе підтримку Ajax. Клієнтська частина за домогою Ajax непомітно для користувача виклика серверні дії та оновлює сторінки користувача.

4.2. Внутрішні процеси

Реалізація ініціалізує код і читає index.xhtml сторінки. Ця сторінка містить теги, такі як h:InputSecret і h: InputText. З кожним тегом звязаний клас обробника тега. При читанні сторінки, виконуються обробники тегів. Обробники тегів співпрацюють один з одним для створення дерева компонентів (див. рис 18).

Рис. 18. Приклад дерева тегів

Дерево компонентів – структура даних, яка містить Java-об'єкти для всіх користувачів елементів інтерфейсу на сторінці.

Далі відбувається візуалізація HTML сторінки. Весь текст, який не місить JSF-теги пропускається. Теги h:Form, h: InputText, h: inputSecret і h: CommandButton перетворюються в HTML. Кожен з цих тегів призводить до створення компонента. Кожен компонент має візуалізації HTML. Наприклад, для візуалізації компонент, який відповідає h: InputText теги виходить наступний результат:

<input type="text" name="unique ID" value="current value"/>

Цей процес називається кодуванням. Модуль візуалізації обєкта UIInput робить запит для пошуку унікального ідентифікатора і поточного значення виразу user.name. За замовчуванням, ID рядка присвоюються реалізацію JSF. Ідентифікатори можуть виглядати досить різноманітно, наприклад, _id_id12: _id_id21. Закодована сторінка відправляється в браузер, і браузер відображає її звичайним чином (рис 19).

Рис. 19. Взаємодія сервера з браузером

4.3. Декодування запитів

Після відображення сторінки в браузері, користувач заповнює поля форми і кліка кнопку «Увійти». Браузер відправляє дані форми назад на веб-сервер, відформатований як POST запит. Це спеціальний формат, який визначається як частина HTTP-протокол. POST запит містить URL виду (/ login / faces / index.xhtml), а також дані форми.

Дані форми мають вигляд рядока який складаэться з пари «ID / значення», наприклад:

 id1 = me & id2 = secret & id3 = login

У рамках нормальної обробки запиту, дані форми поміщаються в хеш-таблиці куди всі компоненти можуть отримати доступ. Далі, реалізація дає кожному компоненту можливість перегляду хеш-таблиці, і цей процес називається декодуванням. Кожен компонент вирішує сам як інтерпретувати дані форми.

Форма входу має три складові об'єкти: два UIInput об'єкта, які відповідають для текстові поля на формі і один UICommand об'єкт, який відповідає за кнопку відправки.

Рис. 20. Приклад використання декодування

UIInput компоненти оновлюють властивості біна, зазначені у атрибутах значень: вони викликають методи зі значеннями, які користувач надав.

Компонент UICommand перевіряє, чи булла кнопка натиснута. Якщо відбулося натиснення, компонент активує подію по запуску дії login атрибуту action. Ця подія говорить обробнику навігації, що потрібно знайти наступну сторінку, welcome.xhtml.

Далі цикл повторюється. Тим не менш, послідовність обробки (в тому числі називається життєвим циклом) трохи складніше. Якщо все іде добре, не потрібно турбуватися про тонкощі життєвого циклу. Тим не менш, при виникненні помилки потрібно зрозуміти, що реалізація JSF робить.

4.4. Життєвий цикл сторінки

Специфікація програмного продукту визначає шість різних етапів:

1. Відновлення представлення.

2. Прийняття значень запиту.

3. Перевірка правильності процессу.

4. Оновлення значень моделі.

5. Виклик програми.

6. Підготовка відповіді до відображення.

Фаза відновлення (Restore View). Відбувається вибірка дерева компонентів для запитуваної сторінки, якщо вона було показано раніше, або будує нове дерево компонентів, якщо воно з'явиться в перший раз.

Якщо запит не потребує ніяких даних, то программа переходить до фази підготовки відповіді до відображення (Render Restore). Це відбувається, коли сторінка відображається вперше.

В іншому випадку, наступна фаза примінення значень запиту (Apply Request Values). У цій фазі програма перебирає в циклі всі об’єкти компонентів в дереві компонентів.

Рис. 21. Життєвий цикл сторінки

Значення, які у компоненті називають локальними значеннями. Також за сторінкою закріплені засоби перевірки,  які виконують перевірку правильності локальних значень. Ці засоби перевірки виконуються у фазі процесу перевірки. Якщо перевірка проходить успішно, цикл життя продовжується в звичайному режимі. Однак, коли на етапі перетворення або перевірки помилок, виникають якісь помилки, тоді відбувається перехід на етап відображення сторінки і відобража попередню сторінку, щоб дати користувачу можливість ввести дані повторно.

Після того як засоби перетворення та перевірки даних закінчують свою роботу, приймається припущення, що можна без побоювань приступити до оновлення данихмоделі. У фазі оновлення значень моделі (Update Model Values) локальні значення використовуються для поновлення бінов, які прив'язані до компонентів.

У фазі виклику програми (Invoke Application) виконується метод action компонента кнопки або посилання, клацання по якій привів до відправки форми. Цей метод дозволяє здійснювати будь-яку прикладну обробку. Він повертає рядок результату, який передається обробнику навігації. Потім обробник навігації відшукує наступнусторінку.

І нарешті, у фазі підготовки відповіді до відображення відповідь кодується і передається браузеру. Якщо користувач відправляє форму, клацає на посиланні нижче або іншим чином генерує новий запит, весь описаний цикл починається заново.

4.5. Навігація

У більшості веб-додатків навігація не є статичною. Потік сторінок залежить не тільки від того, на якій кнопці виконаний клацання, а й від того, які вхідні дані надані.Наприклад, відправка сторінки входу в систему може йметься два результати: успішний і невдалий. Результат обчислюється в коді і в даному випадку вказує, чи єдопустимими ім'я користувача та пароль.

Для забезпечення динамічної навігації кнопка відправки повинна мати вираз методу (method expression), таке, як

<h:commandButton

label="Login" action="#{loginController.verifyllser}"/>

У даному прикладі loginController посилається на бін деякого класу, а цей клас повинен мати метод verifyUser.

Вираз методу в атрибуті action не має параметрів. Повертається їм тип може бутибудь-яким. Значення, що повертається перетвориться в рядок шляхом викликуметоду toString.

Ось приклад дії методу:

String verifyUser() {

if (...)

return "success";

else

return "failure";

}

Цей метод повертає рядок результату, таку як "success" або "failure", використовувану для визначення наступного подання.

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

  1.  Витяг зазначеного біна.
  2.  Виклик методу, зазначеного на засланні, і повернення рядка результату.
  3.  Перетворення рядка результату в ідентифікатор подання.
  4.  Відображення сторінки, відповідної ідентифікатору подання.

Таким чином, для реалізації поведінки з розгалуженням надається посилання на метод у відповідному класі біна. Існує багато варіантів розміщення цього методу. Найкращий підхід полягає в тому, щоб знайти клас, що має всі дані, необхідні для прийняття рішення.

Відображення результатів у ідентифікатори уявлень

Одна з ключових цілей проектування на основі технології JSF полягає у відділенні рівня подання від рівня бізнес-логіки. Якщо рішення по навігації приймаються динамічно, то в коді, в якому обчислюється результат, не потрібні точні відомості про імена веб-сторінок. Технологія JSF надає механізм відображення логічних результатів, таких як успішне або невдале завершення, у дійсні веб-сторінки.

Це досягається шляхом додавання записів navigation-rule (правило навігації) в файл faces-conf ig. xml. Нижче наведено типовий приклад.

<navigation-rule> <from-view-id> / index.xhtml </ from-view-id> <navigation-case> <f ro(n-outcome> success </ f rom-outcome> <to-view- id> / welcome.xhtml </ to-view-id>

</ Navigation-case> </ navigation-rule>

Згідно з цим правилом, результат success повинен призводити до переходу на сторінку / welcome.xhtml, якщо він виникає під час роботи зі сторінкою / index.xhtml.

Ось приклад:

<navigation-rule>

<from-view-id>/index.xhtml</from-view-id>

<navigation-case>

<from-outcome>success</from-outcome>

<to-view-id>/welcome.xhtml</to-view-id>

</navigation-case>

<navigation-case>

<from-outcome>failure</from-outcome>

<to-view-id>/newuser.xhtml</to-view-id>

</navigation-case>

</navigation-rule>

4.6. Організація перенаправлень

Перенаправлення відбувається повільно, оскільки вимагає додаткового циклу обміну даними між сервером і клієнтом (браузером). Однак перенаправлення дає браузеру шанс відновити своє поле адреси.

На рис. 22 та рис. 23 показано, як змінюється поле адреси при використанні перенаправлення.

Якщо перенаправлення не використовується, то вихідний URL-адресу (localhost: 8080 / javaquiz / faces / index. xhtml) залишається незмінним, коли користувач переходить зі сторінки / index, xhtml на сторінку / success, xhtml. А в разі перенаправлення браузер відображає нову URL-адресу (localhost:8080/javaquiz/faces/success. xhtml).

Рис. 22. Приклад організації перенаправлень

Рис. 23. Приклад організації перенаправлень

Якщо правила навігації не використовуються, то необхідно додати рядок ? faces-redirects rue до рядка результату:

<h:commandButton label="Login" action="welcome?faces-redirect = true"/>

У правилі навігації елемент redirect додається після елемента to-view-id наступнимчином:

<navigation-case> <from-outcome> success </ from-outcome> <to-view-id> /success.xhtml </ to-view-id> <redirect/> </ navigation-case> 

Перенаправлення та флеш-пам'ять

Щоб зменшити до межі заповнення непотрібними елементами області дії сеансу, має сенс у максимально можливій мірі використовувати область дії запиту. Не вдаючись до використання елемента redirect, можна застосовувати біни з областю дії запиту для даних, що відображаються в наступному поданні. Проте розглянемо, що відбувається при перенаправлення.

  1.  Клієнт відправляє запит серверу.
  2.  Відображення області дії запиту заповнюється бінамі, для яких областю дії служить запит.
  3.  Сервер відправляє клієнту код стану HTTP 302 (Moved temporarily), що вказує на тимчасове переміщення сторінки поряд з відомостями про місце перенаправлення. На цьому обробка поточного запиту закінчується, і відбувається видалення бінов з областю дії запиту.
  4.  Клієнт виконує запит GET до нового розташування.
  5.  Сервер готує до відображення наступне подання. Однак біни з застосовувалася раніше областю дії запиту стають недоступними.

З метою подолання цієї проблеми у версії JSF 2.0 передбачений об'єкт флеш-пам'яті, який може заповнюватися в одному запиті і використовуватися в іншому. (Поняття флеш-пам'яті запозичене з термінології, що застосовується на веб-платформі Ruby on Rails.) Зазвичай флеш-пам'ять використовується для повідомлень.

Метод ExternalContext. get Flash () повертає об'єкт класу Flash, який реалізує інтерфейс Map <String, 0bject>.

На сторінці JSF посилання на об'єкт флеш-пам'яті здійснюється за допомогою змінної флеш-пам'яті. Наприклад, повідомлення можна відобразити наступним чином: # {flash.message}

Коли повідомлення до відображення і передачі підготовленого подання клієнтові рядок повідомлення автоматично видаляється з флеш-пам'яті. Значення у флеш-пам'яті можна навіть зберегти більше ніж для одного запиту. Вираз # {Flash.keep.message} відправляє значення ключа повідомлення у флеш-пам'ять і додає його знову для ще одного циклу запиту.

Навігація з підтримкою методу REST і застосування URL, які забезпечують формування закладок

За замовчуванням додаток JSF виконує послідовність запитів POST, переданих на сервер. Кожен запит POST містить дані форми. Це має сенс для програми, яка збирає великий обсяг введення від користувача. Але більшість веб-додатків не діє подібним чином. Розглянемо приклад, в якому користувач переглядає каталог товарів для здійснення покупок, за допомогою клацань переходячи від одного посилання до іншого. Користувач не вводить ніяких даних, а лише вибирає посилання для подальшого клацання на них. Ці посилання повинні забезпечувати формування закладок, щоб користувач міг повертатися до одних і тих же сторінках при повторному відвідуванні даного URL. Крім того, сторінки повинні бути кешируємой. Кешування – це важлива частина створення ефективних веб-додатків. Безумовно, запити POST не можуть застосовуватися для вирішення завдань створення закладок або кешування.

Архітектори веб-додатків застосовують стиль, що отримав назву REST (Representational State Transfer – передача представницького стану), який заснований на використанні в додатках протоколу HTTP за таким принципом, який був закладений в ньому спочатку. В операціях пошуку повинні використовуватися запити GET. Запити PUT, POST і DELETE повинні служити для створення, модифікації та видалення.

Прихильники підходу на основі REST, як правило, воліють застосовувати URL приблизно такого типу:

http://myserver.com/catalog/item/1729

але архітектура REST не вимагає застосування подібних URL, які прийнято називати "привабливими". Запит GET з параметром

http://myserver.com/catalog?item=1729

також цілком можна розглядати як підтримуючий метод REST.

Слід враховувати, що запити GET ні в якій мірі не повинні використовуватися для оновлення інформації. Наприклад, запит GET для додавання товару в корзину

http://myserver.com/addToCart?cart=314159&item=1729

був би невідповідним. Запити GET повинні бути ідемпотентнимі. Під цим мається на увазі те, що, припустимо, дворазова видача запиту не повинна приводити до інших наслідків, ніж одноразова. Кешируємой можуть бути тільки такі запити, які підпорядковуються цій вимозі. Запит на "додавання товару до кошику" не є ідемпотентним, оскільки після його дворазового виконання в кошику з'являться два примірники одного і того ж товару. Але в цьому контексті запити POST виразно є прийнятними. Таким чином, навіть у веб-додатку, який підтримує метод REST, повинні певною мірою використовуватися запити POST.

4.7. Параметри перегляду сторінок

Розглянемо запит GET на відображення відомостей про певний товар:

http://myserver.com/catalog?item=1729

Ідентифікатор товару заданий як параметр запиту. Після отримання запиту значення цього параметра має бути передане відповідному біну. З цією метою можуть використовуватися параметри подання.

У верхній частині сторінки додайте теги на зразок таких:

<f:metadata>

<f:viewParam name="item" value="#{catalog.currentItem}"/> </ f: metadata>

При обробці запиту значення параметра запиту відомостей про товар передається методу setCuгrentltem біна каталогу.

Сторінка може мати будь-яку кількість параметрів подання. Параметри подання можуть перевірятися і перетворюватися, як і будь-які інші параметри запиту.

Часто виникає необхідність в отриманні додаткових даних після завдання параметрів подання. Наприклад, після того як буде задано параметр подання певного товару, може знадобитися вибрати дані про властивості товару з бази даних для подальшої підготовки до відображення сторінки з описом товару.

Посилання запитів GET

Користувачам потрібно можливість переміщатися по сторінках з допомогою запитів GET. У зв'язку з цим виникає необхідність у додаванні на сторінки кнопок і посилань, після клацань на яких виробляються запити GET. З цією метою використовуються теги h: button і h: link. (З іншого боку, для вироблення запитів POST служать теги h: commandButton і h: command Link.)

У зв'язку з цим при роботі з такими запитами може знадобитися управляти ідентифікаторами цільового подання та параметрами запиту. Ідентифікатор Цільового подання задається за допомогою атрибуту outcome. Він може являти собою фіксовану рядок:

<h:button value="Done" outcome="done"/>

Ще один варіант полягає в тому, що може бути зазначено вираз значення:

 <h:button value="Skip" outcome="#{quizBean.skipOutcome}"/>

Викликається метод getSkipOutcome. Він повинен видати рядок результату. Потім рядок результату звичайним чином передається в обробник навігації, видаючи ідентифікатор цільового подання.

У цьому полягає велика різниця між атрибутом outcome тега h: button і атрибутомaction тега h: commandButton. Значення атрибута outcome обчислюється до підготовки сторінки до відображення, що дозволяє вбудувати необхідну посиланню ввміст сторінки. Однак обчислення значення атрибута action відбувається тільки після фактично виконаного користувачем клацання на кнопці.

Визначення параметрів запиту

Часто виникає необхідність включати параметри у зв'язку з обробкою посилання із запитом GET. Ці параметри можуть бути отримані з трьох джерел.

  1.  Рядок результату.
  2.  Параметри перегляду.
  3.  Вкладені теги f: param.

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

Розглянемо більш докладно, як здійснюється вибір застосовуваних значень.Установки можуть бути задані в рядку результатів приблизно так:

<h:link outcome="index?q=1" value="Skip">

Оброблювач навігації видаляє параметри з результату, обчислює ідентифікатор цільового уявлення і додає параметри. У цьому прикладі ідентифікатором цільового подання є / index. xhtml? q = 1.

При передачі численних параметрів слід обов'язково передбачити екранування за допомогою роздільника &:

<h:link outcome="index?q=1&score=0" value="Skip">

Безумовно, в рядку результату можна використовувати вираз значення, як у наступному прикладі:

<h:link outcome="index?q=#{quizBean.currentProblem + 1}" value="Skip">

Передбачено зручний скорочений спосіб включення всіх параметрів подання до рядка запиту. Він полягає в тому, що додається один атрибут:

<h:link outcome="index" includeViewParams="true" value="Skip">

За допомогою цього способу можна переносити всі параметри подання з однієї сторінки на іншу, що являє собою звичайне вимога до додатка, який підтримує метод REST.

Для визначення параметрів подання може використовуватися тег f: param. Наприклад:

<h:link outcome="index" includeViewParams="true" value="Skip">

<f:param name="q" value="#{quizBean.currentProblem + 1}"/> </ h: link>

Аналогічні переваги, пов'язані з включенням параметрів подання, можна отримати при роботі з посиланнями перенаправлення, які також є запитами GET. Але замість завдання значення атрибута в тегу слід додавати параметр в результат:

<h:commandLink action="index?faces-redirect=true&includeViewParams=true" value="Skip"/>

На жаль, вкладені теги f:param не включаються до запиту. Якщо для завдання правил навігації служать файли конфігурації в коді XML, використовуєм атрибут include-viewparams та вкладені теги view-param:

<redirect include-view-params=true>

<view-param> <name> q </ name>

<value> # {quizBean.currentProblem + 1} </ value>

</ view-param> </ redirect>

4.8. Використання тегів Facelets

Технологія Facelets була спочатку розроблена як альтернатива обробникові уявлень на основі JSP, що застосовувався у версіях JSF 1.x. У версії JSF 2.0 технологія Facelets замінила JSP як застосовувалася за умовчанням в JSF технології подання.Платформа Facelets не тільки є кращим обробником уявлень, а й підтримує цілий ряд тегів, призначених для реалізації шаблонів та інших цілей.

Теги Facelets можуть бути згруповані по декількох категоріях.

  1.  Включення вмісту з інших сторінок XHTML (ui: include).
  2.  Формування сторінок із шаблонів (ui: composition, ui: decorate, ui: insert, ui: define, ui: param).
  3.  Створення користувальницьких компонентів без написання коду Java (Ui: component, ui: fragment).
  4.  Різні утиліти (ui: debug, ui: remove, ui: repeat).

Щоб мати можливість використовувати теги Facelets, необхідно додати наступне оголошення простору імен до конкретних сторінок:

xmlns: ui = http://java.sun.com / jsf / facelets

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

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

Організація конкретних уявлень

По суті, завдання шаблону призводить до розбиття подання на дві сторінки XHTML: на ту, яка визначає загальні функціональні засоби (шаблон), і ту, за допомогою якої задаються функції, що різняться між уявленнями (композиція).

Незважаючи на те що ця методика застосування шаблонів досить проста, вона дозволяє створювати вельми доступні для коригування і розширювані інтерфейси.Розглянемо додаток planets на більш високому рівні, щоб дізнатися, як це робиться.

На рис. 24 показані файли, з яких складаються шаблон та подання для програми.

Рис. 24. Структура файлів з яких складається шаблон

Мало того, що подання додатка розбиті на загальний шаблон і композиції, а й кожна частина вмісту також винесена в результаті розбиття у власний файл; наприклад, в уявленнях входу в систему і планетарію є по одному файлу і для заголовка, і для бічного меню. Ці окремі частини вмісту включаються кожним поданням за допомогою тега ui: include. Наприклад, на сторінці входу включення заголовка відбувається наступним чином:

^ Ui: define name = "heading">

<ui:include src="sections/login/header.xhtml"/> </ ui: define>

Завдяки тому, що окремі частини вмісту визначаються у своїх власних файлах, стаєпростіше визначати місцезнаходження коду при внесенні змін в той чи інший подання.Наприклад, якщо буде потрібно щось змінити в бічному меню подання входу всистему, то буде відомо, що для цього достатньо відредагувати файл sections / login /sidebarLeft. xhtml, не утруднюючи себе пошуком цього визначення бокового меню водному великому файлі. Як розділити сприяє спрощенню читання, розуміння івнесення змін на конкретні сторінки, оскільки кожен файл містить невеликий обсягрозмітки.

На сторінках даного додатки не використовуються окремі файли для розділів вмісту.Але за бажанням можна винести розділ вмісту в окремий файл Facelets, такий як /sections / login / content, xhtml.

На завершення, розглянемо файли, що знаходяться в каталозі sections.Файли в цьому каталозі містять розділи сторінок, що включаються в шаблон.

Тема вистави входу в систему наведено на рис. 25.

Рис. 25. Приклад одного з елементів структури

Реалізація цього заголовка показана в лістингу.

Зверніть увагу на те, що вміст (у даному випадку текст заголовка) розміщується в тезі ui: composition, який не задає шаблон. У цьому прикладі тег ui: composition застосовується з тактичної причини: він дозволяє знищити навколишні теги XHTML.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtc)">

<html xmlns="http://www.w3.org/1999/xhtml"

xmlns:ui="http://j ava.sun.com/j sf/facelets">

<head><title>IGNORED</title></head>

<body>

<ui:composition>

<div class="header">

#{msgs.loginHeading}

</div>

</ui:composition>

</body></html>

5. ОХОРОНА ПРАЦІ

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

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

5.1. Виявлення та аналіз ШНВШ. Заходи з охорони праці

5.1.1. Повітря робочого середовища

Відповідно до ДСН 3.3.6.042 – 99 роботи в офісі відносять до категорії легка Ia. Дана робота належить до категорії робіт сидячи і не потребуючих фізичної напруги, при яких витрата енергії становить до 120 ккал/год. Оптимальні значення параметрів мікроклімату, прийняті даним проектом, наведені в табл. 1.

Таблиця 1

Оптимальні та припустимі значення параметрів мікроклімату

Період року

Категорія робіт

Температура, C

Відносна вологість, %

Швидкість руху повітря, м/с

Холодний

Легка

22-24

40-60

0,1

Теплий

Легка

23-25

40-60

0,1

Температура корпусу ЕОМ та периферійних пристроїв встановлюються за наступною формулою:

,

де tптемпература зовнішньої поверхні обладнання,

   tопт – оптимальна температура приміщення.

Для нормалізації повітря робочої зони проектом передбачено пристрої штучної вентиляції. Природний обмін повітря приміщення здійснюється за допомогою віконних прорізів.

Для нормалізації мікроклімату передбачено змішану загально обмінну вентиляцію, для рівномірного повітрообміну. Місцева вентиляція служить для подачі свіжого повітря до робочого місця. Передбачено встановлення кондиціонерів.

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

5.1.2. Виробниче освітлення

Правильне виробниче освітлення є не менш важливою складовою умов безпеки на виробництві. Зберігання зору, стану нервової системи людини та безпеки на виробництві у значній мірі залежить від умов освітлення в приміщенні .

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

У проекті передбачене суміщене освітлення: природне – бічне, штучне – верхнє. Проектом передбачені наступні системи освітлення: аварійне, ремонтне, робоче.

В табл. 2 представлені санітарні норми освітлення, наведені значення параметрів освітлення, прийняті проектом.

Таблиця 2

Норми параметрів освітлення

Розряд зорових робіт

Характер зорових робіт

Освітле-

ність при штучному освітленні

Значення КЕО, %

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

При суміщеному освітленні

Спеці-

альне

Верх-

нє

Спеці-

альне

Верх-

нє

IVa

Загальне постійне спостереження за ходом виробничого процесу

300

0,2

1

0,2

0,7

Система штучного освітлення комбінована. В офісі використовуються люмінесцентні лампи типу ЛД. Прийнята напруга – 220 В.

При відключенні робочого освітлення передбачено аварійне та ремонтне освітлення. Аварійне освітлення забезпечується певною кількістю генераторів.

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

Контроль освітленості здійснюється люксметром Ю-116 1-2 рази в рік, а також після ремонту освітлювальних установок.

5.1.3. Захист від виробничого шуму та вібрації

За ДСН 2.2.4/2.1.8.562-96 при виконанні основної роботи на ПЕОМ рівень шуму на робочому місці не повинен перевищувати 50 дБ.

Зниження рівня шуму в приміщенні з ПЕОМ досягається шляхом використання звуковбирних матеріалів з максимальними коефіцієнтами звукопоглинання в області частот 63-8000 Гц для обробки приміщень підтверджених спеціальними акустичними розрахунками. В офісних приміщеннях застосовуються сучасні віконні профілі з двохкамерними або трьохкамерними склопакетами і звукоізоляція зовнішніх стін плитами з різними наповнювачами такими як скловата або кам’яна вата.

Також для забезпечення нормованих рівнів на робочих місцях застосовуються шумопоглинальні засоби, вибір яких обґрунтовується спеціальними інженерно-акустичними розрахунками. Як засоби шумопоглинання застосовуються негорючі або важкогорючі спеціальні перфоровані плити, панелі, які, в основному, встановлюються на стелі. Можливе використання і інших матеріалів дозволених ограгами державного санітарно-епідеміологічного нагляду.

5.1.4. Електробезпека

Проектом передбачено здійснення живлення електроустаткування від трифазної 4-провідної електричної мережі змінного струму промислової частоти із глухозаземленною нейтралью напругою 220 В.

Повна електробезпека можлива, якщо поряд із запропонованими правилами технічної експлуатації електроустановок споживачів використовують технічні засоби захисту, до яких відносять:

  1.  електричну ізоляцію струмоведучих частин;
  2.  вирівнювання потенціалів;
  3.  захисне відключення;
  4.  малу напругу;
  5.  подвійну ізоляцію;
  6.  захисне заземлення;
  7.  занулення.

Захисне заземлення або занулення забезпечує захист людей від поразки електричним струмом при дотику до металевих неструмоведучих частин, які можуть виявитись під напругою в результаті ушкодження ізоляції.

Захисне заземлення виконується навмисним з’єднанням металевих частин електроустановок з «землею» або її еквівалентом.

Занулення виконується електричним з’єднанням металевих частин електроустановок із заземленою точкою джерела живлення електроенергією за допомогою нульового захисного провідника.

Відповідно ГОСТ 12.1.038-82 допустимі рівні напруги дотику (Uд) і струму, що проходить через тіло людини (Iл) дорівнює: при нормальному режимі роботи електроустаткування Uд = 2 В, а Iл = 0.3 мА при τ ≤ 10 хв; при аварійному відповідно 36 В і 6 мА при τ > 1 с.

Якщо людина попадає під повну лінійну напругу, то через неї проходить струм, що визначається формулою:

Напруга дотику визначається наступною формулою:

Як видно з рівняння, при порушенні ПБЕ можливі електротравми з важкими наслідками.

5.1.5. Безпека роботи з обладнанням

Аналізуючи санітарно-гігієнічні норми й правила роботи з обчислювальною технікою, можна скласти ряд рекомендацій з оптимізації праці операторів ЕОМ. Основними напрямками оптимізації є:

  1.  раціональне розміщення техніки в приміщенні, врахування освітленості й зручності організації робочого місця;
  2.  дотримання умов безпеки при прокладанні кабелів мережі та інших;
  3.  увага до організації режимів праці й відпочинку, створення мікроклімату в приміщенні й сприятливого психологічного клімату в колективі, за можливості створення умов для короткочасного рухливого проведення часу, наприклад гри в настільний теніс;
  4.  обов’язкове дотримання вимог техніки безпеки й охорони праці на робочому місці;
  5.  повне інформування працівника про його права й обов’язки, про профзахворювання і їх симптоми, рекомендацій, що виникають пр. и порушенні правил і запобіжних заходів.

Виконання цих рекомендацій дозволить підвищити працездатність, попередити розвиток функціональних розладів, знизити загальну захворюваність.

Робота програміста з дисплеєм ставиться до типу комунікацій «людина – машина». Персональний комп’ютер спроектований з урахуванням ряду ергономічних вимог:

  1.  можливість повороту дисплея;
  2.  можливість переміщення клавіатури;
  3.  мала тепловіддача апаратури;
  4.  можливість регулювання яскравості зображення;
  5.  відстань до монітору не менше відстані витягнутої до нього руки;
  6.  кнопка включення апаратури розташована в межах досяжності.

Існують рекомендації обмеження безперервної роботи перед монітором чотирма годинами при восьмигодинному робочому дні й обсязі інформації 30000 знаків за 4 години. Рекомендується робити регулярні перерви в роботі для відпочинку, самомасажу, гімнастики рук і очей (перерва на 10-15 хвилин кожні дві години).

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

5.2. Пожежна безпека

Дане приміщення ставиться, відповідно до СНиП 21-07-97, до категорії «В» – горючі й важко горючі приміщення, у яких в обігу перебувають рідини, тверді горючі (пластикові корпуси комп'ютерів, дерев'яні столи, лінолеум) і важко горючі речовини (ізоляція сполучних і силових кабелів) і матеріали, здатні горіти тільки при взаємодії з киснем або один з одним, за умови, що приміщення, у яких вони є, не належить до категорії «А» або «Б». Будинок, у якому перебуває приміщення, виконане із залізобетону.

Персональні комп'ютери після закінчення роботи на них необхідно відключати від мережі.

При появі запаху гару терміново припинити роботу, відключити апаратуру. Усунути причину пошкодження.

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

Дозволяється гасити лише порошковими або вуглекислотними вогнегасниками, але в жодному випадку не пінними.

Проектом передбачені наступні міри пожежної безпеки:

  1.  для опалення приміщення використовувати тільки центральне водяне опалення;
  2.  двері в приміщення виконані із ДВП, просоченого вогнестійким складом;
  3.  для зберігання магнітних носіїв використовувати вогнетривку металеву шафу.

Додаткові організаційні заходи:

  1.  встановлення в приміщенні апарату для швидкого виклику екстреної служби;
  2.  фізична доступність розеток для ручного відключення живлення ПЕОМ.

5.3. Блискавкозахист

Блискавкозахист – це комплекс заходів та спеціальних пристосувань для забезпечення безпеки приміщення, а також майна та людей, що знаходяться в ньому. Згідно з діючим Національним стандартом України ДСТУ Б В.2.5-38:2008 блискавкозахист будівель підрозділяється на зовнішній і внутрішній.

Зовнішній блискавкозахист складається з наступних частин:

  1.  блискавкоприймач – перехоплює розряд блискавки. Виконується з металу (нержавіюча сталь, алюміній, мідь);
  2.  струмовідвід – частина блискавкоприймача, призначена для відведення струму блискавки до заземлювача;
  3.  заземлювач – провідна частина, що знаходиться в безпосередньому контакті з землею.

Внутрішня система блискавкозахисту складається з шини вирівнювання потенціалів, яка об’єднує усі металоконструкції будівлі, зокрема об’єднує нейтраль електромережі з контуром заземлення, екрани телевізійних кабелів, труби водопостачання з контуром заземлення.


ВИСНОВКИ

При виконанні даного дипломного проекту я провів детальний аналіз існуючих програмних систем для торгівлі на ринку Forex та існуючих методів розробки. В існуючих програмних рішеннях було виявлено ряд недоліків, а саме:

  1.  Необхідність інсталяції. Існуючі програмні продукти потребують певного дисквго простору на компютерах користувачів.
  2.  Винесення частини бізнес логіки в клієнтський додаток. Звичайно, програма встановлена в користувача на компютері є клієнтською частиною продукту, але все-одно вона виконує частину роботи яку б мав виконувати сервер.
  3.  «Залежність» від свого компютера. Працювати на ринку Forex ви можете тільки зі свого компютера, оскільки на ньому встановлена програма та введені важі персональні дані. Іншим вирішенням проблеми є повторне встановлення програми на новий компютер.
  4.  Оновлення. Клієнт має постійно слідкувати за інформацією щодо нових оновлень, сам має їх скачувати і встановлювати.
  5.  Велика кількість коду через «універсальність» програми. Програмний продукт має добре працювати на всіх операційних системах, відповідно потрібно дублювати класи та функції для різних ОС.

Розроблений мною програмний продукт  в першу чергу є веб-орієнтованим. Це означає, що вся інформація та бізнес логіка знаходиться на віддаленому сервері, а користувач має доступ до продукту через web-браузер на мережу Інтернет. Особливістю розробленої системи є те, що користувачеві тепер немає необхідності турбуватися про вільне міце на жорсткому диску чи слідкувати за останніми оновленнями, все це за нього робить персонал, який обслуговує сервер. Крім того, підтримка однієї версії програми на сервері набагато дешевша по вартості, чим підтримка багатьох віддалено встановлених версій на різних комп’ютерах. Немає необхідності розробляти «універсальний код», потрібно зробити програмний продукт, який добре працюватиме на сервері та налаштувати його. Розроблена система дає можливість вільного доступу до інформації з будь-якого компютера який підключений до мережі Інтернет.

При розробці клієнтської частини основну увагу було приділено простоті та інтуїтивній зрозумілості інтерфейсу. Для пришвидшення роботи клієнтської частини продукту було використано AJAX та теги Facelets.

Клієнтська чатина підтримує перетворення даних, перевірку введених даних на помилки та обробка помилок в разі їх виникнення, динамічну навігацію, будує надійні таблиці з підтримкою CSS.


СПИСОК ВИКОРИСТАНИХ ЛІТЕРАТУРНИХ ДЖЕРЕЛ

  1.  Дипломне проектування за напрямами підготовки ”Прикладна математика”, „Комп’ютерна інженерія”, „Програмна інженерія” [Текст] : навч.-метод. посіб. / Є.С. Сулема : за заг. ред. І.А. Дички — К. : НТУУ «КПІ», 2011. — 224 с. – Бібліогр. : с. 77 — 400 пр.
  2.  JavaServer Faces. Библиотека профессионала, 3-е изд. : Пер. с англ. — М. Тригуб : ООО «И.Д. Вильямс», 2011. — 544 с.
  3.  ORACLE [Електронний ресурс] — Режим доступу: http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html. — Дата доступу : жовтень 2011. — Назва з екрана.
  4.  Wikipedia [Електронний ресурс] — Режим доступу: http://ru.wikipedia.org/wiki/JavaServer_Faces. — Дата доступу: грудень 2011. — Назва з екрана.
  5.  Forexclub [Електронний ресурс] — Режим доступу: http://www.forexclub.ua/. — Дата доступу: січень 2011. — Назва з екрана.
  6.  Pandora [Електронний ресурс] — Режим доступу: http://pandora.ucoz.ru/index/0-5. — Дата доступу: грудень 2011. — Назва з екрана.
  7.  BistForm [Електронний ресурс] — Режим доступу: http://www.bitstorm.org/edwin/en/php/. — Дата доступу: листопад 2011. — Назва з екрана.
  8.  Wikipedia [Електронний ресурс] — Режим доступу: http://ru.wikipedia.org/wiki/Model-View-Controller. — Дата доступу: січень 2011. — Назва з екрана.
  9.  API.JQuery [Електронний ресурс] — Режим доступу: http://api.jquery.com/category/ajax/. — Дата доступу: січень 2011. — Назва з екрана.
  10.  W3School [Електронний ресурс] — Режим доступу: http://www.w3schools.com/ajax/default.asp. — Дата доступу: грудень 2011. — Назва з екрана.
  11.  CitForum [Електронний ресурс] — Режим доступу: http://citforum.ru/internet/javascript/enterpjavabeans.shtml. — Дата доступу: жовтень 2011. — Назва з екрана.
  12.  NetBeans [Електронний ресурс] — Режим доступу:  http://netbeans.org/kb/docs/javaee/javaee-entapp-ejb_ru.html. — Дата доступу: грудень 2011. — Назва з екрана.
  13.  Java.net [Електронний ресурс] — Режим доступу: http://facelets.java.net/nonav/docs/dev/docbook.html — Дата доступу: листопад 2011. — Назва з екрана.
  14.  Oracle [Електронний ресурс] — Режим доступу: http://docs.oracle.com/javaee/6/tutorial/doc/giepx.html — Дата доступу: листопад 2011. — Назва з екрана.
  15.  JavaTalks [Електронний ресурс] — Режим доступу: http://www.javatalks.ru/forum41/%D0%A4%D0%B0%D0%B9%D0%BB%D1%8B-%D0%B8-%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B8-%D0%B2%D0%B2%D0%BE%D0%B4%D0%B0-%D0%B2%D1%8B%D0%B2%D0%BE%D0%B4%D0%B0 — Дата доступу: січень 2011. — Назва з екрана. 

ДОДАТКИ

  1.  ПЗКС.045440-06-99. Програмна система для автоматизації брокерського обслуговування на біржі. Клієнтська частина. Загальна структура програми. Схема структурна.
  2.  ПЗКС.045440-07-99. Програмна система для автоматизації брокерського обслуговування на біржі. Клієнтська частина. Взаємодія клієнта з сервером. Схема структурна.
  3.  ПЗКС.045440-08-99. Програмна система для автоматизації брокерського обслуговування на біржі. Клієнтська частина. Життєвий цикл сторінки. Схема алгоритму.
  4.  Схема роботи модуля динамічного оновлення сторінки. Плакат.
  5.  Мапа сайту. Плакат.
  6.  Фази обробки запитів. Плакат. 
  7.  Лістинг програми


 

А также другие работы, которые могут Вас заинтересовать

5931. Динамические и частотные характеристики САУ 165.9 KB
  Динамические и частотные характеристики САУ Цель работы: Ознакомление с динамическими и частотными характеристиками систем автоматического управления (САУ) и получение навыков исследования линейных динамических моделей. Постановка задачи: В качестве...
5932. Психолого-педагогическая характеристика классного коллектива 156 KB
  Психолого-педагогическая характеристика классного коллектива Данный коллектив существует первый год. Всего в классе - 26 учащихся: девочек - 17 , мальчиков - 9. Был создан из учащ...
5933. Суд присяжных в России: история и современность 140 KB
  Введение Тема курсовой работы - Суд присяжных в России: история и современность. При изучении и разработке вопросов, освещенных в данной работе, основной целью было - выявить: наиболее спорные теоретические вопросы в данной...
5934. Методика воспитательной работы 2.77 MB
  Глава I. Воспитание, воспитательный процесс Воспитание как культурно-исторический феномен Воспитание - категория педагогической науки Теория и методика воспитания в гуманистической парадигме Воспитательный процесс, его цель и сущность...
5935. АНАЛІЗ ГРАМАТИЧНИХ ОСОБЛИВОСТЕЙ ПЕРЕКЛАДУ ЕКОНОМІЧНИХ ТЕКСТІВ 504.5 KB
  Наша країна намагається вийти на світові ринки торгівлі і встановити якомога кращі стосунки зі своїми закордонними колегами, наприклад, укласти найбільш вигідні контракти, та не останнім фактором успішності цих контрактів буде правильний переклад та оформлення ділового паперу, а оскільки будь-який документ такого характеру не можна уявити
5936. Аналіз виховного процесу в 5-В класі 29.5 KB
  Кількість дітей у класі: 22 особи Стосунки між учнями класу загалом дружніі доброзичливі. Але протягом року були випадки суперечок і непорозумінь між учнями, зокрема проблеми у спілкуванні: Шимко-Сирашний, Крючковська-Страшний, а також Барвет, яка м...
5937. Анализ воспитательной работы МБОУ «Устьвашская средняя общеобразовательная школа» за 2011/12 учебный год 102 KB
  Анализ воспитательной работы МБОУ Устьвашская средняя общеобразовательная школа за 2011/12 учебный год. Цель воспитательной работы в 2001/12 учебном году: формирование первичных представлений о базовых национальных российских ценностях (начал...
5938. Анализ воспитательной работы с учащимися 9 а класса 66.5 KB
  Анализ воспитательной работы с учащимися 9 а класса Классный руководитель: Характеристика класса. В классе 25 учеников, из них 11 мальчиков и 14 девочек. По национальному составу - 20 русских, 5 бурят. Количество учащи...
5939. Анализ воспитательной работы за первое полугодие классного руководителя 10 А класса 40.5 KB
  Анализ воспитательной работы за первое полугодие классного руководителя 10 А класса 1. Анализ эффективности целеполагания и планирования воспитательного процесса в классе в 2011-2012 учебном году. Воспитательные задачи в текущем учебном году следующ...