Дії, що виконуються в процесі переходу

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

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

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

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

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

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

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

Одна загальна помилка, яка робиться в процесі переходу, полягає в недооцінці ресурсів, необхідних для підтримки постійного використання складних CASE-засобів. Зростання необхідних ресурсів викликається трьома причинами:

• Складністю засобів
• Частотою появи нових версій
• Взаємодією між засобами і зовнішнім середовищем.

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

Оцінка результатів переходу

Програма постійної оцінки якості і продуктивності ПО має важливе значення для наступного:

• Визначення ступеня вдосконалення процесів
• Попередження можливих стратегічних прорахунків
• Своєчасної відмови від використання застарілої технології.

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

• Використаний час
• Час, виділений персонально для конкретних фахівців
• Розмір, складність і якість ПО
• Зручність супроводу.

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

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

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

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

 

Характеристики CASE-засобів

5.1. Silverrun+JAM

Silverrun

CASE-засіб Silverrun американської фірми Сomputer Systems Advisers, Inc. (CSA) використовується для аналізу і проектування ІС бізнес-класу [22] і орієнтоване більшою мірою на спіральну модель ЖЦ. Вони застосовуються для підтримки будь-якої методології, заснованої на роздільній побудові функціональної і інформаційної моделей (діаграм потоків даних і діаграм "сутність-зв'язок").

