Русский   English
ДонНТУ   Портал магістрів

Реферат на тему магістерскої роботи

Зміст

Вступ

Безперервний розвиток засобів обчислювальної техніки висуває високі вимоги до розроблюваних пристроїв [1]. З зростанням вимог до побудови цифрових пристроїв підвищується тривалість і складність процесу їх синтезу. Розвиток технології виробництва інтегральних схем та постійне збільшення складності цифрових схем визначає актуальність створення програмного забезпечення для автоматизації синтезу цифрових пристроїв.

Розглянута архітектура RIA (Rich Internet application) програми для автоматизованого проектування цифрових пристроїв з мінімальною участю людини, за допомогою суперкомп'ютерних обчислень.

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

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

1 Актуальність теми

Безперервний розвиток засобів обчислювальної техніки висуває високі вимоги до розроблюваних пристроїв [1]. З зростанням вимог до побудови цифрових пристроїв підвищується тривалість і складність процесу їх синтезу. Розвиток технології виробництва інтегральних схем та постійне збільшення складності цифрових схем визначає актуальність створення програмного забезпечення для автоматизації синтезу цифрових пристроїв.

2 Актуальність проблеми

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

3 Постановка задачи

Дана робота присвячена розробці архітектури додатку для автоматизованого синтезу цифрових пристроїв з використанням суперкомп'ютера NeClus.

4 Мета работы

Метою роботи є створення масштабованої, надійної і гнучкої серверної архітектури з багатим інтерфейсом.

5 Вибір базової архітектури

5.1 Опис MVC архітектури

В якості мови програмування був обраний Java, тому що стек технологій JavaEE забезпечує побудову масштабованої, надійної і гнучкої серверної архітектури.

Спочатку єдиним API, доступним в Java для розробки серверних web-додатків, була технологія сервлетів. У сервлетів було багато переваг порівняно зі сценаріями CGI, які раніше були домінуючою технологією. Тим не менш, у сервлетів був один суттєвий недолік. Оскільки код HTML, який буде представлений у вікні оглядача, повинен був вбудовуватися в код Java, то більшу частину коду сервлета було дуже важко підтримувати [2]. Подібний код був не дуже зручний у супроводі.

Один з поширених способів наблизитися до розв'язання цієї проблеми полягає в тому, щоб використовувати шаблон проектування Модель-Представлення-Контроллер (Model-View-Controller). Цей шаблон забезпечує чіткий поділ проблем, надаючи артефакти, які використовуються виключно в якості даних (моделі), в той час як інші артефакти відповідають (використовуються) виключно за відображення (подання) даних, а третій несуть відповідальність за управління даними (контролер) і передають управління необхідному поданням [3]. Базова концепція моделі MVC представлена на рис. 1.

Базовая концепция модели MVC

Рисунок 1 – Базова концепція моделі MVC

(анімація: 2 кадрів, зацикленна, затримка між кадрами 0.2 с., 12.3 КБ)

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

5.2 Реалізація MVC моделі

Найбільш типова реалізація відокремлює представлення від моделі шляхом встановлення між ними протоколу взаємодії, використовуючи апарат подій (підписка/сповіщення). При кожній зміні внутрішніх даних в моделі вона повідомлює всі залежні від неї уявлення, і представлення оновлюється. Для цього використовується шаблон "Спостерігач" При обробці реакції користувача він вибирає, залежно від потрібної реакції, потрібний контролер, який забезпечить ту чи інший зв'язок з моделлю. Для цього використовується шаблон "стратегія" або замість цього може бути модифікація з використанням шаблону "грудки". А для можливості однотипного звернення з подоб'ектами складно-складеного ієрархічного виду може використовуватися шаблон "Компоновщик". Крім того, можуть використовуватися й інші шаблони проектування, наприклад, "Фабричний метод" який дозволить задати за замовчуванням тип контролера для відповідного виду [9].

Розрізняють дві основні модифікації моделі MVC [10]:

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

У даній роботі була обрана активна модель MVC. Для кожного рівня MVC моделі буде обраний фреймворк який реалізує дану задачу.

6 Розробка рівня управління

6.1 Реалізація рівня управління як частина MVC архітектури

