Дослідження та порівняння, аналіз використання 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 Найменування та галузь застосування

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

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

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

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

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

До складу системи входять:.exe - виконавчий файл розробленої системи;.mdb - файл, що містить таблиці баз даних, і який може бути розташований на будь-якому компютері, що підключений до локальної мережі;.mdl - файл CASE-системи Rational Rose, що містить в собі діаграми класів, компонентів, прецедентів, діяльності та компонентну модель системи.

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

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

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

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

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

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

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

Мінімальні вимоги до апаратного забезпечення:сумісний комп'ютер, не нижче Pentium IІ, RAM-512Mb, SVGA-800*600*16bit;

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

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

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

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

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

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

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

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

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

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

На цьому етапі основна роль в організації процесу розробки 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):

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

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-засобІВ моделювання бізнес процесів

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

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

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

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

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

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

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

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

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

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

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

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

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 (навіщо заново створювати все вище перераховане), доповнивши її необхідними складовими, що відображають прикладну специфіку конкретної системи.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Моделювання предметної областіВиконується моделювання наочної області, описується наочна область "як є"НічогоВизначення вимог до системиВизначаються функціональні вимоги до системи, вимоги до інтерфейсу системи.Створюється прототип призначеного для користувача інтерфейсуАналіз та проектуванняВизначаються базові компоненти архітектури, моделюються дані, детально проектуються компоненти системи.Елементи об'єктної моделі Delphi включаються в базову архітектуру. Забезпечується однозначна відповідність елементів діаграм класів Rose і елементів компонент Delphi.РеалізаціяРеалізуються у вигляді програмних модулів діаграми класів, розробляються діаграми компонентів і діаграми розміщення.Реалізується програмний код, забезпечується однозначна відповідність проекту в Rose і Delphi. Документування коди в Delphi відбивається в Rose.ТестуванняМоделі залишаються практично незмінними. Розробляються тестові приклади для тестування функцій системи.Вносяться зміни в програмний код. Зміни в програмному коді відбиваються в коді Delphi.ВпровадженняДіаграми розміщення є основою для впровадження ПО. На основі моделей може бути отримана актуальна документація системного рівня.Нічого

Як можна відмітити з таблиці 4.1, основна взаємодія Rose і Delphi може відбуватися на етапах визначення вимог до системи, аналізу і проектування і реалізації. Основними моделями, використовуваними на цих етапах, є модель функцій системи, модель інтерфейсу, модель даних, модель специфікацій програмних модулів.

4.5.2 Кодогенератор для забезпечення зв'язку між Delphi і Rose. Основні завдання кодогенератора

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

Отже, кодогенератор повинен:

мати можливість перетворювати класи Rational Rose в код визначення класів на цільовій мові, в даному випадку Delphi, при цьому опис, пов'язаний з конкретним класом повинно поміщатися у відповідне місце програмної коди;

для діаграми класів підтримувати стереотипи, пов'язані із специфічними особливостями мови (наприклад, стереотип unit, interface або property, відповідно визначаючи, що конкретний пакет - є модуль Delphi або клас - є інтерфейс Delphi, або атрибут - є властивість для компоненти Delphi);

мати описаний, очевидний і однозначний спосіб відображення діаграми класів в код Delphi, при цьому відображення має бути таким, що набудовується;

мати можливість імпорту актуальної об'єктної моделі Delphi (бажано для різних версій бібліотеки VCL);

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

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

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

виходячи з діаграми компонент Rose, створювати проект Delphi, що містить необхідні програмні модулі (forward engeneering);

на основі готового проекту Delphi будувати діаграму компонент Rose, що містить у вигляді компонент всі модулі проекту Delphi і пов'язані з ними класи, отримані з Delphi в результаті зворотного проектування (reverse engeneering). Діаграми мають бути компактними і очевидними;

забезпечувати автоматичне узгодження моделі Rose і Delphi після внесення змін до коду модулів Delphi (round trip engeneering);

після внесення змін до моделі Rose і повторній генерації коди не знищувати, фрагменти, написані в середовищі Delphi;

окрім генерації коди, мати спосіб відображення такого важливого елементу Delphi, як форми;

на реальних проектах (сотні класів і модулів) працювати з прийнятною продуктивністю.

4.5.3 Rose Delphi Link (RDL) огляд

Rose Delphi Link (далі скорочено RDL) фірми Ensemble Systems є програмою-мостом (Link), зв'язуючою Rational Rose і Delphi і розробленої в рамках програми по підтримці сторонніх виробників програм-мостів (Links) між Rose і іншими засобами розробки, Rational Software, що проводиться.

Згідно основними функціями RDL є генерація коди і зворотного проектування. Перш за все, відмітимо, що код, створюваний RDL не містить реалізацію (для об'єктної моделі це, як правило, це тіло методу). Коли модель оновлюється з коди Delphi (reverse engeneering або round trip), модель не підвантажує програмний код, написаний в середовищі Delphi для тіл методів. Зміни в моделі стосуються лише декларативних елементів: визначень класів, інтерфейсів, типів, записів і тому подібне Проте, при повторній генерації коди з Rose, тіла методів в Delphi також залишаються незмінними, а міняються лише декларативні елементи. Таким чином "зіпсувати" програмний код при повторній генерації не можна. Для відображення елементів моделі в програмний код RDL використовує Code Generation Properties (CGP) - набір спеціальних таблиць, які зв'язуються з кожним елементом моделей Rational Rose і містять специфічну для Delphi інформацію, використовувану для кодогенерації. Набор цих таблиць доступний з головного меню (пункт Tools/options, закладка Delphi). Для того, що б CGP для Delphi було доступне із специфікації необхідно встановити значення поля Default Language = Delphi в закладці Notation пункту меню Tools/options. Для спрощення роботи в розділі меню Tools/ensemble Tools з'являється також закладка Delphi Property Editor, де можна набудувати властивості вибраного елементу моделі. Використання CGP є типовим прийомом для всіх кодогенераторів від Ensemble Systems, Inc і для Rational Rose взагалі. При використанні Delphi Property Editor можна, не виконуючи кодогенерації, проглянути код відповідного елементу моделі (наприклад, класу), що часто буває дуже зручно.

Враховуючи особливості Delphi (а саме її орієнтованість на розробку призначеного для користувача інтерфейсу) компанія Ensemble Systems пропонує наступну, декілька що відрізняється від стандартного підходу до моделювання в Rational Rose, методологію проектування, рис. 4.1.

Рис. 4.1 - Методологія проектування з використанням Delphi Link

Основна ідея такого підходу полягає у використанні зворотного проектування (Round-trip engineering): всі зміни, зроблені на рівні програмної коди в Delphi, відображуються в об'єктній моделі, побудованій в Rose, і навпаки, при зміні класів, методів і тому подібне в об'єктній моделі Rose, відповідно, коректується програмний код.

4.5.4 Недоліки

Раніше ми визначили, що, на нашу думку, повинен забезпечувати кодогенератор Delphi. В цілому RDL охоплює всі перераховані можливості, за винятком, мабуть, одного: він не дозволяє створювати форми. Основна парадигма візуального програмування в середовищі Delphi полягає в завданні значень відповідних властивостей (значень атрибутів класів) і написанні коди обробників подій. І тут, на жаль, RDL нам не помічник. Але, чи дійсно це настільки серйозне обмеження? Тут можуть існувати різні думки.

Один із шляхів такий. Проектується призначений для користувача інтерфейс в середовищі Delphi (а де це зробити швидше і простіше?) і виконується перетворення програмної коди в моделі Rational Rose. Не дивлячись на те, що форми виходять досить громіздкими, їх можна "причесати", а головне, не відображувати в них неістотні деталі. У Rational Rose проектується, власне, об'єктна модель, модель даних, компонентна модель, тобто архітектурно істотні елементи. У поєднанні з моделлю призначеного для користувача інтерфейсу системи вони утворюють, ту структуру системи, яка може бути відстежена засобами управління конфігураціями, включається в документацію, легко аналізується на предмет наявності принципових помилок і є основою для функціонального тестування, тобто може бути використана на будь-якому етапі життєвого циклу (ЖЦ) розробки ПЗ. RDL при цьому забезпечує повне узгодження моделей і програмної коди протягом всього ЖЦ ПЗ.

4.5.5 Моделювання та розробка СУБД

Спершу необхідний визначити що може виконувати користувач використовуючи дану СУБД. Мною для прикладу буде спроектовано СУБД для тих підтримка Інтернет компанії, в якій можна буде проглянути список наявних клієнтів, пошук клієнтів по ФІО, адресі, імені користувача (login), ip, MAC . Також можна буде виконати додавання нового користувача, додавати заявку на підключення, а також переглядати підключення які вже є. Також в даній СУБД можливо виконуватиме реєстрацію дзвінки користувачів в тих підтримку, і пошук надалі за адресою, коли, і з якої причини звертався користувач в тих підтримку. Всі ці вимоги тепер відображуватимемо за допомогою діаграми в Rational Rose.

Рис. 4.2 - Діаграма прецедентів або варіантів використання

Для створення даної діаграми в браузер програми розкриваємо пункт Use CASE View, далі двічі натискуємо на діаграму Main. На панелі інструментів вибираємо елементи які нам необхідно для створення діаграми:

Рис. 4.3 - Панель інструментів для створення діаграми прецедентів

Actor - Актори представляють користувачів. Вони допомагають відмежовують систему і надають представлення того, що система повинна зробити. Важливо відзначити, що інтермедії актора з, але не має ніякого контролю над випадками використання. Актор - хто-небудь або що-небудь.CASE - Випадки використання краще всього виявляють дослідження акторів і визначення, що актор зможе зробити з системою.Association - Взаємовідношення асоціації представляє однонаправлене семантичне взаємовідношення між двома класами.or instantiares - дозволяє створювати і маніпулювати зборами залежних взаємин.

У специфікації кожного елементу, в рядок «Documantation» можна ввести інформацію про даний елемент, примітка. Специфікація викликається за допомогою контекстного меню.

Рис. 4.4 - Специфікація обєкту

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

Рис. 4.5 - Діаграма діяльності (Activity diagram)

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

Вікно База (baza) - основне вікно СУБД. Вікно містить 3-ри вкладки: картотека - містить інформацію про користувачів, також дозволять здійснювати пошук клієнтів всім необхідним нам параметрам; підключення - містить інформацію про заявки на підключення, так само є можливість редагування заявок і додавання нових; дзвінки - для реєстрації дзвінків клієнтів, з подальшою можливістю пошуку за адресою.

Рис. 4.6 - Вікно «База (baza)»

Вікно «find» - пошук, відкривається при натисненні кнопки пошук у вікні база, вкладка дзвінки.

Рис. 4.7 - Вікно «find»

Вікно «Klient» - клієнт, використовується для зміни даних клієнта, відкривається при подвійному натисненні на запис клієнта у вікна база, вкладка картотека.

Рис. 4.8 - Вікно «Klient»

Вікно «newklient» - новий клієнт, використовується для реєстрації в картотеці нового клієнта. Вікно відкривається при натисненні на кнопку «Додати клієнта» у вікні база на вкладці картотека.

Рис. 4.9 - Вікно «newklient»

Вікно «podkl» - підключення, використовується для реєстрації нової заявки на підключення. Вікно відкривається при натисненні на кнопку «Нове підключення» у вікні база на вкладці підключення.

Рис. 4.10 - Вікно «podkl»

Далі створимо базу даних для зберігання всієї необхідної інформації внесеною до СУБД і для подальшого функціонування додатка. Для створення бази даних я скористалася програмним продуктом компанії Microsoft пакетом Microsoft Office Access 2003. База даних має наступний вигляд:

Рис. 4.11 - База даних

Таблиця kartoteca - містить дані про клієнтів компанії.

Рис. 4.12 - Конфігурація таблиці kartoteca

Таблиця new - містить дані про нові підключення;

Рис. 4.13 - Конфігурація таблиці new

Таблиця «cool» - містить дані про дзвінки клієнтів

Рис. 4.14 - Конфігурація таблиці «cool»

Схема даних БД baza має наступний вигляд:

Рис. 4.15 - Схема даних БД baza

Підключаємо БД до створюваної нами СУБД за допомогою технології ADO.

Так як за допомогою Rose Delphi Link та й взагалі Rational Rose генеруються лише декларативні елементи: визначення класів, інтерфейсів, структур і типів. Тому функціональній код мною було прописано в Delphi.

Далі приступаємо до роботи з Rose Delphi Link. Запускаємо Rational Rose Enterprise Edition. Вибираємо меню Toolse -> Ensemble Tools -> Rose Delphi Link. Вікно Rose Delphi Link є основним при узгодженні об'єктних моделей Delphi і Rose і при його використанні реалізується будь-яка з трьох технологій спільної роботи - пряме проектування, зворотне проектування і узгодження (round trip). Ліва панель на екрані містить дерево проекту в Rational Rose (у частині Component View). Права панель відображує дерево проекту в Delphi. Для оновлення інформації про проекти потрібно натискувати кнопку Refresh, а для виконання узгодження моделей в ту або іншу сторону (з Rational Rose в Delphi або з Delphi в Rational Rose) кнопки Update All. Для зручності роботи елементи, які не згоджені, в моделях помічені знаком оклику. Для вибору необхідного проекту в Delphi слід скористатися головним меню вікна.

Рис 4.16 - Вікно після узгодження проектів

Виконали узгодження проектів моделей за допомогою даного вікна і при цьому отримали наступне:

Кожному модулю проекту в Delphi зіставлений компонент із стереотипом <Unit> в розділі Component View дерева проекту Rose. Нашому проекту Project1.dpr зіставлений компонент із стереотипом <Program>.

Для кожного модуля Delphi в розділі Logical View утворився пакет із стереотипом <Unit>, а усередині пакету міститься діаграма класів, відповідна даному модулю. СУБД містить 5-ть робочих вікон, формується 5-ть діаграм класів.

Рис. 4.17 - Діаграма класів, та звязків між класами

Вікно «baza» відповідає Unit 1 і діаграма класів наступного вигляду:

Рис.4.18 - Діаграма класів Unit 1

Клас Tbaza виконує такі операції:

Рис. 4.19

В Rational Rose програмний код цих операцій має вигляд:

// Основная форма приложения= class (TForm)

// Операция по открытию формы для регистрации новой заявкиButton4Click (Sender : TObject);

// Операция на открытие формы для регистрации клиентаButton2Click (Sender : TObject);

// Операция выполнения запроса по адресуButton5Click (Sender : TObject);

// Операция выполняемая при открытии формыFormShow (Sender : TObject);

// Операция выполнения запроса по ФИОButton6Click (Sender : TObject);

// Операция по открытию формы для редактирования данных о клиентеDBGrid2DblClick (Sender : TObject);

// Операция выполнения запроса по MACButton7Click (Sender : TObject);

// Операция выполнения запроса по ipButton8Click (Sender : TObject);

// Операция выполнения запроса по логинуButton9Click (Sender : TObject);

// Операция по открытию формы на выполнения поиска в списке звонковButton1Click (Sender : TObject);

// Операция вывода сообщения при закрытии формыFormClose

(Sender : TObject;Action : TCloseAction);;

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

Вікно «find» відповідає Unit 5 і діаграма класів наступного вигляду:

Рис.4.20 - Діаграма класів Unit 5

Клас Tfind виконує такі операції:

Рис. 4.21

В Rational Rose програмний код цих операцій має вигляд:

// Форма поиска в списке звонков клиентов по адресу= class (TForm)

// Поиск по таблице согласно запросуButton2Click (Sender : TObject);

// Закрытие формыButton1Click (Sender : TObject);;

Вікно «newklient» відповідає Unit 2 і діаграма класів наступного вигляду:

Рис.4.22 - Діаграма класів Unit 2

Клас Tnewklient виконує такі операції:

Рис. 4.23

В Rational Rose програмний код цих операцій має вигляд:

// Форма регистрации клиента в базу.= class (TForm)

// Операция закрытия формы без сохранения данныхButton2Click (Sender : TObject);

// Операция перед открытием формыFormShow (Sender : TObject);

// Операция перед сохранением данныхTable1BeforePost (DataSet : TDataSet);

// Операция сохранения данных с последующим закрытием формыButton1Click (Sender : TObject);;

Вікно «podkl» відповідає Unit 3 і діаграма класів наступного вигляду:

Рис. 4.24 - Діаграма класів Unit 3

Клас Tpodkl виконує такі операції:

Рис. 4.25

В Rational Rose програмний код цих операцій має вигляд:

// Форма добавления нового подключения в базу= class (TForm)

// Операция закрытия без сохранения данныхButton2Click (Sender : TObject);

// Операция выполняемая при открытии формыFormShow (Sender : TObject);

// Операция, выполняемая перед сохранением данныхTable1BeforePost (DataSet : TDataSet);

// Операция добавления новой заявки в базуButton1Click (Sender : TObject);;

Вікно «Klient» відповідає Unit 4 і діаграма класів наступного вигляду:

Рис.4.26 - Діаграма класів Unit 4

Клас TKlient виконує такі операції:

Рис. 4.27

В Rational Rose програмний код цих операцій має вигляд:

// Форма для редактирования информации клиентов компании= class (TForm): Tbaza;

// Операция сохранения данных с закрытием формыButton1Click (Sender : TObject);

// Операция выполняемая при открытии формыFormShow (Sender : TObject);

// Операция закрытия формыButton2Click (Sender : TObject);;

Також, що в процесі додавання в систему нових модулів і класів і узгодження моделей ми автоматично отримали компонентну модель системи:

Рис. 4.28 - Компонентна модель системи

Отже, підведемо короткі підсумки. В результаті спільного використання Rational Rose і Delphi ми отримали:

інтерфейсні і такі, що управляють класи, організовані в пакети;

компонентну модель системи.

Класи - суть і діаграми, що описують динаміку, спроектовані в Rational Rose. Надалі моделі Rational Rose дають нам базу для документування проекту, відстежування його стану і організації функціонального тестування. Проект, отриманий в Delphi, у свою чергу, є основою для виконання реалізації. В процесі реалізації проводиться періодичне узгодження проекту в Delphi з моделлю Rational Rose на основі технології round trip, що дозволяє підтримувати моделі в актуальному стані і плавно здійснювати їх еволюцію відповідно до вимог, що змінилися, до системи.

5. AllFusion ERwin Data Modeler (ERwin)

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

ERwin/erx призначений в основному для розробників, проектувальників БД, системних аналітиків. Функціональність ERwin/erx робить його також незамінним інструментом для адміністраторів БД і керівників проектів. Керівники проектів можуть за допомогою ERwin/erx ретельно задокументувати структуру БД, отримати звіти презентаційної якості і забезпечити ефективне управління проектом, використовуючи інтеграцію ERwin/erx із спеціалізованим засобом організації колективної роботи - CA Modelmart. Оскільки ERwin/erx підтримує роботу з БД на фізичному рівні, враховуючи особливості кожної конкретної СУБД, адміністратори БД можуть з його допомогою максимально підвищити продуктивність інформаційної системи. Розробники за допомогою ERwin/erx можуть спочатку, використовуючи візуальні засоби, описати схему БД, а потім автоматично згенерувати файли даних для вибраної реляційної СУБД (пряме проектування). Автоматично генеруються також тригери, що забезпечують посилальну цілісність БД. Підтримуються процедури, що зберігаються. ERwin/erx підтримує нотації Idef1x, IE і DIMENSIONAL. Користувач описує структуру даних візуально. Він задає службовці прообразами реляційних таблиць суті з їх атрибутами і за допомогою миші "натягує" між ними зв'язки, які є прототипами реляційних стосунків.

Попередні версії ERwin - 1.5 і 2.1 - завоювали всі можливі призи серед програм свого класу, у тому числі DBMS Readers'' Choice в 1992, 1993, 1994, 1995 роках, Software Development Productivity Award 1993, Data Based Advisor Readers'' choice 1992 і 1994. Поточна версія продукту - 2.5.

Реалізація моделювання в ERwin базується на теорії реляційних баз даних і на методології Idef1x.

Методологія IDEF1X розроблена для ВПС США і тепер використовується зокрема, в урядових, аерокосмічних і фінансових установах, а також у великі кількості приватних компаній.

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

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

5.1.1 Основні характеристики

Підтримка стандартної нотації IDEF1X для ER діаграм моделей даних, нотації IE і спеціальної нотації, що призначена для проектування сховищ даних - DIMENSIONAL;

Можливість імпорту / експорту даних з BРwin, Oracle Designer;

Підтримка проектування інформаційних сховищ (на основі Red Brick і Teradata);

Підтримка спільного проектування (версія для ModelMart);

Підтримка тригери, збережених процедур і шаблонів;

Розвинені засоби перевірки коректності моделей даних;Engineering (генерація моделі даних на основі аналізу існуючої бази даних), включаючи відновлення зв'язків по індексам;

Автоматична генерація SQL DDL для створення баз даних;

Повна сумісність і підтримка більше 20-ти типів СУБД на основі прямого доступу до системного каталогу баз даних (відпадає потреба у використанні ODBC).

Спеціальні реалізації продукту з прямою підтримкою розширеного набору атрибутів у моделях даних для засобів розробки додатків PowerBuilder і Visual Basic. Існують лінки для роботи з Delphi від третіх виробників.

Глибока інтеграція з продуктами Oracle, Sybase, Centura, Microsoft на базі єдиного сховища і ефективного обміну проектами; імпорт / експорт з Rational Rose.

Автоматична генерація екранних форм додатків для PowerBuilder, Delphi, Visual Basic, створених на основі спроектованої моделі даних.

5.1.2 Системні вимоги ERwin / ERX

ERwin / ERX працює зі всіма версіями операційної системи Windows, існує у 16-ти і 32-розрядної варіанти і займає близько 50 Mb дискового простору.

5.2 Інтеграція ERwin з іншими програмними продуктами

Ще більш високої ефективності використання ERwin / ERX можна домогтися, використовуючи можливості інтеграції його з іншими програмними продуктами. Різні принципи доступу до розроблених моделей з інших програм, написаних з використанням різних засобів розробки, дозволяють створити більш гнучку, потужну та високоефективну сучасну інформаційну систему. / ERX не прив'язаний до технології якої-небудь конкретної фірми, постачає СУБД або засоби розробки. Він підтримує різні сервери баз даних і настільні СУБД, а також може звертатися до бази даних через ODBC.

У ERwin / ERX вбудована підтримка наступних СУБД: Oracle, Sybase; Informix; CA Ingres; DB2, Rdb; Watcom; Centura SQLBase; Microsoft SQL Server; AS/400; Progress; FoxPro; InterBase; dBASE; Clipper; Paradox; Access та ін./ ERX можна використовувати разом з багатьма популярними засобами розробки додатків: Delphi, PowerBuilder, Visual Basic, Oracle Designer/2000 та ін. Продукт інтегрований також з Rational Rose, CA Paradigm Plus, CA BPwin і CA ModelMart.

5.3 Моделювання в ERwin

Процес побудови інформаційної моделі складається з наступних кроків:

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

визначення залежностей між сутностями;

завдання первинних та альтернативних ключів;

визначення атрибутів сутностей;

приведення моделі до необхідному рівню нормальної форми;

перехід до фізичного опису моделі: призначення відповідностей ім'я сутності - ім'я;

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

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

5.4 Відображення логічного та фізичного рівня моделі даних в ERwin

У ERwin існують два рівня представлення і моделювання - логічний і фізичний. Логічний рівень означає пряме відображення фактів з реального життя. Наприклад, люди, столи, відділи, собаки і комп'ютери є реальними об'єктами. Вони іменуються на природному мовою, з будь-якими роздільниками слів (пробіли, коми і т.д.). На логічному рівні не розглядається використання конкретної СУБД, не визначаються типи даних (наприклад, ціле або Речовий число) і не визначаються індекси для таблиць.

Цільова СУБД, імена об'єктів та типи даних, індекси складають другий (фізичний) рівень моделі ERwin.надає можливості створювати та управляти цими двома різними рівнями подання однієї діаграми (моделі), так само як і мати багато варіантів відображення на кожному рівні.

.5 Компоненти діаграми ERwin та основні види уявлень діаграми

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

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

Режим "сутності" - всередині прямокутників відображається ім'я сутності (для логічної моделі) або ім'я таблиці (для фізичного представлення моделі); служить для зручності огляду великий діаграми або розміщення прямокутників сутностей на діаграмі;

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

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

Режим "піктограми". Для презентаційних цілей кожної таблиці може бути поставлено у відповідність піктограма (bitmap);

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

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

5.6 Інструменти для створення моделі в ERwin

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

Натисненням миші над сутністю здійснюється вхід в один з численних редакторів ERwin:

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

редактори атрибутів (визначення атрибутів, колонки таблиці у фізичному представленні моделі, Репозитарії засоби 4GL, наприклад, розширені атрибути в PowerBuilder).

5.7 MetaBASE як засіб доступу до метадані

MetaBASE являє собою набір утиліт та візуальних компонент для Delphi 1.0 і 2.0, випущений компанією gs-soft і поставляється в комплекті з ERwin (Logic Works). Призначення цього набору - надати об'єктно-орієнтований доступ до моделі даних ERwin в процесі розробки і виконання клієнтських додатків, що створюються за допомогою Delphi. Здійснюється цей доступ за рахунок створення спеціалізованого словника даних (у термінології авторів продукту - Metamodel), відмінного від словника даних Delphi 2.0, який, c одного боку, підтримує двонаправлений обмін метаданими з ER-діаграмою формату. Erx за допомогою спеціальної утиліти, а, з іншого боку, доступний для використання набором поставляються в комплекті візуальних компонент для доступу до даних, які, в свою чергу, є повноцінною заміною стандартним компонентів з комплекту поставки Delphi, хоча і не виключають їх використання в додатку. Відзначимо, що користувачі 16-розрядної версії Delphi, кількість яких в нашій країні ще, мабуть, довго буде досить великий, при використанні MetaBASE отримують відсутній у цій версії, але для багатьох бажаний словник даних.

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

Складові частини MetaBASE:- менеджер проектів MetaBASE (написаний на Delphi). Він транслює модель даних в об'єкти MetaBASE і зберігає їх у спеціалізованому словнику даних (Metamodel). Пізніше цей словник даних використовується як середовищем розробки Delphi, так і розробленими додатком під час виконання. також може здійснювати перенесення змінених об'єктів MetaBASE назад в модель даних. Іншими словами, це повноцінний інструмент two-way-tool. Metamodel - об'єкт, який містить всю інформацію про об'єкти моделі даних - сутність, індекси, атрибути, доменах і зв'язках. Крім того, Metamodel містить розширені атрибути типу масок, міток і т.д., які можуть бути змінені в редакторі MetaBASE Editor. Всі об'єкти моделі даних доступні при створенні програми.Editor-ієрархічної вікно перегляду метамоделі, що дозволяє редагувати модель даних, змінювати розширені атрибути, синхронізувати моделі даних в ER-діаграмі і в словнику даних, вибирати інтерфейсні елементи для відображення таблиць і полів, вибирати спосіб доступу до даних (таблиця або запит). Цей редактор метаданих використовується в середовищі розробки в якості редактора властивостей компонентів, що входять в комплект поставки MetaBASE.

Бібліотека візуальних компонентів MetaBASE, що мають прямий доступ до словника даних. Ці VCL-компоненти існують в 16 - розрядний і 32-розрядний варіантах.використовується для визначення загальної інформації, що не має прямого відношення до моделі даних. Приклад - "гарячі клавіші", які є допустимими в додатку.являє собою центральний модуль для визначення бізнес-правил. В його властивості визначаються правила перевірки достовірності, форматування і значень за замовчуванням. За допомогою цього компонента здійснюється зв'язок меж у словником даних Metamodel та додатком.- спадкоємець стандартного компоненту TQuery Delphi. Однак цей компонент безпосередньо пов'язаний з Metamodel. Всі поля, що містяться в TQueryGS, автоматично використовують бізнес-правила, визначені в TMetaBaseGS. Крім стандартних функцій, TqueryGS підтримує розширення функції QBE (Query By Example - запит за зразком).- спадкоємець стандартного компоненту TTable Delphi's, також безпосередньо пов'язаний з Metamodel. Всі поля, що містяться в TTableGS, автоматично підпорядковуються бізнес-правилами, визначеними в TMetaBaseGS. Крім стандартних функцій, TTableGS підтримує розширений пошук та функції індексування.- інтерфейс між компонентами набору даних (TTableGS, TQueryGS) та візуальними компонентами форм. TDataSourceGS - спадкоємець TDataSource Delphi, здатний використовуватися в якості перемикача між звичайним режимом візуального відображення даних, режимом запиту за зразком або режимом пошуку в таблиці і режимом індексації. - багатофункціональний компонент, який може відобразити дані у вигляді "інтелектуальних" таблиць (на зразок DBControlGrid). При цьому TDBGridGS відображає поля за допомогою тих інтерфейсних елементів, які визначені в словнику даних Metamodel (наприклад CheckBox, Search Table і т.д.). TDBGridGS може також бути використаний для режиму Query By Example.- центральний компонент для відображення даних. Він відображається самостійно у вигляді того інтерфейсного елемента, який визначений в словнику даних Metamodel (наприклад як check-box або lookup field).пов'язаний з TDBFieldGS і являє собою позначку, визначену у словнику даних Metamodel. - інформаційний компонент, який дозволяє представити текст для розшифровки поля з поточного набору даних, використовуючи пов'язану словникову таблицю.застосовується для відображення додаткової інформації, доступною за допомогою зовнішнього ключа, з пов'язаної таблиці (а саме, атрибути відповідного запису).використовується для визначення значення пошуку в індексованої таблиці.використовується для активізації процесу пошуку (можливо, за допомогою діалогу).схожий на компонент TIdxDBFieldGS. Він використовується для введення значень Query By Example. Компоненти TQbeDBFieldGS можуть бути скомбінувати для виконання запиту до декількох полів.з усіх значень, записаних в компонентах TQbeDBFieldGS, створює команду SQL і виконує запит. При об'єднанні цього компоненту з TDBGridGS, можна переключатися між режимом візуального відображення даних і режимом Query By Example.призначений для зміни індексу таблиці, відображається з допомогою компонента TtableGS.дозволяє вибрати таблицю зі словника даних під час виконання. TDBAttributComboGS дозволяє змінити атрибут DBFieldGS під час виконання.

5.7.1 Delphi + ERwin + MetaBase

Delphi не може безпосередньо працювати з ERwin. Посередником між ними виступив продукт фірми gs-soft MetaBase.

Як взаємодіють ці три продукту? Створена за допомогою ERwin модель даних зберігається у файлі з розширенням ERX (за замовчуванням ERwin створює файли з розширенням ER1). Формат ERX стандартизована і описує модель даних в текстовому форматі. Застосовується він для перенесення моделей між різними CASE-засобами і для організації доступу до моделей з користувальницьких додатків. Щоб зрозуміти подальший процес проектування давайте визначимо послідовність перетворення моделі даних. Модель перетвориться в метамодель MetaBase, яка зберігається у файлі спеціального формату. У метамоделі описуються властивості сутностей і атрибутів моделі даних. Крім того, MetaBase містить бібліотеку компонент, що крім роботи з базою вміють читати метамодель. При побудові проекту на Delphi з використанням даних компонент не потрібно налаштування властивостей, тому що вони описані вже в метамоделі. У чому перевага такого підходу до проектування. При зміні моделі даних потрібно тільки прочитати її в MetaBase і змінити метамодель, налаштувати властивості нових або змінених сутностей та атрибутів. Але спочатку треба зробити зворотне проектування метамоделі в модель даних (щоб в моделі даних збереглися всі описані в метамоделі властивості). При запуску проекту на Delphi все нові колонки або поля з'являться в екранній формі. Мабуть, потрібно лише змінити розмір форми (якщо будуть додаткові поля). Для роботи з MetaBase необхідно запустити програму MetaGen.

Рис. 5.1 - Вигляд початкового вікна програми MetaGen

Робота починається зі створення проекту (закладка Projects), для якого треба задати наступні параметри:

назва проекту;

каталог, де буде розташований проект;

каталог, де знаходиться модель даних;

ім'я бази даних (оголошується у BDE);

фільтр проекту - свого роду маска для імен файлів проекту.

На закладці Model виводиться список файлів моделей даних, розташованих у вказаному каталозі та відповідних фільтру. Необхідно вибрати одну модель для проекту. Закладки Settings та Settings Codegen дозволяють встановити додаткові параметри для проекту.

Далі треба перейти на закладку Transfer. Натисканням кнопки Import модель перетвориться в метамодель MetaBase. Щоб мати можливість редагувати метамодель треба натиснути кнопку Check Out. Для редагування натискається кнопка MetaBase Editor. Для відкриття доступу до метамоделі треба натиснути кнопку Check In. Кнопкою Export виконується процес створення з метамоделі моделі даних у форматі ERX.

Рис. 5.2 - Редактор метамоделі даних

Редактор метамоделі дозволяє встановити властивості суті і атрибутів моделі даних, які зберігаються в метамоделі:

влучні;

заголовки;

домени;

підказки і так далі;

Особливістю MetaBase є можливість завдання індивідуальних властивостей для кожного користувача (за умови багатокористувацької версії MetaBase), кожен користувач може побачити свої заголовки колонок в таблиці і т. п. Одного версія працює тільки з користувачем, що має ім'я USER1. Цю особливість треба врахувати при створенні бази, оголосивши користувача USER1 в БД.

В редакторі можна виконати команди Check In та Check Out. Наступним етапом треба створити новий проект в Delphi. Якщо створюється перший проект, попередньо потрібно встановити компоненти MetaBase.

Рис. 5.3 - Компоненти MetaBase в Delphi

Компоненти встановлюються командою Install Packages. Встановлювати треба файл, розташований в підкаталозі VCLGS того каталогу, де був встановлений MetaBase. Порядок створення форми для роботи з MetaBase в Delphi практично нічим не відрізняється від створення стандартної форми для роботи з базою даних. Відмінність полягає лише в використовуваних компонентах (назви компонент MetaBase закінчується на GS). У таблиці наведена послідовність підключення компонент у стандартному і розглянутому випадку (розглянуто найпростіший випадок).

Таблиця 5.1 - Послідовність підключення компонент у стандартному і розглянутому випадку

СтандартнийРобота з БД з використанням MetaBaseDatabase *)MetabaseGS *) -MetaSourceGS Table або QueryTableGS або QueryGS DataSourceDataSourceGS DBGridDBGridGS *) - Використання необов'язково

