12.2.3. Концептуальна модель

Зовнішніми сутностями системи біржі праці є праценаймачі (надалі вакансії) та працешукачі (надалі замовники).

Побудуємо контекстну діаграму предметної області засобами Visio рис. 12.11).

Рис. 12.11 Контекстна діаграма

Процес 1 «Співставлення вимог» розбивається на три основних процеси: 1.1. “Облік замовлень”, 1.2. “Облік вакансій”, 1.3. “Аналіз замовлень”, 1.4. “Перекваліфікація”.

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

Вхідними потоками даних є резюме та заявки на вакансії від фірм-роботодавців.

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

Діаграма потоків даних першого рівня подана на рис. 12.12.

Перших два процеси (1.1 та 1.2) реалізують такі функції працівника біржі праці:

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

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

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

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

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

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

Приведемо пояснення до діаграм потоків даних, зображених на рис. 4.12 - 4.13.

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

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

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

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

Сховище оцінених замовлень містить проміжні результати аналізу. Результатом аналізу даних сховища FZ можуть бути нові класифікатори, ознаки “ненадійних” замовлень або вакансій тощо.

Сховища даних «Замовлення» та «Вакансії» повинні містити однакову за структурою інформацію, що характеризує вміння та навички працівника.

У сховищі Освітньо-кваліфікаційна характеристика фахівця зберігається нормативні документи, які встановлюють:

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

• систему соціально-професійних і професійних задач;

• сукупність і рівень сформованості вмінь і знань, необхідних для вирішення соціально-професійних і професійних задач;

• вимоги до атестації випускників навчальних закладів.

Ієрархію задач біржі праці подамо на рис. 12.14.

Рис. 12.14 Ієрархія задач системи

Діаграма об'єктів-зв'язків у нотації Чена для моєї ПрО “Біржа праці” подана на рис. 12.15.

Рис. 12.15. Діаграма об'єктів-зв'язків у нотації Чена ПрО “Біржа праці”

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

РОЗДІЛ 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 - Entity-Relationship eXpert) забезпечує побудову моделей даних "сутність-зв'язок", не прив'язаних до конкретної реалізації. Цей модуль має вбудовану експертну систему, що дозволяє створити коректну нормалізовану модель даних за допомогою відповідей на змістовні питання про взаємозв'язок даних. Можлива автоматична побудова моделі даних з описів структур даних. Аналіз функціональних залежностей атрибутів дає можливість перевірити відповідність моделі вимогам третьої нормальної форми і забезпечити їх виконання. Перевірена модель передається в модуль 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, використовуються або для автоматичної генерації інтерфейсних об'єктів, або для швидкого їх створення вручну.

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

• Система звітів. Можна, визначивши вміст звіту по репозиторію, записати звіт у текстовий файл. Цей файл можна потім завантажити у текстовий редактор або включити в інший звіт;

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

• Зберігання репозиторія у зовнішніх файлах через ODBC-драйвери. Для доступу до даних репозиторія з найпоширеніших систем управління базами даних забезпечена можливість зберігати усю проектну інформацію безпосередньо у форматі цих СКБД.

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

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

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

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

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

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

13.1.2. JAM

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

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

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

Одним з додаткових модулів 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 (перенесення схеми бази даних і екранних форм застосування між CASE-засобом SILVERRUN-RDM і JAM версії 7.0).

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

13.2.1. Vantage Team Builder (Westmount I-CASE)

Vantage Team Builder [14] є інтегрованим програмним продуктом, орієнтованим на реалізацію каскадної моделі ЖЦ ПЗ і підтримання повного ЖЦ ПЗ.

Vantage Team Builder забезпечує виконання наступних функцій:

• проектування діаграм потоків даних, "сутність-зв'язок", структур даних, структурних схем програм і послідовностей екранних форм;

• проектування діаграм архітектури системи - SAD (проектування складу і зв'язку обчислювальних засобів, розподіли завдань системи між обчислювальними засобами, моделювання зв’язків типу "клієнт-сервер", аналіз використання менеджерів транзакцій і особливостей функціонування систем у реальному часі);

• генерація кодів програм на мові 4GL цільової СКБД з повним забезпеченням програмного середовища і генерація SQL-кода для створення таблиць БД, індексів, обмежень цілісності і збережених процедур;

• програмування на мові C з вбудованою SQL;

• керування версіями і конфігурацією проекту;

• розрахований на багато користувачів доступ до репозиторія проекту;

• генерація проектної документації по стандартних і індивідуальних шаблонах;

• експорт і імпорт даних проекту у форматі CDIF (CASE Data Interchange Format).

Vantage Team Builder постачається в різних конфігураціях залежно від засосованої СКБД (ORACLE, Informix, Sybase або Ingres) або засобів розроблення застосувань (Uniface). Конфігурація Vantage Team Builder for Uniface відрізняється від останніх орієнтацією на спіральну модель ЖЦ ПЗ за рахунок можливостей швидкого прототипування. Для опису проекту ІС використовується чималий набір діаграм, конкретні варіанти якого для найпоширеніших конфігурацій наведені в таблиці 13.1.

Таблиця 135.1. Діаграми в Vantage Team Builder

Тип діаграми	Позна-чення	Vantage Team Builder for ORACLE	Vantage Team Builder for Informix	Vantage Team Builder for Uniface
Сутність-зв'язок	ERD	+	+	+
Потоків даних	DFD	+	+	+
Структур даних	DSD	+	+	+
Архітектура системи	SAD	+	+	+
Потоків управління	CSD	+	+	+
Типів даних	DTD	+	+	+
Структури меню	MSD	+
Послідовності блоків	BSD	+
Послідовності форм	FSD		+	+
Вмісту форм	FCD		+	+
Переходів станів	STD	+	+	+
Структурних схем	SCD	+	+	+

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

При побудові DFD забезпечується контроль відповідності діаграм різних рівнів декомпозиції. Контроль за правильністю верхнього рівня DFD здійснюється за допомогою матриці списків подій (ELM). Для контролю за декомпозицією складених потоків даних використовується декілька варіантів їх опису: у вигляді діаграм структур даних (DSD) або в нотації БНФ (форма Бекуса-Наура).

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

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

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

При розробленні досить великою ІС вся система в цілому відповідає одному проекту як категорії Vantage Team Builder. Проект може бути декомпозиційований на ряд систем, кожна з яких відповідає деякій відносно автономній підсистемі ІС і розробляється незалежно від інших. Надалі системи проекту можуть бути інтегровані.

Процес проектування ІС з використанням Vantage Team Builder реалізується у вигляді 4-х послідовних фаз (стадій) - аналізу, архітектури, проектування і реалізації, при цьому закінчені результати кожної стадії повністю або частково переносяться (імпортуються) у наступну фазу. Усі діаграми, окрім ERD, перетворюються у інший тип або змінюють вигляд відповідно до особливостей заданої фази. Так, DFD перетворюється у фазі архітектури у SAD, DSD - в DTD. Після завершення імпорту логічний зв'язок з попередньою фазою розривається, тобто до діаграм можуть вноситися усі необхідні зміни.

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

Конфігурація Vantage Team Builder for Uniface забезпечує спільне використання двох систем у рамках єдиного технологічного середовища проектування, при цьому схеми БД (SQL-моделі) переносяться в репозиторій Uniface, і, навпаки, прикладні моделі, сформовані засобами Uniface, можуть бути перенесені в репозиторій Vantage Team Builder. Можливі розузгодження між репозиторіями двох систем усуваються за допомогою спеціальної утиліти. Розробка екранних форм в середовищі Uniface виконується на базі діаграм послідовностей форм (FSD) після імпорту SQL-моделі.

13.2.2. Uniface

Uniface 6.1 [15] – продукт фірми Compuware (США) – є середовищем розроблення великомасштабних застосувань в архітектурі «клієнт-сервер» і має наступну компонентну архітектуру:

• Application Objects Repository (репозиторій об’єктів застосувань) містить описи елементів, які автоматично використовуються усіма останніми компонентами впродовж життєвого циклу ІС (прикладні моделі, описи даних, бізнес-правила, екранні форми, глобальні об’єкти і шаблони). Репозиторій може зберігатися у будь-якій з баз даних, підтримуваних Uniface;

• Application Model Manager підтримує прикладні моделі (ER моделі), кожна з яких є підмножиною загальної схеми БД з точки зору заданого застосування, і включає відповідний графічний редактор;

• Rapid Application Builder – засіб швидкого створення екранних форм і звітів на базі об’єктів прикладної моделі. Включає графічний редактор форм, засоби прототипування, відлагодження, тестування і документування. Реалізований інтерфейс з різними типами віконних елементів керування (Open Widget Interface) для існуючих графічних інтерфейсів – MS Windows, Motif, OS/2. Універсальний інтерфейс презентації (Universal Presentation Interface) дозволяє використовувати одну і ту ж версію застосування у середовищі різних графічних інтерфейсів без зміни програмного коду;

• Developer Services (служби розробника) –реалізують контроль версій (Uniface Version Control System), права доступу (розмежування повноважень), глобальні модифікації і так далі. Забезпечує розробників засобами паралельного проектування, вхідного і вихідного контролю, пошуку, перегляду, підтримки і видачі звітів за даними системи контролю версій;

• Deployment Manager (керування поширенням застосувань) – засоби, що дозволяють підготувати створене застосування для поширення, встановлювати і супроводжувати його (при цьому платформа користувача може відрізнятися від платформи розробника). У їх склад входять мережеві драйвери , сервер застосувань, засоби поширення застосувань і управління базами даних. Uniface підтримує інтерфейс практично зі всіма відомими програмно-апаратними платформами, CASE-засобами, протоколами і менеджерами транзакцій;

• Personal Series (персональні засоби) – використовуються для створення складних запитів і звітів у графічній формі (Personal Query і Personal Access – PQ/PA), а також для перенесення даних у такі системи, як Word і Excel;

• Distributed Computing Manager – засіб інтеграції з менеджерами транзакцій Tuxedo, Encina, CICS, OSF DCE.

13.3. Designer/2000 + Developer/2000

CASE-засіб Designer/2000 2.0 фірм ORACLE [23] є інтегрованим CASE-засобом, що забезпечує в сукупності зі засобами розроблення застосувань Developer/2000 підтримку повного ЖЦ ПЗ для систем, що використовують СКБД ORACLE.

Designer/2000 є сімейством методологій і програмних продуктів, що їх підтримують. Базова методологія Designer/2000 (CASE*Method) - структурна методологія проектування систем, що повністю охоплює усі етапи життєвого циклу ІС [8,9]. Відповідно до цієї методології на етапі планування визначаються цілі створення системи, пріоритети і обмеження, розробляється системна архітектура і план розроблення ІС. У процесі аналізу будуються модель інформаційних потреб (діаграма "сутність-зв'язок"), діаграма функціональної ієрархії (на основі функціональної декомпозиції ІС), матриця перехресних посилань і діаграма потоків даних.

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

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

Designer/2000 забезпечує графічний інтерфейс при розробці різних моделей (діаграм) предметної області. У процесі побудови моделей інформація про них заноситься в репозиторій. До складу Designer/2000 входять наступні компоненти:

• Repository Administrator - засоби керування репозиторієм (створення і знищення застосувань, керування доступом до даних з боку різних користувачів, експорт і імпорт даних);

• Repository Object Navigator - засоби доступу до репозиторія, що забезпечують багатовіконний об'єктно-орієнтований інтерфейс доступу до усіх елементів репозиторія;

• Process Modeller - засіб аналізу і моделювання ділової діяльності, що грунтується на концепціях глобальної системи керування якістю (TQM - Total Quality Management);

• Systems Modeller - набір засобів побудови функціональних і інформаційних моделей проектованої ІС, що включає засоби для побудови діаграм "сутність-зв'язок", діаграм функціональних ієрархій, діаграм потоків даних і засіб аналізу і модифікації зв'язків об'єктів репозиторія різних типів;

• Systems Designer - набір засобів проектування ІС, що включає засіб побудови структури реляційної бази даних, а також засоби побудови діаграм, що відображають взаємодію з даними, ієрархію, структуру і логіку застосувань, які виконуються збереженими процедурами на мові PL/SQL;

• Server Generator - генератор описів об'єктів БД ORACLE (таблиць, індексів, ключів, послідовностей і так далі). Окрім продуктів ORACLE, генерація БД може виконуватися для СКБД Informix, DB/2, Microsoft SQL Server, Sybase, а також для стандарту ANSI SQL DDL і баз даних, доступ до яких реалізується за допомогою ODBC;

• Forms Generator (генератор застосувань для ORACLE Forms). Застосування, що генеруються, включають різні екранні форми, засоби контролю даних, перевірки обмежень цілісності і автоматичні підказки. Подальша робота зі застосуванням виконується у середовищі Developer/2000;

• Repository Reports - генератор стандартних звітів, інтегрований з ORACLE Reports.

Репозиторієм Designer/2000 є сховище усіх проектних даних. Він може працювати у багатокористувацькому режимі, забезпечуючи паралельне оновлення інформації декількома розробниками. У процесі проектування автоматично підтримуються перехресні посилання між об'єктами словника і можуть генеруватися більше 70 стандартних звітів модельованої предметної області. Фізичне середовище зберігання репозиторія - база даних ORACLE.

Генерація застосувань, окрім продуктів ORACLE, виконується також для Visual Basic.

Designer/2000 можна інтегрувати з іншими засобами, використовуючи відкритий інтерфейс застосувань API (Application Programming Interface). Крім того, можна використовувати засіб ORACLE CASE Exchange для експорту/імпорту об'єктів репозиторія з метою обміну інформацією з іншими CASE-засобами.

РОЗДІЛ 14. Об'єктна модель

• Еволюція об'єктної моделі

• Складові частини об'єктного підходу

• Застосування об'єктної моделі

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

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

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