Налаштування на конкретну методологію забезпечується вибором необхідної графічної нотації моделей і набору правил перевірки проектних специфікацій. В системі є готові настройки для найпоширеніших методологій: DATARUN (основна методологія, що підтримується Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для кожного поняття, введеного в проекті є можливість додавання власних описувачів. Архітектура Silverrun дозволяє нарощувати середовище розробки в міру необхідності.

Структура і функції

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

Модуль побудови моделей бізнес-процесів у формі діаграм потоків даних (BPM - Business Process Modeler) дозволяє моделювати функціонування обстежуваної організації або створюваної ІС. В модулі BPM забезпечена можливість роботи з моделями великої складності: автоматична зміна нумерації, робота з деревом процесів (включаючи візуальне перетягування гілок), від'єднання і приєднання частин моделі для колективної розробки. Діаграми можуть зображатися в декількох визначених нотаціях, включаючи Yourdon/DeMarco і Gane/Sarson. Існує можливість створювати власні нотації, у тому числі додавати в число дескрипторів, що зображаються на схемі, визначені користувачем поля.

Модуль концептуального моделювання даних (ERX - Entity-Relationship eXpert) забезпечує побудову моделей даних "сутність-зв'язок", не прив'язаних до конкретної реалізації. Цей модуль має вбудовану експертну систему, що дозволяє створити коректну нормалізовану модель даних за допомогою відповідей на змістовні питання про взаємозв'язок даних. Можлива автоматична побудова моделі даних з описів структур даних. Аналіз функціональної залежності атрибутів дає можливість перевірити відповідність моделі вимогам третьої нормальної форми і забезпечити їх виконання. Перевірена модель передається в модуль RDM.

Модуль реляційного моделювання (RDM - Relational Data Modeler) дозволяє створювати моделі "сутність-зв'язок", призначені для реалізації в реляційній базі даних, що деталізуються. В цьому модулі документуються всі конструкції, пов'язані з побудовою бази даних: індекси, тригери, процедури, що зберігаються і т.д. Гнучка змінна нотація і розширюваність репозиторія дозволяють працювати за будь-якою методологією. Цей модуль забезпечує проектування і повне документування реляційних баз даних.

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

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

Взаємодія з іншими засобами

Для автоматичної генерації схем баз даних у Silverrun існують мости до найпоширеніших СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачі даних в засоби розробки додатків є мости до мов 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Всі мости дозволяють завантажити в Silverrun RDM інформацію з каталогів відповідних СУБД або мов 4GL. Це дозволяє документувати, перепроектувати або переношувати на нові платформи бази даних і прикладні системи, що вже знаходяться в експлуатації. При використовуванні моста Silverrun розширює свій внутрішній репозиторій специфічними для цільової системи атрибутами. Після визначення значень цих атрибутів генератор додатків переносить їх у внутрішній каталог середовища розробки або використовує при генерації коду на мові SQL. Таким чином можна повністю визначити ядро бази даних з використанням всіх можливостей конкретної СУБД: тригерів, процедур, що зберігаються, обмежень посилальної цілісності. При створенні додатку на мові 4GL дані, перенесені з репозиторія Silverrun, використовуються або для автоматичної генерації інтерфейсних об'єктів, або для швидкого їх створення вручну.

Для обміну даними з іншими засобами автоматизації проектування, створення спеціалізованих процедур аналізу і перевірки проектних специфікацій, складання спеціалізованих звітів відповідно до різних стандартів в системі Silverrun є три способи видачі проектної інформації в зовнішні файли:

• Система звітів. Можна, визначивши вміст звіту по репозиторію, видати звіт в текстовий файл. Цей файл можна потім завантажити в текстового редактора або включити в інший звіт;
• Система експорту/імпорту. Для більш повного контролю над структурою файлів в системі експорту/імпорту є можливість визначати не тільки вміст експортного файлу, але і роздільники записів, полів в записах, маркери початку і кінця текстових полів. Файли з вказаною структурою можна не тільки формувати, але і завантажувати в репозиторій. Це дає можливість обмінюватися даними з різними системами: іншими CASE-засобами, СУБД, текстовими редакторами і електронними таблицями;
• Зберігання репозиторія в зовнішніх файлах через ODBC-драйвери. Для доступу до даних репозиторія з найпоширеніших систем управління базами даних забезпечена можливість берегти всю проектну інформацію безпосередньо у форматі цих СУБД.

Групова робота

Групова робота підтримується в системі Silverrun двома способами:

• В стандартній розрахованій на одного користувача версії є механізм контрольованого розділення і злиття моделей. Розділивши модель на частини, можна роздати їх декільком розробникам. Після детальної доробки моделі об'єднуються в єдині специфікації;
• Мережна версія Silverrun дозволяє здійснювати одночасну групову роботу з моделями, що зберігаються в мережному репозиторії на базі СУБД Oracle, Sybase або Informix. При цьому декілька розробників можуть працювати з однією і тією ж моделлю, оскільки блокування об'єктів відбувається на рівні окремих елементів моделі.

Середовище функціонування

Silverrun реалізований на трьох платформах - MS Windows, Macintosh і OS/2 Presentation Manager - з можливістю обміну проектними даними.

Для функціонування в середовищі Windows необхідно мати комп'ютер з процесором моделі не нижче i486 і оперативну пам'ять об'ємом не менше 8 Мб (рекомендуються 16 Мб). На диску повна інсталяція Silverrun займає 20 Мб.

JAM

Засіб розробки додатків JAM [28] (JYACC's Application Manager) - продукт фірми JYACC (США). В даний час поставляється версія JAM 7 і готується до виходу JAM 8.

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

Структура і функції

JAM має модульну структуру і складається з наступних компонент:

• Ядро системи;
• JAM/DBi - спеціалізовані модулі інтерфейсу до СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC і т.д.);
• JAM/RW - модуль генератора звітів;
• JAM/CASEi - спеціалізовані модулі інтерфейсу до CASE-засобів (JAM/CASE-TeamWork, JAM/CASE-Innovator і т.д.);
• JAM/TPi - спеціалізовані модулі інтерфейсу до менеджерів транзакцій (наприклад, JAM/TPi-Server TUXEDO і т.д.);
• Jterm - спеціалізований емулятор X-терміналу.

Ядро системи (власне, сам JAM) є закінченим продуктом і може самостійно використовуватися для розробки додатків. Всі решта модулі є додатковими і самостійно використовуватися не можуть.

Ядро системи включає наступні основні компоненти:

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

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

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

В ядро JAM вбудована розрахована на одного користувача реляційна СУБД JDB. Основним призначенням JDB є прототипізація додатків в тих випадках, коли робота з штатною СУБД неможлива або недоцільна. В JDB реалізований необхідний мінімум можливостей реляційних СУБД за винятком індексів, процедур, що зберігаються, тригерів і представлень (view). За допомогою JDB можна побудувати БД, ідентичну цільовій БД (з точністю до відсутніх в JDB можливостей) і розробити значну частину додатку.

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

Утиліти JAM включають три групи:

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

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

Додатки, розроблені з використанням JAM, не вимагають так званих виконавчих (run-time) систем і можуть бути виготовлені у вигляді виконуваних модулів. Для цього розробник повинен мати компілятор С і редактор зв'язків. Для виготовлення промислової версії до складу JAM входить файл збірки (makefile), початкові тексти (на мові С) ряду модулів додатку і необхідні бібліотеки.

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

З погляду реалізації логіки додатку JAM є подія-орієнтованою системою. В JAM визначений набір подій, що включає відкриття і закриття вікон, натиснення клавіші клавіатури, спрацьовування системного таймера, отримання і передача управління кожним елементом екрану. Розробник реалізує логіку додатку шляхом визначення обробника кожної події. Наприклад, обробник події "натиснення кнопки на екрані" (мишею або за допомогою клавіатури) може відкрити наступне екранне вікно. Обробниками подій в JAM можуть бути як вбудовані функції JAM, так і функції, написані розробником на С або JPL. Набір вбудованих функцій включає більше 200 функцій різного призначення. Вбудовані функції доступні для викликів С функцій, написаних як на JPL, так і на С.

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

• виконуваний модуль інтерпретатора додатку. В цей модуль можуть бути вбудовані функції, написані розробниками на мовах 3-го покоління;
• екрани, що становлять сам додаток (можуть поставлятися у вигляді окремих файлів, у складі бібліотек екранів або ж бути вбудовані в тіло інтерпретатора);
• зовнішні JPL-модулі. Можуть поставлятися у вигляді текстових файлів або в прекомпільованому вигляді, причому прекомпільовані зовнішні JPL-модулі можуть бути як у вигляді окремих файлів, так і у складі бібліотек екранів;
• файли конфігурації додатку - файли конфігурації клавіатури і терміналу, файл системних повідомлень, файл загальної конфігурації.

Взаємодія з іншими засобами

Безпосередню взаємодію з СУБД реалізують модулі JAM/DBi (Data Base interface). Способи реалізації взаємодії в JAM розділяються на два класи: ручні і автоматичні. При ручному способі розробник додатку самостійно пише запити на SQL, в яких як джерелами, так і адресатами прийому результатів виконання запиту можуть бути як інтерфейсні елементи візуально спроектованого зовнішнього рівня, так і внутрішні, невидимі для кінцевого користувача змінні. Автоматичний режим, реалізовуваний менеджером транзакцій JAM, здійснимо для типових і найпоширеніших видів операцій з БД, так званих QBE (Query Example - запити за зразком), з урахуванням достатньо складних взаємозв'язків між таблицями БД і автоматичним управлінням атрибутами екранних полів уведення-виведення залежно від виду транзакції (читання, запис і т.д.), в якій бере участь згенерований запит.

JAM дозволяє будувати додатки для роботи більш ніж з 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-сумісні СУБД і ін.

Відмінною рисою JAM є високий рівень інтеграції додатків між різними платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS і ін.). Може бути потрібно лише "перемальовувати" статичні текстові поля на екранах з російським текстом при перенесенні між середовищами DOS-Windows-UNIX. Крім того, інтеграція полегшується тим, що в JAM додатки розробляються для віртуальних пристроїв уведення-виведення, а не для фізичних. Таким чином при перенесенні додатку з платформи на платформу, як правило, вимагається лише визначити відповідність між фізичними пристроями уведення-виведення і їх логічними уявленнями для додатку.

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

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

