Створення автоматизованого робочого місця технолога станції

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

1. Розробка та аналіз технічного завдання

1.1 Опис предметної області

У рамках курсового проекту необхідно на основі СУБД розробити програму для автоматизації робочого місця технолога станції із застосуванням Web-технології.

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

На залізничному транспорті ведуться розробки та впровадження АРМ працівників масових професій, пов'язаних з управлінням інформаційним забезпеченням перевізного процесу.

Створення АРМ передбачає підвищення рівня використання пропускної здатності, підвищення продуктивності праці, поліпшення умов праці.

1.1.1 Призначення і класифікація станцій

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

Станцією називається роздільний пункт, що мають колійний розвиток, що дозволяє проводити операції з приймання, відправлення, схрещування і обгону поїздів. На станціях розміщені технічні пристрої, що забезпечують пропускну і провізну спроможність залізничних ліній: споруди та пристрої станційного господарства, локомотивні та вагонні депо, пункти технічного обслуговування вагонів і т.д. Від роботи станції в значній мірі залежать: забезпечення виконання плану перевезень пасажирів і вантажу; відправлення поїздів за графіком і у відповідності з планом формування поїздів - повними за масою і довжині, справними в технічному і комерційному відношенні; безпеку руху поїздів, їх приймання, відправлення, схрещування, обгону і маневрів; регулярність, своєчасність і збереження доставки вантажів; зниження собівартості перевезень; виконання комплексного показника роботи залізниць - обігу вагона (за час свого обороту вагон знаходиться в русі тільки 30% часу, а 70% - на станції).

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

1.1.2 Технічне оснащення станцій

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

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

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

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

1.2 Розробка технічного завдання

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

Система повинна забезпечувати достовірність даних, що вводяться;

Система повинна мати графічний інтерфейс;

Повинна захищати інформацію від посягань з боку неавторизованих користувачів;

Система повинна забезпечувати можливість додавання нових, зміни існуючих, видалення і пошук даних;

Система повинна виробляти журналювання виконуваних дій;

Система повинна забезпечувати одночасну роботу декількох технологів;

Система повинна працювати з безліччю довідкових таблиць (~ 200 шт.).

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

кількість робочих місць дорівнює 12, тому що стільки робочих місць технологів станцій;

час реакції системи на дії користувача повинно бути як можна менше.

У проектованої системі слід передбачити наявність декількох робочих місць: адміністратора, технологів.

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

Технолог може працювати у відповідності з правами, наданими йому адміністратором.

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

1.3 Техніко-економічне обгрунтування

Розглянемо можливі варіанти при вирішенні поставленої задачі.

Варіант № 1 «Новий АРМ - новий модуль роботи з довідниками»

При такому розвитку подій виходить, що кожен програміст при створенні нового АРМу пише модуль для роботи зі своїми довідниками. Це призведе до затягування впровадження АРМу.

Варіант № 2 «Використання DBACCESS»

DBACCESS - програма поставляється разом з СУБД Informix, призначена для написання і виконання запитів. Використання даного інструменту вкрай важко, крім того, він не забезпечує перевірку коректності введення даних. При цьому неминуче будуть з'являтися помилки, які важко потім буде відстежити.

Варіант № 3 «Використання попередніх розробок»

Використання попередніх розробок можливе в обмеженому обсязі, тільки при роботі з деякими довідниками. Структура довідкових таблиць змінюється, попередні АРМи мають «жорсткий» внутрішній алгоритм і підстроювання структури програми до структури змінених даних займе багато часу (зміна програми + тестування). Попередні розробки реалізовувалися на внутрішньому мові СУБД Informix 4 GL. Крім того, при зміні СУБД старі розробки довелося б переписувати заново.

Варіант № 4 «Розробка інформаційної системи»

Розробка інформаційної системи дозволить:

не залежати від використовуваної СУБД, тому що планований мову реалізації Java (доступ до СУБД через JDBC);

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

скоротити час інших розробок, тому що проектована ІС дозволить вводити дані в довідкові таблиці для кожного нового АРМу;

можливість одночасної роботи з ІС декількох користувачів;

Таким чином, розробка ІВ є найкращим варіантом вирішення поставленого завдання.

