Дослідження та порівняння, аналіз використання CASE систем при проектуванні СУБД Delphi

ВСТУП

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

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

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

відсутність прямих аналогів, що обмежує можливість використання яких-небудь типових проектних рішень і прикладних систем;

необхідність інтеграції що існують і знов розробляються додатків;

функціонування в неоднорідному середовищі на декількох апаратних платформах;

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

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

В останні роки на світовому ринку програмних продуктів з’явилося багато програмних засобів, які називаються CASE-системами чи CASE-засобами.

Слово CASE являє собою скорочення від Computer Aided Software Engineering. У російськомовній літературі немає відповідного загальноприйнятого терміна. Але є два найбільш відповідних оригіналу і призначення CASE-систем переказу: ''Програмна інженерія, підтримувана комп’ютером і менш буквальний, але більш відповідає суті переклад '' Засоби розробки програм за допомогою комп’ютера. Теоретичне осмислювання цього явища та його місця в технології програмування перебуває на дуже ранніх стадіях.

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

Метою дипломної роботи є дослідження та порівняння, аналіз використання CASE систем при проектуванні СУБД в середі Delphi. Для вирішення цієї задачі, використано Delphi 7.0 та дві CASE системи: Rational Rose Enterprise Edition 2003 та ERwin. В розробці СУБД використовується мова програмування UML та Object Pascal.

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь застосування

Розроблена в процесі дослідження, порівняння та аналізу CASE-систем СУБД може бути використана при роботі службами підтримки різноманітних компанії.

1.2 Підстава для створення

Підставою для розробки є наказ № 62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.

1.3 Характеристика розробленого програмного забезпечення

Гнучка система автоматизації була реалізована в середі Delphi 7.0. з використанням технології доступу до файлів баз даних ADO.

До складу системи входять:

Project1.exe — виконавчий файл розробленої системи;

baza.mdb — файл, що містить таблиці баз даних, і який може бути розташований на будь-якому комп’ютері, що підключений до локальної мережі;

rose.mdl — файл CASE-системи Rational Rose, що містить в собі діаграми класів, компонентів, прецедентів, діяльності та компонентну модель системи.

1.4 Мета й призначення

Метою дипломної роботи було дослідження та порівняння, аналіз використання CASE-систем при проектуванні СУБД в середі Delphi. Для цього булореалізовано невеликий приклад СУБД «База для технічної підтримки Інтернет компаній», за допомогою якої можна буде знаходити данні про необхідних клієнтів, реєструвати нового клієнта, записувати заявки на підключення та вести реєстр усіх дзвінків клієнтів.

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

Робота в середовищі операційних систем Windows 2000/XP;

Відсутність додаткових вимог до розміщення здійснених файлів;

Простота й зрозумілість інтерфейсу.

Мінімальні вимоги до апаратного забезпечення:

IBM-сумісний комп’ютер, не нижче Pentium IІ, RAM-512Mb, SVGA-800*600*16bit;

Вільний простір на жорсткому диску не менш 2Мб;

Підключення до локальної мережі.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

довідкова література;

наукова література;

технічна література;

програмна документація.

2. UML - мова об'єктно-орієнтованого моделювання

2.1 Unified Modeling Language — уніфікована мова моделювання

UML (скороч. від англ. Unified Modeling Language — уніфікована мова моделювання) — мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, званою моделлю UML. UML був створений для визначення, візуалізації, проектування і документування в основному програмних систем.

Використання UML не обмежується моделюванням програмного забезпечення. Його також використовують для моделювання бізнес-процесів, системного проектування і відображення організаційних структур. UML дозволяє розробникам ПО досягти угоди в графічних позначеннях для представлення загальних понять (таких як клас, компонент, узагальнення (generalization), об'єднання (aggregation) і поведінка) і більше концентруватися на проектуванні і архітектурі.

2.2 Історія

В 1994 році Граді Буч і Джеймс Рамбо, що працювали в компанії Rational Software, об'єднали свої зусилля для створення нової мови об'єктно-орієнтованого моделювання. За основу мови ними були узяті методи моделювання, розроблені Бучем (Booch) і Рамбо (Object-modeling Technique — OMT). OMT був орієнтований на аналіз, а Booch — на проектування програмних систем. У жовтні 1995 року була випущена попередня версія 0.8 уніфікованого методу (англ. Unified Method). Восени 1995 років до компанії Rational приєднався Айвар Якобсон, автор методу Object-oriented Software Engineering — OOSE. OOSE забезпечував чудові можливості для специфікації бізнес-процесів і аналізу вимог за допомогою сценаріїв використання.

OOSE був також інтегрований в уніфікований метод.

На цьому етапі основна роль в організації процесу розробки UML перейшла до консорціуму OMG (Object Management Group). Група розробників в OMG, в яку також входили Буч, Рамбо і Якобсон, випустила специфікації UML версій 0.9 і 0.91 в червні і жовтні 1996 року.

На хвилі зростаючого інтересу до UML до розробки нових версій мови в рамках консорціуму UML Partners приєдналися такі компанії, як Digital Equipment Corporation, Hewlett-packard, i-logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments і Unisys. Результатом спільної роботи стала специфікація UML 1.0, що вийшла в січні 1997 року. У листопаді того ж року за нею випустили версія 1.1, що містила поліпшення нотації, а також деякі розширення семантики.

Подальші релізи UML включали версії 1.3, 1.4 і 1.5, опубліковані, відповідно в червні 1999, вересні 2001 і березні 2003 року.

Формальна специфікація останньої версії UML 2.0 опублікована в серпні 2005 року. Семантика мови була значно уточнена і розширена для підтримки методології Model Driven Development — MDD (англ.). UML 1.4.2 прийнятий як міжнародний стандарт Iso/iec 19 501:2005.

2.3 Основне поняття мови UML — діаграми

Основним поняттям мови UML є діаграма, що графічно відображує якусь суть або поняття системи, а також зв’язки між поняттями. Це може бути, наприклад, клас, об'єкт, користувач, супровідна інформація і так далі.

В UML використовуються наступні види діаграм.

Структурні діаграми (Structure Diagrams):

Класів (Class diagram);

Компонентів (Component diagram);

Композитної/складної структури (Composite structure diagram);

Кооперацій (UML2.0) (Collaboration (UML2.0));

Розгортання (Deployment diagram) ;

Об'єктів (Object diagram);

Пакетів (Package diagram);

Діаграми поведінки (Behavior Diagrams):

Діяльності (Activity diagram);

Стан (State Machine diagram);

Варіантів використання (Use CASE diagram);

Діаграми взаємодії (Interaction Diagrams):

Комунікації (UML2.0) / Кооперації (UML1.x) (Communication diagram (UML2.0) / Collaboration (UML1.x));

Огляду взаємодії (UML2.0) (Interaction overview diagram (UML2.0));

Послідовності (Sequence diagram);

Синхронізації (UML2.0) (Timing diagram (UML2.0));

Основні види та характеристика діаграм Діаграма класів:

Діаграма класів, Class diagram — статична структурна діаграма, що описує структуру системи, вона демонструє класи системи, їх атрибути, методи і залежності між класами.

Стереотипи класів. Стереотипи — це механізм, що дозволяє розділяти класи на категорії. У мові UML визначено три основні стереотипи класів: Boundary (межа), Entity (суть) і Control (управління).

Граничними класами (boundary classes) називаються такі класи які розташовані на межі системи і всього навколишнього середовища.

Це екранні форми, звіти, інтерфейси з апаратурою (такий як принтери або сканери) і інтерфейси з іншими системами. Щоб знайти граничні класи, треба досліджувати діаграми варіантів використання. Кожній взаємодії між дійовою особою і варіантом використання повинен відповідати, по крайній мірі, один граничний клас. Саме такий клас дозволяє дійовій особі взаємодіяти з системою.

Класи-суть (entity classes) містять інформацію, що зберігається .

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

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

У системі можуть бути і інші класи, що управляють, спільним для декількох варіантів використання. Наприклад, може бути клас Securitymanager (менеджер безпеки), що відповідає за контроль подій, пов’язаних з безпекою. Клас Transactionmanager (менеджер транзакцій) займається координацією повідомлень, що відносяться до транзакцій з базою даних. Можуть бути і інші менеджери для роботи з іншими елементами функціонування системи, такими як розділення ресурсів, розподілена обробка даних або обробка помилок.

Діаграма компонентів:

Діаграма компонентів, Component diagram — статична структурна діаграма, показує розбиття програмної системи на структурні компоненти і зв’язки (залежності) між компонентами. Як фізичних компонент можуть виступати файли, бібліотеки, модулі, виконувані файли, пакети і тому подібне.

Кожен клас моделі (або підсистема) перетвориться в компонент початкової коди. Після створення вони відразу додаються до діаграми компонентів. Між окремими компонентами зображають залежності, відповідні залежностям на етапі компіляції або виконання програми.

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

Діаграма композитної /складна структури:

Шаблон проектування адаптер на діаграмі кооперації Діаграма композитної/ складна структури, Composite structure diagram — статична структурна діаграма, демонструє внутрішню структуру класів і, по можливості, взаємодію елементів (частин) внутрішньої структури класу.

Підвидом діаграм композитної структури є діаграми кооперації (Collaboration diagram, введені в UML 2.0), які показують ролі і взаємодію класів в рамках кооперації. Кооперації зручні при моделюванні шаблонів проектування.

Діаграми композитної структури можуть використовуватися спільно з діаграмами класів.

Діаграма розгортання:

Діаграма розгортання, Deployment diagram — служить для моделювання працюючих вузлів (апаратних засобів, англ. node) і артефактів, розгорнутих на них. У UML 2 на вузлах розвертаються артефакти (англ. artifact), тоді як в UML 1 на вузлах розверталися компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, встановлюється залежність маніфестації.

Діаграма об'єктів:

Діаграма об'єктів, Object diagram — демонструє повний або частковий знімок модельованої системи в заданий момент часу. На діаграмі об'єктів відображуються екземпляри класів (об'єкти) системи з вказівкою поточних значень їх атрибутів і зв’язків між об'єктами.

Діаграма пакетів:

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

Діаграма діяльності:

Діаграма діяльності, Activity diagram — діаграма, на якій показано розкладання деякої діяльності на її складові частини. Під діяльністю (англ. activity) розуміється специфікація виконуваної поведінки у вигляді координованого послідовного і паралельного виконання підлеглих елементів — вкладених видів діяльності і окремих дій (англ. action), сполучених між собою потоками, які йдуть від виходів одного вузла до входів іншого.

Діаграми діяльності використовуються при моделюванні бізнес-процесів, технологічних процесів, послідовних і паралельних обчислень. Аналогом діаграм діяльності є схеми алгоритмів по ДОСТ 19.701−90.

Діаграма автомат:

Діаграма автомата, State Machine diagram (діаграма кінцевого автомата, діаграма станів) — діаграма, на якій представлений кінцевий автомат з простими станами, переходами і композитними станами.

Кінцевий автомат (англ. State machine) — специфікація послідовності станів, через які проходить об'єкт або взаємодія у відповідь на події свого життя, а також у відповідь дії об'єкту на ці події. Кінцевий автомат прикріплений до вихідного елементу (класу, кооперації або методу) і служить для визначення поведінки його екземплярів.

Діаграма прецедентів:

Діаграма прецедентів, Use CASE diagram (діаграма варіантів використання) — діаграма, на якій відбиті стосунки, що існують між акторами і прецедентами. Основне завдання — бути єдиним засобом, що дає можливість замовникові, кінцевому користувачеві і розробникові спільно обговорювати функціональність і поведінку системи. Діаграми комунікації і послідовності.

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

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

Дійові особи діляться на три основні типи — користувачів системи, інші системи, що взаємодіють з даною, і час. Час стає дійовою особою, якщо від нього залежить запуск яких-небудь подій в системі.

Діаграми комунікації і послідовності:

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

Діаграма комунікації:

Діаграма комунікації, Communication diagram (у UML 1. x — діаграма кооперації, collaboration diagram) — діаграма, на якій відображаються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються стосунки між елементами (об'єктами), а час як окремий вимір не використовується (застосовуються порядкові номери викликів).

Діаграма послідовності:

Діаграма послідовності, Sequence diagram — діаграма, на якій змальована впорядкована в часі взаємодія об'єктів. Зокрема, на ній відображаються об'єкти, що беруть участь у взаємодії, і послідовність повідомлень, якими вони обмінюються.

Діаграма огляду взаємодії:

Діаграма огляду взаємодії, Interaction overview diagram — різновид діаграми діяльності, що включає фрагменти діаграми послідовності і конструкції потоку управління.

Діаграма синхронізації:

Діаграма синхронізації, Timing diagram — альтернативне представлення діаграми послідовності, явним чином що показує зміни перебування на лінії життя із заданою шкалою часу. Може бути корисна в додатках реального часу.

2.4 Переваги UML

UML об'єктно-орієнтований, внаслідок чого методи опису результатів аналізу і проектування семантично близькі до методів програмування на сучасних ОО-мовах;

UML дозволяє описати систему практично зі всіх можливих точок зору і різні аспекти поведінки системи;

Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;

UML розширює і дозволяє вводити власні текстові і графічні стереотипи, що сприяє його вживанню не лише у сфері програмної інженерії;

UML набув широкого поширення і динамічно розвивається.

2.5 Недоліки

Не дивлячись на те, що UML досить широко поширений і використовуваний стандарт, його часто критикують із-за наступних недоліків:

Надмірність мови. UML часто критикується, як невиправдано великий і складний. Він включає багато надлишкових або практично невживаних діаграм і конструкцій. Частіше це можна почути відносно UML 2.0, чим UML 1.0, оскільки новіші ревізії включають більше розробленим «комітетом» компромісів.

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

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

Лише код відображає код. Ще одна думка — що важливі робочі системи, а не красиві моделі. Як лаконічно виразився Джек Рівс, «The code is the design.» (англ. «Код і є проект»). Відповідно до цієї думки, існує потреба в кращому способі написання ПЗ; UML цінується при підходах, які компілюють моделі для генерування вихідної або здійснимої коди. Проте цього все ж може бути недостатньо, оскільки UML не має властивостей повноти по Т’юрингу і будь-який код, що згенерував, буде обмежений тим, що може розгледіти або передбачити інтерпретуючий інструмент UML.

Кумулятивне навантаження/Розгалуження навантаження (Cumulative Impedance/impedance mismatch). Розгалуження навантаження — термін з теорії системного аналізу для позначення нездатності входу системи сприйняти вихід інший. Як в будь-якій системі позначень UML може представити одні системи коротше і ефективно, чим інші. Таким чином, розробник схиляється до рішень, які комфортніше личать до переплетення сильних сторін UML і мов програмування. Проблема стає очевиднішою, якщо мова розробки не дотримується принципів ортодоксальної об'єктно-орієнтованої доктрини (не прагне відповідати традиційним принципам ООП).

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

3. ДОСЛІДЖЕННЯ СУЧАСНИХ CASE-засобІВ моделювання бізнес процесів

3.1 Загальна характеристика і класифікація

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

неадекватна специфікація вимог;

нездатність виявляти помилки в проектних рішеннях;

низька якість документації, що знижує експлуатаційні якості;

затяжний цикл і незадовільні результати тестування.

Перераховані чинники сприяли появі програмно-технологічних засобів спеціального класу — CASE-засобів, що реалізовують CASE-технологію створення і супроводу ІС. Термін CASE (Computer Aided Software Engineering) використовується в даний час у вельми широкому сенсі. Первинне значення терміну CASE, обмежене питаннями автоматизації розробки тільки програмного забезпечення (ПЗ), в даний час придбало новий сенс, що охоплює процес розробки складних ІС в цілому. Тепер під терміном CASE-засобу розуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, проектування прикладного ПЗ (додатків) і баз даних, генерацію коди, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. CASE-засоби разом з системним ПЗ і технічними засобами утворюють повне середовище розробки ІС. Появі CASE-технології і CASE-засобів передували дослідження в області методології програмування. Програмування знайшло межі системного підходу з розробкою і впровадженням високого рівня методів структурного і модульного програмування, мов проектування і засобів підтримки, формальних і неформальних мов описів системних вимог і специфікацій так далі. Крім того, появі CASE-технології сприяли і такі чинники, як:

підготовка аналітиків і програмістів, сприйнятливих до концепцій модульного і структурного програмування;

широке впровадження і постійне зростання продуктивності комп’ютерів, що дозволили використовувати ефективні графічні засоби і автоматизувати більшість етапів проектування;

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

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

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

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

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

потужні графічні засоби для опису і документування ІС, що забезпечують зручний інтерфейс з розробником і розвивають його творчі можливості;

інтеграція окремих компонент CASE-засобів, що забезпечує керованість процесом розробки ІС;

використання спеціальним чином організованого сховища проектних метаданих (репозиторії). Інтегрований CASE-засіб (або комплекс засобів, що підтримують повний ЖЦ ПЗ) містить наступні компоненти;

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

графічні засоби аналізу і проектування, забезпечуючи створення і редагування ієрархічно зв’язаних діаграм (DFD, ERD і ін.), створюючи моделі ІС;

засоби розробки додатків, включаючи мови 4gl і генератори код;

засоби конфігураційного управління;

засоби документування;

засоби тестування;

засоби управління проектом;

засоби рєїнжинірінга.

Всі сучасні CASE-засоби можуть бути класифіковані в основному по типах і категоріях. Класифікація за типами відображає функціональну орієнтацію CASE-засобів на ті або інші процеси ЖЦ. Класифікація за категоріями визначає міру інтегрованості по виконуваних функціях і включає окремі локальні засоби, вирішальні невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані засоби, що підтримують весь ЖЦ ІС і зв’язані загальним репозиторієм. Окрім цього, CASE-засоби можна класифікувати по наступних ознаках:

вживаним методологіям і моделям систем і БД;

міри інтегрованості з СУБД;

доступним платформам.

Класифікація за типами в основному збігається з компонентним складом CASE-засобів і включає наступних основних типів:

засоби аналізу (Upper CASE), призначені для побудови і аналізу моделей наочної області (Design/idef (Meta Software), Bpwin (Logic Works));

засоби аналізу і проектування (Middle CASE), підтримуючі найбільш поширені методології проектування і що використовуються для створення проектних специфікацій (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (Mcdonnell Douglas), CASE. Аналітик (МакроПроджект)). Виходом таких засобів є специфікації компонентів і інтерфейсів системи, архітектура системи, алгоритмів і структур даних;

засоби проектування баз даних, що забезпечують моделювання даних і генерацію схем баз даних (як правило, на мові SQL) для найбільш поширених СУБД. До них відносяться ERwin (Logic Works), S-designor (SDP) і Database Designer (ORACLE). Засоби проектування баз даних є також у складі CASE-засобів Vantage Team Builder, Designer/2000, Silverrun і PRO-IV;

Засоби розробки додатків. До них відносяться засоби 4gl (Uniface (Compuware), JAM (JYACC), Powerbuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) і ін.) і генератори код, що входять до складу Vantage Team Builder, PRO-IV і частково — в Silverrun;

засоби рєїнжинірінга, що забезпечують аналіз програмних код і схем баз даних і формування на їх основі різних моделей і проектних специфікацій. Засоби аналізу схем БД і формування ERD входять до складу Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin і S-designor. В області аналізу програмних код найбільшого поширення набувають об'єктно-орієнтовані CASE-засобі, що забезпечують рєїнжинірінг програм на мові С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Допоміжні типи включають:

засоби планування і управління проектом (SE Companion, Microsoft Project і ін.);

засоби конфігураційного управління (PVCS (Intersolv));

засоби тестування (Quality Works (Segue Software));

засоби документування (SODA (Rational Software)).

3.2 Технологія впровадження CASE-засобів

Технологія базується в основному на стандартах IEEE (IEEE — Institute of Electrical and Electronics Engineers — Інститут інженерів по електротехніці і електроніці). Термін «впровадження» використовується в широкому сенсі і включає всі дії від оцінки первинних потреб до повномасштабного використання CASE-засобів в різних підрозділах організації-користувача. Процес впровадження CASE-засобів складається з наступних етапів:

визначення потреб в CASE-засобах;

оцінка і вибір CASE-засобів;

виконання пілотного проекту;

практичне впровадження CASE-засобів.

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

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

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

широка різноманітність якості і можливостей CASE-засобів;

відносно невеликий час використання CASE-засобів в різних організаціях і недолік досвіду їх вживання;

широка різноманітність в практиці впровадження різних організацій;

відсутність детальних метрик і даних для вже виконаних і поточних проектів;

широкий діапазон наочних областей проектів;

різна міра інтеграції CASE-засобів в різних проектах.

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

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

Технологія. Розуміння обмеженості існуючих можливостей і здатність прийняти нову технологію;

Культура. Готовність до впровадження нових процесів і взаємин між розробниками і користувачами;

Управління. Чітке керівництво і організованість по відношенню до найбільш важливих етапів і процесів впровадження.

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

достовірна оцінка віддачі від інвестицій в CASE-засоби скрутна зважаючи на відсутність прийнятних метрик і даних по проектах і процесах розробки ПЗ;

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

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

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

деякі CASE-засоби вимагають надто багато зусиль для того, щоб виправдати їх використання в невеликому проекті, при цьому, проте, можна отримати вигоду з тієї дисципліни, до якої зобов’язав їх вживання;

негативне відношення персоналу до впровадження нової CASE-технології може бути головною причиною провалу проекту.

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

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

високий рівень технологічної підтримки процесів розробки і супроводу ПЗ;

позитивна дія на деяких або всіх з перерахованих чинників: продуктивність, якість продукції, дотримання стандартів, документування;

прийнятний рівень віддачі від інвестицій в CASE-засоби.

3.3 Визначення потреб в CASE-засобах

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

Рис. 3.1 -Визначення потреб в CASE-засобах

3.4 Оцінка і вибір CASE-засобів

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

Процес оцінки і вибору може переслідувати декілька цілей, включаючи одну або більш з наступних:

оцінка декількох CASE-засобів і вибір один або більш з них;

оцінка одного або більш за CASE-засоби і збереження результатів для подальшого використання;

вибір один або більш за CASE-засоби з використанням результатів попередніх оцінок.

Рис. 3.2 — Модель процесу оцінки і вибору Як видно з малюнка, вхідною інформацією для процесу оцінки є:

визначення призначених для користувача потреб;

цілі і обмеження проекту;

дані про доступні CASE-засоби;

список критеріїв, використовуваних в процесі оцінки.

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

Елементи процесу включають:

цілі, припущення і обмеження, які можуть уточнюватися в ході процесу;

потреби користувачів, що відображають кількісні і якісні вимоги користувачів до CASE-засобів;

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

формалізовані результати оцінок одного або більш за засоби;

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

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

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

Визначення списку критеріїв засноване на призначених для користувача вимогах і включає:

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

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

визначення області використання кожного критерію (оцінка, вибір або обидва процеси);

визначення одній або більш за метрики для кожного критерію оцінки;

призначення ваги кожному критерію при виборі.

4. ЕКСПЕРИМЕНТАЛЬНЕ ДОСЛІДЖЕННЯ Об'єктно-орієнтованОГО CASE-засОбУ Rational Rose

4.1 Загальна характеристика

Компанія Rational Software (США) вже декілька років є лідером в області створення інструментальних засобів для проектування, розробки, тестування і супроводу програмного забезпечення. Основним продуктом в лінійці Rational є CASE-засіб Rational Rose. Rational Rose використовує синтез-методологію об'єктно-орієнтованого аналізу і проектування, засновану на підходах трьох провідних фахівців в даної області: Золить, Рамбо і Джекобсона. Розроблена ними універсальна нотація для моделювання об'єктів (UML — Unified Modeling Language) претендує на роль стандарту в області об'єктно-орієнтованого аналізу і проектування. Конкретний варіант Rational Rose визначається мовою, на якій генеруються коди програм (C++, Smalltalk, Powerbuilder, Ada, Sqlwindows і Objectpro). Основний варіант — Rational Rose/c++ - дозволяє розробляти проектну документацію у вигляді діаграм і специфікацій, визначати специфікації класів, об'єктів, атрибутів і операцій, а також генерувати програмні коди на С++. Крім того, Rational Rose містить засоби рєїнжинірінга програм, що забезпечують повторне використання програмних компонент в нових проектах.

Rational Rose Enterprise — є, напевно, найбільш відомим і популярним продуктом на ринку CASE-засобів для об'єктно-орієнтованого проектування. Популярність Rational Rose обумовлена наступними характеристиками:

Система підтримує генерацію коди по діаграмах і зворотне проектування (тобто побудова моделі за програмним кодом) відразу для декількох мов, включаючи Visual Basic, C++, Java, Powerbuilder, CORBA Interface Definition Language (IDL), Data Definition Language для більшості СУБД, ERwin моделі.

Система реалізує об'єктно-орієнтоване моделювання, повністю сумісне з UML (Unified Modeling Language).

Система має широкі перспективи розвитку, у тому числі за рахунок появи додаткових продуктів-перехідників (Links), тісно інтегрованих з Rational Rose.

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

Система дозволяє працювати з діаграмами наступних видів:

* Activity diagram (діаграми опису технологій, процесів, функцій).

* Use CASE diagram (діаграми прецедентів).

* Class diagram (діаграми класів).

* State diagram (діаграми станів).

* Sequence diagram (діаграми послідовностей дій).

* Collaboration diagram (діаграми взаємодій об'єктів).

* Component diagram (діаграми компонентів).

* Deployment diagram (діаграми топології).

Rational Rose підтримує пряме і зворотне проектування для наступних систем: C++, ADA, CORBA, Visual Basic, XML, COM, Oracle. Для багатьох систем, що не входять в стандартний набір є модулі («лінки»), розроблені сторонніми виробниками, доповнюючи Rational Rose можливостями роботи з цими системами.

Версії Rational Rose Enterprise починаючи з 2000 року підтримують також повноцінне проектування баз даних (пряме і зворотне).

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

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

У складі Rational Rose можна виділити 6 основних структурних компонент: репозиторії, графічний інтерфейс користувача, засоби перегляду проекту (browser), засоби контролю проекту, засоби збору статистики і генератор документів. До них додаються генератор код (індивідуальний для кожної мови) і аналізатор для С++, забезпечуючи рєїнжинірінг — відновлення моделі проекту по вихідних текстах програм.

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

Засоби автоматичної генерації код програм на мові С++, використовуючи інформацію, що міститься в логічній і фізичній моделях проекту, формують файли заголовків і файли описів класів і об'єктів. Створюваний таким чином скелет програми може бути уточнений шляхом прямого програмування на мові С++. Аналізатор код С++ реалізований у вигляді окремого програмного модуля. Його призначення полягає в тому, щоб створювати модулі проектів у формі Rational Rose на основі інформації, що міститься у визначуваних користувачем вихідних текстах на С++. В процесі роботи аналізатор здійснює контроль правильності вихідних текстів і діагностику помилок. Модель, отримана в результаті його роботи, може цілком або фрагментарно використовуватися в різних проектах. Аналізатор володіє широкими можливостями налаштування по входу і виходу. Наприклад, можна визначити типів вихідних файлів, базовий компілятор, задати, яка інформація має бути включена у формовану модель і які елементи вихідної моделі слід виводити на екран. Таким чином, Rational Rose/С++ забезпечує можливість повторного використання програмних компонент.

В результаті розробки проекту за допомогою CASE-засобу Rational Rose формуються наступні документи:

діаграми класів;

діаграми станів;

діаграми сценаріїв;

діаграми модулів;

діаграми процесів;

специфікації класів, об'єктів, атрибутів і операцій заготівки текстів програм;

модель програмної системи, що розробляється.

Останній з перерахованих документів є текстовим файлом, що містить всю необхідну інформацію про проект (у тому числі необхідну для здобуття всіх діаграм і специфікацій). Тексти програм є заготовками для подальшої роботи програмістів. Вони формуються в робочому каталозі у вигляді файлів типів .h (заголовки, що містять описи класів) і .cpp (заготовки програм для методів). Система включає в програмні файли власні коментарі, які починаються з послідовності символів //##. Склад інформації, що включається в програмні файли, визначається або за умовчанням, або по розсуду користувача. Надалі ці вихідні тексти розвиваються програмістами в повноцінні програми.

4.3 Взаємодія з іншими засобами і організація групової роботи

Rational Rose інтегрується із засобом PVCS для організації групової роботи і управління проектом і із засобом SODA — для документування проектів. Інтеграція Rational Rose і SODA забезпечується засобами SODA. Для організації групової роботи в Rational Rose можливе розбиття моделі на керовані підмоделі. Кожна з них незалежно зберігається на диску або завантажується в модель. Як підмоделі може виступати категорія класів або підсистема.

Для керованої підмоделі передбачені операції:

завантаження підмоделі в пам’ять;

вивантаження підмоделі з пам’яті;

збереження підмоделі на диску у вигляді окремого файлу;

установка захисту від модифікації;

заміна підмоделі в пам’яті на нову.

Найефективніше групова робота організовується при інтеграції Rational Rose із спеціальними засобами управління конфігурацією і контролю версій (PVCS). В цьому випадку захист від модифікації встановлюється на всі керовані підмоделі, окрім тих, які виділені конкретному розробникові. В цьому випадку ознака захисту від запису встановлюється для файлів, які містять підмоделі, тому при причитуванні «чужих» підмоделей захист їх від модифікації зберігається і випадкові дії виявляться неможливими.

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

Rational Rose функціонує на різних платформах: IBM РС (у середовищі Windows), Sun SPARC stations (UNIX, Solaris, SUNOS), Hewlett-packard (HP UX), IBM Rs/6000 (AIX).

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

Платформа Windows — процесор 80386sx або вище (рекомендується 80 486), память8mб (рекомендується 12mб), простір на диску 8mб + 1−3mб для однієї моделі.

Платформа UNIX — пам’ять 32+(16*число користувачів) Mб, простір на диску 30mб + 20 при інсталяції + 1−3mб для однієї моделі.

Сумісність по версіях забезпечується на рівні моделей. Оскільки Rational Rose володіє всіма необхідними характеристиками для проектування архітектури системи будь-якого масштабу, напрошується ідея використання Rose з такою потужною і популярною системою програмування, як Delphi.

4.5 Взаємодія Rational Rose і Delphi

В даний час Delphi є одним з найбільш популярних програмних продуктів для створення інформаційних систем. На його основі створюються як невеликі програми, так і системи масштабу підприємства. Чим же такий привабливий Delphi з точки зору розробника? Перш за все, це прекрасне середовище візуального програмування, зрозуміле, просте для вивчення і, частенько, не вимагаючи знань професійного розробника (які, як відомо, по крупицях накопичуються протягом багатьох років і десятиліть і коштують неймовірно дорого). У середовищі Delphi можна створювати досить складні програмні системи практично з нуля, написавши мінімум програмної коди. При цьому мова, на якій пишеться програма, знайомий багатьом Object Pascal, вивчається в даний час на молодших курсах більшості вітчизняних технічних інститутів.

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

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

Повернемося до достоїнств Delphi. Якщо відкинути середовище візуального програмування, то, що ж залишиться? Об'єктна модель. А ось це вже гідність Delphi, приваблива з точки зору проектувальника системи і саме об'єктна модель в багато визначає успіх середовища візуального програмування. Об'єктна модель Delphi охоплює широкий круг завдань, забезпечуючи високорівневі (але при цьому виключно гнучкі, практично без обмежень) засоби організації призначеного для користувача інтерфейсу, управління ресурсами операційної системи, маніпулювання даними БД, підтримку стандартів відкритих систем, підтримку популярних технологій (включаючи CORBA і COM), багаторівневу архітектуру і, нарешті, Internet/intranet технології. Базова архітектура може використовувати елементи об'єктної моделі Delphi (навіщо заново створювати все вище перераховане), доповнивши її необхідними складовими, що відображають прикладну специфіку конкретної системи.

Rational Rose володіє всіма необхідними характеристиками для створення базової архітектури системи будь-якого масштабу. Маючи достатній досвід програмування в середовищі Delphi, привабливим є використання Rational Rose і Delphi спільно, в рамках єдиного технологічного процесу.

4.5.1 Використання Rational Rose і Delphi на різних етапах розробки СУБД

Методологія, якою ми слідуємо при розробці СУБД, це методологія розробки програмного забезпечення Rational Unified Process фірми Rational Software Corporation. Методологія з технологічної точки зору включає наступні етапи (зрозуміло, в рамках кожної ітерації): моделювання наочної області, визначення вимог до системи, аналіз і проектування, реалізацію (кодування і автономну відладку), тестування і впровадження. Нижче приведена таблиця, в якій представлене те, що ми чекаємо отримати за допомогою Rational Rose і Delphi на кожному етапі, див. таблицю 4.1.

Таблиця 4.1 — Використання Rational Rose і Delphi на різних етапах розробки СУБД