Інтерфейс JAM/CASE маєподібний інтерфейс до СУБД і дозволяє здійснити обмін інформацією між репозиторієм об'єктів JAM і репозиторієм CASE-засобу аналогічно тому, як структура БД імпортується в репозиторій JAM безпосередньо з БД. Відмінність полягає в тому, що у вирадку інтерфейсу до CASE цей обмін є двонаправленим. Окрім модулів JAM/CASEi, існує також модуль JAM/CASEi Developer's Kit. За допомогою цього модуля можна самостійно розробити інтерфейс (тобто спеціалізований модуль JAM/CASEi) для конкретного CASE-засобу, якщо готового модуля JAM/CASEi для нього не існує.

Міст (інтерфейс) Silverrun-RDM <-> JAM реалізує взаємодію між CASE-засобом Silverrun і JAM (перенесення схеми бази даних і екранних форм додатку між CASE-засобом Silverrun-RDM і JAM версії 7.0). Даний програмний продукт має 2 режими роботи:

• прямий режим (Silverrun-RDM->JAM) призначений для створення об'єктів CASE-словника і елементів репозиторія JAM на основі представлення схем в Silverrun-RDM. В цьому режимі міст дозволяє, виходячи з представлення моделей даних інтерфейсу в Silverrun-RDM, генерувати екрани і елементи репозиторія JAM. Міст перетворить таблиці і відносини реляційних схем RDM в послідовність об'єктів JAM відповідних типів. Методика побудови моделей даних інтерфейсу в Silverrun-RDM припускає вживання механізму підсхем для прототипування екранів додатку. По опису кожної з підсхем RDM міст генерує екранну форму JAM;
• зворотний режим (JAM->Silverrun-RDM) призначений для перенесення модифікацій об'єктів CASE-словника в реляційну модель Silverrun-RDM.

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

Групова робота

Ядро JAM має вбудований інтерфейс до засобів конфігураційного управління (PVCS на платформі Windows і SCCS на платформі UNIX). Під управлінням цих систем передаються бібліотеки екранів и/или репозиторії. За відсутності таких систем JAM самостійно реалізує частину функцій підтримки групової розробки.

Використання PVCS є більш переважним в порівнянні з SCCS, оскільки дозволяє організувати єдиний архів модулів проекту для всіх платформ. Оскільки JAM на платформі UNIX не має прямого інтерфейсу до архівів PVCS, то вибірка модулів з архіву і повернення їх в архів проводяться з використанням PVCS Version Manager. На платформі MS-Windows JAM має вбудований інтерфейс до PVCS і дії по вибірці/поверненню проводяться безпосередньо з середовища JAM.

Середовище функціонування

JAM, як середовище розробки, і додатки, побудовані з його використанням, не є ресурсоємними системами. Наприклад, на платформі MS-Windows достатньо мати 8MB оперативної пам'яті і 50 MB дискового простору для середовища розробки. На UNIX-платформах вимоги до апаратури визначаються самою операційною системою.

5.2. Vantage Team Builder (Westmount I-CASE) + Uniface