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

Основним поняттям мови 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

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 [12]. Для багатьох систем, що не входять в стандартний набір є модулі («лінки»), розроблені сторонніми виробниками, доповнюючи 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 або вище (рекомендується 80486), память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 на різних етапах розробки СУБД

Етап	Що ми очікуємо від Rose	Що ми очікуємо від Delphi
Моделювання предметної області

Страница:

•  1 
•  2 
•  3 

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

Подобные документы

• Дослідження роботи транзистора Делфі

  Концепції об'єктно-орієнтованого програмування. Спеціалізовані засоби розробки програмного забезпечення мовою Delphi. Загальні питання побудови та використання сучасних систем об’єктно-орієнтованного та візуального проектування програмних засобів.
  
  курсовая работа [201,4 K], добавлен 01.04.2016
  

• Проектування програмного продукту із застосуванням систем візуального моделювання

  Технології об'єктно-орієнтованого аналізу та проектування інформаційних систем. Історія та структура мови UML. Опис функціональної моделі засобами UML. Використання UML в проектуванні програмного забезпечення. Характеристика CASE-засобів Visual Paradigm.
  
  дипломная работа [7,9 M], добавлен 26.05.2012
  

• Моделювання процесу роботи гідроакумулятора

  Розгляд принципів моделювання для дослідження роботи гідроакумулятора в системах водопостачання. Опис математичної моделі для підбору гідроакумулятора. Створення графічної моделі процесу вмикання та вимикання насосу, комп’ютерної в середовищі Delphi.
  
  курсовая работа [392,4 K], добавлен 08.12.2015
  

• Робота з середовищем Rational Rose

  Характеристика CASE-засобу Rational Rose 98/2000. Дослідження призначення панелей інструментів середовища. Причини, що стримують застосування CASE-засобів. Особливості робочого інтерфейсу Rational Rose. Відмінність між нотаціями Booch, OMT та Unified.
  
  лабораторная работа [260,8 K], добавлен 10.11.2021
  

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

  Класифікація інформаційних систем. Дослідження особливостей мови UML як засобу моделювання інформаційних систем. Розробка концептуальної моделі інформаційної системи поліклініки з використанням середи редактора програмування IBM Rational Rose 2003.
  
  дипломная работа [930,4 K], добавлен 26.10.2012
  

• Моделювання систем

  Основні поняття моделювання систем, етапи створення, надійність, ефективність. Життєвий цикл та структурне інформаційне забезпечення модельованої системи. Зміст сase-технології, програмне забезпечення та кодування інформації. Головні завдання контролінгу.
  
  курсовая работа [151,3 K], добавлен 27.05.2014
  

• VHDL - технології дослідження цифрових пристроїв

  Мова VHDL. Створення проекту для моделювання цифрових і аналогових схем. Синтез і моделювання комбінаційних пристроїв, заданих в табличній формі, за допомогою системи Active-HDL 6.1. Створення ієрархічних структур при проектуванні складних пристроїв.
  
  реферат [287,3 K], добавлен 14.02.2009
  

• Об’єктно-орієнтоване програмування МП Delphi

  Розроблення додатка за допомогою об'єктно-орієнтованого візуального проектування Delphi для виконання арифметичних операцій або з використанням меню. Створення інтерфейсу користувача з використанням компонентів SYSTEM і WIN32. Обробка двовимірного масиву.
  
  методичка [326,1 K], добавлен 13.01.2010
  

• Уніфікована мова моделювання (UML)

  Дослідження сутності UML (уніфікована мова моделювання) - мови графічного опису для об'єктного моделювання в області розробки програмного забезпечення. Передумови й історія виникнення UML. Керована моделями інженерія. Огляд англомовної літератури UML.
  
  реферат [49,4 K], добавлен 19.07.2010
  

• Система для автоматизации продаж в магазині

  Загальна характеристика мови моделювання UML. Розробка діаграм UML з метою автоматизації продаж в магазині. Rational Rose як засіб візуального моделювання об'єктно-орієнтованих інформаційних систем. Зворотне проектування як головна перевага Rational Rose.
  
  контрольная работа [1,7 M], добавлен 23.10.2014
  

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

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам