PrIS

211

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

Діаграма потоків даних першого рівня подана на рис. 12.12. Перших два процеси (1.1 та 1.2) реалізують такі функції працівника

біржі праці:

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

Збереження та оперативне опрацювання – збереження зазначених потоків даних у сховищах даних V.Вакансії та О.замовники; виділення із вказаних даних класифікаційних ознак та збереження їх у сховищі даних С.Класифікатори;

Рис. 12.12 Діаграма потоків даних процесу “Співставлення вимог”.

Експорт інформації – надання зацікавленим особам інформації про нові вакансії, нових замовників тощо (інформаційні потоки інформація про нові вакансії та інформація про нових замовників). Фактично,

здійснюється рекламна діяльність замовлень та вакансій.

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

212

Аналіз замовлень призначений для підтримки процесу пошуку та прийняття рішень щодо вказаної частини роботи працівника біржі праці. Розглянемо цей процес детальніше (рис. 12.13).

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

Наведемо пояснення до діаграм потоків даних, зображених на рис. 12.12 - 12.13.

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

Рис. 12.13 Деталіація процесу Аналіз завмовлень.

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

215

Рис. 12.16. ERD-діаграма ПО Біржа праці.

216

РОЗДІЛ 13. Характеристики CASE-засобів

Silverrun+JAM

Vantage Team Builder (Westmount I-CASE) + Uniface

Урозділі описано CASE-засоби.

13.1. Silverrun+JAM

13.1.1. Silverrun

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

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

Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для кожного поняття, введеного у проекті є можливість додавання власних описів. Архітектура Silverrun дозволяє нарощувати середовище розроблення у міру необхідності.

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

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

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

Модуль концептуального моделювання даних (ERX — EntityRelationship eXpert) забезпечує побудову моделей даних "сутністьзв'язок", не прив'язаних до конкретної реалізації. Цей модуль має вбудовану експертну систему, що дозволяє створити коректну

217

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

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

Менеджер репозиторію робочої групи (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, використовуються або для автоматичного ґенерування інтерфейсних об'єктів, або для швидкого їх створення вручну.

219

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 вбудована розрахована на одного користувача реляційна СКБД JDB. Основним призначенням JDB є прототипування застосувань у тих випадках, коли робота зі штатною СКБД неможлива або недоцільна. У JDB реалізований необхідний мінімум можливостей реляційних СКБД за винятком індексів, збережених процедур, триґерів і переглядів (view). За допомогою JDB можна побудувати БД, ідентичну до цільової БД (з точністю до відсутніх в JDB можливостей) і розробити значну частину застосування.

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

конвертори файлів екранів JAM у текстові. JAM зберігає екрани у вигляді двійкових файлів власного формату. У ряді випадків (наприклад, для виготовлення програмної документації проекту) необхідний текстовий опис екранів;

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

220

обслуговування бібліотек екранів (традиційні операції з

бібліотеками).

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

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

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

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

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 і ін.).

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

Міст (інтерфейс) SILVERRUN-RDM <-> JAM реалізує взаємодію між CASE-засобом Silverrun і JAM (перенесення схеми бази даних і