1.4 Аналіз технічного завдання

Проаналізуємо можливі варіанти реалізації висунутих вимог до створюваної інформаційної системи.

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

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

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

При введенні даних ІС посилає запити до сервера БД, який у відповідь посилає через мережу необхідний блок даних. Після отримання його система виконує дії, описані в конфігураційному файлі.

Висновок: Для побудови ІС розташуємо БД на виділеному сервері з доступом до нього через мережу. Інші способи реалізації в даному випадку не ефективні.

1.5 Вибір засобів вирішення виконання технічного завдання

Для вирішення поставленого завдання буде використаний СУБД Informix, тому що він використовується в даний час. Вибір СУБД Informix викликаний також необхідністю підтримки існуючих АРМів, більшість яких написані на PHP, 4 GL, ECSQL. Переваги Informix:

Має засоби забезпечення цілісності даних.

Informix підтримує мову SQL.

Informix дозволяє захищати бази даних на рівні користувачів.

У Informix 'e є засоби для організації спільного доступу до бази даних і механізм блокування записів.

MS SQL Server і DB 2 мають таку ж продуктивність і масштабованість як і Informix, забезпечують підтримку великих баз даних, але в даний час використовується Informix.

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

СУБД Informix фізично розташований на сервері під управлінням ОС Unix. Фізичний сервер повинен залишатися працездатним при одночасному зверненні 12 користувачів, тобто мати достатню: обчислювальну потужність, кількість пам'яті і вільного простору жорсткому диску достатнього для розміщення ОС і БД.

На стороні клієнта буде використовуватися один з Web-броузерів (Internet Explorer, Netscape, Opera або Mozilla).

З причини переходу, найближчим часом, на СУБД Oracle 8.1.7 вибирається мову реалізації Java, доступ до БД буде здійснюватися через JDBC. Застосування JDBC дозволить, не змінюючи внутрішнього вмісту програми, легко перейти на іншу СУБД шляхом зміни JDBC-драйвера.

2 Розробка моделі процесів об'єкта професійної діяльності

2.1 Побудова моделі прецедентів

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

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

Рисунок 2.1 - Діаграма прецедентів використання системи

2.1.1 Прецедент «Введення інформації за спеціалізацією шляхів»

Основний виконавець: технолог.

Зацікавлені особи та їхні вимоги

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

Адміністрація станція. Хоче швидко сформувати поїзд і швидко відправити його за призначенням.

ГЖД. Хоче швидко перевезти вантаж і задовольнити інтереси одержувача вантажу.

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

Передумови

Технолог аутентифікований.

Результати (Післяумови)

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

Основний (успішний) сценарій

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

Система читає конфігураційний файл, що описує логіку введення інформації;

Система показує форму для введення даних;

Технолог вибирає шлях, на якому буде сформований поїзд;

Вибирає станцію призначення майбутнього поїзда;

Вибирає домінуюче призначення майбутнього поїзда;

Вибирає супутнє призначення;

Система аналізує вибрані призначення і виставляє прапор домінуючого призначення в true;

Система вибирає з таблиці призначення плану формування значення:

Мінімальна і максимальна значення графікових довжини;

Мінімальна і максимальна значення графікових ваги.

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

Альтернативні сценарії.

У разі невдалої аутентифікації технолога, він повинен звернутися до адміністратора, з проханням надати йому доступ до БД. Реалізується засобами Unix, Web-сервера і СУБД.

2.2 Побудова моделі процесів

На основі моделі прецедентів побудуємо модель процесів в методології IDEF 0. Модель IDEF 0 являє собою сукупність робіт, яка перетворює входи на виходи з використанням механізмів і управління. Моделі процесів допомагають зрозуміти особливості функціонування системи та взаємодії з зовнішнім середовищем. Для визначення контексту моделі процесів необхідно задати область моделювання, мета моделювання і точку зору. Як приклад побудуємо модель для процесу введення інформації у довідник «Спеціалізація шляхів».

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

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

Точка зору. Модель будується з точки зору розробника даної системи. Основна робота, вироблена системою, - «Введення довідкової інформації». На вхід системи надходять різна інформація залежно від призначення довідника.

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

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

