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

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-сервер доступу до даних представляє собою СОМ-сервер. З технологічної точки зору 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.

Remote Data Module - віддалений модуль даних, інкапсулює сервер Автоматизації. Використовується для організації з'єднань через DCOM, HTTP, сокети.

Transactioiial Data Module - віддалений модуль даних, інкапсулює сервер MTS (Microsoft Transaction Server).

SOAP Server Data Module - віддалений модуль даних, інкапсулює сервер SOAP (Simple Object Access Protocol).

WebSnap Data Module - віддалений модуль даних, що використовує Web-служби і Web-браузер в якості сервера.

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

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

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

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

TDCOMConnection - використовує DCOM;

TSocketconnection - використовує сокети Windows;

TWebConnection - використовує HTTP.

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

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

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

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

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

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

4.4.1 Компонент TDCOMConnection

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

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

property ComputerName: string;

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

property ServerName: string;

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

property ServerGUID: string;

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

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

property Connected: Boolean;

або методами

procedure Open / procedure Close;

відповідно.

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

property AppServer: Variant;

який також може бути отриманий методом

function GetServer: lAppServer; override;

Властивість

property 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. Для успішного відкриття з'єднання на стороні сервера повинен працювати сокет-сервер.

Для успішного з'єднання властивість

property Host: String; повинно містити ім'я комп'ютера сервера.

Додатково, властивість

property Address: String; повинно містити IP-адресу сервера.

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

Властивість

property Port: Integer;

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

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

property ServerName: string;

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

property ServerGUID: string;

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

Метод

function GetServerList: OleVariant; virtual;

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

property Connected: Boolean;

або методами

procedure Open;

procedure Close;

відповідно.

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

property InterceptName: string;

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

property InterceptGUID: string;

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

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

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

function GetlnterceptorList: OleVariant; virtual;

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

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

property AppServer: Variant;

який також може бути отриманий методом

function GetServer: lAppServer; override;

Властивість

property 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, то властивість

property URL: string;

повинно містити таке значення:

http://someserver.com/scripts/httpsrvr.dll

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

property ServerName: string;

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

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

property ServerGUID: string;

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

property UserName: string;

та

property Password: string;

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

Властивість

property Proxy: string;

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

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

property Agent: string;

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

property Connected: Boolean;

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

procedure Open;

procedure Close;

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

property AppServer: Variant;

або метод

function GetServer: IAppServer; override;

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

function GetServerList: OleVariant; virtual;

Властивість

property ObjectBroker: TCustomObjectBroker;

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

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

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

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

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

property DataSet: TDataSet;

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

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

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

property Constraints: Boolean; управляє передачею обмежень серверного набору даних клієнтського. Якщо властивість має значення True, обмеження передаються.

property Exported: Boolean; дозволяє використовувати в клієнтському наборі даних інтерфейс IAppServer. Для цього властивість повинно мати значення True.

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

type

TProviderOption = (poFetchBlobsOnDemand, poFetchDetailsOnDemand, poIncFieldProps, poCascadeDeletes, poCascadeUpdates, poReadOnly, poAllowMultiRecordUpdates, poDisablelnserts, poDisableEdits, poDisableDeletes, poNoReset, poAutoRefresh, poPropogateChanges, poAllowCoinmandText, poRetainServerOrder);

TProviderOptions = set of TProviderOption;

Набір параметрів властивості задається присвоєнням елементам значення True.

property Options: TProviderOptions;

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

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

poIncFieldProps - включає передачу в клієнтський набір даних декількох властивостей для об'єктів полів: Alignment, DisplayLabel, DisplayWidth, Visible, DisplayFormat, EditFormat, MaxValue, MinValue, Currency, EditMask, DisplayValues;

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

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

poReadOnly - включає режим "тільки для читання" для набору даних сервера;

poAllowMultiRecordUpdates - включає режим внесення змін відразу в кілька записів одночасно. Інакше всі записи змінюються послідовно, одна за одною;

poDisablelnserts - забороняє клієнту вносити в набір даних сервера нові записи;

poDisableEdits - забороняє клієнту вносити в набір даних сервера зміни;

poDisableDeletes - забороняє клієнту видаляти записи в наборі даних сервера;

poNoReset - забороняє оновлення набору даних сервера перед передачею записів клієнтові (перед викликом методу AS_GetReccrds інтерфейсу IAppServer);

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

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

poAllowCommandText - дозволяє змінювати текст запиту SQL, імена збережених процедур або таблиць в компоненті набору даних на сервері додатків;

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

Методи-обробники компонента-провайдера даних представлені в таблиці 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.4.5 Допоміжні компоненти - брокери з'єднань

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

Компонент TSimpleObjectBroker

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

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

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

property Servers: TServerCollection;

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

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

Властивості класу TServeritem

property ComputerName: string; Ім'я комп'ютера, на якому функціонує сервер ;

property DisplayName: String; Містить ім'я сервера для подання в списку серверів;

property Enabled: Boolean; Керує доступністю запису про сервер для вибору при підключенні. При значенні True компоненти сполук можуть використовувати даний запис списку для підключення ;