В якості контролера може служити сама реалізація шаблону MVC, яка повинна забезпечувати надійну структуру. З цим завданням повністю справляється модуль Spring MVC на базі фреймворка MVC. Він являє розгорнуту підтримку даного шаблону, а також інших засобів (наприклад, оформлення темами, інтернаціоналізацію, перевірку достовірності, перетворення типів, форматування і т.п.). Головною і найважливішою особливістю його є Inversion of сontrol контейнер, який представляє засоби конфігурування та управління об'єктами Java за допомогою відображення. Контейнер відповідає за управління життєвим циклом об'єкта : створення об'єктів, виклик методів ініціалізації та конфігурування об'єктів шляхом зв'язування їх між собою. Об'єкти, створювані контейнером, також називаються керованими об'єктами (beans). Зазвичай конфігурування контейнера здійснюється шляхом завантаження XML-файлів, містять визначення bean'ов і надають інформацію, необхідну для створення bean'ов. Контейнер відповідає за управління життєвим циклом циклом об'єкта : створення об'єктів, виклик методів ініціалізації та конфігурування об'єктів шляхом зв'язування їх між собою [4].

6.2 Spring Frameworkяк основний компонент у додатку

Spring Framework забезпечує рішення багатьох задач, з якими стикаються Java розробники та організації, які хочуть створити інформаційну систему, засновану на платформі Java. За широкої функціональності важко визначити найбільш значущі структурні елементи, з яких він складається. Spring Framework не повністю пов'язан з платформою Java Enterprise, незважаючи на його масштабну інтеграцію з нею, що є важливою причиною його популярності. Spring Framework, ймовірно, найбільш відомий як джерело розширень (features), потрібних для ефективної розробки складних бізнес-додатків поза великовагових програмних моделей, які історично були домінуючими в промисловості. Ще одне його достоїнство в тому, що він ввів раніше невикористовувані функціональні можливості в сьогоднішні панівні методи розробки, навіть поза платформи Java. Цей фреймворк пропонує послідовну модель та робить її застосовної до більшості типів додатків, які вже створені на основі платформи Java. Вважається, що Spring Framework реалізує модель розробки, засновану на кращих стандартах індустрії, і робить її доступною в багатьох галузях Java.

Незважаючи на те, що Spring Framework не забезпечував якусь конкретну модель програмування, він став широко поширеним в Java-співтоваристві головним чином як альтернатива і заміна моделі Enterprise JavaBeans. Spring Framework надає більшу свободу Java-розробникам в проектуванні, крім того, він надає добре документовані і легкі у використанні засоби вирішення проблем, що виникають при створенні додатків корпоративного масштабу. Тим часом, особливості ядра Spring Framework застосовні в будь-якому Java-додатку, і існує безліч розширень і удосконалень для побудови web-додатків на Java Enterprise платформі. З цих причин Spring придбав велику популярність і визнається розробниками як стратегічно важливий фреймворк.

На безе цього фреймворку була складена загальна структура програми, представлена на рис. 2

Загальна структура додутку

Рисунок 2 – Загальна структура додутку

7 Розробка рівня представлення

7.1 Основні критерії до web-додатків

У web-додатках рівень представлення є критично важливим і робить значний вплив на ступінь прийняття додатка користувачами. Рівень представлення – це свого роду "парадні двері" в додаток. Він дозволяє користувачам виконувати бізнес-функції, що подаються додатком, а також забезпечує візуальне представлення інформації, якою управляє додаток. Ефективність користувача інтерфейсу вносить досить істотний внесок в успіх додатку в цілому [5].

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

Побудова web-додатків, що задовольняє зазначеним вище вимогам, не є простою задачею, проте ці вимоги розглядаються користувачами як обов'язкові. Для вирішення цих потреб були розроблені нові технології та інфраструктури. Останнім часом багато платформ та бібліотек для розробки web-додатків-серед яких Spring MVC, Struts, Java Server Faces (JSF), Google Web Toolkit (GWT), jQuery і Dojo-пропонують інструменти і розвинені бібліотеки компонентів, що допомагають побудувати високо інтерактивні користувальницькі інтерфейси для web-мережі.

7.2 RIA як представлення

Додатки які базуються на таких концепціях почали називати RIA – Rich Internet application (Насичений інтернет-додаток). Це web-додаток, доступний через Інтернет, насичений функціональністю традиційних настільних додатків, який надається або унікальною специфікою браузера, або через плагін, або шляхом "пісочниці" (віртуальної машини).