3 Розробка моделі даних об'єкта професійної діяльності

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

Сутність Спеціалізація колій повинна містити:

Ідентифікатор;

Номер шляху, на якому буде сформований поїзд;

Код станції, до якої піде поїзд (ідентифікатор із сутності Станції);

Домінуюче напрямок, у якому напрямку піде потяг;

Супутнє напрямок, через який напрямок буде проходити потяг;

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

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

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

Сутність Станції повинна містити:

Ідентифікатор;

ЕСР станції, код станції описаний в класифікації МПС;

Код дороги, до якої дорозі належить станція;

Найменування станції, як називається станція (наприклад, Оріхово);

Короткий найменування станції, скорочення (наприклад, Орх.);

Код шляху, з якого шляху відправляється поїзд в Орехово (ідентифікатор із сутності Станційні колії).

Сутність Станційні колії повинна містити:

Ідентифікатор;

Номер шляху, числовий номер колії;

Номер шляху, числовий номер шляхи для АСОУП;

Умовна довжина шляху;

Код станції, код станції куди з даного шляху відправляється поїзд;

Сутність Призначення плану формування повинна містити:

Ідентифікатор;

Код станції, станція до якої йде поїзд;

Графікових довжина хв. і макс., який макс. і мін. довжини може бути потяг, який прийде до даної станції;

Графікових вага хв. і макс., який макс. і мін. вага може бути в поїзда, який прийде до даної станції.

У ERWin можна задавати ідентифікують і неидентифицирующей зв'язку

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

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

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

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

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

4 Зв'язок моделі даних з моделлю процесів

При проектуванні інформаційної системи необхідно вказати розробнику які дії, над якими даними може виконувати конкретна робота. Для цього використовується зв'язок моделі даних, побудованої в ERWin та моделі процесів, побудованої в BPWin. Простежимо процес перетворення даних при введенні даних в сутність «Спеціалізація шляхів».

Робота системи починається з завантаження файлу конфігурації. При цьому відбувається читання і відображення вмісту сутності «Спеціалізація шляхів», а також підготовка форми для введення вихідних даних. Після цього Вихідні дані і Готова форма для введення надходять в якості вхідних даних у роботу Введення вих. даних.

В якості управління виступає Вибір, а в якості механізму Технолог та Система.

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

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

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

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

На вхід роботі Аналіз введеної інформації, надходять: Код станції, Код домінуючого напрямку, Код супутнього спрямування. Тут відбувається порівняння кодів призначень і установка Прапора домінування.

На підставі попередніх результатів та коду станції система вибирає з сутності «Призначення плану формування» максимальне і мінімальне значення графікових довжини і на підставі тільки Коду станції вибирається максимальне і мінімальне значення графікових ваги.

5 Розрахунки та оцінки

5.1 Розрахунок необхідних ресурсів обчислювальних засобів

Реалізація системи передбачається на мові Java. Вимоги до ресурсів обумовлені в основному мінімальними вимогами для нормального функціонування ОС і бібліотек Java.

Вимоги для комп'ютера технолога:

Процесор: Pentium 200 або вище.

Пам'ять: Для Windows 95 або Windows 98: 64 Мб пам'яті для операційної системи.

Для Windows NT 4.0: 128 Мб пам'яті для операційної системи.

Жорсткий диск: 1 Гб.

Монітор: Монітор SVGA 17''.

Розрахуємо приблизний обсяг збережених даних для оцінки необхідного вільного місця на жорсткому диску. Кожен запис в Спеціалізації шляхів займає близько 40 байт. 5000 записів займе 200 Кбайт. Запис про Станції буде приблизно займати 50 байт і при зберіганні 60000 станцій обсяг складе 3Мбайта. Решта сутності в цілому будуть займати приблизно 1Мбайт. Таким чином, для зберігання річної інформації, за умови, що за добу буде надіслано 20 поїздів до 100 станцій, буде потрібно 365 * 40 * 20 * 100 = 29200000 байт. Таким чином, для зберігання річної інформації про 20 поїздах йдуть до 100 станцій на добу потрібно 30 Мбайт. Весь цей обсяг даних буде зберігатися на окремому диску, на сервері, крім цього там будуть зберігатися щоденні копії БД (так званих level backup), що додатково потребуватиме близько 2 Мбайт. Вимоги до сервера БД пов'язані з тим, що всі дії (операції) з БД буде виконувати саме сервер БД, а комп'ютер технолога буде тільки відображати результат дій сервера. Крім того, цей сервер буде використаний для роботи інших АРМів і на ньому працюватимуть кілька різних БД (10-15).

Вимоги для сервера БД:

Процесор: Pentium II 400 або вище.

Пам'ять: 512 Мб.

Жорсткі диски: 4,3 Гб для системи + 10 Гб для зберігання баз даних.

Монітор: Монітор SVGA 14''(може бути відсутнім).

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

5.2 Розрахунок за функціонально-орієнтованої метриці

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

Рис. 5.2

При розрахунках за функціонально-орієнтованої метриці використовується 5 інформаційних характеристик:

1. Кількість зовнішніх вводів: 1 (кнопка OK); даний елемент вводу складається з 7 елементів даних (1 поле введення, 5 полів зі списком, 1 командна кнопка).

2. Кількість зовнішніх висновків: 1 (повідомлення повідомлення); елемент виведення складається з 1 елементу даних (командна кнопка).

3. Кількість зовнішніх запитів: 0.

4. Кількість внутрішніх логічних файлів: 4 (довідник ДомінірующееНаправленіе, довідник сопутствующееНаправленіе, таблиця Станції, таблиця Шляху); таблиця Станції складається з 6 елементів даних, довідник ДомінірующееНаправленіе, довідник сопутствующееНаправленіе і таблиця Станції - із 3.

5. Кількість зовнішніх інтерфейсних файлів: 0.

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

Після збору всієї необхідної інформації підрахуємо загальну функціональну метрику (таблиця 5.2).

Таблиця 5.2

Аналогічним чином розрахуємо функціональність другого типу для користувача форми (рисунок 5.2). Результати розрахунку в таблиці 5.2.

Таблиця 5.2

З урахуванням того, що в проекті передбачається використання 3 призначених для користувача форм першого типу та 2 призначених для користувача форм другого типу, підрахуємо загальну функціональну метрику для всього проекту:

FP = 3 * 36 + 2 * 32 = 172

Отриману загальну метрику необхідно суб'єктивним чином зважити, використовуючи наступну формулу:

FP = Общее_колічество * (0,65 + 0,01 * å ¹⁴ _{i = 1} F _i), (5.1)

де F _i - коефіцієнти регулювання складності.

Таблиця 5.3 - Визначення системних параметрів програми

Кожен коефіцієнт може приймати наступні значення: 0 - немає впливу, 1 - випадкове, 2 - невелике, 3 - середнє, 4 - важливе, 5 - основне.

Значення вибираються емпірично внаслідок відповіді на 14 запитань, які характеризують системні параметри програми (таблиця 5.3).

У результаті кількість функціональних покажчиків одно:

FP = 172 * (0.65 + 0.29) = 162

Використовуючи таблицю перекладу, а також враховуючи, що реалізація ІС передбачається з використанням мови Visual Basic, отримаємо LOC-оцінку проекту: 162 * 32 = 5184 (рядків коду).

Висновок

У рамках даного курсового проекту була спроектована система введення довідкової інформації для робочого місця технолога. На основі вимог технічного завдання була розроблена модель даних у середовищі ERWin в стандарті IDEF 1 X. На прикладі основного процесу, що відбувається в системі - введення інформації до деяких довідники була показана послідовність перетворення даних - зв'язок моделі даних з моделлю процесів.

Система реалізується за допомогою СУБД Informix з використанням мови Java. Ця СУБД була обрана в зв'язку з тим, що дана СУБД використовується в даний час.

Мова Java була обрана на увазі спрямованості відділу ВЦЛП на Web-розробку, а також через перехід на іншу СУБД (Oracle 8.1.7) з метою зниження можливих змін внутрішнього змісту програми.

Бібліографічний список

Сервери корпоративних баз даних. Www.citforum.ru;

П. Ноутон, Г. Шільдт. Java ^тм 2: Пер. з англ .- СПб.: БХВ-Петербург, 2001.