Розробка гнучкої системи автоматизації відстеження дзвінків з мобільних телефонів

 

Міністерство освіти і науки України

Криворізький інститут

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

Кафедра технічної кібернетики

ДИПЛОМНА РОБОТА

зі спеціальності

.091402 Гнучкі компютеризовані системи та робототехніка

ПОЯСНЮВАЛЬНА ЗАПИСКА

«Розробка гнучкої системи автоматизації відстеження дзвінків з мобільних телефонів»

Студента групи ГКС-05-з Вишневського Костянтина Івановича

Керівник роботи ст. викл. Супрунова Юлія Анатоліївна

Кривий Ріг

Анотація

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

Розроблена система реалізована в середовищі Delphi 7. Додатковою вимогою є встановлення пакету MS Excel, який необхідний для формування документів із вхідною інформацією.

Аннотация

Целью дипломной работы является разработка гибкой системы отслеживания звонков с мобильных телефонов. Разработанная система прошла апробацию в экспертно-криминалистическом отделе Криворожского городского управления УМВД Украины в Днепропетровской области.

Разработанная система реализована в среде Delphi 7. Дополнительным требованием является установка пакета MS Excel, который необходим для формирования документов с входящей информацией.

summary

purpose of the diploma is development of a flexible system for tracking calls from mobile phones. The developed system has been tested in the expertise and forensic department of Kriviy Rih urban management Ministry of Internal Affairs of Ukraine in the Dnipropetrovsk regiondeveloped system is realized in the environment of Delphi 7. Setting of package of MS Excel, which is required for the formation of documents with the incoming information.

ЗМІСТ

ВСТУП

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

.1 Найменування та галузь використання

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

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

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

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

.6 Джерела розробки

. DELPHI, ЯК ВІЗУАЛЬНЕ СЕРЕДОВИЩЕ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

.1 З чого все починалося

.2 Історія Delphi

.3 Візуальне конструювання форм

.4 Інтегроване середовище розробки

. ОСНОВИ ТЕХНОЛОГІЇ ACTIVEX DATA OBJECTS (ADO)

.1 Огляд технології ADO

.2. Огляд технології OLE DB

.3. Архітектура технології ADO

. ТЕХНОЛОГІЯ DATASNAP

.1 Багатокористувацькі інформаційні системи

.1.1 Склад

.1.2 Типові проблеми

.1.3 Способи вирішення проблем

.2 Введення в технологію DataSnap

.3. Багатоланкові додатки

.3.1 Структура багатоланкового додатку в Delphi

.3.2 Триланковий додаток в Delphi

.3.3 Сервер додатків

.3.4 Клієнтський додаток

.4. Механізм віддаленого доступу до даних DataSnap

.4.1 Компонент TDCOMConnection

.4.2 Компонент TSocketConnection

.4.3 Компонент TWebConnection

.4.4 Провайдери даних

.4.5 Допоміжні компоненти - брокери з'єднань

. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ

.1 Предметна область і задачі, покладені на гнучку систему автоматизації

.2 Архітектура побудови проектованої системи

.3 Схема інформаційних потоків проектованої системи

.4 База даних PhoneInfo

.5. Сервер додатків

.5.1 Логіко - функціональна схема сервера додатків

.5.2 Інтерфейс та програмна реалізація сервера додатків

.6. Клієнтський додаток

.6.1 Логіко - функціональна схема клієнтського додатку

.6.2 Інтерфейс клієнтського додатку

.6.3 Програмна реалізація проектованої системи;6. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ

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

ПРОГРАМНОГО ПРОДУКТУ

.1 Визначення витрат на створення програмного продукту

.2 Витрати, пов'язані з розробкою програми на ПК

.3 Визначення планованої економії від упровадження програмного продукту

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

.1 Аналіз небезпечних й шкідливих виробничих факторів

.2 Заходи щодо нормалізації небезпечних і шкідливих факторів

.3 Пожежна безпека

ВИСНОВКИ

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

ВСТУП

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

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

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

Реалізація даної задачі проводиться у системі програмування Delphi 7 з використанням технологій ADO та DataSnap.являє собою середовище програмування, яка призначена для створення комп'ютерних програм. Для забезпечення більш легкого і швидкого створення діючих програм Delphi включає до складу візуальне середовище програмування IDE (Integrated Development Environment). IDE служить для організації взаємодії з програмістом і містить безліч, створених розробниками, компонентів і, практично готових до використання, заготовок. Також Delphi має розвинені можливості по створенню призначеного для користувача інтерфейсу, широкий набір функцій, методів і властивостей для вирішення прикладних розрахунково-обчислювальних завдань.

Для спрощення доступу та обробки, дані повинні бути систематизовані і впорядковані в таблиці даних. Для управління систематизованими даними необхідна система управління базами даних (СУБД).

У даній дипломній роботі використовується СУБД MS SQL Server2000. Microsoft SQL Server - система управління реляційними базами даних, розроблена корпорацією Microsoft.

Microsoft SQL Server в якості мови запитів використовує версію SQL, що отримала назву Transact-SQL (скорочено T-SQL), яка є реалізацією SQL-92 (стандарт ISO для SQL) з множинними розширеннями. T-SQL дозволяє використовувати додатковий синтаксис для збережених процедур і забезпечує підтримку транзакцій (взаємодія бази даних з керуючим додатком). Microsoft SQL Server також підтримує Open Database Connectivity (ODBC) - інтерфейс взаємодії додатків з СУБД.

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

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

Найменування розробки: гнучка система автоматизації відстеження дзвінків з мобільних телефонів. Розроблена система пройшла апробацію в експертно-криміналістичному відділі Криворізького міського управління УМВС України в Дніпропетровській області.

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

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

Початок робіт: 01.11.09. Закінчення робіт: 25.05.10.

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

Розроблена система реалізована в середовищі Delphi 7. Система повинна функціонувати під керуванням операційної системи Windows ХР. Додатковою вимогою є встановлення пакету MS Excel, який необхідний для формування вхідних документів системи та наявність встановленого сервера баз даних MS SQL Server 2000, на якому буде розгорнута база даних для зберігання необхідної інформації для роботи даної системи.

Вхідною інформацією для розробленої системи є файл формату xls. Вхідною інформацією для розробленої системи є данні про особистість (П.І.Б, адреса реєстрації, адреса проживання, наявність автотранспорту, судимості), а також файл формату xls, в якому міститься дані про здійснені дзвінки з мобільних телефонів.

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

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

-Інформація щодо кількості дзвінків між двома абонентами

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

·Client.exe - виконавчий файл для користувача розробленої системи;

·Server.exe - - виконавчий файл - сервер додатків, який може бути розташований на будь-якому компютері, що підключений до локальної мережі;

·PhoneInfo_Data.MDF - файл, що містить таблиці баз даних, і який може бути розташований на будь-якому компютері, де інстальована СУБД MS SQL Server 2000 і що підключений до локальної мережі;

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

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

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

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

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

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

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

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

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

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

·Наявність СУБД MS SQL Server 2000 і локальної мережі;

·Додаткове програмне забезпечення: встановлення пакету MS Excel, який необхідний для формування вхідних документів системи.

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

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

·загальний опис технології процесу;

·опис інформаційних потоків в експертно-криміналістичному відділі Криворізького міського управління УМВС України в Дніпропетровській області;

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

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

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

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

2. DELPHI, ЯК ВІЗУАЛЬНЕ СЕРЕДОВИЩЕ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

.1 З чого все починалося

З початку ніяких мов програмування не було - для перших ЕОМ програми писалися на "чистій" машинній мові. Це було дуже важким і копітким заняттям. Потім комусь спало на думку, що простіше створити програму, яка сама буде переводити вихідний код, написаний за певними правилами, в машинну мову. Так з'явився перший компілятор - Асемблер. Компілятор - програма, яка переводить вихідний програмний код в машинну мову, і створює повноцінний виконуваний програмний файл. Такі файли можуть мати розширення *. com і *. exe. Розширення *. com зрідка ще зустрічаються в старих програмах, які створювалися під операційну систему MS-DOS. Всі сучасні програми, створені для Windows, мають розширення *. exe.

Також існують інтерпретатори - програми, які не створюють виконуваний програмний файл. Інтерпретатори представляють собою оболонку, в яку потрібно завантажити файл з вихідним текстом програми, потім інтерпретатори порядково переводять код в машинну мову, і виконують його. Найбільш відомим інтерпретатором є класичний Бейсік (Basic). Незручність використання інтерпретаторів та програмного забезпечення, створеного на них, не дозволяють використовувати їх широко. Для розповсюдження програм, створених на інтерпретаторі, необхідно на комп'ютер користувача встановити не тільки написану програму, але і сам інтерпретатор. А користувачу доведеться навчитися користуватися цим інтерпретатором (завантажувати в нього програму, давати команду на виконання), а також навчитися користуватися самою програмою. Проте в деяких випадках інтерпретатори бувають вельми корисні, наприклад, інтерпретатори PHP і Perl, що використовуються в Web-програмуванні, виконуються на стороні сервера, і не доставляють користувачеві проблем.

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

Створення Асемблера сприяло бурхливому розвитку мов програмування. З'явилося безліч мов високого рівня - C, C + +, Pascal і багато інших. Правила створення коду на мовах високого рівня більш наближені до людських мов, тому програми на таких мовах створювалися ще простіше й швидше. Мови програмування стали удосконалюватися не по днях, а по годинах. Перші мови високого рівня були процедурними - в них логіка програми будувалася на використанні функцій і процедур, які можна викликати з будь-якого місця програми.

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

Останньою ланкою еволюції мов програмування стали візуальні середовища розробки програм. Ви просто вибираєте об'єкт - компонент, перетягувати його на форму, і вже в процесі розробки програми бачите те, що повинне вийти в результаті. Приблизно також при редагуванні тексту у редакторі MS Word ви відразу бачите те, що повинне вийти при друку цього тексту на аркуш паперу. Середовище розробки програм взяло на себе майже всю "чорну" роботу по створенню коду. Програмування перестало бути нудним і трудомістким, і перетворилася на творчий процес.

2.2 Історія Delphi

Історія Delphi починається з 60-х років, коли професор Н. Вірт розробив мова високого рівня Pascal. Це була найкращий мова для вивчення програмування, і для створення програм для операційної системи MS-DOS. Потім, в 1983 році, А. Гейлсберг спільно з іншими програмістами, які тільки що організували компанію Borland, розробив компілятор Turbo Pascal, який став наступним кроком в еволюції Delphi. Потім з'явився Object Pascal, який вже використовував об'єктно-орієнтований підхід до програмування. Коли з'явилася перша версія Windows - Windows 3.10, Програмісти Borland створили Delphi 1. Це вже була об'єктно-орієнтоване середовище для візуальної розробки програм, заснована на мові Object Pascal.

З появою Windows 95 з'явилася Delphi 2, потім Delphi 3, 4, 5. Мова програмування Object Pascal, який був стрижнем Delphi, перетерпів такі суттєві зміни, що з появою Delphi 6 компанія Borland, яка вже перетворилася на корпорацію, офіційно оголосила про перейменування Object Pascal в Delphi. Тому мають рацію ті, хто говорить, що Delphi - це візуальне середовище розробки програм. Але також мають рацію і ті, хто стверджує, що Delphi - це один з кращих мов програмування.

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

2.3 Візуальне конструювання форм

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

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

Це прискорення досягається за рахунок наступних властивостей Delphi:

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

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

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

2.4 Інтегроване середовище розробки

Інтегроване середовище розробки (Integrated Development Environment - IDE) - це середовище, в якому є все необхідне для проектування, запуску і тестування додатків і де все націлено на полегшення процесу створення програм. IDE інтегрує в собі редактор кодів, відладчик, інструментальні панелі, редактор зображень, інструментарій баз даних - все, з чим доводиться працювати.

Рис. 2.1 Головні вікна Delphi

.Головне вікно програми. У головному вікні програми знаходиться основне меню, панелі інструментів і палітра компонентів, які дозволяють здійснювати управління як проектом, так і самою програмою.

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

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

Сторінка властивостей (Properties) Інспектори Об'єктів показує властивості того об'єкта, який в даний момент виділено вами.

Сторінка подій (Events) становить другу частину Інспектора Об'єктів. На ній зазначені всі події, на які може реагувати вибраний об'єкт.

4.Форма. Основою майже всіх додатків Delphi є форма. Її можна розуміти як типове вікно Windows. Форма є основою, на якій розміщаються компоненти інтерфейсу користувача та є однією із важливіших складових візуального програмування.

5.Редактор коду. Однією з найбільш важливих частин середовища Delphi є вікно редактора коду. Його вигляд і можливості змінюються від версії до версії. Редактор Коду в Delphi 7 має дві сторінки: Code (код) і Diagram (діаграми). Перша з них містить коди модулів програми та тексти інших файлів, які відкриті в процесі проектування. Друга сторінок дозволяє будувати діаграми, що ілюструють взаємини компонентів у додатку. Ця сторінка є повноцінним програмним редактором. Її можна налаштовувати на різний стиль роботи. У редакторі застосовується виділенням кольором і шрифтом синтаксичних елементів.

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