Як правило, додаток RIA:

  1. передає веб-клієнту необхідну частину користувальницького інтерфейсу, залишаючи велику частину даних (ресурси програми, дані і пр.) на сервері;
  2. запускається в браузері і не вимагає додаткової установки ПЗ;
  3. запускається локально в середовищі безпеки, званої "пісочниця" (sandbox).

недоліки RIA:

  1. "Пісочниця". Оскільки RIA завантажуються в локальному середовищі безпеки-"пісочниці"-вони мають обмежений доступ до системних ресурсів. Якщо права на доступ до ресурсам некоректні, RIA можуть працювати неправильно.
  2. Підключення скриптів. Як правило, для роботи RIA потрібно JavaScript або інші скриптові мови. Якщо користувач відключив активні сценарії у своєму браузері, RIA може не функціонувати належним чином або взагалі не працювати.
  3. Швидкість обробки клієнтом. Щоб забезпечити платформену незалежність, деякі RIA використовують скриптову мову на стороні клієнта, наприклад, такий як JavaScript, з частковою втратою продуктивності (серйозна проблема для мобільних пристроїв). Однак така проблема не виникає при використанні вбудованої мови, скомпільованого на стороні клієнта, такого як Java, де продуктивність порівнянна з використанням традиційних вбудованих мов, або з Flash або з Silverlight, в яких програмний код запускається безпосередньо в плагін Flash Player або Silverlight відповідно.
  4. Час завантаження скрипта. Навіть якщо немає необхідності в установці скрипта, движок клієнта RIA повинен бути передан до клієнта сервером. Оскільки більшість скриптів зберігаються у кеші, він повинен бути переданий хоча б один раз. Залежно від розміру і типу передачі, завантаження скрипта може зайняти досить багато часу. Розробники RIA можуть зменшити наслідки цієї затримки за допомогою стиснення скриптів, а також за рахунок розбиття передачі додатки на кілька сторінок.
  5. Утрата цілісності. Якщо додаток заснований на X/HTML, можливі конфлікти між цілями додатків (яке, природно, хоче мати контроль над його поданням і діями) і цілями X/HTML (яке хоче віддати контроль). Інтерфейс DOM для X/HTML робить можливим створення RIA, але це не дає жодних гарантій, що воно буде працювати коректно. Через те, що клієнт RIA може змінювати основну структуру програми та перевизначати його дії та уявлення, це може привести до помилки додатка на стороні клієнта. Зрештою, ця проблема може бути вирішена за рахунок нового механізму клієнт-сервер, що надає клієнту RIA обмежений доступ до зміни тих ресурсів, які не входять до сфери його повноважень. Робота рідного стандартного ПО не викликає подібних проблем, оскільки вони за визначенням автоматично володіють усіма необхідними правами на локальні ресурси.
  6. Втрата видимості для пошукових систем. Пошукові системи можуть виявитися не в змозі проіндексувати вміст програми RIA.
  7. Залежність від підключення до Інтернету. Ідеальна заміна для настільних додатків повинна дозволяти користувачам підключатися до мережі "епізодично", покидаючи хот-стопи, йдучи і приходячи в офіс. Однак до 2007 року типові програми RIA вимагали постійного підключення.
  8. Доступність. Відомо безліч проблем веб-сумісності з RIA. Одна з поширених полягає в тому, що користувачеві, що читає текст з екрану, складно виявляти динамічні зміни (викликані JavaScript) в контенті HTML.
  9. Складність розширюваності. RIA складно розширювати плагінами і модами, як це робиться в традиційних додатках. Можливе використання користувальницьких JavaScript, запроваджуваних iFrame контентом, і тощо.

Серед маси RIA платформ був обраний фреймворк Vaadin, який на відміну від бібліотек на Javascript і специфічних плагінів для браузерів пропонує сервер-орієнтовану архітектуру, базовану на Java Enterprise Edition. Використання JEE дозволяє виконувати основну частину логіки програми на стороні сервера, тоді як технологія AJAX, використовувана на стороні браузера, дозволяє інтерактивно взаємодіяти з користувачем. Для відображення елементів інтерфейсу користувача та взаємодії з сервером на стороні клієнта Vaadin використовує Google Web Toolkit [6].

На базі інтеграції фреймворків Spring MVC і Vaadin була складена загальна структура web-додатка, представлена на рис. 3.

Загальна структура web-додатка

Рисунок 3 – Загальна структура web-додатка

8 Розробка рівня постійності

8.1 Проблеми програмування баз даних і способи боротьби з ними

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

В якості рівня постиінойсті буде використана реляційна база даних. Але використання реляційної бази даних для зберігання об'єктно-орієнтованих даних призводить до семантичного провалу, змушуючи програмістів писати програмне забезпечення, яке повинно вміти як обробляти дані в об'єктно-орієнтованому вигляді, так і вміти зберегти ці дані в реляційної формі. Ця постійна необхідність у перетворенні між двома різними формами даних не тільки сильно знижує продуктивність, але і створює труднощі для програмістів, так як обидві форми даних накладають обмеження один на одного [7]. Розроблено безліч пакетів, що усувають необхідність у перетворенні об'єктів для зберігання в реляційних базах даних. Деякі пакети вирішують цю проблему, надаючи бібліотеки класів, здатних виконувати такі перетворення автоматично. Маючи список таблиць в базі даних і об'єктів у програмі, вони автоматично перетворять запити з одного виду в інший. У результаті запиту об'єкта "людина" (з прикладу з адресною книгою) необхідний SQL-запит буде сформований і виконаний, а результати особливим чином перетворені в об'єкти "номер телефону" всередині програми. З точки зору програміста система повинна виглядати як постійне сховище об'єктів. Він може просто створювати об'єкти і працювати з ними як зазвичай, а вони автоматично будуть зберігатися в реляційній базі даних. Такий підхід називається ORM (Object-relational mapping,) – об'єктно-реляційне відображення.

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

З точки зору програміста система повинна виглядати як постійне сховище об'єктів. Він може просто створювати об'єкти і працювати з ними як зазвичай, а вони автоматично будуть зберігатися в реляційній базі даних. На практиці все не так просто і очевидно. Всі системи ORM зазвичай виявляють себе в тому чи іншому вигляді, зменшуючи в деякому роді можливість ігнорування бази даних. Більш того, шар транзакцій може бути повільним і неефективним (особливо в термінах згенерованого SQL). Все це може призвести до того, що програми будуть працювати повільніше і використовувати більше пам'яті, ніж програми, написані "вручну".

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

8.2 Hibernate як реалізація рівня постійності

В якості ORM бібліотеки була обрана бібліотека Hibernate, яка надає легкий у використанні каркас (фреймворк) для відображення об'єктно-орієнтованої моделі даних у традиційні реляційні базі даних [8].

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