Для зв'язку компонент в ланцюжок встановлюються відповідні властивості. При установці властивості MetaBaseName в компоненті MetaSourceGS (треба встановити ім'я метамоделі) для інших компонент стають доступними відповідні параметри і властивості метамоделі. Наприклад, у компоненті TableGS для властивості MetaEntityName з'являється можливість вибору зі списку сутностей метамоделі. Після вибору суті автоматично встановлюється властивість TableName, так як в метамоделі прописана зв'язок імен сутностей і таблиць.

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

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

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

6. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ

.1 Організаційно-економічна частина

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

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

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

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

Необхідні для проектування СУБД засоби обчислювальної техніки: персональна ЕОМ на базі процесора Pentium IV з тактовою частотою 2.1 Мгц, 512 Мб оперативної памяті, HDD 40 Гб, дисковод для компакт-дисків 4-х швидкісний.

6.2 Розрахунок економічного ефекту по упровадженню програмного продукту

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

Таблиця 6.1 - Витрати на додаткові матеріали

№ п/пНайменування матеріалуВитрата, шт.Ціна, грн./шт.Сума, грн.1Допоміжна література255,001102 Диск DVD-R12,002,003Rational Rose Enterprise Edition 2003 або ERwin1600600Разом: 712,00 грн.

Основні виробничі фонди:

