PrIS

221

екранних форм застосування між 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.

222

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

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

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

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

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

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

223

При розробленні досить великою ІС вся система загалом відповідає одному проекту як категорії 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 – засіб швидкого створення екранних форм

ізвітів на базі об’єктів прикладної моделі; містить графічний редактор

224

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

225

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

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

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

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,

226

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-засобами.

227

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

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

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

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

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

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

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

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

14.1.1. Основні положення об'єктної моделі

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

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

228

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

ООАП відображають еволюційний, а не революційний розвиток проектування; нова методологія не перекреслює попередні методи, а будується із врахуванням попереднього досвіду. На жаль, більшість програмістів нині формально і неформально натреновані на вживання лише методів структурного проектування. Зрозуміло, багато хороших проектувальників створили і продовжують удосконалювати значну кількість програмних систем на основі цієї методології. Проте алгоритмічна декомпозиція допомагає лише до певної межі, і звернення до об'єктно-орієнтованої декомпозиції необхідне. Понад це, при спробах використовувати такі мови, як C++ або Ada як традиційні, алгоритмічно орієнтовані, ми не лише втрачаємо їх внутрішній потенціал ─ найімовірніше за все результат буде навіть гірше, ніж при використанні звичайних мов С і Pascal. Дати електродриль тесляру, який не чув про електрику, означає використовувати її як молоток. Він зігне декілька цвяхів і розіб'є собі пальці, тому що електродриль мало придатна для заміни молотка.

14.1.2. OOP, OOП і ООА

У спадок від багатьох попередників об'єктний підхід, на жаль, перейняв і заплутану термінологію. Програміст у Smalltalk користується терміном метод, в C++ ─ терміном віртуальна функція, у CLOS ─ узагальнена функція. В Object Pascal використовується термін приведення типів, а в мові Ada те ж саме називається перетворення типів. Аби зменшити плутанину, треба визначити, які властивості є об'єктноорієнтованими, а які ні. Визначення найуживаніших термінів і понять ви знайдете у глосарії в кінці книги.

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

229

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

Термін "об'єкт" з'явився практично незалежно в різних областях, пов'язаних з комп'ютерами, і майже одночасно на початку 70-х років ХХ ст. для позначення того, що може мати різні прояви, залишаючись цілісним. Щоб зменшити складність програмних систем, об'єктами називалися компоненти системи або фраґменти знань. Об'єктноорієнтований підхід був пов'язаний з такими подіями:

прогрес в області архітектури ЕОМ;

розвиток мов програмування, таких як Simula, Smalltalk, CLU, Ada;

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

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

розвиток теорії баз даних;

дослідження в області штучного інтелекту;

досягнення філософії і теорії пізнання.

Поняття "об'єкт" вперше було використане понад 20 років тому під час конструювання комп'ютерів з descriptor-based і capability-based

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

З об'єктно-орієнтованою архітектурою тісно пов'язані об'єктноорієнтовані операційні системи (ОС). Дейкстра, працюючи над мультипрограмною системою THE, вперше увів поняття машини з рівнями стану як засіб побудови системи. Серед перших об'єктноорієнтованих ОС відзначимо: Plessey/System 250 (для мультипроцесора

Plessey 250), Hydra (для CMU C.mmp), CALTSS (для CDC 6400), CAP (для комп'ютера Cambridge CAP), UCLA Secure UNIX (для PDP 11/45 і 11/70), STAROS (для CMU Cm*), Medusa (також для CMU Cm*) і iMAX (для Intel 432).

Найзначніший вклад у розвиток об'єктного підходу внесений об'єктними і об'єктно-орієнтованими мовами програмування. Вперше поняття класів і об'єктів уведені в мові Simula 67. Система Flex і діалекти Smalltalk-72, що слідували за нею -74, -76 і, нарешті -80, взявши за основу

230

методи Simula, довели їх до логічного завершення, виконуючи всі дії на основі класів. У 1970-х роках створено ряд мов, що реалізовують ідею абстракції даних: Alphard, CLU, Euclid, Gypsy, Mesa і Modula. Потім методи, що використовуються в мовах Simula і Smalltalk, були використані у традиційних мовах високого рівня. Уведення об'єктноорієнтованого підходу в С привело до виникнення мов C++ і Objective С.

На основі мови Pascal виникли Object Pascal, Eiffel і Ada. З'явилися діалекти LISP, такі як Flavors, LOOPS і CLOS (Common LISP Object System), з можливостями мов Simula і Smalltalk.

Першим, хто вказав на необхідність побудови систем у вигляді структурованих абстракцій, був Дейкстра. Пізніше Парнас увів ідею приховування інформації, а в 1970-х роках ряд дослідників, головним чином Лісков, Жиль, Гуттаг і Шоу, розробили механізми абстрактних типів даних. Хоар доповнив ці підходи теорією типів і підкласів.

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

відношення" (ER, entity-relationship). У моделях ER, вперше запропонованих Ченом, моделювання відбувається в термінах сутностей, їх атрибутів і відношень.

Розробники способів подання даних в області штучного інтелекту також внесли свій вклад в розуміння об'єктно-орієнтованих абстракцій. У 1975 р. Мінські висунув теорію фреймів для відображення реальних об'єктів у системах розпізнавання образів і природних мов. Фрейми почали використовуватися як архітектурна основа в різних інтелектуальних системах.

Об'єктний підхід відомий ще здавна. Грекам належить ідея про те, що світ можна розглядати в термінах як об'єктів, так і подій. А в XVII столітті Декарт відзначав, що люди зазвичай мають об'єктноорієнтований погляд на світ. У XX столітті цю тему розвинув Ренд у своїй філософії об'єктивістської епістемології. Пізніше Мінські запропонував модель людського мислення, в якій розум людини розглядається як сукупність агентів , які мислять різноманітно. Він доводить, що лише спільна дія таких агентів приводить до осмисленої поведінки людини.

Об'єктно-орієнтоване програмування.

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

У цьому визначенні можна виділити три частини: 1) OOP використовує як базові елементи об'єкти, а не алгоритми (ієрархія "бути частиною"); 2) кожний об'єкт є екземпляром якого-небудь певного класу; 3) класи організовані ієрархічно (див. поняття про ієрархію "is_а").