Дослідження та порівняння, аналіз використання CASE систем при проектуванні СУБД 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 - Актори представляють користувачів. Вони допомагають відмежовують систему і надають представлення того, що система повинна зробити. Важливо відзначити, що інтермедії актора з, але не має ніякого контролю над випадками використання. Актор - хто-небудь або що-небудь.

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

Unidirectional Association - Взаємовідношення асоціації представляє однонаправлене семантичне взаємовідношення між двома класами.

Dependency 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 програмний код цих операцій має вигляд:

// Основная форма приложения

Tbaza = class (TForm)

Published

// Операция по открытию формы для регистрации новой заявки

procedure Button4Click (Sender : TObject);

// Операция на открытие формы для регистрации клиента

procedure Button2Click (Sender : TObject);

// Операция выполнения запроса по адресу

procedure Button5Click (Sender : TObject);

// Операция выполняемая при открытии формы

procedure FormShow (Sender : TObject);

// Операция выполнения запроса по ФИО

procedure Button6Click (Sender : TObject);

// Операция по открытию формы для редактирования данных о клиенте

procedure DBGrid2DblClick (Sender : TObject);

// Операция выполнения запроса по MAC

procedure Button7Click (Sender : TObject);

// Операция выполнения запроса по ip

procedure Button8Click (Sender : TObject);

// Операция выполнения запроса по логину

procedure Button9Click (Sender : TObject);

// Операция по открытию формы на выполнения поиска в списке звонков

procedure Button1Click (Sender : TObject);

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

procedure FormClose

(Sender : TObject;

var Action : TCloseAction);

end;

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

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

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

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

Рис. 4.21

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

// Форма поиска в списке звонков клиентов по адресу

Tfind = class (TForm)

Published

// Поиск по таблице согласно запросу

procedure Button2Click (Sender : TObject);

// Закрытие формы

procedure Button1Click (Sender : TObject);

end;

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

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

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

Рис. 4.23

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

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

Tnewklient = class (TForm)

Published

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

procedure Button2Click (Sender : TObject);

// Операция перед открытием формы

procedure FormShow (Sender : TObject);

// Операция перед сохранением данных

procedure Table1BeforePost (DataSet : TDataSet);

// Операция сохранения данных с последующим закрытием формы

procedure Button1Click (Sender : TObject);

end;

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

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

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

Рис. 4.25

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

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

Tpodkl = class (TForm)

Published

// Операция закрытия без сохранения данных

procedure Button2Click (Sender : TObject);

// Операция выполняемая при открытии формы

procedure FormShow (Sender : TObject);

// Операция, выполняемая перед сохранением данных

procedure Table1BeforePost (DataSet : TDataSet);

// Операция добавления новой заявки в базу

procedure Button1Click (Sender : TObject);

end;

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

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

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

Рис. 4.27

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

// Форма для редактирования информации клиентов компании

TKlient = class (TForm)

public

theTbaza : Tbaza;

published

// Операция сохранения данных с закрытием формы

procedure Button1Click (Sender : TObject);

// Операция выполняемая при открытии формы

procedure FormShow (Sender : TObject);

// Операция закрытия формы

procedure Button2Click (Sender : TObject);

end;

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

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

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

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

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

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

5. AllFusion ERwin Data Modeler (ERwin)

5.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);

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

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

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

ERwin / 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 та ін.

ERwin / ERX можна використовувати разом з багатьма популярними засобами розробки додатків: Delphi, PowerBuilder, Visual Basic, Oracle Designer/2000 та ін. Продукт інтегрований також з Rational Rose, CA Paradigm Plus, CA BPwin і CA ModelMart.

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

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

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

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

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

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

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

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

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

генерація бази даних.

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

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

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

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

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

5.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:

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

MetaGen також може здійснювати перенесення змінених об'єктів MetaBASE назад в модель даних. Іншими словами, це повноцінний інструмент two-way-tool. Metamodel - об'єкт, який містить всю інформацію про об'єкти моделі даних - сутність, індекси, атрибути, доменах і зв'язках. Крім того, Metamodel містить розширені атрибути типу масок, міток і т.д., які можуть бути змінені в редакторі MetaBASE Editor. Всі об'єкти моделі даних доступні при створенні програми.

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

Бібліотека візуальних компонентів MetaBASE, що мають прямий доступ до словника даних. Ці VCL-компоненти існують в 16 - розрядний і 32-розрядний варіантах.

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

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

TQueryGS - спадкоємець стандартного компоненту TQuery Delphi. Однак цей компонент безпосередньо пов'язаний з Metamodel. Всі поля, що містяться в TQueryGS, автоматично використовують бізнес-правила, визначені в TMetaBaseGS. Крім стандартних функцій, TqueryGS підтримує розширення функції QBE (Query By Example - запит за зразком).

TTableGS - спадкоємець стандартного компоненту TTable Delphi's, також безпосередньо пов'язаний з Metamodel. Всі поля, що містяться в TTableGS, автоматично підпорядковуються бізнес-правилами, визначеними в TMetaBaseGS. Крім стандартних функцій, TTableGS підтримує розширений пошук та функції індексування.

TDataSourceGS - інтерфейс між компонентами набору даних (TTableGS, TQueryGS) та візуальними компонентами форм. TDataSourceGS - спадкоємець TDataSource Delphi, здатний використовуватися в якості перемикача між звичайним режимом візуального відображення даних, режимом запиту за зразком або режимом пошуку в таблиці і режимом індексації.

TDBGridGS - багатофункціональний компонент, який може відобразити дані у вигляді "інтелектуальних" таблиць (на зразок DBControlGrid). При цьому TDBGridGS відображає поля за допомогою тих інтерфейсних елементів, які визначені в словнику даних Metamodel (наприклад CheckBox, Search Table і т.д.). TDBGridGS може також бути використаний для режиму Query By Example.

TDBFieldGS - центральний компонент для відображення даних. Він відображається самостійно у вигляді того інтерфейсного елемента, який визначений в словнику даних Metamodel (наприклад як check-box або lookup field).

TLabelGS пов'язаний з TDBFieldGS і являє собою позначку, визначену у словнику даних Metamodel.

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

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

TIdxDBFieldGS використовується для визначення значення пошуку в індексованої таблиці.

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

TQbeDBFieldGS схожий на компонент TIdxDBFieldGS. Він використовується для введення значень Query By Example. Компоненти TQbeDBFieldGS можуть бути скомбінувати для виконання запиту до декількох полів.

TQbeControllerGS з усіх значень, записаних в компонентах TQbeDBFieldGS, створює команду SQL і виконує запит. При об'єднанні цього компоненту з TDBGridGS, можна переключатися між режимом візуального відображення даних і режимом Query By Example.

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

TDBEntityComboGS дозволяє вибрати таблицю зі словника даних під час виконання. 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 - Послідовність підключення компонент у стандартному і розглянутому випадку

Стандартний	Робота з БД з використанням MetaBase
Database *)	MetabaseGS *)
-	MetaSourceGS
Table або Query	TableGS або QueryGS
DataSource	DataSourceGS
DBGrid	DBGridGS

*) - Використання необов'язково

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

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

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

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

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

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

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

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

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

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

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

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

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

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

№ п/п	Найменування матеріалу	Витрата, шт.	Ціна, грн./шт.	Сума, грн.
1	Допоміжна література	2	55,00	110
2	Диск DVD-R	1	2,00	2,00
3	Rational Rose Enterprise Edition 2003 або ERwin	1	600	600
Разом: 712,00 грн.

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

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

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

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

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

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

На - норма амортизації.

I квартал 4025*0,15=603,75 грн.

II квартал (4025-603,75)*0,15=513,1875 грн.

III квартал (4025-603,75-513,1875)*0,15=436,209 грн.

IV квартал (4025-603,75-513,1875-436,209)*0,15=370,778 грн.

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

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

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

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

1235*0,20=247 грн.

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

1235+247=1482 грн.

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

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

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

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

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

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

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

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

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

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

№ п/п	Найменування статей витрат	Витрати, грн.
1	Амортизація основних засобів	1923,92
2	Розхідні матеріали	712
3	Основна заробітна плата програміста	1235
4	Додаткова заробітна плата програміста	247
5	Відрахування на соціальне страхування	548,34
6	Накладні витрати	3087,5
Разом витрат: Зк= 7753,76

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

,

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

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

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

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

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

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

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

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

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

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

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

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

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

,

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

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

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

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

Для даного випадку:

ta = 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грн/рік

t0 = 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;

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