property HasFailed: Boolean; Після невдалої спроби використати даний запис списку при підключенні властивості присвоюється значення True і надалі цей запис не використовується;

property Port: Integer; Містить номер порту, використовуваного при підключенні до сервера;

Крім списку серверів компонент має лише кілька допоміжних властивостей і методів.

function GetComputerForGUID (GUID: TGUID): string; override; повертає ім'я комп'ютера, на якому зареєстрований сервер з GUID, заданим параметром.

function GetComputerForProgID (const ProgID): string; override; повертає ім'я комп'ютера, на якому зареєстрований сервер з ім'ям, заданим параметром Progio.

property LoadBalanced: Boolean; управляє вибором сервера зі списку. При значенні True запис про сервер вибирається випадковим чином, інакше для з'єднання пропонується перша доступна запис про сервер.

Компонент TLocalConnection

Компонент TLocalConnection використовується локально для отримання доступу до існуючих компонентів-провайдерам.

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

Загальне число компонентів-провайдерів в списку повертає властивість

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

property AppServer: IAppServer;

або метод

function GetServer: IAppServer; override;

Компонент TSharedConnection

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

Властивість

property ParentConnection: TDispatchConnection; повинно містити посилання на компонент з'єднання з головним віддаленим модулем даних сервера додатків. Дочірній віддалений модуль даних визначається властивістю

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

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

property AppServer: Variant;

або метод

function GetServer: lAppServer; override;

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

Компонент TConnectionBroker

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

property Connection: TCustomRemoteServer;

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

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

property AppServer: Variant;

або метод

function 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_p	Int	Номер запису (ключове поле)
NomerID_F	VarChar (15)	Номер телефону першого абонента
IMEI_F	VarChar (15)	IMEI телефону першого абонента
TipID	VarChar (3)	Тип дзвінка
Data	DateTime	Дата здійснення дзвінка
Vremya	DateTime	Час здійснення дзвінка
Dlitelnost	DateTime	Тривалість дзвінка
GPS	VarChar(24)	Розташування здійснення дзвінка
NomerID_S	VarChar(15)	Номер телефону другого абонента
IMEI_S	VarChar(15)	IMEI телефону другого абонента

Таблиця 5.3

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

Ім'я поля	Тип поля	Опис
PersonaID	Int	Персональний ідентифікатор абонента (ключове поле)
Familiya	VarChar(20)	Прізвище абонента
Imya	VarChar(15)	Ім'я абонента
Otchestvo	VarChar(15)	По-батькові абонента
Prozvishe	VarChar(24)	Прізвисько абонента
DataRoghdeniya		Дата народження
AdresRegistr	VarChar(150)	Адреса реєстрації
AdresProg	VarChar(150)	Адреса проживання
Avto	VarChar(8000)	Наявність авто
Sudimosti	VarChar(20)	Наявність судимостей
Foto	Image	Фотографія

Таблиця 5.4

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

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

Таблиця 5.5

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

Ім'я поля	Тип поля	Опис
TipID	VarChar(3)	Ідентифікатор типу дзвінка (ключове поле)
Tip	VarChar(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_id
InsrtInMain	Процедура додавання інформації в головну таблицю. Вхідні параметри: @ 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 Сервер додатків

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 Віддалений модуль даних

Для шифрування / дешифрування пароля входу в систему використовується функція

function TFormMain.crypt(str: string): string;

function TFormMain.crypt(str: string): string;

var

i:integer;

crypt_res,crypt_txt:string;

begin

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

i:=0;

crypt_txt:=str;

while i<length(crypt_txt) do

begin

inc (i);

crypt_res:=crypt_res +chr(ord(crypt_txt[i]) xor ord(key[i mod 8]));

end;

Result:=crypt_res;

end;

Для авторизації клієнта сервером БД в сервері додатків використовується функція

TRDModule.Login(const UserName, Password: WideString): WordBool;

function TRDModule.Login(const UserName, Password: WideString): WordBool;

var

S:String;

begin

/ / Новий метод для авторизації, створений в бібліотеці типів S:=Password;

if Length(s) = 0 then s:='""';

try

ADOConnection1.ConnectionString:=

Format(ConnectionString,[S, UserName]);

ADOConnection1.Connected:=true;

Result:=True;

Except

Result:=false;

end;

end;

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

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

begin

reg:=TRegistry.Create;

reg.RootKey:=HKEY_CURRENT_USER;

reg.OpenKey('\Software\PhoneInfo\Admin',true);

if (not reg.ValueExists('ip')) and (not reg.ValueExists('comp_name'))

then

begin

BarCnnctClick(Sender);

end;

if PasswordDlg.ShowModal = mrCancel then Application.Terminate;

if not adminRights then

begin// заборона адмінських меню

barNewUser.Enabled:=false;

barDelUser.Enabled:=false;

end;

end;

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

procedure TPasswordDlg.cxButton1Click(Sender: TObject);

var

str:string;

begin

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

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