Hibernate забезпечує прозору підтримку збереження даних (persistence) для "POJO" (тобто для стандартних Java-об'єктів); єдине сувора вимога для зберігається класу-наявність конструктора за замовчуванням (без параметрів). Може використовуватися як в самостійних додатках Java, так і в програмах Java EE, виконуваних на сервері (наприклад, сервлет або компоненти EJB). Також він може включатися як додаткова можливість до інших мов програмування.

Колекції об'єктів даних, як звичай, зберігаються у вигляді колекцій Java-об'єктів, таких як набір (Set) та список (List). Підтримуються узагальнені класи (Generics), введені в Java 5. Hibernate може бути налаштований на "ліниві" (відкладені) завантаження колекцій. Відкладені завантаження є варіантом за замовчуванням, починаючи з Hibernate 3. Пов'язані об'єкти можуть бути налаштовані на каскадні операції. Наприклад, батьківський клас, Album (музичний альбом), може бути налаштований на каскадне збереження та/або видалення свого нащадка Track. Це може скоротити час розробки і забезпечити цілісність. Функція перевірки зміни даних (dirty checking) дозволяє уникнути непотрібного запису дій в базу даних, виконуючи SQL оновлення тільки при зміні полів персистентних об'єктів.

На безе інтеграції фреймворка Spring MVC і бібліотеки Hibernate була розроблена вдосконалена структура web-додатки. Структура програмного модуля постійності представлена на рис. 4.

Структура программного модуля постійності

Рисунок 4 – Структура программного модуля постійності

9 Сервіс проектування цифрових пристроїв

Для проектування цифрових пристроїв буде розроблено програмний модуль (сервіс), який реалізовуватиме оптимальний алгоритм обчислень на суперкомп'ютері. В якості суперкомп'ютера буде використовуватися кластер NeClus кафедри комп'ютерної інженерії ДонНТУ. Для віддаленого підключення до кластеру необхідно використовувати SSH протокол. Для цього буде використана бібліотека JSCH.

Розроблюваний модуль за описом алгоритму управління створює VHDL-модель керуючого пристрою, що інтерпретує даний алгоритм. Користувач описує алгоритм управління, для якого має бути синтезована схема керуючого пристрою. Для опису алгоритму управління буде використовуватися мова XML або графічний редактор блок-схем. Модуль містить деяку інформацію про створюваної ГСА: кількість ОЛЦ, логічних умов, наборів мікрооперацій, частку операторних вершин.

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

Процес синтезу логічної схеми пристрою буде виконаються в САПР Xilinx ISE WebPack вхідними даними для якої є файли VHDL-моделі КМУУ, а також параметри мікросхеми (сімейство, тип, корпус та ін), яка буде використана для реалізації схеми. Результатом синтезу логічної схеми КМПК в базисі сучасних мікросхем типу FPGA за допомогою САПР Xilinx буде файл звіту синтеза, який містить інформацію про кількість необхідних ресурсів мікросхеми та часових параметрах синтезованої схеми УУ. Інформація про кількість доступних ресурсів мікросхеми дозволяє зробити висновок про можливість реалізації схеми в даному елементному базисі, а порівняння часових параметрів до вимог до мінімально необхідного швидкодії пристрою ще й про доцільність такої реалізації.

Структура модуля проектування цифрових пристроїв представлена на рис. 5.

Структура модуля проектування цифровых пристроїв

Рисунок 5 – Структура модуля проектування цифровых пристроїв

Висновок

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

Таким чином, для реалізації даної програми необхідно мати один сервер для розгортання Spring-MVC додатки з виділеним реальним IP та окремий аккаунт для SSH доступу до кластеру NeClus. Базу даних можна розмістити на тому-ж сервері разом з web-додатком, чим скоротивши апаратурні витрати.

При написанні даного реферату магістерська робота ще не завершена. Остаточне завершення: грудень 2014 року. Повний текст роботи і матеріали по темі можуть бути отримані у автора або його керівника після зазначеної дати.

Список источников

  1. Методи синтезу композиційних мікропрограмних пристроїв керування з модифікацією системи адресації мікрокоманд. : дис. на соискание науч. степени канд. техн. наук : спец. 05.13.05 "Компьютерные системы и компоненты"/ Мирошкин А.Н. ; ДонНТУ. –Донецк – 2013 г. – 152 с.
  2. Java ЕЕ 6 nf сервер додатків GlassFish 3. Дэвид Хеффельфингер- М.: ДМК Пресс, 2013.-416 с.: ил.
  3. Розробка додатків Java ЕЕ 6 в NetBeans 7. Дэвид Хеффельфингер-М.: ДМК Пресс, 2013.-330 с.: ил.
  4. Spring в дії. Уоллс К. – М.: ДМК Пресс, 2013. – 752 с.: ил.
  5. Spring 3 для професіоналів. Роб Харроп, Кларенс Хо. – М.: Вильямс, 2012. – 880с.:ил.
  6. Vaadin. ММатеріал з Вікіпедії-вільної енциклопедії. Електронний ресурс. режим доступу: http://ru.wikipedia.org/wiki/Vaadin
  7. ORM. Матеріал з Вікіпедії-вільної енциклопедії. Електронний ресурс. режим доступу: http://ru.wikipedia.org/wiki/ORM
  8. Hibernate. Матеріал з Вікіпедії-вільної енциклопедії. Електронний ресурс. режим доступу: http://ru.wikipedia.org/wiki/Hibernate
  9. Прийоми об'єктно-орієнтованого проектування. Патерни проектування. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж.- СПб: Питер, 2001. — 368 с.: ил.
  10. Pro Spring MVC (The Expert`s Voice in Spring). – M. Deinum, K. Serneels, C. Yates – M.: Apress,2012. – 590c.:ил.