ПРИКЛАД2: Перенесення успадкованого рішення з мэйнфрейму

Компанія Xenergy була заснована в 1975 році, у самий розпал енергетичної кризи на Заході. Її єдиним продуктом була програма Xencap, яка призначала для оптимізації споживання електроенергії, природного газу й комунальних послуг за рахунок збору статистичних даних і їх наступного аналізу. Економія різних підприємств, держустанов і приватних домовласників від застосування цієї програми виявилася настільки відчутної, що вона одержала широке поширення в США й Канаді.

Одним з компонентів системи був модуль друку, уведення й обробки опитувачів для приватних споживачів енергії, що дозволяв енергетичним корпораціям і комунальним службам планувати піки навантажень і уникати криз у поставках для безлічі малих клієнтів. Завдяки поширенню Internet з'явилася можливість полегшити процедуру заповнення опитувачів. Крім того, в останні роки продажам Xencap стала заважати застаріла платформа: код на PL/1 і комп'ютери DEC VAX із СКБД DB2. Підтримка системи обходилася усе дорожче.

Були сформульовані наступні цілі реінжинірингу:

перейти на сучасну платформу з умовою повернення інвестицій за три роки;

забезпечити масштабованість «в обидва боки» — від малого до дуже великої кількості користувачів;

перевести опитувачі й АРМ уведення первинної інформації на Web-технології, щоб усунути необхідність в адмініструванні клієнтських станцій;

автоматизувати імпорт даних і обробку опитувачів;

спростити адміністрування системи, створивши зручний АРМ супровідного персоналу.

Був оголошений тендер на реалізацію проекту. Обрана пропозиція містила в собі повне техніко-економічне обґрунтування рекомендованого підходу до реінжинірингу системи. Замовникові був представлений порівняльний аналіз можливих цільових серверів додатків (Java/J2EE/EJB і VC++/COM+) і серверів баз даних (Oracle, DB2, SQL Server). Більше того, була зроблена попередня оцінка сукупної вартості володіння системою з урахуванням усіх робіт, витрат на ліцензії й вимог до супроводу для платформ IBM, Sun Microsystems, Oracle, BEA Systems і Microsoft. В Xenergy зупинили свій вибір на рішенні, заснованому на технологіях Microsoft; для збереження гомогеності платформи й зниження загальної вартості володіння було намічено забезпечити підтримку тільки одного сервера бази даних.

Виявилося, однак, що вихідні тексти PL/1 минулого не документовані, а закладена в програму математична модель ніде не була описана. Аналітикам підрядника довелося провести зворотне проектування («реверс-інжиніринг«), щоб відновити алгоритми, розібратися в структурі даних і призначенні тих або інших частин системи. Лише після документування математичної моделі вдалося приступитися до проектування системи.

Розроблювачі створили прототип користувацького інтерфейсу, який був погоджений із представниками замовника й удосконалений у ході тестування. Технічна реалізація містила в собі перенесення математичних розрахунків на VC++; при цьому використовувалися механізми розподілених обчислень і балансування навантаження для реалізації вимог масштабованості. Був перероблений функціонал створення й обробки опитувачів, і персонал Xenergy зміг за допомогою візуального конструктора складати списки питань і варіанти відповідей, розширюючи реквізити форм.

Для підтримки нових функцій при переході з DB2 на SQL Server була перепроектована структура бази даних, але спадкоємність збереглася. Сьогодні розрахункове ядро системи засноване на структурі даних і алгоритмах, створених в 1975 році й повністю «реставрованих».

Поради й висновки

Не можна повністю довіряти виробникам, постачальникам і консультантам, які говорять про стандарти, що гарантують переносність і сумісність. Підтвердженням цього може послужити цитата із книги Майка Вилсона «Різниця між Богом і Ларри Эллисоном»: «Переносна програма подібна танцюючої свині. Разюче не те, наскільки добре свиня танцює, а сам факт того, що вона танцює». Ці рядки були написані на зорі становлення індустрії розробки програмного забезпечення, але проблеми міграції актуальні дотепер.

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

Відмінності є й на рівні серверів додатків: обіцяна стосовно всіх Java-платформ сумісність зі стандартом J2EE не завжди виявляється повною.

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

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

Ще одна розповсюджена омана така: при перенесенні рішення на нову платформу або його створенні «з нуля» досить лише доповнити колишню функціональність новими можливостями — відповідно до вимог, що змінилися. Як показує досвід, кількість побажань, що нагромадилися, і зауважень може вилитися в переосмислення всього функціонала, користувацького інтерфейсу й архітектури системи в цілому. Яскравий приклад — засоби розробки 4GL, популярні в часи архітектури «клієнт-сервер». Вони не зуміли адаптуватися до Web-технологій, тому багатоланцюгова архітектура, яка імітується середовищем виконання 4GL-програм, вийшла досить великоваговою.

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

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