Дослідження та порівняння, аналіз використання CASE систем при проектуванні СУБД Delphi - Программирование, компьютеры и кибернетика дипломная работа
Главная
Программирование, компьютеры и кибернетика
Дослідження та порівняння, аналіз використання CASE систем при проектуванні СУБД Delphi
Unified modeling language як мова об'єктно-орієнтованого моделювання. Дослідження сучасних сase-засобів моделювання бізнес процесів. Кодогенератор для забезпечення зв'язку між Delphi і Rose. Перелік основних інструментів для створення моделі в ERwin.
посмотреть текст работы
скачать работу можно здесь
полная информация о работе
весь список подобных работ
Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Тенденції розвитку сучасних інформаційних технологій приводять до постійного зростання складності інформаційних систем (ІС), що створюються в різних областях економіки. Сучасні крупні проекти ІС характеризуються, як правило, наступними особливостями:
складність опису (достатньо велика кількість функцій, процесів, елементів даних і складні взаємозв'язки між ними), що вимагає ретельного моделювання і аналізу даних і процесів;
наявність сукупності тісно взаємодіючих компонентів (підсистем), що мають свої локальні завдання і цілі функціонування (наприклад, традиційних застосувань, пов'язаних з обробкою трансакцій і вирішенням регламентних завдань, і додатків аналітичної обробки (підтримка ухвалення рішень), що використовують нерегламентовані запити до даних великого об'єму);
відсутність прямих аналогів, що обмежує можливість використання яких-небудь типових проектних рішень і прикладних систем;
необхідність інтеграції що існують і знов розробляються додатків;
функціонування в неоднорідному середовищі на декількох апаратних платформах;
роз'єднаність і різнорідність окремих груп розробників по рівню кваліфікації і традиціям використання тих або інших інструментальних засобів, що склалися;
істотна тимчасова протяжність проекту, обумовлена, з одного боку, обмеженими можливостями колективу розробників, і, з іншого боку, масштабами організації-замовника і різним ступенем готовності окремих її підрозділів до впровадження ІС.
В останні роки на світовому ринку програмних продуктів з'явилося багато програмних засобів, які називаються 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 Найменування та галузь застосування
Розроблена в процесі дослідження, порівняння та аналізу CASE-систем СУБД може бути використана при роботі службами підтримки різноманітних компанії.
Підставою для розробки є наказ № 62С-01 від 29 жовтня 2008 р. по Криворізькому інституту КУЕІТУ.
1.3 Характеристика розробленого програмного забезпечення
Гнучка система автоматизації була реалізована в середі Delphi 7.0. з використанням технології доступу до файлів баз даних ADO.
Project1.exe - виконавчий файл розробленої системи;
baza.mdb - файл, що містить таблиці баз даних, і який може бути розташований на будь-якому комп'ютері, що підключений до локальної мережі;
rose.mdl - файл CASE-системи Rational Rose, що містить в собі діаграми класів, компонентів, прецедентів, діяльності та компонентну модель системи.
Метою дипломної роботи було дослідження та порівняння, аналіз використання CASE-систем при проектуванні СУБД в середі Delphi. Для цього булореалізовано невеликий приклад СУБД “База для технічної підтримки Інтернет компаній”, за допомогою якої можна буде знаходити данні про необхідних клієнтів, реєструвати нового клієнта, записувати заявки на підключення та вести реєстр усіх дзвінків клієнтів.
Вимоги до програмного забезпечення:
Робота в середовищі операційних систем Windows 2000/XP;
Відсутність додаткових вимог до розміщення здійснених файлів;
Простота й зрозумілість інтерфейсу.
Мінімальні вимоги до апаратного забезпечення:
IBM-сумісний комп'ютер, не нижче Pentium IІ, RAM-512Mb, SVGA-800*600*16bit;
Вільний простір на жорсткому диску не менш 2Мб;
Джерелами розробки дипломної роботи є:
2 . UML - мова об'єктно-орієнтованого моделювання
2.1 Unified Modeling Language - уніфікована мова моделювання
UML (скороч. від англ. Unified Modeling Language - уніфікована мова моделювання) - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, званою моделлю UML. UML був створений для визначення, візуалізації, проектування і документування в основному програмних систем.
Використання UML не обмежується моделюванням програмного забезпечення. Його також використовують для моделювання бізнес-процесів, системного проектування і відображення організаційних структур. UML дозволяє розробникам ПО досягти угоди в графічних позначеннях для представлення загальних понять (таких як клас, компонент, узагальнення (generalization), об'єднання (aggregation) і поведінка) і більше концентруватися на проектуванні і архітектурі.
В 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 19501:2005.
2 . 3 Основне поня ття мови UML - діаграми
Основним поняттям мови UML є діаграма, що графічно відображує якусь суть або поняття системи, а також зв'язки між поняттями. Це може бути, наприклад, клас, об'єкт, користувач, супровідна інформація і так далі.
В UML використовуються наступні види діаграм.
Структурні діаграми (Structure Diagrams):
Композитної/складної структури (Composite structure diagram);
Кооперацій (UML2.0) (Collaboration (UML2.0) );
Діаграми поведінки (Behavior Diagrams):
Варіантів використання(Use CASE diagram);
Діаграми взаємодії (Interaction Diagrams):
Комунікації (UML2.0) / Кооперації (UML1.x) (Communication diagram (UML2.0) / Collaboration (UML1.x));
Огляду взаємодії (UML2.0) (Interaction overview diagram (UML2.0));
Синхронізації (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 - альтернативне представлення діаграми послідовності, явним чином що показує зміни перебування на лінії життя із заданою шкалою часу. Може бути корисна в додатках реального часу.
UML об'єктно-орієнтований, внаслідок чого методи опису результатів аналізу і проектування семантично близькі до методів програмування на сучасних ОО-мовах;
UML дозволяє описати систему практично зі всіх можливих точок зору і різні аспекти поведінки системи;
Діаграми UML порівняно прості для читання після досить швидкого ознайомлення з його синтаксисом;
UML розширює і дозволяє вводити власні текстові і графічні стереотипи, що сприяє його вживанню не лише у сфері програмної інженерії;
UML набув широкого поширення і динамічно розвивається.
Не дивлячись на те, що 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 систем при проектуванні СУБД Delphi дипломная работа. Программирование, компьютеры и кибернетика.
Контрольная работа по теме Основные понятия в страховании
Федеральная Служба Исполнения Наказаний Курсовая Работа
Контрольная работа по теме Внебиржевые фондовые рынки
Курсовая Валютные Счета
Реферат: История и историки. Скачать бесплатно и без регистрации
Курсовая работа по теме Учёт нераспределённой прибыли
Реферат по теме Мышцы
Курсовая работа по теме Расчет тепловой схемы турбоустановки
Белогорская Крепость В Жизни Гринева Сочинение Ребят
Курсовая работа: Лингвистика . Скачать бесплатно и без регистрации
Реферат: Социально-философские взгляды Никколо Макиавелли
Реферат: С.В. Карпенко "Очерки истории белого движения на юге России (1917-1920 гг.)"
Курсовая работа по теме Правотворчество как вид социального проектирования
Заполнение Дневника Преддипломной Практики
Стартовая Контрольная Работа По Биологии 10 Класс
Доклад: Качественный креатив: что это такое?
Статья: Кассовые операции
Реферат: Когнитивно-рациональное консультирование. Скачать бесплатно и без регистрации
Полет Человека На Марс Диссертация
Дипломная работа по теме Приложения дифференциальных уравнений в естествознании
Дифференциальная геометрия поверхностей Каталана - Математика дипломная работа
Понятие и признаки правового государства - Государство и право реферат
Понятие и виды сложного преступления - Государство и право реферат