3. ОСНОВИ ТЕХНОЛОГІЇ ACTIVEX DATA OBJECTS (ADO)

Доступ до даних є найважливішою вимогою при розробці сучасних бізнес-додатків. Технологія ODBC забезпечує доступ до реляційних баз даних і це перший крок на шляху вирішення цієї проблеми. Однак, коли розроблювачі хочуть включити у свої проекти не реляційні джерела даних або працювати в середовищах, подібних Інтернет, вони стикаються з дилемою - або розробляти власні парадигми доступу до даних, або працювати на рівні API, що несумісне з новими середовищами. ActiveX об'єкти доступу до даних (ActiveX Data Object) вирішують цю дилему і забезпечують єдину модель, що працює з усіма джерелами даних у різних середовищах. У такий спосіб ADO забезпечує послідовний, високопродуктивний доступ до даних, із якими можливо створювати клієнтські програми для роботи з БД або бізнес-об'єкти середнього рівня, що використовують додатки, інструментарій, мова або, навіть, Інтернет-переглядач (Internet Explorer). ADO - це єдиний інтерфейс доступу до даних, що необхідний для створення одне- і багаторівневих додатків архітектури клієнт/сервер і Web-орієнтованих інформаційних систем.

3.1 Огляд технології ADO

Технологія ADO була вперше застосована в Microsoft Internet Information Server як інтерфейс доступу до БД. Використання ADO дозволяє мінімізувати мережний трафік у ключових Internet-сценаріях і зменшити кількість проміжних рівнів між клієнтським додатком і джерелом даних. ADO легко використовувати, тому що він (або вони (об'єкти) або вона (технологія)) застосовує звичну систему викликів - інтерфейс Автоматизації OLE, доступний сьогодні в більшості засобів розробки додатків. Через легкість застосування й вивчення популярність ADO буде рости й у підсумку ADO витисне технології RDO і DAO, що у даний час застосовуються дуже широко. Технологія ADO багато в чому подібна до RDO і DAO, наприклад, вона використовує ті ж угоди мови. ADO також підтримує аналогічну семантику і тому може бути легко освоєна розроблювачами ПЗ.є інтерфейсом програмного рівня до OLE DB, новітній і наймогутнішої парадигмі доступу до даних від MS. OLE DB забезпечує високопродуктивний доступ до багатьох джерел даних. ADO і OLE DB разом являють собою основу стратегію універсального доступу до даних (Universal Data Access). OLE DB дає можливість універсального доступу до багатьох даних і представляє розроблювачам можливість зробити це досить легко. Тому що ADO знаходиться на вершині OLE DB, те застосування ADO має всі привілеї універсального доступу до даних, що забезпечує OLE DB.

3.2 Огляд технології OLE DB

DB - це відкрита специфікація, розроблена на основі успіху специфікації ODBC і забезпечує відкритий стандарт доступу до усіх видів даним у системах масштабу підприємства. OLE DB - це ядро технології підтримуючий універсальний доступ до даних. На відміну від технології ODBC, що була створена для доступу до реляційних БД, технологія OLE DB розроблена для реляційних і не реляційних джерел даних, таких як сховища пошти (mail stores), текстів і графіки для Web, служби каталогів (directory services), IMS і VSAM сховищ даних на мейнфреймах.

Компоненти OLE DB складаються з провайдерів даних (data providers), що представляють свої дані, споживачів даних (data consumers), що використовують дані, і сервісних компонентів (service components), що обробляють і транспортують дані (наприклад, процесор запитів і механізм курсорів). OLE DB містить у собі міст із ODBC, щоб дати можливість розроблювачам використовувати ODBC-драйвера реляційних БД, широко розповсюджені в даний час.

3.2.1 OLE DB провайдери

Існує два типи OLE DB додатків: споживачі й провайдери. Споживачами можуть бути будь-які додатки, що використовують OLE DB інтерфейси. Наприклад, Delphi додаток, що використовує OLE DB інтерфейси для зв'язку із сервером БД - це OLE DB споживач. Об'єктна модель ADO, що використовує OLE DB інтерфейси, - це теж OLE DB споживач. Будь-який додаток, що використовує ADO, побічно використовує OLE DB інтерфейси через об'єкти ADO.

OLE DB провайдер здійснює OLE DB інтерфейси, тому, OLE DB провайдер дає можливість споживачам мати доступ до даним однаковим способом через ряд документованих інтерфейсів. У цьому змісті OLE DB провайдер подібний ODBC драйверові, що забезпечує універсальний механізм доступу до реляційних БД, але тільки для не реляційних типів даних. Більш того, OLE DB провайдер убудований у вершину OLE COM інтерфейсів, що додає йому велику гнучкість, а ODBC драйвер убудований у вершину C API специфікації.OLE DB SDK version 1.1 поставляє два OLE DB провайдери: ODBC провайдер і провайдер текстів. Провайдер текстів є прикладом, що демонструє докладну реалізацію OLE DB провайдеру. ODBC провайдер - це OLE DB провайдер для ODBC драйверів. Цей провайдер надає механізм для споживачів, щоб використовувати існуючі ODBC драйвери без необхідності термінової заміни існуючих ODBC драйверів на нові OLE DB провайдери.

3.2.2 ODBC провайдери

ODBC провайдер встановлює відповідність між OLE DB інтерфейсами і ODBC API. З ODBC провайдером OLE DB споживачі можуть зв'язуватися із сервером БД через існуючі ODBC драйвери. Споживач викликає OLE DB інтерфейс через ODBC провайдеру. ODBC провайдер викликає відповідні ODBC API інтерфейси і посилає запити до ODBC драйвера. Метою розробки ODBC провайдеру є здійснення усієї функціональності менеджера ODBC драйвера. Тому тепер немає необхідності в менеджері ODBC драйвера. Однак при використанні ODBC провайдером версії 1.1 менеджер ODBC драйвера усе ще потрібно для підтримки зв'язку з ODBC додатками.

3.3 Архітектура технології ADO

засновано на технології COM (Component Object Model) - компонентній обєктній моделі. Всі об'єкти й інтерфейси ADO є інтерфейсами й об'єктами COM.

Рис. 3.1 Архітектура ADO

3.3.1 Огляд компонентів ADO в середовищі Delphi

Для роботи з ADO на вкладці компонентів ADO є шість компонентів: TADOConnection, TADOCommand, TADODataSet, TADOTable, TADOQuery, TADOStoredProc.

Рис. 3.2 Палітра компонентів ADO

аналогічний компонентові BDE TDatabase і використовується для вказівки бази даних і роботи з транзакціями.

TADOTable - таблиця доступна через ADO.

TADOQuery - запит до бази даних. Це може бути як запит, у результаті якого повертаються дані і бази (наприклад, SELECT), так і запит не повертає даних (наприклад, INSERT).- виклик збереженої процедури. На відміну від BDE і InterBase збережені процедури в ADO можуть повертати набір даних, по цьому компонент даного типу є нащадком від TDataSet і може виступати джерелом даних у компонентах типу TDataSource.і TADODataSet є найбільше загальними компонентами для роботи з ADO, але і найбільш складними в роботі. Обидва компоненти дозволяють виконувати команди мовою провайдера даних (так у ADO називається драйвер бази даних).

Різниця між ними в тім, що команда, що виконується через TADODataSet, повинна повертати набір даних і цей компонент дозволяє працювати з ними засобами Delphi (наприклад, прив'язати компонент типу TDataSource). А компонент TADOCommand дозволяє виконувати команди не повертають набір даних, але не має штатних засобів Delphi для наступного використання повернутого набору даних.

Очевидно, що усі компоненти повинні зв'язуватися з базою даних. Робиться це двома способами або через компонент TADOConnection або прямим указівкою бази даних в інших компонентах. До TADOConnection інші компоненти прив'язуються за допомогою властивості Connection, до бази даних прямо через властивість ConnectionString.

База даних може бути зазначена двома способами через файл лінка до даних (файл у форматі Microsoft Data Link, розширення UDL), або прямим завданням параметрів з'єднання.

Значення властивості всіх ConnectionString цих компонентів можуть бути введені прямо в текстовій формі, але куди простіше викликати редактор властивості натиснувши на кнопку «…» наприкінці отримавши введення. Вікно цієї властивості виглядає так:

Рис. 3.3 Вікно властивості ConnectionString

При виборі «Use data link file» і натисканні на кнопку «Browse...» з'являється стандартний діалог вибору файлу. Цей файл можна створити в будь-якому вікні explorer-а (у цьому вікні відкриття файлу, у самому explorer, на desktop і т.д.) викликавши контекстне меню і вибравши пункт «New/Microsoft Data Link». Потім викличте локальне меню для створеного файлу і виберіть у ньому пункт «Open». Після цього з'явиться property sheet описаний трохи нижче. Ці ж вкладки містить і property sheet, викликуваний через пункт «Property» локального меню UDL файлу, але в ньому ще є вкладки стосовні до самого файлу.

Використання файлів Microsoft Data Link спрощує підтримку додатків, тому що можливо використовувати засобу Windows для настроювання додатка.

При виборі в редакторі властивості «Use connection string» і натисканні на кнопку «Build...» з'являється такою же property sheet, як і при виборі «Open» для Microsoft Data Link файлу.

У цьому вікні вибирається тип бази даних, місце розташування бази і параметри з'єднання.

На першій сторінці вибирається тип бази даних або Provider, у термінах ADO.

Рис. 3.4 Вибір типу бази даних (провайдера)

Бази MS Access доступні як через «Microsoft Jet OLE DB Provider», так і через «Microsoft OLE DB Provider for ODBC».

Наступна сторінка залежить від обраного типу бази, однак для всіх типів є кнопка «Test connection» що дозволяє перевірити правильність і повноту параметрів.

Для «Microsoft Jet OLE DB Provider» вона виглядає так:

Рис. 3.5 Вибір джерела бази даних

«Blank password» придушує діалог введення ідентифікатора і пароля користувача при встановленні з'єднання, якщо поле пароля порожнє.«Allow saving password» зберігає пароль у рядку параметрів з'єднання. Якщо він не відзначений, то введений пароль буде використовуватися тільки при виконанні тестового з'єднання.

Для «Microsoft OLE DB Provider for ODBC» ця сторінка виглядає так:

Рис. 3.6 Вибір джерела бази даних

Радіокнопка «Use data source name» дозволяє ввести аліас ODBC, а через «Use connection string» уводиться як аліаси так і тип ODBC драйвера і параметри з'єднання.

Параметри ідентифікації користувача аналогічні вище описаним.

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

Рис. 3.7 Встановлення додаткових параметрів

На сторінці «All» можна відредагувати всі параметри з попередніх сторінок і параметри залежні від провайдера, але не ввійшли на сторінку «Connection». Редагування здійснюється у виді параметр - значення, причому в текстовій формі, ніяких діалогів немає. Допомоги те ж ні, ці параметри описані тільки в документації на провайдер. Її можна знайти в MSDN Data Access Services/Microsoft Data Access Components (MDAC) SDK/Microsoft Active Data Objects (ADO)/Microsoft ADO Programmer's Reference/Using Providers with ADO.

Рис. 3.8 Сторінка з усіма доступними параметрами відкриття

У компоненті TADOConnection є властивості Provider, DefaultDatabase і Mode які є альтернативним методом завдання частин рядка параметрів з'єднання - провайдеру, бази даних (наприклад, шляхи до бази MS Access) і режиму спільного використання файлів бази даних. Ці значення цих властивостей автоматично включаються в рядок з'єднання, якщо були задані до активізації компонента й автоматично виставляються після з'єднання.

3.3.2 Інтерфейси архітектури ADO

Інтерфейс Connection

Об'єкти цього типу виконують наступні функції:

·зв'язок із сервером

·керування транзакціями

·одержання інформації про помилки, що відбулися, (властивість Errors)

·одержання інформації про схему даних (таблиці, поля і т.д.)

Рис. 3.9 Схема взаємодії в ADO основних COM інтерфейсів

Інтерфейси Recordset і Field

Інтерфейс Recordset (на нижньому рівні ADO це IRowset) є аналогом TDataSet у Delphi.

Підтримує поточне положення і переміщення курсору, закладки (bookmarks), читання, зміна і видалення записів і так далі. Значення полів і їхніх типів доступні за допомогою властивості Fields.

Інтерфейс Field дозволяє одержувати значення полючи, його тип довжину і так далі.

Інтерфейси Command і Parameter

Ці два типи дозволяють працювати з командами джерела даних. Синтаксис команд для кожного з джерел свій.

Інтерфейс Property

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

Бібліотека досить заплутана, багато функцій дубльовані в різних об'єктах. Наприклад, Recordset можна створювати прямо, методом Open, (причому попередньо створювати Connection не обов'язково), можна одержати як результат виконання методу Command.Execute, або після Connection.Execute задавши команду без параметрів.

Особливості інтерфейсу Command та RecordSet

Інтерфейс Command інкапсульований в усі компоненти за винятком TADOConnection. Це зроблено тому, що в ADO немає можливості одержати дані не виконавши команду.

Інтерфейс Recordset інкапсульований у компоненти похідні від TCustomADODataSet. Це компоненти TADODataSet, TADOTable, TADOQuery, TADOStoredProc. Одержувати дані з них можливо штатними засобами Delphi.

Можливе одержання даних і при виконанні компонента TADOCommand. Метод цього компонента Execute повертає тип _Recordset. Після чого його можна, наприклад, зв'язати з компонентом TADODataSet у такий спосіб

ADODataSet1.RecordSet := ADOCommand1.Execute;

Компоненти TADOTable, TADOQuery і TADOStoredProc є окремими випадками команди, відповідно для таблиці, SQL запиту і збереженої процедури.

Тип Connection інкапсулюється в компонент TADOConnection.

Коли ви виконуєте команду попередньо не відкриваючи з'єднання, воно все рівно створюється. Одержати до нього доступ можливо через властивість Recordset. Прив'язати компонент TADOConnection до уже відкритого з'єднання можливо через властивість ConnectionObject.

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

3.3.3 Використання компонента TADOConnection

У цьому прикладі розглядається робота з компонентом TADOConnection, SQL запитами з параметрами і трансакціями.

Створимо додаток з наступних компонентівтипу TADOConnectionі DetailSQL типу TADODataSetі DetailDS типу TDataSourceі DetailGrid типу TDBGrid

Рис. 3.10 Master-detail форма на етапі дизайну

Зв'язуємо MasterGrid, MasterDS, MasterSQL і DetailGrid, DetailDS, DetailSQL аналогічно попередньому прикладові, за винятком того, що замість типу TADOTable використовується тип TADODataSet.

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

Для введення SQL запитів необхідно відредагувати властивість CommandText компонентах MasterSQL і DetailSQL. Після натискання на кнопку "SQLString" з'явиться редактор компонентів, що виглядає в такий спосіб:

Рис. 3.11 Редактор SQL-запита

Кнопка «Add Table to SQL» додає в текст SQL запиту таблицю, обрану в списку «Tables», а «Add Field to SQL» поле таблиці, обране в списку «Fields».

Запит для MasterSQL

select VendorNo, VendorName, Country, City, State, Preferredvendors

Запит у DetailSQL повинний вибирати тільки ті деталі, постачальник яких є поточним у MasterSQL. Для цього установимо властивість DataSource компонента DetailSQL у значення MasterDS.

select PartNo, OnOrder, OnHand, ListPrice, Description, CostpartsVendorNo = :VendorNo

Запит для DetailSQL наступний:у частині where - параметр запиту. Параметри при встановленому DataSource беруться з нього.

Активізуємо MasterSQL і DetailSQL аналогічно попередньому прикладові.

Додаток можна запускати. Цей приклад можна знайти в директорії MasterDetail.

3.3.4 Використання параметрів запиту

Тепер обмежимо вибірку постачальників за значенням полючи State. Для цього додамо до форми наступні компоненти StateEdit типу TEdit c вкладки Standard, QueryButton типу TButton c вкладки Standard

Змінимо запит у MasterSQL на

:StateID - параметр, замість якого при виконанні підставляється значення.

select VendorNo, VendorName, Country, City, State, PreferredvendorsState = :StateID

Додамо так само обработчик події OnClick у QueryButton наступного змісту

procedure TForm1.QueryButtonClick(Sender: TObject);.Active := False;.Active := False;.Parameters.ParamByName('StateID').Value := StateEdit.Text;.Active := True;.Active := True;;

Програма готова. Цей приклад можна знайти в директорії Param.

3.4.5 Синхронізація даних клієнта і сервера

У ADO використовуються три методи синхронізації даних на клієнті і сервері.

Перший - c допомогою методу Resync, що повторно зчитує запису набору. Цей метод використовується при виконанні методу Refresh Delphi.

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

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

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

3.4.6 Робота з транзакціями

У компонентах ADO робота з транзакціями здійснюється через компонент TADOConnection.

Тип транзакції встановлюється у властивості IsolationLevel однієї з наступних констант:

Таблиця 3.1

Список констант

IlUnspecified Сервер буде використовувати кращий, на його думку, тип ізоляції. IlChaos Транзакції з більш високим рівнем ізоляції не можуть змінювати дані змінені, але не підтверджені в поточної транзакції.IlReadUncommittedЧитання даних змінених у не підтверджених транзакцій. Тобто зміни видні відразу після того як інша транзакція передала них на сервер.IlBrowseТе ж саме що і IlReadUncommittedIlReadCommittedЧитання даних змінених підтвердженими транзакціями. Тобто зміна даних буде очевидно після виконання Commit в інший транзакції.IlCursorStabilityТе ж саме що і IlCursorStability.IlRepeatableRead Зміни, зроблені іншими транзакціями не видимі, але при виконанні перезапиту вони транзакція може одержувати новий набір даних.IlIsolated Трансакція не бачить змін даних зроблених іншими транзакціями.IlSerializable Те ж саме що і IlIsolated.

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

Властивість Attributes установлює чи відкривати нову транзакцію автоматично- при підтвердженні транзакції- при скасуванні транзакції

Так само в компонента TADOConnection є три методи для роботи з транзакціями:Починає транзакціюПідтверджує зроблені зміниВідкочує транзакцію.

3.4.7 Атрибути доступу до даних

На відміну від BDE, ADO підтримує більше настроювань роботи даних.

У ADO є поняття набору даних (recordset) і тісно зв'язане з ним поняття курсору (cursor). Що таке курсор у документації на ADO не описане. Однак чому те місце розташування набору даних називається положенням курсору. Я думаю, що це термінологічна плутанина в Microsoft і курсор той же саме що набір даних.

В усіх компонентах що мають набір даних (тобто в TADODataSet, TADOTable, TADOQuery, TADOStoredProc) є властивості CursorLocation, CursorType, LockType і MarshalOptions, що встановлюють параметри обміну із сервером. Усі ці властивості повинні бути встановлені до того, як набір даних відкривається. Якщо ви установите їх пізніше, те ефекту не буде.- визначає, де виконується робота з набором на клієнті (clUseClient) або на сервері (clUseServer). Якщо набір даних розташований на клієнті, то із сервера дані запитуються однократно (або до виконання повторного запиту), надалі уся вибірка даних і позиціювання йде на клієнті. Однак модифікація даних виробляється негайно.- установлює тип курсору. Значення одне з:- бібліотека ADO сама визначає оптимальний тип блокування.- статичний курсор. Статична копія набору записів, що ви можете використовувати, наприклад, для генерації звіту. Додавання, зміни або видалення записів іншими користувачами не видимі.

сtOpenForwardOnly - ідентичний статичному курсорові, за винятком того, що ви можете переходити тільки вперед. Це тип поліпшує ефективність у ситуаціях, коли ви робите тільки один прохід через набір даних.- динамічний курсор. Додавання, зміни і видалення іншими користувачами видимі і можливі всі типи пересування по наборі даних. Закладки (bookmarks) можливі тільки, якщо провайдер даних них підтримує.- курсор набору даних. Аналогічний динамічному курсорові, за винятком того, що ви не побачите записи додані іншими користувачами, а записи вилучені іншими користувачами недоступні з вашого набору даних. Зміни даних іншими користувачами видимі.

Треба помітити, що TDBGrid і інші компоненти, що одночасно працюють з декількома записами, можуть працювати тільки коли закладки підтримуються. Тому для компонентів з якими ви будите зв'язувати такі компоненти повинні використовуватися типи ctKeyset або ctDynamic.- визначає тип блокування записів у наборі даних. Воно з:- бібліотека ADO сама визначає який тип буде використовуватися.- тільки читання, зміна даних неможливо.- песимістичне блокування. Запис блокується відразу після початку редагування і до збереження записів.- оптимістичне блокування. Запис блокується тільки коли зміни зберігаються.- теж саме що і ltOptimistic, але використовується відкладене збереження змін записів. Більш докладно вона розглядається в наступному пункті.- це властивість визначає чи будуть відправлені на сервер ті полючи, що не були змінені. При значенні moMarshalAll будуть, а при moMarshalModifiedOnly не будуть.

4. ТЕХНОЛОГІЯ DATASNAP

delphi дзвінок відстеження автоматизація

Технологія DataSnap призначена для створення за допомогою Delphi і подальшої експлуатації віддалених серверів автоматизації, що надають своїм контролерам доступ до даних серверних СУБД (в даному випадку вони звичайно називаються серверами доступу до даних).

4.1 Багатокористувацькі інформаційні системи

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

4.1.1 Склад

Якщо розглядати багатокористувацьку роботу з корпоративними даними в мережі, засновану на застосуванні будь-якої СУБД (в даному випадку неважливо, мережевий або серверної), можна помітити, що вона підкоряється деяким загальним правилам і складається, як правило, зі стандартного набору програмних компонентів і сервісів.

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

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

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

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

У разі серверних СУБД до цього набору додаються засоби взаємодії користувацького програми та сервера баз даних, що використовують ту ж саму підтримку мережевих протоколів операційними системами. Ці засоби зазвичай включають клієнтську частину серверної СУБД, що містить, як правило, низькорівневий інтерфейс для взаємодії з сервером баз даних. Крім цього, засоби забезпечення доступності даних нерідко містять бібліотеки, які реалізують якийсь універсальний механізм доступу до даних. Ці функції спрощують використання клієнтської частини, якщо СУБД серверна, або реалізують стандартні операції з даними, якщо СУБД не є серверною. У разі користувальницьких додатків, створених за допомогою засобів розробки Borland, це бібліотека Borland Database Engine (BDE) з драйверами SQL Links, бібліотеки dbExpress, а також бібліотеки ADO (ActiveX Data Objects), ODBC-драйвери і OLE DB-провайдери.

4.1.2 Типові проблеми

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

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

Рис. 4.1 Класична інформаційна система

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

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

Наступний фактор безпосередньо пов'язаний з тим, що багато засобів розробки використовують одні й ті ж стандартні бібліотеки доступу до даних (у випадку Windows це ADO, ODBC, іноді BDE). На сьогоднішній день є чимала кількість різних програмних продуктів, що містять будь-які дані (особливо енциклопедій й довідників), при встановленні яких встановлюються і ці бібліотеки (подібні дії дозволені при певних умовах виробниками цих бібліотек). У цьому разі, особливо при застосуванні бібліотек BDE, немає стовідсоткової гарантії, що версія будь-який з подібних бібліотек, що входить в комплект поставки такого роду продукту, виявиться новіше, ніж встановлена в корпоративній інформаційній системі, і що програма установки «чужого» продукту не внесе змін в налаштування, що супроводжують цю бібліотеку, таким чином, що працездатність вашої, вже встановленою, інформаційної системи виявиться порушеною. Подібна ситуація, звичайно, суперечить правилам створення дистрибутивів, але такі випадки час від часу трапляються навіть з непоганими комерційними продуктами, при цьому далеко не у всіх організаціях діють жорсткі обмеження на застосування тих чи інших програмних продуктів на робочих місцях користувачів.

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

4.1.3 Способи вирішення проблем

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

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

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

Технології, що використовуються для реалізації таких сервісів, можуть бути різними, і в загальному випадку набір можливих клієнтських і серверних платформ може бути досить широкий і аж ніяк не обмежуватися різними версіями Windows. Якщо ж мова йде про відносно недорогих рішеннях на основі Windows, для створення таких сервісів зручно використовувати технологію DCOM або різні розширення СОМ (наприклад, технологію Borland DataSnap) і реалізовувати сервіси проміжного шару всередині серверів автоматизації або компонентів Microsoft Component Services.

4.2 Введення в технологію DataSnap

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

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

Рис. 4.2 Інформаційна система з сервером доступу до даних

Що стосується сервера доступу до даних, зазвичай він кінцевим користувачам недоступний, і тому користувальницький інтерфейс в традиційному розумінні (форми, кнопки, поля для введення даних) мати може, але не зобов'язаний. Іншими словами, сервер доступу до даних може бути і звичайним Windows-додатком з формами, та програмою без форм, і консольним додатком, і навіть просто сервісом операційної системи, які пишуть повідомлення для адміністратора системи в файл журналу (log file). Його завдання - обмінюватися даними з тонким клієнтом і звертатися до сервера баз даних з власними запитами (зазвичай ініційованими цим обміном). Тому сервер доступу до даних, з одного боку, повинен надавати клієнтам інтерфейси, що дозволяють отримувати від нього дані, а з іншого боку, бути повноцінним клієнтом сервера баз даних. Іншими словами, що містить його комп'ютер повинен мати як мінімум встановлену клієнтську частину серверної СУБД. Нерідко такий комп'ютер має й інші бібліотеки доступу до даних. Наприклад, у версіях MIDAS 1 і MIDAS 2 (Delphi 3 та Delphi 4) обов'язковою складовою його частиною була бібліотека Borland Database Engine. У версії MIDAS 3 (Delphi 5) і більш пізніх як механізму доступу до даних можуть бути використані й інші бібліотеки, наприклад бібліотеки ADO (або взагалі ніяких бібліотек, крім тих, які підтримують клієнтський API і поставляються з сервером баз даних). І нарешті, з виходом Delphi 6 до різноманітних механізмів доступу до даних, що застосовуються в технології DataSnap, додався універсальний механізм - dbExpress, який отримав подальший розвиток в Delphi 7.сервер доступу до даних представляє собою СОМ-сервер. З технологічної точки зору DataSnap є реалізована в ряді компонентів VCL надбудова над СОМ, що здійснює перетворення набору даних у тип, допустимий для СОМ, передачу таких даних звичайним для СОМ способом і зворотне відновлення набору даних на стороні, що ці дані одержує.

Ліцензійна точка зору на DataSnap практично збігається з технологічної - у разі Delphi версій 4-6 оплаті підлягає можливість передавати набори даних з одного комп'ютера на інший; істотна різниця полягає лише в тому, що в межах одного комп'ютера дані можна передавати, не купуючи ліцензій. Однак поставка розподілених DataSnap-додатків, розроблених за допомогою Delphi 7 Studio, може здійснюватися без додаткового ліцензування.

Для створення DataSnap-серверів використовуються наявні в Delphi компоненти доступу до даних (спадкоємці класу TDataSet) і серверні DataSnap-компоненти, що надають клієнтський програмі дані, отримані за допомогою компонентів доступу до даних, такі як TDataSetProvider (а в ран ¬ них версіях MIDAS - TProvider). Клієнтські DataSnap-додатки, у свою чергу, використовують ряд компонентів, що відповідають за обмін даних з сервером (до них відносяться компоненти TDCOMConnection, TSocketConnection, TWebConnection), і компонент TClientDataSet, що здійснює кешування отриманих даних.

Коли слід вибирати DataSnap як технологія розподілених обчислень? Робити це слід у тому випадку, коли:

·сервери доступу до даних планується експлуатувати під управлінням різних версій Windows без застосування інших платформ;

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

·число клієнтських додатків може виявитися або великим, або непередбачуваним.

4.3 Багатоланкові додатки

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

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

власне сервер бази даних;

сервер додатків (серверна частина програми);

клієнтська частина програми.

Всі вони об'єднані в єдине ціле єдиним механізмом взаємодії (транспортний рівень) і обробки даних (рівень бізнес-логіки).

Компоненти та об'єкти Delphi, що забезпечують розробку багатоланкових додатків, об'єднані загальною назвою DataSnap.

У попередніх версіях Delphi (Delphi 4 і 5) ці компоненти об'єднувалися під назвою MIDAS (Multi-tier Distributed Applications Services-сервіси багатоланкових розподілених додатків).

Палітра компонентів Delphi містить спеціальну сторінку DataSnap.

Рис. 4.3 Палітра компонентів DataSnap

4.3.1 Структура багатоланкового додатку в Delphi

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

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

Багатоланкова архітектура додатків БД покликана виправити перераховані недоліки.

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

Клієнтські додатки звертаються не до сервера БД безпосередньо, а до спеціалізованого ПЗ проміжного шару. Це може бути і одна ланка (найпростіша триланкова модель) і більш складна структура.

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

Сервер БД виконує отримані запити і відправляє результати сервера додатків, який адресує дані клієнтам.

Рис. 4.4 Багатоланкова архітектура додатків БД

Таким чином, багатоланкової додаток БД складається з "тонких" клієнтських додатків, що забезпечують лише передачу, подання, редагування та найпростішу обробку даних; одного або декількох ланок ПЗ проміжного шару (сервер додатків), які можуть функціонувати як на одному комп'ютері, так і беруть участь люди - в локальній мережі; сервера БД (Oralce, Sybase, MS SQL, InterBase і т. д.), що підтримує функціонування бази даних і обробного запити.

Більш проста триланкова модель містить наступні елементи:

·"Тонкі" клієнти;

·сервер додатків;

·сервер БД.

У середовищі розробки Delphi є набір інструментів і компонентів для створення клієнтського ПЗ та ПЗ проміжного шару.

Сервер додатків взаємодіє з сервером БД, використовуючи одну з технологій доступу до даних, реалізованим в Delphi. Це технології ADO, BDE, InterBase Express і dbExpress. Розробник може вибрати найбільш підходящу, виходячи з поставленого завдання і параметрів сервера БД.

Дистанційні клієнтські програми створюються з використанням спеціального набору компонентів, об'єднаних загальною назвою DataSnap. Ці компоненти інкапсулюють стандартні транспорти (DCOM, HTTP, сокети) і забезпечують підключення віддаленого клієнтського додатку з сервером додатки. Також компоненти DataSnap забезпечують доступ клієнта до функцій сервера додатків за рахунок використання інтерфейсу AppServer

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

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

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

Наприклад, при надмірне завантаження сервера, сервер додатків може самостійно обробляти запити користувачів (ставити їх у чергу або скасовувати) без додаткового завантаження сервера БД.

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

Крім того, ви легко зможете використовувати захищені канали передачі даних, наприклад HTTPS.

4.3.2 Триланковий додаток в Delphi

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

Рис. 4.5 Схема триланкового розподіленого додатка

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

Для передачі даних між сервером додатків та клієнтами використовується інтерфейс AppServer, що надається віддаленим модулем даних сервера додатків. Цей інтерфейс використовують компоненти-провайдери TDataSetProvider на стороні сервера і компоненти TClientDataSet на стороні клієнта.

4.3.3 Сервер додатків

Сервер додатків інкапсулює велику частину бізнес-логіки розподіленого програми та забезпечує доступ клієнтів до бази даних.

Основною частиною сервера додатків є віддалений модуль даних.

По-перше, як звичайний модулю даних він є платформою для розміщення невізуальних компонентів доступу до даних і компонентів-провайдерів. Розміщені на ньому компоненти з'єднань, транзакцій і компоненти, інкапсулюючих набори даних, забезпечують триланкового додаток зв'язком з сервером БД. Це можуть бути набори компонентів для технологій ADO, BDE, InterBase Express, dbExpress.

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

До складу Delphi входять віддалені модулі даних. Для їх створення використовуйте сторінки Multitier, WebSnap і WebServices Репозиторія Delphi.Data Module - віддалений модуль даних, інкапсулює сервер Автоматизації. Використовується для організації з'єднань через DCOM, HTTP, сокети.Data Module - віддалений модуль даних, інкапсулює сервер MTS (Microsoft Transaction Server).Server Data Module - віддалений модуль даних, інкапсулює сервер SOAP (Simple Object Access Protocol).Data Module - віддалений модуль даних, що використовує Web-служби і Web-браузер в якості сервера.

Крім віддаленого модуля даних невід'ємною частиною сервера додатків є компоненти-провайдери TDataSetProvider. З кожним компонентом, інкапсулюючих набір даних, призначеним для передачі клієнту, в модулі даних повинен бути пов'язаний компонент-провайдер.

.3.4 Клієнтський додаток

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

У першу чергу віддалене клієнтське додаток повинен забезпечити з'єднання з сервером додатків. Для цього використовуються компоненти з'єднань DataSnap:- використовує DCOM;- використовує сокети Windows;- використовує HTTP.

Компоненти з'єднання DataSnap надають інтерфейс IAppServer, використовуваний компонентами-провайдерами на стороні сервера і компонентами TClientDataSet на стороні клієнта для передачі пакетів даних.

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

Для представлення даних і створення користувальницького інтерфейсу в клієнтському ПО застосовуються стандартні компоненти зі сторінки DataControls палітри компонентів.

4.4 Механізм віддаленого доступу до даних DataSnap

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

Різні типи з'єднань, що дозволяють налаштувати транспорт і почати передачу і прийом даних, інкапсулірованние у кількох компонентах DataSnap. Для створення з'єднання з тим або іншим транспортним протоколом розробнику досить перенести відповідний компонент на форму і правильно налаштувати декілька властивостей. Нижче розглядаються варіанти налаштування транспортних протоколів для компонентів, що використовують DCOM, сокети, TCP / IP, HTTP.

.4.1 Компонент TDCOMConnection

Компонент TDCOMConnection надає транспорт на основі технології Distributed COM і застосовується в основному для організації транспорту в рамках локальної мережі.

Для установки з'єднання DCOM в першу чергу необхідно задати ім'я комп'ютера, на якому функціонує сервер додатків. Для компонента TDCOMConnection це повинен бути зареєстрований сервер автоматизації. Ім'я комп'ютера задається властивістюComputerName: string;

Якщо воно задано правильно, у списку властивостіServerName: string;

в інспектора об'єктів можна вибрати один з доступних серверів. При виборі сервера також автоматично заповнюється властивістьServerGUID: string;

Причому для успішного з'єднання клієнта з сервером додатків обидва властивості повинні бути задані в обов'язковому порядку. Лише ім'я сервера або тільки його GUID не забезпечать правильний доступ до віддаленого об'єкту СОМ.

Відкриття та закриття з'єднання здійснюється властивістюConnected: Boolean;

або методамиOpen / procedure Close;

відповідно.

Для організації передачі даних між клієнтом і сервером компонент TDCOMConnection надає інтерфейс IAppServerAppServer: Variant;

який також може бути отриманий методомGetServer: lAppServer; override;

ВластивістьObjectBroker: TCustomObjectBroker;

дозволяє використовувати екземпляр компонента TsimpleObjectBroker для отримання списку доступних серверів по час виконання (див. нижче).

Методи-обробники компонента TDCOMConnection представлені в таблиці 4.1.

Таблиця 4.1

Методи-обробники компонента TDCOMConnection

ОголошенняОписproperty Af terConnect: TNotifyEvent; Викликається після встановлення з'єднання property AfterDisconnect: TNotifyEvent; Викликається після розриву з'єднання property BeforeConnect: TNotifyEvent; Викликається перед встановленням з'єднання property BeforeDisconnect: TNotifyEvent;Викликається перед розривом з'єднання type TGetUsernameEvent = procedure ( Sender : TOb j ect ; var Username: string) of object; property OnGetUsername : TGetUsernameEvent ;Викликається безпосередньо перед появою діалогу віддаленої авторизації користувача. Для цього властивість LoginPrompt повинно мати значення True. Параметр Username може містити ім'я користувача за замовчуванням, яке з'явиться в діалозі type TLoginEvent = procedure ( Sender: TOb j ect; Username, Password: string) of object; property OnLogin: TLoginEvent;Викликається після відкриття з'єднання, якщо властивість LoginPrompt має значення True. Параметри Username і Password містять ім'я користувача та пароль, введені під час авторизації

4.4.2 Компонент TSocketConnection

Компонент TSocketConnection забезпечує з'єднання клієнта з сервером додатків за рахунок використання сокетів TCP / IP. Для успішного відкриття з'єднання на стороні сервера повинен працювати сокет-сервер.

Для успішного з'єднання властивістьHost: String; повинно містити ім'я комп'ютера сервера.

Додатково, властивістьAddress: String; повинно містити IP-адресу сервера.

Для відкриття з'єднання повинно бути задано обидва чи одне з цих властивостей.

ВластивістьPort: Integer;

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

Після правильного вибору комп'ютера в списку властивостіServerName: string;

в інспекторів об'єктів з'являється перелік доступних серверів Автоматизації. І після вибору сервера властивістьServerGUID: string;

яке містить ім'я комп'ютера GUID зареєстрованого сервера, задається автоматично, хоча його можна задати і вручну.

МетодGetServerList: OleVariant; virtual;

повертає список зареєстрованих серверів Автоматизації. Відкриття та закриття з'єднання здійснюється властивістюConnected: Boolean;

або методамиOpen;Close;

відповідно.

Канал сокета TCP / IP може бути зашифрований. Для цього використовується властивістьInterceptName: string;

містить програмний ідентифікатор об'єкта СОМ, що забезпечує шифрування / дешифрування даних в каналі, і властивістьInterceptGUID: string;

що містить ім'я комп'ютера GUID цього об'єкту.

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

Звісно, на стороні сервера повинен бути зареєстрований об'єкт СОМ, що виконує зворотну операцію. Для цього також використовується сокет-сервер. Рядок Interceptor на сторінці повинна містити ім'я комп'ютера GUID об'єкта-перехоплювача СОМ.GetlnterceptorList: OleVariant; virtual;

повертає список зареєстрованих на сервері об'єктів-перехоплювачів.

Для організації передачі даних між клієнтом і сервером компонент TSocketConnection надає інтерфейс IAppServerAppServer: Variant;

який також може бути отриманий методомGetServer: lAppServer; override;

ВластивістьObjectBroker: TCustomObjectBroker;

дозволяє використовувати екземпляр компонента TSimpieObjectBroker для отримання списку доступних серверів під час виконання (див. нижче).

Методи-обробники подій компонента TSocketConnection повністю збігаються з методами-обробниками компонента TDCOMConnection.

4.4.3 Компонент TWebConnection

Компонент TWebConnection надає клієнтові з'єднання на основі транспорту HTTP. Для роботи компонента на клієнтському комп'ютері повинна бути зареєстрована бібліотека wininet.dll. Звичайно, це не вимагає спеціальних зусиль, тому що це фото вже є в системній папці Windows, якщо на комп'ютері встановлений Internet Explorer.

На комп'ютері сервера повинен бути інстальований Internet Information Server версії не нижче 4.0 або Netscape Enterprise версії не нижче 3.6. Перелічене ПО забезпечує доступ компонента TWebConnection до динамічної бібліотеці HTTPsrvr.dll, яка також повинна знаходитися на сервері.

Наприклад, якщо файл HTTPsrvr.dll розташований в папці Scripts US 4.0 на Web-сервер www.someserver.com, то властивістьURL: string;

повинно містити таке значення:://someserver.com/scripts/httprvr.dll

Якщо URL заданий вірно і сервер налаштований правильно, то в списку властивостіServerName: string;

в інспекторів об'єктів з'являється перелік зареєстрованих серверів додатків. Ім'я одного з них повинно міститися у властивості ServerName.

Після вибору імені сервера у властивостіServerGUID: string;

автоматично з'являється GUID сервера. ВластивостіUserName: string;

таPassword: string;

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

ВластивістьProxy: string;

містить ім'я використовуваного проксі-сервера.

У заголовок повідомлень HTTP можна помістити назву програми. Для цього використовується властивістьAgent: string;

З'єднання відкривається і закривається за допомогою властивостіConnected: Boolean;

Аналогічні операції виконують методиOpen;Close;

Доступ до інтерфейсу IAppServer надає властивістьAppServer: Variant;

або методGetServer: IAppServer; override;

Список доступних з'єднанню серверів додатків повертає методGetServerList: OleVariant; virtual;

ВластивістьObjectBroker: TCustomObjectBroker;

дозволяє використовувати екземпляр компонента TSimpieObjectBroker для отримання списку доступних серверів під час виконання (див. нижче).

Методи-обробники подій компонента TWebConnection повністю збігаються з методами-обробниками компонента TDCOMConnection.

4.4.4 Провайдери даних

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

Всі необхідні операції компонент виконує автоматично. Розробнику необхідно лише розмістити компонент TDataSetProvider і пов'язати його з набором даних сервера додатків. Для цього призначено властивістьDataSet: TDataSet;

Якщо з'єднання у клієнтському додатку налаштований правильно, то в списку вибору властивості ProviderName компонента TClientDataSet в інспекторів об'єктів з'являються імена всіх компонентів-провайдерів сервера додатків. Якщо зв'язати клієнтський набір даних з компонентом-провайдером, а потім відкрити його, в клієнтський набір даних будуть передані записи з набору даних сервера додатків, зазначеного у властивості DataSet компонента-провайдера TDataSetProvider.

Компонент також містить властивості, що допомагають налаштувати процес обміну даними.ResolveToDataSet: Boolean; управляє передачею даних від клієнта серверу БД. Якщо воно має значення True, всі зміни передаються в набір даних сервера додатків, заданий властивістю DataSet. Інакше зміни направляються безпосередньо серверу БД. Якщо сервер додатків не повинен відображати зроблені клієнтом зміни, то властивості ResolveToDataSet можна присвоїти значення False, що прискорить роботу додатка.Constraints: Boolean; управляє передачею обмежень серверного набору даних клієнтського. Якщо властивість має значення True, обмеження передаються.Exported: Boolean; дозволяє використовувати в клієнтському наборі даних інтерфейс IAppServer. Для цього властивість повинно мати значення True.

Параметри компонента-провайдера задаються властивістю= (poFetchBlobsOnDemand, poFetchDetailsOnDemand, poIncFieldProps, poCascadeDeletes, poCascadeUpdates, poReadOnly, poAllowMultiRecordUpdates, poDisablelnserts, poDisableEdits, poDisableDeletes, poNoReset, poAutoRefresh, poPropogateChanges, poAllowCoinmandText, poRetainServerOrder);= set of TProviderOption;

Набір параметрів властивості задається присвоєнням елементам значення True.Options: TProviderOptions;- включає передачу в клієнтський набір даних значень полів типу BLOB. За замовчуванням ця можливість, відключена для прискорення роботи;- включає передачу в клієнтський набір даних підлеглих записів для відносини "один-до-багатьох". За замовчуванням ця можливість відключена для прискорення роботи;- включає передачу в клієнтський набір даних декількох властивостей для об'єктів полів: Alignment, DisplayLabel, DisplayWidth, Visible, DisplayFormat, EditFormat, MaxValue, MinValue, Currency, EditMask, DisplayValues;- включає автоматичне видалення підлеглих записів щодо "один-до-багатьох" на стороні сервера, якщо головна запис була видалена у клієнтському наборі даних;- включає автоматичне оновлення підлеглих записів щодо "один-до-багатьох" на стороні сервера, якщо головна запис була змінена в клієнтському наборі даних;- включає режим "тільки для читання" для набору даних сервера;- включає режим внесення змін відразу в кілька записів одночасно. Інакше всі записи змінюються послідовно, одна за одною;- забороняє клієнту вносити в набір даних сервера нові записи;- забороняє клієнту вносити в набір даних сервера зміни;- забороняє клієнту видаляти записи в наборі даних сервера;- забороняє оновлення набору даних сервера перед передачею записів клієнтові (перед викликом методу AS_GetReccrds інтерфейсу IAppServer);- включає автоматичне оновлення записів клієнтського набору даних. За замовчуванням ця можливість відключена для прискорення роботи;- якщо У методах-обробників BeforeUpdateRecord або AfterUpdateRecord клієнтського набору даних були зроблені додаткові зміни, то після їх запису в наборі даних сервера, зміни знову направляються клієнту для поновлення запису. В увімкненому стані ця можливість дозволяє повністю контролювати збереження змін на сервері;- дозволяє змінювати текст запиту SQL, імена збережених процедур або таблиць в компоненті набору даних на сервері додатків;- включає заборону на зміну порядку сортування записів клієнтом. Якщо цей параметр відключити, можливі помилки відображення набору даних, які проявляються в появі подвійних записів.

Методи-обробники компонента-провайдера даних представлені в таблиці 4.2.

Таблиця 4.2

Методи-обробники подій компонента TDataSetProvider

ОголошенняОписproperty Af terApplyUpdates: TRemoteEvent; Викликається після збереження змін, переданих від клієнта, в наборі даних сервераproperty AfterExecute: TRemoteEvent; Викликається після виконання запиту SQL або збереженої процедури на сервері property AfterGetParams: TRemoteEvent; Викликається після того, як компонент-провайдер сформував набір параметрів набору даних сервера для їх передачі клієнту property AfterGetRecords: TRemoteEvent; Викликається після того, як компонент-провайдер сформував пакет даних для передачі набору даних сервера клієнтові property AfterRowRequest: TRemoteEvent ; Викликається після оновлення поточного запису клієнта компонентом-провайдером property AfterUpdateRecord: TAf terUpdateRecordEvent ; Викликається відразу після поновлення одиничної запису на сервері property Bef oreApplyUpdates: TRemoteEvent ; Викликається перед збереженням змін, переданих від клієнта, в наборі даних сервера property BeforeExecute: TRemoteEvent; Викликається перед виконанням запиту SQL або збереженої процедури на сервері property BeforeGetParams: TRemoteEvent ; Викликається перед тим, як компонент-провайдер сформував набір параметрів набору даних сервера для їх передачі клієнту property BeforeGetRecords: TRemoteEvent ; Викликається перед тим, як компонент-провайдер сформував пакет даних для передачі набору даних сервера клієнтові property BeforeRowRequest: TRemoteEvent ; Викликається перед оновленням поточного запису клієнта компонентом-провайдером property BeforeUpdateRecord: TBeforeUpdateRecordEvent; Викликається безпосередньо перед оновленням одиничної запису на сервері property OnDataRequest: TDataRequestEvent; Викликається під час обробки запиту на отримання даних клієнтом property OnGetData: TProviderDataEvent; Викликається після отримання даних від набору даних сервера, але перед їх відправкою клієнту property OnGetDataSetProperties: TGetDSProps; Викликається при створенні структури параметрів набору даних сервера для їх передачі клієнту property OnGetTableName: TGetTableNameEvent; Викликається при отриманні компонентом-провайдером імені таблиці, що підлягає оновленню property OnUpdateData: TProviderDataEvent ; Викликається при збереженні змін в наборі даних сервера property OnUpdateError: TResolverErrorEvent; Викликається при виникненні помилки збереження змін в наборі даних сервера

.4.5 Допоміжні компоненти - брокери з'єднань

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

Компонент TSimpleObjectBroker

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

Для цього необхідно заповнити список серверів компонента TSimpleobjectBroker і вказати посилання на нього у властивості objectBroker компонента з'єднання (див. вище). І тоді при "перевідкриття" з'єднання ім'я сервера буде запитуватися зі списку компонента TsimpleobjectBroker.

Список серверів задається властивістюServers: TServerCollection;

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

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

Властивості класу TServeritemComputerName: string; Ім'я комп'ютера, на якому функціонує сервер ;DisplayName: String; Містить ім'я сервера для подання в списку серверів;Enabled: Boolean; Керує доступністю запису про сервер для вибору при підключенні. При значенні True компоненти сполук можуть використовувати даний запис списку для підключення ;HasFailed: Boolean; Після невдалої спроби використати даний запис списку при підключенні властивості присвоюється значення True і надалі цей запис не використовується;Port: Integer; Містить номер порту, використовуваного при підключенні до сервера;

Крім списку серверів компонент має лише кілька допоміжних властивостей і методів.GetComputerForGUID (GUID: TGUID): string; override; повертає ім'я комп'ютера, на якому зареєстрований сервер з GUID, заданим параметром.GetComputerForProgID (const ProgID): string; override; повертає ім'я комп'ютера, на якому зареєстрований сервер з ім'ям, заданим параметром Progio.LoadBalanced: Boolean; управляє вибором сервера зі списку. При значенні True запис про сервер вибирається випадковим чином, інакше для з'єднання пропонується перша доступна запис про сервер.

Компонент TLocalConnection

Компонент TLocalConnection використовується локально для отримання доступу до існуючих компонентів-провайдерам.Providers [const ProviderName: string]: TCustomProvider; містить посилання на всі компоненти-провайдери, розміщені з компонентом TLocalConnection на одній формі. Індексація в списку здійснюється на ім'я компонента-провайдера.

Загальне число компонентів-провайдерів в списку повертає властивістьProviderCount: Integer; Крім цього, за допомогою компонента TLocalConnection можна отримати доступ до інтерфейсу IAppServer локально. Для цього використовується властивістьAppServer: IAppServer;

або методGetServer: IAppServer; override;

Компонент TSharedConnection

Якщо інтерфейс IAppServer віддаленого модуля даних має метод, який повертає посилання на аналогічний інтерфейс іншого віддаленого модуля даних, то перший модуль називається головним, а другий - дочірнім. Компонент TSharedConnection використовується для з'єднання клієнтського додатку з дочірнім віддаленим модулем даних сервера додатків.

ВластивістьParentConnection: TDispatchConnection; повинно містити посилання на компонент з'єднання з головним віддаленим модулем даних сервера додатків. Дочірній віддалений модуль даних визначається властивістюChildName: string; яка повинна містити його ім'я. Якщо інтерфейс головного віддаленого модуля даних налаштований правильно, то в списку вибору властивості в інспекторів об'єктів з'являються імена всіх дочірніх віддалених модулів даних.

Інтерфейс IAppServer дочірнього віддаленого модуля даних повертає властивістьAppServer: Variant;

або методGetServer: lAppServer; override;

Методи-обробники компонента TSharedConnection успадковані від класу предка TCustomConnection

Компонент TConnectionBroker

Компонент TConnectionBroker забезпечує централізоване управління з'єднанням клієнтських наборів даних із сервером додатків. Для цього властивість connectionBroker клієнтських наборів даних повинне посилатися на екземпляр компонента TConnectionBroker. Тоді для зміни з'єднання (наприклад, при переході з транспорту HTTP на сокети TCP / IP) немає необхідності змінювати значення властивості RemoteServer всіх компонентів TClientDataSet, а достатньо змінити властивістьConnection: TCustomRemoteServer;

компонента TConnectionBroker.

Доступ до інтерфейсу IAppServer забезпечує властивістьAppServer: Variant;

або методGetServer: lAppServer; override;

5. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ

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

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

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

Оперативної обробки інформації;

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

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

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

5.2 Архітектура побудови проектованої системи

На рисунку 5.1 наведена архітектура побудови проектованої системи автоматизації відстеження дзвінків з мобільних телефонів

Рис. 5.1 Архітектура побудови проектованої системи

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

СУБД, на якій розгорнуто база даних «PhoneInfo» і сервер додатків можуть знаходиться як на одному комп'ютері-сервері, так і на різних, об'єднаних мережею.

У ролі клієнта може виступати будь-який персональних комп'ютер, об'єднаний з сервером додатків мережею. Для використання системи користувач на клієнтському ПК зобов'язаний пройти авторизацію.

5.3 Схема інформаційних потоків проектованої системи

Рис. 5.2 Схема інформаційних потоків в ІС «PhoneInfo»

В інформаційній системі «PhoneInfo» інформаційні потоки діляться на 2 види: це передача даних між сервером БД і сервером додатків та передача даних між клієнтським додатком і сервером додатків. У свою чергу кожен з цих видів ділиться на вхідні і вихідні потоки.

Для клієнта ІС потоками даних буде інформація від операторів мобільного зв'язку, додаткова особиста інформація, а так само представлення і звітна інформація. Для сервера БД потоками служать параметри пошуку, пакети даних з результатами пошуку, а так само службова інформація. Сервер додатків використовує потоки даних як клієнтського додатка, так і сервера БД, будучи при цьому «посередником» в передачі даних.

5.4 База даних PhoneInfo

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

Опис структури бази даних PhoneInfo

База даних PhoneInfo представлена 4 - ма таблицями та 8 - у збереженими процедурами. Перелік таблиць бази даних PhoneInfo з їх описом представлений в таблиці 5.1.

Таблиця 5.1

Перелік таблиць бази даних PhoneInfo

Назва таблиціТип таблиціОпис таблиціTabMain Основна Основна інформація, що отримується від операторів мобільного зв'язку і містить повну інформацію про здійснені дзвінкиTabPersonaОсновнаРозширена інформація про абонента стільникової мережіTabTipДопоміжнаСписок типів дзвінківTabPhonPers ДопоміжнаСписок зв'язків між номерами телефонів та абонентами стільникового зв'язку

Таблиця 5.2

Структура полів таблиці TabMain

Ім'я поляТип поляОписN_p_pIntНомер запису (ключове поле)NomerID_F VarChar (15) Номер телефону першого абонентаIMEI_F VarChar (15) IMEI телефону першого абонентаTipID VarChar (3) Тип дзвінкаData DateTimeДата здійснення дзвінкаVremyaDateTime Час здійснення дзвінкаDlitelnostDateTimeТривалість дзвінкаGPSVarChar(24)Розташування здійснення дзвінкаNomerID_SVarChar(15)Номер телефону другого абонентаIMEI_SVarChar(15)IMEI телефону другого абонента

Таблиця 5.3

Структура полів таблиці TabPersona

Ім'я поляТип поляОписPersonaIDIntПерсональний ідентифікатор абонента (ключове поле)FamiliyaVarChar(20)Прізвище абонентаImyaVarChar(15)Імя абонентаOtchestvoVarChar(15)По-батькові абонентаProzvisheVarChar(24)Прізвисько абонентаDataRoghdeniyaДата народженняAdresRegistrVarChar(150)Адреса реєстраціїAdresProgVarChar(150)Адреса проживанняAvtoVarChar(8000)Наявність автоSudimostiVarChar(20)Наявність судимостейFotoImageФотографія

Таблиця 5.4

Структура полів таблиці TabPhonPers

Ім'я поляТип поляОписNomer_IDIntНомер запису (ключове поле)NomerVarChar(15)Номер телефонуPersonaIDIntПерсональний ідентифікатор абонента

Таблиця 5.5

Структура полів таблиці TabTip

Ім'я поляТип поляОписTipIDVarChar(3)Ідентифікатор типу дзвінка (ключове поле) TipVarChar(10)Тип дзвінка

На рисунку 5.3 представлена схема взаємозв'язку таблиць бази даних PhoneInfo. Зв'язок між таблицями TabMain і TabPhonPers здійснюється динамічно при виконанні запитів.

Рис. 5.3 Схема взаємозв'язку таблиць бази даних PhoneInfo

Таблиця 5.6

Перелік збережених процедур бази даних PhoneInfo

Назва збереженої процедуриОпис збереженої процедуриdeleteUserПроцедура видалення користувача із системи. Вхідні параметри: @ Login - ім'я користувача, що видаляєтьсяIns_Or_Upd_PersonaПроцедура додавання / зміни запису про абонента. Вхідні параметри: @ Fam - прізвище абонента, @ im - ім'я абонента, @ otch - по батькові абонентаIns_Or_Upd_PhonPersПроцедура додавання / зміни зв'язку між телефонними номерами та абонентами. Вхідні параметри: @ Tel_nom varchar (15), @ pers_idInsrtInMainПроцедура додавання інформації в головну таблицю. Вхідні параметри: @ Nomer1 - номер телефону абонента першого, @ imei1 - IMEI першого абонента, @ tip - тип дзвінка, @ Data - дата здійснення дзвінка, @ vremya - час здійснення дзвінка, @ dlitelnost - тривалість дзвінка, @ gps-місцеположення здійснення дзвінка, @ nomer2 - номер телефону абонента другого, @ imei2 - IMEI другого абонентаNewPassПроцедура зміни коду користувача інформаційної системи. Вхідні параметри: @ OldPass - старі пароль, @ newPass - новий пароль, @ login - ім'я користувачаnewUserПроцедура додавання користувача інформаційної системи. Вхідні параметри: @ Login - ім'я користувача, @ pass - пароль для входу в системуSortKolchestvoПроцедура вибірки та сортування даних з кількості дзвінків за вказаним номером. Вхідні параметри: @ Nomer - номер абонента, @ imei - IMEI абонентаUpd_n_InstПроцедура оновлення / вставки даних про абонента і його зв'язки з номером телефону. Вхідні параметри: @ Familiya - прізвище абонента, @ imya - ім'я абонента, @ otchestvo - по батькові, @ nomer - номер телефону

.5 Сервер додатків

.5.1 Логіко - функціональна схема сервера додатків

Логіко - функціональна схема сервера додатків представлена на рисунку 5.4.

Рис. 5.4 Логіко - функціональна схема сервера додатків

5.5.2 Інтерфейс та програмна реалізація сервера додатків

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

Адміністратор системи про стан сервера додатків може впізнати за наявністю зображення в треї (рисунок 5.5a), куди сервер додатків згортається під час запуску. Так само у сервера додатків є контекстне меню для керування (рисунок 5.5b).

a) b)

Рис. 5.5 Інтерфейс сервера додатків

Сервер додатків складається з основної форми, яка в додатку не використовується і служить для його ініціалізації та віддалений модуль даних (Remote Data Module), зображений на рисунку 5.6.

Рис. 5.6 Віддалений модуль даних

Для шифрування / дешифрування пароля входу в систему використовується функціяTFormMain.crypt(str: string): string;TFormMain.crypt(str: string): string;:integer;_res,crypt_txt:string;

// Шифрування / дешифрування тексту:=0;_txt:=str;i<length(crypt_txt) do(i);_res:=crypt_res +chr(ord(crypt_txt[i]) xor ord(key[i mod 8]));;:=crypt_res;;

Для авторизації клієнта сервером БД в сервері додатків використовується функція.Login(const UserName, Password: WideString): WordBool;TRDModule.Login(const UserName, Password: WideString): WordBool;:String;

/ / Новий метод для авторизації, створений в бібліотеці типів S:=Password;Length(s) = 0 then s:='""';.ConnectionString:=(ConnectionString,[S, UserName]);.Connected:=true;:=True;:=false;;;

5.6 Клієнтський додаток

.6.1 Логіко - функціональна схема клієнтського додатку

Логіко - функціональна схема клієнтського додатку представлена на рисунку 5.7

Рис. 5.7 Логіко - функціональна схема клієнтського додатку

5.6.2 Інтерфейс клієнтського додатку

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

У програмі використовується 15 форм, ієрархія яких представлена на рисунку 5.8.

Рис. 5.8 Ієрархія форм у додатку

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

Рис. 5.9 Налаштування підключення

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

Рис. 5.10 Вікно авторизації

Якщо авторизація на сервері БД пройшла успішно, з'являється головне вікно програми. В іншому випадку з'являється повідомлення про помилку.

Рис. 5.11 Попереджувальне вікно

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

Рис. 5.12 Головне вікно програми

Головне меню програми має наступну структуру:

Рис. 5.13 Структура головного меню програми

Робота з системою починається з додавання даних з файлу формату *. xls, отриманого від операторів мобільного зв'язку. Інформація зчитується з файлу, перетворюється в дані для БД і, після обробки сервером додатків, додається у головну таблицю бази даних PhoneInfo. Щоб додати інформації необхідно використовувати пункт меню Додати з файлу головного меню програми, який відкриє вікно додавання з файлу (рисунок 5.14).

Рис. 5.14 Вікно додавання з файлу

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

Рис. 5.15 Вікно параметрів пошуку

У вікні відображення результатів пошуку відображається інформація, що відповідає параметрам пошуку та вибраному режимі відображення: Показати всі записи (рисунок 5.16 a) і Відсортувати за кількістю дзвінків (рисунок 5.16 b).

a)

b)

Рис. 5.16 Вікно виводу результатів пошуку: a) детальний, b) за кількістю дзвінків

При натисканні на фотографію виводиться збільшене зображення. Приклад показаний на рисунку 5.17. Натискання на збільшений варіант зображення прибирає його з екрану.

Рис. 5.17 Збільшене зображення

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

Рис. 5.18 Вікно з особистими даними абонента

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

Рис. 5.19 Контекстне меню

Рис. 5.20 Вікно позиціонування на місцевості

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

Рис. 5.21 Вікно зміни пароля поточного користувача

Якщо поточний користувач має привілеї адміністратора системи, то пункти меню Новий користувач та Видалити користувача стають активними. За допомогою цих пунктів можна додати (рисунок 5.22) або видалити (рисунок 5.23) користувачів системи.

Рис. 5.22 Вікно додавання користувачів у систему

Рис. 5.23 Вікно видалення користувачів із системи

Для зберігання всіх не візуальних компонентів в програмі використовується модуль даних (рисунок 5.24).

Рис. 5.24 Модуль даних для не візуальних компонентів

5.6.3 Програмна реалізація проектованої системи

Клієнтський додаток з самого старту активно використовує системний реєстр. Так перед підключенням до сервера додатків програма звертається до реєстру з метою зчитування налаштувань.

procedure TFormMain.FormShow(Sender: TObject);:=TRegistry.Create;.RootKey:=HKEY_CURRENT_USER;.OpenKey('\Software\PhoneInfo\Admin',true);(not reg.ValueExists('ip')) and (not reg.ValueExists('comp_name'))(Sender);;PasswordDlg.ShowModal = mrCancel then Application.Terminate;not adminRights then// заборона адмінських меню.Enabled:=false;.Enabled:=false;

end;;

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

procedure TPasswordDlg.cxButton1Click(Sender: TObject);

var:string;

/ / Якщо в реєстрі є запис імені хоста і / або IP адреса

// тоді заповнюємо значення Host і / або address для SocketConnection

if reg.ValueExists('comp_name') then:=reg.ReadString('comp_name');.SocketConnection1.Host:=str;;reg.ValueExists('IP') then:=reg.ReadString('IP');.SocketConnection1.Address:=str;

end;

// Якщо вибраний чекбокс, то зберігаємо в реєстрі логін,

// А також в зашифрованому вигляді пароль

if cxCheckBox1.Checked then

begin.WriteString('login',EditLogin.Text);.WriteString('pass',FormMain.crypt(EditPass.Text));

end

// Якщо чекбокс не вибрано логін / пароль не зберігаємо,

// А якщо є збережений, то видаляємо

else

begin.DeleteValue('login');

reg.DeleteValue('pass');;

// Виконуємо підключення до сервера додатків

if DataModule1.SocketConnection1.Connected.SocketConnection1.Connected:=false;.Caption:=FormMain.Caption+' отключен';.SocketConnection1.Connected:=True;.Caption:=FormMain.Caption+' подключен';

except(0, 'Ошибка подключения! Перезапустите приложение и'+#13+

' настройте параметры подключения!', 'Ошибка подключения!', mb_Right);

reg.DeleteValue('ip');.DeleteValue('comp_name');.Terminate;;DataModule1.SocketConnection1.AppServer.LogIn(EditLogin.Text,EditPass.Text).Caption:=FormMain.Caption+'. Вход произведен';else

DataModule1.SocketConnection1.Connected:=false;(0, 'Вы не авторизировались на севере!'+#13

+'Приложение будет закрыто!', 'Ошибка авторизации!', mb_Right);

Application.Terminate;;EditLogin.Text='sa'then:=true;;:=EditLogin.Text;

userPass:=EditPass.Text;;

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

function TFormMain.crypt(str: string): string;:integer;_res,crypt_txt:string;

begin

//Шифрование/дешифрование текста

i:=0;

crypt_txt:=str;i<length(crypt_txt) do(i);_res:=crypt_res +chr(ord(crypt_txt[i]) xor ord(key[i mod 8]));

end;:=crypt_res;;

Так як у реалізованій програмі використовується технологія DataSnap, то прямі запити до бази даних не застосовуються. Замість цього для формування запиту у відповідному компоненті ClientDataSet у властивість Params заносяться параметри запиту. Результати запиту повертаються до відповідного компонент DataSource.

Для виконання основної вибірки виконується процедура:

procedure TFormFind.BtnFindClick(Sender: TObject);.PopupMenu1.Items[0].Visible:=true;DataModule1.ClientDataSet1 do

//Получение параметров для поиска[0].AsString:='%'+trim(EditPhone.Text)+'%';[1].AsString:='%'+trim(EditPhone.Text)+'%';[2].AsString:='%'+trim(EditIMEI.Text)+'%';[3].AsString:='%'+trim(EditIMEI.Text)+'%';EditDateStart.Text = ''[4].AsDateTime:=StrToDateTime('01.01.2001');[4].AsDateTime:=EditDateStart.Date;;((EditDateEnd.Text='')or(StrToDate(EditDateEnd.Text)<StrToDate(EditDateStart.Text)))Params[5].AsDateTime :=NowParams[5].AsDateTime:=EditDateEnd.Date;;.ClientDataSet1.Close;.ClientDataSet8.Close;.ClientDataSet1.Active:=True;.DBGrid1.DataSource:=DataModule1.ds_MainSelect;

end;

procedure TFormFind.EditIMEIKeyPress(Sender: TObject; var Key: Char);Key IN ['0'..'9'] then.Properties.EditMask:='!000000000000000;0; 'Key:=#0;;TFormFind.EditPhoneKeyPress(Sender: TObject; var Key: Char);Key in ['0'..'9'] then.Properties.EditMask:='!+99\-999\-999\-99\-99;0'Key:=#0;

end;

Для вибірки з кількості дзвінків використовується процедура:

procedure TFormFind.cxButton1Click(Sender: TObject);.PopupMenu1.Items[0].Visible:=false;DataModule1.ClientDataSet8 do

// Отримання параметрів для пошуку[0].AsString:=trim(EditPhone.Text);[1].AsString:='%'+trim(EditIMEI.Text)+'%';EditDateStart.Text = ''[2].AsDateTime:=StrToDateTime('01.01.2001');

end

else[2].AsDateTime:=EditDateStart.Date;;((EditDateEnd.Text='')or(StrToDate(EditDateEnd.Text)<StrToDate(EditDateStart.Text)))Params[3].AsDateTime :=NowParams[3].AsDateTime:=EditDateEnd.Date;;.ClientDataSet1.Close;.ClientDataSet8.Close;.ClientDataSet8.Active:=True;.DBGrid1.DataSource:=DataModule1.ds_ViewSort;

end;

При пересуванні по рядках таблиці виконується запит на вибірку даних по людині

procedure TDataModule1.ClientDataSet1AfterScroll(DataSet: TDataSet);.Params[0].AsString:=ClientDataSet1.Fields[0].AsString;.Params[0].AsString:=ClientDataSet1.Fields[6].AsString;.Active:=false;.Active:=true;.Active:=false;.Active:=true;

end;

Для відображення оновлення даних про особу абонента в нижній частині вікна результатів пошуку після виконання попередньої процедури виконуються 2 наступні процедури (оновлення даних у двох панелях):

procedure TFormFindRes.cxButton1Click(Sender: TObject);FormPeople do:=1;_nomer.DataBinding.DataSource:=DataModule1.ds_MainSelect;_nomer.DataBinding.DataField:='NomerID_F';_Familiya.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_Imya.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_Otchestvo.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_Prozvishe.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_DataRoghdeniya.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_AdresRegistr.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_AdresProg.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_Avto.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_sudimosti.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;_Foto.DataBinding.DataSource:=DataModule1.ds_Ppl_1_Select;;;;TFormFindRes.cxButton2Click(Sender: TObject);FormPeople do:=2;_nomer.DataBinding.DataSource:=DataModule1.ds_MainSelect;_nomer.DataBinding.DataField:='NomerID_S';_Familiya.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_Imya.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_Otchestvo.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_Prozvishe.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_DataRoghdeniya.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_AdresRegistr.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_AdresProg.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_Avto.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_sudimosti.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;_Foto.DataBinding.DataSource:=DataModule1.ds_Ppl_2_Select;

ShowModal;;;

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

procedure TFormPeople.BitBtn1Click(Sender: TObject);((textedit_Familiya.Text = '') or (textedit_Imya.Text='')(textedit_Otchestvo.Text='')) then

Begin(Application.Handle,

'Не введены обязательные параметры!','Внимание!',0);

EndClDtStID of

: if DataModule1.ClientDataSet2.Modified then.ClientDataSet2.ApplyUpdates(-1);;

: if DataModule1.ClientDataSet3.Modified then.ClientDataSet3.ApplyUpdates(-1);;;DataModule1.ClientDataSet4 do[0].AsString:=textedit_Familiya.Text;[1].AsString:=textedit_Imya.Text;[2].AsString:=textedit_Otchestvo.Text;[3].AsString:=textedit_nomer.Text;:=True;:=False;;

End;;

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

procedure TFormFindRes.btMapClick(Sender: TObject);inetString:string;:DWORD;:boolean;:=_CONNECTION_MODEM or_CONNECTION_LAN or_CONNECTION_PROXY;:=InternetGetConnectedState(@dwConnectionTypes,0);result then

//#"justify">+DataModule1.ClientDataSet1.Fields[8].AsString+

'8&z=18&t=h&hl=ua';.WebBrowser1.Navigate(inetString);.ShowModal;

end('Проверьте подключение к интернету!');

end;

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

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

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

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

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

В розробці користуємося мовою програмування Borland Delphi v.7.0.

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

Мінімальні апаратні вимоги:

для роботи додатків необхідно:

·ПК типу IBM PC або сумісний з ним, продуктивністю не менше 2 ГГц;

·Оперативна пам'ять не менше 512 Мбайт;

·Монітор із SVGA адаптером;

·НЖМД не менше 4,3 Гбайт;

·Компакт-дисковий носій (CD);

·Монітор, клавіатура, маніпулятор типу "миша".

6.1 Визначення витрат на створення програмного продукту

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

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

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

витрати на оплату машинного часу, затраченого при розробці програми.

Витрати на оплату праці розроблювачів програми

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

, де

Зрозр - середньо-годинна оплата програміста,розр. - трудомісткість створення програми, що містить у собі витрати праці на наступні дії:

·Знайомство з проблемою й визначення шляхів її вирішення;

·Розробка структури інформаційної системи;

·Розробка моделі бази даних «PhoneInfo»;

·Розробка програмного продукту «PhoneInfo»;

·Налагодження програми на ПК;

·Підготовка документації по задачі.

Витрачений час на вирішення поставленої задачі розрахуємо за календарним планом виконання робіт (табл. 6.1)

Таблиця 6.1

Календарний план виконання робіт по створенню програми

Найменування етапів виконання робітКількість затрачених годинЗнайомство з проблемою і визначення шляхів її вирішення35Розробка структури інформаційної системи 50Розробка моделі бази даних25Розробка програмного продукту75Налагодження програми на ПК3Підготовка документації по програмному забезпеченню25

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

tрозр.= tпробл.+ tстр..+ tмод.+ tпрогр.+ tнал.+ ttдок , де

tпробл. - час на знайомство з проблемою й визначення шляхів її вирішення,стр. - час на розробку структури інформаційної системи,мод. - час на розробку моделі бази даних «Деканат»;прогр... - час на розробку програмного продукту «Деканат»,нал..- час на налагодження програми на ПК,док...- час на підготовку документації по задачі,розр. = 35+50+25+75+3+25 = 213 [люд./годин]

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

Таким чином, річний фонд грошового забезпечення програміста складає 1500,00*12+ 450,00*12+ 500,00 = 28 400,00 гривень.

Нарахування на ФОП:

1.Безробіття 1,3%

2.Пенсійний фонд 33,2%

.Соцзабезпечення тимчасової непрацездатності 1,6%

.Соцзабезпечення від нещасних випадків 1,16%

Підсумок: 37,26%

Далі визначимо число робочих годин у році, за формулою:

n(p) = (N - N(п) - N(в)) * 8, де

N - загальне число днів у році,(п) - число святкових днів у році,(в) - число вихідних днів у році,

Число святкових днів у році - 10, вихідних - 104. Отже, число робочих годин у році дорівнює:(p) = ( 365 - 10 - 104) * 8 = 2008 [години]

Середньо годинна оплата програміста визначається співвідношенням:

Срозр. = ФЗПсн / n(p), де

ФЗПсн - річний фонд грошового забезпечення,

Срозр. = 28 400 / 2008 = 14,14 [гривень]

Отже, витрати на оплату праці ( Зрозр. ) розроблювачів програми складають:

Зрозр. = 213 * 14,14 = 3011,82 [гривень]

Зрозр.нарах.= 3011,82+ 3011,82* 37,26% = 4134,02 [гривень]

6.2 Витрати, пов'язані з розробкою програми на ПК

Витрати, пов'язані з розробкою програми на ПК, визначаються, як добуток години використання ПК для розробки програми на собівартість машинного часу обчислювальної техніки. Собівартість ( СПК ) однієї години роботи ПК дорівнює відношенню річних поточних витрат на експлуатацію ПК ( ЗгПК ) до річного фонду годин ( ТгПК ) корисної роботи ПК.

СПК = ЗгПК / ТгПК

Розрахунок річного фонду тривалості робочого часу ПК (у годинах)

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

ТгПК = n(p) - (6 * 8 + 5 * 12),

ТгПК = 2008 - (6 * 8 + 5 * 12) = 1900 [години]

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

ЗгПК = ЗгАМ + ЗгЭЛ + ЗгРЕМ + ЗгМАТ + ЗгДР, де

ЗгАМ - річні відрахування на амортизацію,

ЗгЭЛ - річні витрати на електроенергію для ПК,

ЗгРЕМ - річні витрати на ремонт ПК,

ЗгМАТ - річні витрати на додаткові комплектуючі ПК,

ЗгДР - інші витрати.

Амортизаційні відрахування

Основні фонди підлягають розподілу на групи. У нашому випадку, компютер, група 4 (ЕОМ, інші машини призначені для автоматичної обробки інформації, а також повязані з ними засоби зчитування або друку інформації та інші). Амортизація основних фондів групи 4 відбувається до досягнення балансової вартості групи нульового значення. Для основних фондів групи 4 - амортизація відбувається з кварталу, наступного за кварталом придбання матеріальних цінностей.

Заключний етап в нарахуванні податкової амортизації - це щоквартальний розрахунок суми амортизації. Норми амортизації встановлені у відсотках до балансової вартості 4 групи основних фондів і складають 60% на рік, так як нарахування амортизації відбувається щоквартально, то норма амортизаційних відрахувань у квартал складає (60% / 4 ) = 15%.

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

ЗгАМ = ЦПК * НА, де

ЦПК - балансова вартість ПК,

НА - норма амортизаційних відрахувань, що дорівнює 15% (у квартал).

Балансова вартість ПК :

Цпк = Цр * ( 1+ Кун ), де

Цр - ринкова вартість ПК,

Кун - коефіцієнт, що враховує витрати на установку й налагодження, рівний 12%.

Ринковою вартістю ПК, будемо вважати ту вартість до якої входить повна комплектація ПК, вона становитиме 5000 грн.

Цпк = 5000 * ( 1 + 0.12 ) = 5600 [гривень],

кв. = 5600 * 0,15 = 840 [гривень],

кв. = (5600 - 840) * 0.15 = 714 [гривень],

кв. = (5600 - 840 - 714) * 0.15 = 606,90 [гривень],

кв. = (5600 - 840 - 714 - 606,90) * 0,15 = 515,87 [гривень],

ЗгАМ = 840 + 714 + 606,90 + 515,87 = 2676,77 [гривень]

Витрати на електроенергію, споживану ПК

Витрати на електроенергію, затрачену ПК, визначаються за формулою:

ЗгЕЛ = РчПК * ТгПК * ЦЕЛ * А, дечПК - потужність ПК ( PчПК = 0.3 [кВт.]),

ТгПК - річний фонд корисного часу роботи машини,

ЦЕЛ - вартість 1 квт/годину електроенергії (ЦЕЛ = 0,24 [грн.]),

А - коефіцієнт інтенсивного використання ПК ( 0.9 - 1 ).

Таким чином, кількість витрат на електроенергію, споживану ПК, складає:

ЗгЕЛ = 0.3 * 1900 * 0,24 * 1.0 = 136,80 [гривень]

Витрати на поточний і профілактичний ремонт

Витрати на поточний і профілактичний ремонт приймаються рівними 6% від вартості ПК:

ЗгРЕМ = ЦПК * 0.06,

ЗгРЕМ = 5600* 0.06 = 336 [гривень]

Витрати на матеріали

Витрати на матеріали - витрати, необхідні для забезпечення експлуатації ПК, приймаються рівними 2% від вартості ПК.

ЗгМАТ = ЦПК * 2%,

ЗгМАТ = 5600 * 0.02 = 112 [гривень]

Непрямі витрати.

Непрямі витрати, пов'язані з експлуатацією ПК, приймаються рівними 5 - 10% вартості ПК.

ЗгДР = ЦПК * 5%,

ЗгДР = 5600 * 0.05 = 280 [гривень]

Повні витрати на експлуатацію ПК

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

ЗгПК= 2676,77 + 136,80 + 336 + 112 + 280 = 3541,57 [гривень]

Собівартість однієї години роботи машини ( CПК ) складає:

СПК = 3541,57 / 1900 =1,86 [гривень]

Витрати машинного часу.

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

·написання програми за готовою схемою алгоритму;

·налагодження програми на ПК;

·підготовки документації по задачі.

Таким чином, витрати машинного часу склали (tмаш):

tмаш = tпрог.+ tотл. + tдок,маш = 75 + 3 + 25 = 103 [чол./часів]

Витрати на оплату машинного часу можна розрахувати за формулою:

Змаш = tмаш * СПК,

Змаш = 103* 1,86 = 191,58 [гривень]

Загальні витрати на створення програмного комплексу

Зразом = З розр. + З маш,

Зразом = 2882,70 + 191,58 = 3074,28 [гривень]

6.3 Визначення планованої економії від упровадження програмного продукту

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

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

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

Таблиця 6.2

Річний фонд заробітної плати двох штатних одиниць

З/П до автоматизаціїКількість чоловікМісячна З/П, грн.Премія 40% та коєф. 15%, грн.Всього З/П за рік, грн.Працівник 111300715(1300*12+715*12) = 24180Працівник 211300715(1300*12+715*12) = 24180Відрахування на ФОП224180 + 24180 = 4836037,16%17970,58ВСЬОГО: 66330,58

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

Е = Зразом_прац - Зразом - ЗгПК, де

Зразом_прац - річний фонд заробітної плати 1-го працівника,

Зразом - загальні витрати на створення програмного комплексу,

ЗгПК - повні витрати на експлуатацію ПК протягом року.

Е = 33189,47 - 3074,28 -3541,57 = 26573,62 [гривень]

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

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

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

Законодавча база охорони праці України має ряд законів, основним з яких є Закон України «Про охорону праці» і Кодекс законів про працю (КЗпП). До законодавчої бази також належать Закони України: «Про загальнообов'язкове страхування від нещасних випадків на виробництві й професійних захворювань, які викликали втрату працездатності», «Про охорону здоров'я», «Про пожежну безпеку», «Про забезпечення санітарного й епідеміологічного добробуту населення», «Про використання ядерної енергії й радіаційну безпеку», «Про дорожній рух», «Про обов'язкове страхування у зв'язку з тимчасовою втратою працездатності й витратами, обумовленими народженням й похоронами». Їх доповнюють державні галузеві й міжгалузеві нормативні акти - це стандарти, інструкції, правила, норми, положення, статути й інші документи які мають статус правових норм, обов'язкових для виконання всіма установами й працівниками України.

Найбільш повним нормативним документом по забезпеченню охорони праці користувачів ПК є «Державні санітарні правила й норми роботи з візуальними дисплейними терміналами (ВДТ) електронно-обчислювальних машин» ДСанПіН 3.3.2.007-98.

В Україні затверджене положення про створення державних нормативних актів по охороні праці ДНАОП. Це норми, інструкції, вказівки й інші види державних нормативних актів по охороні праці обов'язкові по виконанню й керівництво підприємствами й установами, на які поширюється сфера дії цих актів.

7.1 Аналіз небезпечних й шкідливих виробничих факторів

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

До основних параметрів метеорологічних умов робочої зони приміщення відносять температуру, відносну вологість, швидкість переміщення повітря й барометричний тиск (таблиця 7.1). Метеоумови в робочій зоні приміщення визначаються ДСТУ 12.0.005.88 «Загальні санітарно-гігієнічні вимоги до повітря робочої зони».

Таблиця 7.1

Оптимальні норми температури, відносної вологості і швидкості руху повітря

Період рокуКатегорія роботиТемпература, °СВідносна вологість повітря, %Швидкість руху повітря, не більше м/сХолодний і перехіднийлегка21-2440-600,1Теплийлегка22-2540-600,2

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

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

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

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

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

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

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

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

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

Крім освітленості, великий вплив на діяльність оператора роблять кольори фарбування приміщення й спектральних характеристик використовуваного світла. Рекомендується, щоб стеля відбивала 80-90%, стіни - 50-60%, підлога - 15-30% падаючого на них світла. Тому приміщення оператора пофарбоване в сині кольори, що відноситься до кольорів "холодного" тону (синій, зелений, фіолетовий), що створює враження спокою й викликає в людини відчуття прохолоді.

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

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

1)знижується гострота зору, слуху;

2)підвищується кров'яний тиск;

)знижується увага.

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

При використанні дисплеїв випромінюються електромагнітні хвилі які негативно впливають на здоров'я людини. Спектр випромінювання комп'ютерного дисплея містить у собі рентгенівські, ультрафіолетову й інфрачервону області, а також широкий діапазон електромагнітних хвиль інших частот. У ряді експериментів було виявлено, що електромагнітні поля із частотою 50 Гц (що виникають навколо ліній електропередач, відеодисплеїв і навіть внутрішньої електропроводки) можуть ініціювати біологічні зрушення (аж до порушення синтезу ДНК) у клітках тварин. На відміну від рентгенівських променів електромагнітні хвилі мають незвичайну властивість: небезпека їхнього впливу зовсім не обов'язково зменшується при зниженні інтенсивності опромінення, певні електромагнітні поля діють на клітки лише при малих інтенсивностях випромінювання або на конкретних частотах - в вікнах прозорості. Джерело високої напруги комп'ютера - строковий трансформатор - міститься в задній або бічній частині термінала, рівень випромінювання з боку задньої панелі дисплея вище, причому стінки корпуса не екранують випромінювання. Тому користувач повинен перебувати не ближче чим на 1,2 м від задніх або бічних поверхонь сусідніх терміналів.

За результатами виміру електромагнітних випромінювань встановлено, що максимальна напруженість електромагнітного поля на кожусі відеотермінала становить 3.6 В/м, однак у місці знаходження оператора її величина відповідає фоновому рівню (0.2-0.5 В/м); градієнт електростатичного поля на відстані 0.5м менш 300 В/см є в межах припустимого.

На відстані 5 см від екрана інтенсивність електромагнітного випромінювання становить 28-64В/м залежно від типу приладу. Ці значення знижуються до 0.3-2.4 В/м на відстані 30 см від екрана (мінімальна відстань очей оператора до площини екрана).

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

Все устаткування підєднане до мережі змінного струму (220 В, 50 Гц). Кабельне розведення виконане відповідно до вимог ДНАОП 0.00-1.31-99 і Правилами побудови й експлуатації електроустановок. Підведення електроживлення до робочих місць виконано системою із закритою проводкою, що забезпечує додаткову безпеку працівників від поразки електричним струмом і підвищує пожежобезпечність. Все устаткування, використовуване в лабораторії при дотриманні елементарних вимог електробезпечності виключає можливість поразки електричним струмом. Для виключення можливого короткого замикання й поразки електрострумом у лабораторії застосовується устаткування й розетки із захисним заземленням. Для забезпечення безпеки при перевантаженнях живильної мережі на уведенні електропроводки в приміщення встановлений розподільний щит з автоматичними вимикачами С-16, які автоматично розмикають ланцюг при перевищенні силою струму значення 16 А.

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

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

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

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

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

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

Для запобігання поразки персоналу електричним струмом всі розетки й вимикачі оснащені написами «Напруга 220 V». Передбачено щоквартальні профілактичні огляди стану електроустаткування й проводки, а також 2 рази в рік виміри опору ґрунту в місцях монтажу заземлюючого пристрою.

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

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

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

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

(7.1)

де U - фазна напруга мережі, кВ;- довжина кабельних ліній, км;- довжина повітряних ліній, електрично об'єднаних в одну мережу, км.

(7.2)

Звідси опір заземлюючого пристрою дорівнює:

(7.3)

Тому приймаємо згідно ППЕ R0=4 Ом

Для виконання робочого заземлення приймаємо металеві труби довжиною l=1м і діаметром d=50мм, з'єднаних металевою смугою 48мм2.

Опір відстані струму визначаємо по наступній емпіричній формулі:

, (7.4)

де r =1×104 Ом×см - питомий опір глинистого ґрунту;- довжина провідника;- діаметр провідника.

, (7.5)

З огляду на сезонні коливання питомого опору ґрунту, приймаємо
коефіцієнт 1.2 тоді:

(7.6)

Необхідне число трубних стрижнів визначаємо зі співвідношення:

, (7.7)

де n-число трубних стрижнів;

hЕ=0,88 - коефіцієнт використання труб, що враховує їхню екрануючу взаємодію, при розташуванні між ними до 6 м, тоді:

(7.8)

Довжина смуги, що поєднує труби:

(7.9)

Опір розтікання струму смуги буде:

, (7.10)

де h=1,2 - глибина на якій перебуває смуга:=80 - ширина смуги.

З урахуванням коливання питомого опору ґрунту:

(7.11)

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

(7.12)

де hэл=0,91 - коефіцієнт використання сполучної смуги.

(7.13)

Опір розтікання захисного заземлення повинен бути не більше 4 Ом. У такий спосіб розрахований контур заземлення забезпечить надійний захист від поразки електричним струмом.

7.3 Пожежна безпека

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

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

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

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

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

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

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

Автоматична установка й установка з механічним включенням відрізняється тільки засобами відкриття запірного крана. В автоматичних установках використаються різні датчики виявлення пожежі (по диму, тепловому й світловому випромінюванню), а в механічних спеціальні тросові системи з легкоплавкими замками. У цей час освоєні модульні порошкові установки ОПА-50, ОПА-100, УАПП.

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

У приміщенні застосовуються сповіщувачі типу ИП 104, які спрацьовують при перевищенні температури в приміщенні +600С. І сповіщувачі типу ИП 212, які спрацьовують при скупченні диму в приміщенні. На стінах всіх приміщеннях будинку не далі 50 м. друг від друга встановлені ручні пожежні сповіщувачі про загоряння, що передають сигнал на пульт пожежної охорони. На всіх поверхах перебувають пожежні щити з необхідним інвентарем.

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

ВИСНОВКИ

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

·покращити ефективність роботи;

·підвищити оперативність та точність обробки інформації;

·зменшити обсяг паперових носіїв.

Областю застосування розробленої системи є установи, які займаються правоохоронною діяльність.

В ході роботи були вирішені наступні задачи:

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

-розробка сервера додатків;

розробка клієнтського додатку.

Для реалізації задачі по проектуванню БД були використані можливості MSSQL Server 2000. Завдяки використанню саме цієї СУБД, при виконанні роботи вдалося спростити розробку БД та підвищити безпеку використання розробки.

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

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

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

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

1.Бобровский С. Delphi 5 - CПб.: Питер, 2000.

2.Гаевский А. Разработка программных приложений на Delphi 6 - М.: Киев, 2000.

.Галисеев, Г.В. Программирование в среде Delphi 8 for .NET. Самоучитель. :- М.: Издательский дом "Вильямс", 2004.

.Глинский Я.Н., Анохин В.Е., Ряжская В.А. Turbo Pascal 7.0 и Delphi. Учебное пособие. СПб.: ДиаСофтЮП, 2003.

.Гофман В., Хомоненко А. Delphi 6. CПб.: БХВ-Петербург, 2004.

.Грибачев К. Г. Delphi и Model Driven Architecture. Разработка приложений баз данных. - СПб.. Питер, 2004.

.Грибачев К. Тонкие базы данных и инструменты для их разработки в Delphi и C++Builder. - КомпьютерПресс, 2003, № 7, 8.

.Дарахвелидзе П. Г., Марков Е. П. Delphi - среда визуального программирования. СПб.: BHV- Санкт-Петербург, 1999.

.Елманова Н., Трепалин С., Тенцер А. Delphi 6 и технология COM. - CПб.: Питер, 2002.

.Калверт Ч. Delphi 5. Энциклопедия пользователя. СПб.: ДиаСофтЮП, 2003.

.Климова Л. М. "Delphi 7. Самоучитель. М.: ИД КУДИЦ-ОБРАЗ, 2005.

.Корняков В.Н. Программирование документов и приложений MS Office в Delphi. - CПб.: БХВ-Петербург, 2005.

.Коцюбинский А.О., Грошев С.В. Язык программирования Delphi 5 - М.: "Издательство Триумф", 1999.

.Леонтьев В. Delphi 5 - М.: Москва "Олма-Пресс", 1999.

.Мадрел Тео. Разработка пользовательского интерфейса/ Пер. с англ.- М.:ДМК,2001.

.Матросов А. В. и др. MS Office ХР: разработка приложений / Матро

сов А. В., Новиков Ф. А., Усаров Г. Е., Харитонова И. А. / Под ред. Ф. А. Новикова. - СПб.: БХВ-Петербург, 2003.

17.Немнюгин С.А. Программирование - CПб.: Питер, 2000.

18.Озеров В. Delphi. Советы программистов (2-е издание). - СПб.: Символ- Плюс, 2002.

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

.Ревнич Ю. В. Нестандартные приемы программирования на Delphi. - СПб.: БХВ-Петербург, 2005.

.Ремизов Н. Delphi - CПб.: Питер, 2000.

.Симонович С.В., Евсеев Г.А. Занимательное программирование: Delphi. - М.: АСТ-ПРЕСС Кнрга, 2001.

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

.Ханекамп Д. Вилькен П. Программирование под Windows/ Пер. с нем. -М.: ЭКОМ, 1996.

.Хомоненко А. Д Delphi 7. CПб.: БХВ-Петербург, 2005.

26.<http://www.delphikingdom.ru> // Королевство Delphi. Виртуальный клуб программистов

.<http://www.delphiworld.narod.ru> //Профессиональные программы для разработчиков

.<http://www.delphisources.ru> // Программирование на Delphi

.<http://www.delphibasics.ru> // Справочник - «Основы Delphi»

30.<http://www.delphimaster.ru> // Мастера Delphi

Міністерство освіти і науки України Криворізький інститут Кременчуцького університету економіки, інформаційних технологій і управління Кафедра технічно

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