Комп'ютер класу Pentium IV - 1 шт за ціною 3220 грн;

Загальна сума виробничих фондів складає - 3220 грн.

Вартість устаткування збільшується на вартість транспортування - 10% та вартість монтажу - 15%. Разом вартість устаткування складе:

Соб= 3220 + 322 + 483 = 4025 грн.

Амортизація комп'ютера складає 15% у квартал від залишкової вартості, тобто А = Ф*На, де Ф - залишкова вартість на початок кварталу,

На - норма амортизації.квартал 4025*0,15=603,75 грн.квартал (4025-603,75)*0,15=513,1875 грн.квартал (4025-603,75-513,1875)*0,15=436,209 грн.квартал (4025-603,75-513,1875-436,209)*0,15=370,778 грн.

Разом амортизація = 1923,92 грн.

Таблиця 6.2 - Основна заробітна плата програміста

№ п/пВиконавціТрудомісткість, люд.дн.Оклад, грн.Витрати по з/п, грн.1Програміст2013001235

Додаткова заробітна плата програміста складає 20 % від основної заробітної плати:

*0,20=247 грн.

Фонд заробітної плати являє собою суму основної й додаткової заробітної плати:

+247=1482 грн.

Відрахування на заробітну плату складає:

,2% - пенсійний фонд;

,5% - соціальне страхування;

,3% - відрахування в державний фонд сприяння зайнятості;

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

Разом відрахування на соціальні нужди складають 37% від фонду оплати праці:

*0,37=548,34 грн.

Накладні витрати складають 250 % від величини основної заробітної плати:

*2,5=3087,5 грн.

Таблиця 6.3 - Калькуляція

№ п/пНайменування статей витратВитрати, грн.1 Амортизація основних засобів1923,922Розхідні матеріали7123 Основна заробітна плата програміста12354 Додаткова заробітна плата програміста2475Відрахування на соціальне страхування548,346 Накладні витрати3087,5 Разом витрат: Зк= 7753,76

Витрати на ручну обробку інформації визначаються по формулі:

,

де - обєм інформації, що обробляється вручну, Мбайт;

- вартість однієї години праці, грн. / рік;

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

- норма виробітку, Мбайт / рік.

У даному випадку:

= 20 Мбайт (загальний розмір даних, що обробляються),

Заробітна плата оператора 1000 грн.

Ц=1000/21/8=5,95 грн. / година,

Гд = 2,5 (встановлений експериментально),

Нв = 0,004 Мбайт / година.

Отже, витрати на ручну обробку інформації дорівнюють:

Зр=13*5,95*2,5/0,004=48343,75 грн.

Витрати на автоматизовану обробку інформації розраховуються по наступній формулі:

,

де - година автоматизованої обробки, рік.;

- вартість однієї години машинного часу, грн./рік;

- година роботи оператора, рік.;

- вартість однієї години роботи оператора, грн./рік.

Для даного випадку:= 180 год.,Номінальний фонд робочого часу розраховується по формулі :

моделювання delphi rose кодогенератор

к - кількість відпрацьованих годин за рік;

к1 - внутрішні втрати робочого часу, 1- 2% (пільгові години, перерви та ін.).

К = д * р * м

д - середня кількість робочих днів у місяці = 21;

р - тривалість робочого дня = 8;

м - кількість робочих місяців за рік = 11;

К = 21 * 8 * 11 = 1848 годин за рік.

= 1663,2 год.

Час роботи оператора = 1663,2 годин за рік

Вартість однієї години машинної години дорівнює:

Цм = Цэ*Р

Цэ - вартість 1квт електроенергії (0,24 грн.)

Р - споживана потужність комп'ютера в рік 160 Вт

Цм=0,24*0,16=0,04грн/рік= 180 год

Ц0 =1000/ 21/8=5,95 грн. (заробітна плата оператора 1000 грн)

Отже, витрати на автоматизовану обробку інформації дорівнюють:

За=180*0,04+180*(5,95+0,04) =1085,40 грн.

Таким чином, річна економія від упровадження дорівнює:

Еу = 48343,75 - 1085,40 - 7753,76= 39504,59 грн.

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

.

Ег=39504,59 - 7188,76*0,2=38067 грн.

Ефективність розробки може бути оцінена по формулі:

.

Ер=38067* 0,4/7188,76=2,1181

Якщо Ер > 0,20, то спроектована СУБД з використанням CASE систем є економічно доцільною.

Вартісна оцінка результатів застосування програмного забезпечення за

,

де - розрахунковий період ;

- вартісна оцінка результатів розрахункового періоду, грн.;

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

Дисконтуюча функція має вигляд:

,

де р - коефіцієнт дисконтування (р = Ен = 0,2, Ен - нормативний коефіцієнт ефективності капітальних вкладень).

Таким чином,

.

Якщо програмне забезпечення заміняє ручну працю, отже, набір корисних результатів у принципі не міняється. У якості оцінки результатів застосування програмного забезпечення за рік береться різниця (економія) витрати, які виникають у результаті використання програмного забезпечення, тобто Рt = Еу.

Припускається, що дана розробка без змін та доопрацювань буде використовуватись у плині 3-х років. Тоді вартісна оцінка результатів застосування програмного забезпечення (економія) за розрахунковий період Т = 3 роки складе:

= 31722,5 +26435,42+22029,52=80187,44 грн.

Економічний ефект від використання програмного забезпечення за розрахунковий період Т = 3 роки складе:

Ет = 80187,44 - 7753,76 = 72433,68 грн.

Таким чином, у результаті аналізу встановлено, що впровадження спроектованої СУБД з використанням CASE систем виправдано й економічно доцільно.

7. ОХОРОНА ПРАЦІ

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

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

Законодавство України про охорону праці базується на:

Конституції України, яка гарантує права громадян на працю, відпочинок, охорону здоровя, медичну допомогу і страхування;

Законі України „Про охорону праці , де вказано, що державна політика в області охорони праці базується на пріоритеті життя і здоровя людей в умовах їх трудової діяльності. Відповідальність за створення нормальних і безпечних умов труда несе роботодавець незалежно від форми власності підприємства чи установи які здійснюють розробку виробництва та застосування ПЕОМ і ПК;

Нормах штучного та природного освітлення визначені СНіП ІІ-4-79/85;

Законі України „Про забезпечення санітарного та епідемічного благополуччя населення де вказані основні вимоги гігієни та санітарії;

Параметрах мікроклімату на робочих місцях регламентовані у ДОСТ 12.1.005-88 и ДСН 3.3.6.042-99;

Категорія робіт по величині загальних енергозатрат встановлена ДСН 3.3.6.042-99;

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

Кодексі законів про працю (КЗпП) де викладені окремі вимоги охорони праці;

Законі України „Про пожежну безпеку і „Правила про пожежну безпеку в Україні

Крім того є ряд Державних стандартів, правил, норм, інструкцій та інших нормативних документів, регламентуючих питання охорони праці.

7.1 Інженерна охорона праці

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

Робоче місце, устатковане відео-терміналом, забезпечується:

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

. відповідністю оптимальних параметрів мікроклімату;

. належними ергономічними характеристиками основних елементів робочого місця.

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

Відповідно діючим нормативним документам площа приміщення 30,0 м²; обєм - 20 м³. Стіна, стеля, підлога приміщення виготовляються з матеріалів, дозволених для оформлення приміщень санітарно-епідеміологічним наглядом. Підлога приміщення вкрита діелектричним килимком, випробуваним на електричну міцність.

Висота робочої поверхні столу для відео-терміналу - 690 мм, ширина повинна забезпечувати можливість виконання операцій в зоні досягнення моторного ходу; висота столу 725 мм, ширина 800 мм, глибина 900 мм. Простір для ніг: висота 600 мм, ширина 500 мм, глибина на рівні колін 500 мм, на рівні витягнутої ноги 650мм.

Ширина й глибина сидіння 400 мм, висота поверхні сидіння 450 мм, кут нахилу поверхні від 15º вперед до 5º назад. Поверхня сидіння плоска, передній край закруглений.

В приміщенні з ПЕОМ кожен день проводиться вологе прибирання.

В доступних місцях знаходяться аптечки першої медичної допомоги.

7.2 Аналіз небезпечних та шкідливих на виробництві факторів при роботі на компютері

Небезпечні та шкідливі виробничі чинники класифікуються згідно ДОСТ 12.0.003-74 за природою дії на наступні групи:

. фізичні;

. психофізичні.

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

Фізичні небезпечні та шкідливі виробничі чинники підрозділяються на наступні:

підвищений рівень шуму на робочому місці;

підвищена або знижена вологість;

недостатня освітленість робочої зони;

підвищена або знижена рухливість повітря;

підвищений рівень статичної електрики;

Психофізичні небезпечні і шкідливі виробничі чинники по характеру дії підрозділяються на:

фізичні перевантаження (статичні і динамічні);

нервово-психічні перевантаження (розумова напруга і перенапруження, монотонність праці, емоційні перевантаження, стомлення, емоційний стрес).

7.2.1 Мікроклімат робочої зони

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

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

Одним з найважливіших фізіологічних механізмів організму є терморегуляція, що залежить від мікрокліматичних умов навколишньої середи. Терморегуляція підтримує тепловий баланс організму людини при різноманітних метеорологічних умовах і тяжкості роботи, що виконується за рахунок звуження або розширення поверхні кровоносних судин і відповідної роботи потових залоз. В холодні періоди року температура повітря, швидкість його руху і відносна вологість повітря відповідно складають: 22-24 С°; 0,1 м/с; 40-60%; в теплі періоди року температура повітря - 23-25 Сº; відносна вологість 40-60 %; швидкість руху повітря - 0,1 м/с.

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

7.2.2 Вплив шуму

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

Допустимим рівнем звукового тиску в октавних смугах частот, рівні звуку і еквівалентні рівні звуку на робочому місці дорівнює 50 дБА.

7.2.3 Освітлення робочого місця

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

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

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

В офісі природного освітлення немає, є лишень штучне освітлення.

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

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

Штучне освітлення є загальним (рівномірним або локалізованим) і комбінованим (до загального додається місцеве). На виробництві застосовується лише загальне освітлення.

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

7.2.4 Дія електричного струму та електромагнітного поля

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

роду і величини напруги і струму;

частоти електричного струму;

шляхи проходження струму через тіло людини;

тривалості дії на організм людини;

умов зовнішнього середовища.

Норми на допустимі струми складає і напруги дотику в електроустановках встановлюються відповідно до гранично допустимих рівнів дії на людину струмів і напруг дотику і затверджуватися в установленому порядку по ДОСТ 12.1.038-82, вони складають відповідно 0,3 мА і 2 В.

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

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

7.2.5 Психофізіологічні шкідливі і небезпечні виробничі чинники

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

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

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

7.3 Організаційні і технічні заходи по зменшенню рівня шкідливих виробничих чинників

.3.1 Захист від ураження електричним струмом

Гранично допустимі рівні напруги дотику і струмів при експлуатації і ремонті обладнання забезпечені:

? ізоляцією струмоведучих мереж;

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

? правильного компонування, монтажу приладів і елементів;

? дотриманням умов безпеки при настанові і заміні приладів і інше.

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

? застосування захисного заземлення або занулення;

? ізоляцією струмопровідних частин;

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

? надійним контактним сполученням з урахуванням перепаду кліматичних параметрів.

7.3.2 Захист від статичної електрики

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

На робочих місцях всі металеві та електропровідні неметалеві обладнання заземлені.

7.3.3 Захист від шуму та вібрації

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

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

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

7.3.4 Оздоровлення повітряного середовища

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

7.3.5 Забезпечення раціонального освітлення

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

Раціональне освітлення відповідає ряду вимог:

достатнє, щоб очі без напруги могли розрізняти деталі;

постійна напруга в мережі не коливається більше ніж на 4%;

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

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

не викликає різких тіней на робочих місцях.

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

При проектуванні освітлювальної установки необхідно вирішити наступні основні питання:

? вибрати тип джерела світла - рекомендуються газорозрядні лампи, за винятком місць, де температура повітря може бути менш +5 ° C і напруга в мережі падати нижче 90 % номінального, а також місцевого;

? визначити систему освітлення (загальна локалізована або рівномірна, комбінована);

? вибрати тип світильників з урахуванням характеристик світорозподілення, умов середовища;

? розподілити світильники і визначити їх кількість (світильники можуть матися в своєму розпорядженні рядами, в шаховому порядку, ромбоподібно);

? визначити норму освітленості на робочому місці.

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

=(Emin·S·K·z) / n1·n·N,

де F - світловий потік лампи в світильнику, лм; S - площа приміщення, м2; K - коефіцієнт запасу; z - коефіцієнт нерівномірного освітлення; n1 - коефіцієнт використання світлового потоку; n - кількість ламп в світильнику; N - число світильників.

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

Значення коефіцієнта n1 визначається по довіднику в залежності від типу світильника, коефіцієнтів відбивання стін Рс, стелі Рп, робітничій поверхні і від розмірів приміщення.

Показник приміщення fi визначається з виразу:

fi= А·В/Нр·(А+В),

де А і В - довжина і ширина освітленого приміщення, м;

Нр - висота підвісу світильника над робітничою поверхнею, м.

У випадку застосування люмінесцентних ламп потрібна кількість світильників N, яка визначається за формулою:

N=Emin·S·K·z/F·n1·n

Поділивши число світильників N на число вибраних рядів світильників, визначають число світильників у кожному ряду.

Нехай зал має розміри А=6м, В=5м, h=3м, стеля обладнується світильниками Л201Б з люмінесцентними лампами ЛБ80.

Рівень робітничої поверхні над полом 0,8 м, при цьому Нр=2,2 м.

Показник приміщення рівний:=40/2,2 (8+5)=1,3986

По довіднику визначаємо значення коефіцієнта n1 (для значень Рс=0,5, Рп=0,3): n1=0,7. Значення коефіцієнта нерівномірного освітлення приймаємо рівним 1,1, а коефіцієнта запасу - 1,5. При загальному типі освітлення значення Emin=400 лк.

Знаючи значення світлового потоку кожної лампи, можемо визначити необхідну кількість світильників:=400· 6· 5 ·1,5· 1,1/5220· 0,7· 2=3(штук)

Загальна потужність освітлювальної установки рівна:

Р=2· 80 · 3=480(Вт)

По результатах проведених розрахунків можна зробити висновок про те, що нам для нормального рівня штучного освітлення необхідно 3 світильників, загальною потужністю 480 Вт.

7.4 Протипожежні заходи

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

В звязку з цим можна виділити ряд заходів для пожежобезпеки:

не палити і не використовувати нагрівальні прилади в приміщеннях з ПЕОМ;

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

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

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

Технологічні обємні підлоги виконуються з негорючих або тяжко горючих матеріалів з межею вогнестійкості не менше 0,5 г. Підпільні простори під обємними підлогами відділяють негорючими перегородками з межею вогнестійкості не менше 0,75 г на ділянки площею не більш 250 м2.

В кожній кімнаті знаходяться вогнегасники. Вони діляться на хімічні, пінні, повітряно-пінні, СО2 - вогнегасники і порошкові.

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

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

Первинні засоби пожежегасіння: ручні вогнегасники в кількості 2 шт.

Засоби гасіння загорання й пожежі, які можуть бути ефективно використані в початковій стадії пожежі: внутрішні пожежні крани, вогнегасники, кошми, пісок.

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

ВИСНОВКИ

З дослідження, аналізу та порівняння CASE-засобів Rational Rose і ERwin можна зробити декілька загальних висновків. Ці засоби можна розділити на 2-ва типи. До першого типа відносяться універсальна система розробки Rational Rose Enterprise, що розраховані на повний цикл розробки системи і охоплює всі області - проектування структури програми, проектування схеми бази даних, проектування моделі поведінки системи. До другого типа можна віднести систему, орієнтовану на роботу лише з певною областю - роботу з даними, ERwin.

З точки зору автоматичної генерації коду можливості засобів першого типа ширші, залежно від підтримуваного типа моделей ним може генеруватися код наступного вигляду:

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

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

Жодна з розглянутих систем не дає можливості генерації коди, що програмно зв'язує класи системи з базою даних, тому ця робота лягає на плечі програміста. Однією з можливих причин є те, що системи першого типа дуже універсальні, а наявність описаного вище зв'язку характерна для певного класу систем. Предметна область системи 2-го типу взагалі обмежена БД.

Основні переваги спільного використання RDL і Rational Rose:

швидке і зручне створення прототипу призначеного для користувача інтерфейсу;

можливість отримати детальну модель інтерфейсних класів, і на її основі виділити принципові архітектурні особливості системи;

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

можливість створення класів, що управляють, в моделях Rational Rose з подальшою генерацією кода в Delphi;

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

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

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

Одним з найістотніших недоліків цієї системи на сьогоднішній день є те, що програма розрахована на старі версії ERwin і Delphi.

СПИСОК ЛІТЕРАТУРИ

1.Бенькович Е., Колесов Ю.Б., Сениченков Ю.Б. Практическое моделирование динамических систем. Учебное пособие. - CПб.:БХВ-Петербург, 2002.

2.Брайен А. Уайт Управление конфигурацией программных средств. Практическое руководство по Rational - M.: ДМК Пресс, 2002.

.Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. - М.,2003.

.Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000.

.Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. 2-е изд., испр Бином. Лаборатория знаний Интуит, 2008.

.Джозеф Шмуллер Освой самостоятельно UML 2 за 24 часа. Практическое руководство - 3-е издание.; Вильямс, 2005.

.Дубейковский Эффективное моделирование с CA ERwin Process Modeler(BPwin; AllFusion Process Modeler) CПб.: БХВ-Петербург, 2004.

.Дубейковский В.И. Эффективное моделирование с CA ERwin Process Modeler (BPwin; AllFusion Process Modeler)2-е изд., испр. и доп. - М.: Диалог-МИФИ, 2009.

.Дубейковский В.И. Практика функционального моделирования - М.: Диалог-МИФИ, 2004.

.Керри Н. Праг, Дженнифер Рирдон, Лоренс С. Казевич, Дайана Рид, П. В. Фэн Интенсивный курс программирования в Access 2003 за выходные. - Вильямс.: Диалектика, 2004.

.Калянов Г.Н. CASЕ-технологии. Консалтинг в автоматизации бизнес процессов. - 3-е изд. - М.: Горячая линия - Телеком, 2002.

.Маклаков С.В. Bpwin и Erwin: CASЕ - средства для разработки информационных систем. - М.: Диалог-МИФИ, 1999.

.Мюллер Роберт Базы данных и UML. Проектирование .: Лори, 2002.

.Оболенски Н. Практический реинжиниринг бизнеса.: ЛОРИ, 2004.

.Пономарев В. Самоучитель Delphi 7. CПб.: БХВ-Петербург, 2005.

.Раскин Ж. Интерфейс: новые направления в проектировании компьютерных систем. -М.: Символ-Плюс, 2004.

.Торрес Роберт Дж Практическое руководство по проектированию и разработке пользовательского интерфейса - Изд.: Вильямс, 2002.

.Трофимов С.А. CASE-технологии: практическая работа в Rational Rose - "Издательство БИНОМ", 2001.

.Фараонов В. Система программирования Delphi. CПб.: БХВ-Петербург, 2005.

.Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASЕ-технологии: Практикум. - М.: Горячая линия - Телеком, 2003.

.Черемных С.В., Семенов И.О., Ручкин В.С. Моделирование и анализ систем. IDEF - технологии: Практикум - M.: Финансы и статистика, 2005.

.#"justify">.#"justify">.#"justify">.#"justify">.#"justify">.http://www.arirom.com/rus/erwin2.htm//CA ERwin Process Modeler(BPwin; AllFusion Process Modeler).

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

Больше работ по теме: