Модуль збору та обробки статистичної інформації в медичному закладі
Міністерство
освіти і науки, молоді та спорту України
Криворізький інститут
Кременчуцького університету
економіки, інформаційних технологій та управління
Кафедра технічної кібернетики
Спеціальність 7.05020102
«Комп’ютеризовані та робототехнічні системи»
ДИПЛОМНА РОБОТА
Тема:
Модуль збору та обробки
статистичної інформації в медичному закладі
Студентки групи КРС-07-з
Зозулі Марини Олександрівни
Керівник роботи ст. викл.
Супрунова Юлія Анатоліївна
Кривий Ріг 2012
ЗАВДАННЯ
на дипломну роботу студентки Зозулі Марини Олександрівни
. Тема роботи: Модуль збору та обробки статистичної
інформації в медичному закладі
. Термін здачі студентом закінченої роботи 03.05.12
. Вхідні дані до роботи: Вимоги до кінцевого програмного
продукту, вихідні масиви даних, програмна документація; матеріали наукових
досліджень.
. Зміст розрахунково-пояснювальної записки (перелік питань,
що підлягають розробці): Постановка завдання; Інформаційні системи як
сукупність засобів для збереження та обробки інформації; Командна оболонка та
мова сценаріїв PowerShell; Дослідження технології COM та створення контролерів
автоматизації MS Office; Опис функціональних можливостей та програмної
реалізації проектованої системи; Економічне обґрунтування доцільності розробки
програмного продукту; Охорона праці.
. Перелік графічного матеріалу (з точними вказівками
обов'язкових креслень)
. Логіко-функціональна схема роботи системи;
2. Схема інформаційних потоків;
3. Приклади робочих вікон системи;
. Схема роботи покажчика СОМ-інтерфейсу;
. Схема взаємодії клієнта с внутрішнім сервером;
. Схема взаємодії клієнта з сервером в різних процесах на
одному комп’ютері;
. Схема взаємодії клієнта з сервером на різних комп’ютерах;
. Об'єктна модель MS Excel;
6. Консультанти з роботи, з вказівками розділів роботи, що
належать до них
|
Розділ
|
Консультант
|
Підпис, дата
|
|
|
Завдання видав
|
Завдання прийняв
|
|
Економічна частина
|
Вдовиченко І.В.
|
|
|
|
Охорона праці
|
Климович Г.Б.
|
|
|
. Дата видачі завдання 03.11.11 р.
Календарний план
|
№ п/п
|
Найменування етапів дипломної роботи
|
Термін виконання етапів роботи
|
Примітки
|
|
Отримання завдання на дипломну роботу
|
03.11.11
|
|
|
Огляд існуючих рішень
|
20.02.12
|
|
|
Теоретичне дослідження інструментальних засобів
реалізації проекту
|
13.03.12
|
|
|
Програмна частина (постановка задачі, створення
програмного забезпечення, опис алгоритму рішення задачі, проектування та опис
інтерфейсу користувача, опис програми)
|
28.04.12
|
|
|
Оформлення пояснювальної записки
|
05.05.12
|
|
|
Оформлення графічної документації
|
14.05.12
|
|
|
Оформлення електронних додатків до диплому
|
20.05.12
|
|
|
Представлення дипломної роботи до захисту
|
03.05.12
|
|
АНОТАЦІЯ
Метою виконання дипломної роботи є автоматизація збору
статистичних інформації в умовах неврологічного відділення Криворізького
інституту професійних захворювань. Призначення системи - отримання
лікарем-дослідником статистичного ряду згідно обраних показників.
Оболонка системи була реалізована засобами середовища
програмування Delphi, модуль пошуку даних представлений у вигляді скрипту
системи пакетної обробки PowerShell.
Розділів 7, схем та рисунків 22, таблиць 8, бібліографічних
посилань 30, загальний обсяг - 103.
АННОТАЦИЯ
Целью выполнения дипломной работы является автоматизация
сбора статистических информации в условиях неврологического отделения
Криворожского института профессиональных заболеваний. Назначение системы -
получение врачом-исследователем статистического ряда согласно выбранным
показателям.
Оболочка системы была реализована средствами среды
программирования Delphi, модуль поиска данных представлен в виде скрипта
системы пакетной обработки PowerShell.
Разделов 7, схем и рисунков 22,
таблиц 8, библиографических ссылок 30, общий объем - 103.
THE SUMMARY
purpose of the diploma work is automation of information
statistical collection in the conditions of neurological separation of the
Kriviy Rih institute of professional diseases. Setting of the system is receipt
by the doctor-researcher of statistical row in obedience to the chosen indexes.
The shell of the system was realized in Delphi program environment,
the module of data retrieval is presented as the script of the PowerShell batch
processing system.7, circuits and figures 22, tables 8, bibliographic
references 30, total amount - 103.
ЗМІСТ
ВСТУП
. ПОСТАНОВКА ЗАВДАННЯ
.1 Найменування та
галузь використання
.2 Підстава для
створення
.3 Характеристика
розробленого програмного забезпечення
.4 Мета й призначення
.5 Загальні вимоги до
розробки
.6 Джерела розробки
. ІНФОРМАЦІЙНІ
СИСТЕМИ ЯК СУКУПНІСТЬ ЗАСОБІВ ДЛЯ ЗБЕРЕЖЕННЯ ТА ОБРОБКИ ІНФОРМАЦІЇ
.1 Класифікація
інформаційних систем
.2 Бази даних як
складова частина інформаційної системи
. КОМАНДНА ОБОЛОНКА
ТА МОВА СЦЕНАРІЇВ POWERSHELL
.1 Історія розвитку
.2 Загальні відомості
.3 Командлети
.4 Конвейєр
.5 Сценарії
. ДОСЛІДЖЕННЯ
ТЕХНОЛОГІЇ COM ТА СТВОРЕННЯ КОНТРОЛЕРІВ АВТОМАТИЗАЦІЇ MS OFFICE
.1 Загальні принципи
СОМ-технології
.2 Розвиток
СОМ-технологій
.3 Склад СОМ-додатку
4.3.1 СОМ - інтерфейс
.3.2 СОМ-сервери
4.3.3 СОМ-клієнти
.4 Об'єктна модель MS
Excel
.5 Загальні принципи
створення контролерів автоматизації MS Office
.6. Принципи
створення контролерів автоматизації MS Excel
4.6.1 Створення
об'єкту Excel. Application, запуск і візуалізація вікна системи
.6.2 Робота з
аркушами робочої книги
.6.3 Робота з
комірками
.6.4 Пошук і заміна
тексту
.6.5 Формули
5. ОПИС
ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ
.1 Функціональне
призначення та технологічні особливості розробки
.2 Розробка схеми
інформаційних потоків та логіко-функціональної схеми роботи системи
.3 Опис інтерфейсу користувача
.4 Програмна
реалізація системи
5.4.1 Реалізація
інтерфейсної оболонки засобами Delphi
.4.2 Здійснення
пошуку та збору інформації засобами системи пакетної обробки PowerShell
6 ЕКОНОМІЧНЕ
ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ
. ОХОРОНА ПРАЦІ
.1 Аналіз небезпечних
й шкідливих виробничих факторів
.2 Заходи щодо
нормалізації небезпечних і шкідливих факторів
.3 Пожежна безпека
ВИСНОВКИ
СПИСОК ЛІТЕРАТУРИ
ВСТУП
Масиви даних, потрібних для тих чи інших цілей, наразі
зберігаються в різному вигляді, добре якщо принаймні в електронному. Більшість
конче потрібної медичної інформації продовжує жити на папері. Там же, де було
прийнято спроби хоч якоїсь автоматизації роботи лікаря маємо сумнівні
результати.
Розглянемо ті методи збереження та роботи з інформацією, які
використовуються у сучасному медичному середовищі:
· системи корпоративного управління змістом (ECM system
- enterprise content management system);
· прості бази даних;
· окремі файли;
· паперові носії.
Усе перераховане вище йде у порядку зростання відсотку
розповсюдження. Перша у списку система навіть у такій високорозвинутій у
технологічному плані державі, як Сполучені Штати Америки, займає не більше двох
відсотків від загальної кількості медичних закладів. Тому розгляд її та простих
баз даних на наших теренах не має поки що жодного сенсу. Розгляд обробки даних,
що отримані з паперових носіїв теж не входить до сфери наших інтересів, адже
велика кількість людино-годин, що вона потребує для більш-менш нормальних
статистичних результатів, просто космічна.
В нашому випадку робота з пошуку та обробки даних для
статистичного дослідження проводилась із окремими файлами, що, правда, мають
досить схожий формат зберігання. Саме цей чинник серйозно полегшив нашу справу.
Із схожою проблемою обробки даних можуть зіткнутися ті
лікарі, що протягом останніх років самостійно, чи з тиску різних обставин,
розпочали зберігання окремих видів медичної документації в електронному вигляді
(найчастіше у форматі MS Word). Також важливим чинником може слугувати і той
факт, що з такими документами простіше працювати і в якійсь мірі те, що це
обов'язковий наказ міністерства охорони здоров'я.
Що ж найчастіше можна зустріти в тих самих окремих файлах, в
яких лікарі так старанно зберігають результати своєї праці? Велика частка
документів являє собою виписку з історії хвороби. Тож на разі маємо такі вхідні
дані - файли виписок, що містять більшість необхідної для статистичних
досліджень інформації і одноманітний формат базових елементів, що складають її
основу.
Метою виконання дипломної роботи є автоматизація збору
статистичних інформації в умовах неврологічного відділення Криворізького
інституту професійних захворювань.
Інтерфейс системи був створений за допомогою
інструментального засобу прискореної розробки програмного забезпечення Delphi.
Збір даних був реалізований за допомогою системи пакетної обробки PowerShell,
що базується на основі технології .NET Framework. При цьому скрипт сценарію
генерується та виконується автоматично на основі умов, заданих користувачем
системи та під управлінням оболонки системи.PowerShell - розширюваний засіб
автоматизації від Microsoft, що складається з оболонки з інтерфейсом командного
рядка і супутньої мови сценаріїв. Windows PowerShell побудований на базі
Microsoft .NET Framework і інтегрований з ним. Додатково PowerShell надає
зручний доступ до COM, WMI і ADSI, рівно як і дозволяє виконувати звичайні
команди командного рядка, щоб створити єдине оточення, в якому адміністратори
змогли б виконувати різні завдання на локальних і видалених системах. Windows
PowerShell також надає механізм вбудовування, завдяки якому виконувані
компоненти PowerShell можуть бути вбудовані в інші додатки. Ці додатки потім
можуть використовувати функціональність PowerShell для реалізації різних
операцій, включаючи ті, що надаються через графічний інтерфейс.
1.
ПОСТАНОВКА ЗАВДАННЯ
.1
Найменування та галузь використання
Найменування розробки: модуль збору та обробки інформації в
медичному закладі. Розроблена система створена згідно замовленню та пройшла практичну
апробацію в умовах неврологічного відділення Криворізького інституту
професійних захворювань.
1.2
Підстава для створення
Підставою для розробки є наказ № 55С-01 від 1 листопада 2011
р. по Криворізькому інституту КУЕІТУ.
Початок робіт: 03.11.11. Закінчення робіт: 03.05.12.
1.3
Характеристика розробленого програмного забезпечення
Інтерфейс системи був створений за допомогою
інструментального засобу прискореної розробки програмного забезпечення Delphi з
використанням пакетів альтернативних компонентів Development Express та
AlphaControls 2010. У зв’язку з великим об’ємом вхідних даних та тривалим часом
їх обробки пошук та збір даних був реалізований за допомогою системи пакетної
обробки PowerShell, що базується на основі технології .NET Framework. При цьому
скрипт сценарію генерується та виконується автоматично на основі умов, заданих
користувачем системи та під управлінням оболонки системи.
Склад розробленої системи:
· medical_stat.exe - виконавчий файл оболонки системи;
· script.ps1 - файл скрипту PowerShell;
· DocConverterX.exe - зовнішній
конвертор файлів формату *.doc в формат *.txt;
· baza.mdb - файл бази даних формату
Microsoft Access, що зберігає допоміжну та проміжну інформацію;
· my.ini - файл налаштувань інтерфейсу
системи.
Вхідна інформація системи - виписки з історії хвороби у
вигляді файлів формату *.doc повинні зберігатися в каталозі doc, в тій же
директорії, де знаходиться виконавчий файл.
.4
Мета й призначення
Метою виконання дипломної роботи є автоматизація збору
статистичних інформації в умовах неврологічного відділення Криворізького
інституту професійних захворювань.
В якості вхідних даних служать файли виписок з історії
хвороби у форматі MS Word, які містять більшість необхідної для статистичних
досліджень інформації і мають схожу структуру базових елементів. Також є список
захворювань і професій, для яких ведеться збір інформації, який формується
лікарем-дослідником та зберігається у базі даних.
Призначення системи - отримання лікарем-дослідником
статистичного ряду згідно обраним показникам, які в подальшому можуть бути
передані до обробки в пакети MS Excel та STATISTICA.
1.5
Загальні вимоги до розробки
Вимоги до програмного забезпечення:
· робота в середовищі операційних систем Windows
XP/Vista/7;
· відсутність додаткових вимог до
розміщення здійсненних файлів, простота та зрозумілість інтерфейсу користувача;
· додаткове програмне забезпечення: установка пакету MS
Office, для операційних системи версій нижче Windows7 необхідна установка
Windows Management Framework.
Мінімальні вимоги до апаратного забезпечення:
· IBM-Сумісний комп'ютер, не нижче Pentium III,
RAM-512Mb, SVGA-800*600*16bit, вільний простір на жорсткому диску не менш 250
мБ.
1.6
Джерела розробки
Джерелами розробки дипломної роботи є:
· технічне завдання на реалізацію проекту;
· довідкова література;
· наукова література;
· технічна література;
· програмна документація.
2.
ІНФОРМАЦІЙНІ СИСТЕМИ ЯК СУКУПНІСТЬ ЗАСОБІВ ДЛЯ ЗБЕРЕЖЕННЯ ТА ОБРОБКИ ІНФОРМАЦІЇ
Інформаційні системи (ІС) здавна знаходять (в тому чи іншому
вигляді) досить широке застосування в життєдіяльності людства. Це пов'язано з
тим, що для існування цивілізації необхідним є обмін інформацією - передача
знань, як між окремими членами і колективами суспільства, так і між різними
поколіннями.
Найдавнішими і найпоширенішими ІС слід вважати бібліотеки. І,
дійсно, здавна в бібліотеках збирають книжки (або їх аналоги), зберігають їх,
дотримуючись певних правил, створюють каталоги різного призначення для
полегшення доступу до книжкового фонду. Видаються спеціальні журнали та
довідники, що інформують про нові надходження, ведеться облік видачі.
Ще один приклад. На великому сучасному підприємстві в тому чи
іншому вигляді повинна існувати інформаційна система. Для забезпечення якісного
управління потрібно знати (можливо з різним ступенем оперативності) об'єм
запасів тієї чи іншої сировини, скільки і якої вироблено продукції, скільки
споживається електроенергії, який цех що виробляє і що потребує, та багато
іншої інформації, яка стосується виробничих питань. Крім цього, профспілкам
необхідні відомості про потреби співробітників у соціально-побутовій,
медично-оздоровчій сферах, тощо. Для обробки всіх таких даних потрібні певні
організаційні і технічні засоби, тобто ІС.
Найстаріші (у моральному і у фізичному розумінні) системи
повністю базувалися на ручній праці. Пізніше їм на зміну прийшли різні
механічні пристрої для обробки даних (наприклад, для сортування, копіювання,
асоціативного пошуку, тощо). Наступним кроком стало впровадження
автоматизованих інформаційних систем (АІС), тобто систем, де для забезпечення
інформаційних потреб користувачів використовується ЕОМ зі своїми носіями
інформації.
В наш час - епоху інформаційного вибуху - розроблюється і
впроваджується велика кількість самих різноманітних АІСів з дуже широким
спектром використання.
2.1
Класифікація інформаційних систем
В науковій літературі існує досить значне розмаїття щодо
класифікації АІС. Різні автори в залежності від своїх задач та точок зору
виділяють ті чи інші критерії і розподіляють пріоритети між ними. Зупинимось на
одному з таких підходів, який на наш погляд, найбільш узгоджується з іншими
темами цього курсу. Отже, АІС класифікуються:
· за призначенням (фактографічні, документальні та
змішані);
· за мовами (замкнуті системи, системи
з базовою мовою та змішані);
· за локалізацією (локальні та
розподілені);
· за схемою додаткової обробки
(постобробка та попередня обробка);
· за структурами даних (ієрархічні,
мережаного типу , реляційні).
Критерії за якими діляться АІС:
) за призначенням.
Документальні системи зорієнтовані на обробку та зберігання
документа (порівняно великої за розміром послідовності символів), внутрішню
структуру якого система (майже) повністю ігнорує, тобто він неподільний
(атомарний) з точки зору системи. Споживачем результатів пошуку виступає, як
правило, кінцевий користувач.
Фактографічні системи оперують фактами (даними) різних типів,
що зв'язані в системі в більш чи менш складні структури. Дані, що є результатом
пошуку, можуть стати складовою частиною звітів або використовуються різноманітними
обчислювальними процесами.
Змішані системи включають в себе в тих чи інших пропорціях
риси обох вищеназваних варіантів. Переважну більшість сучасних систем для ПЕОМ
слід віднести до категорії змішаних.
Звичайно, наведені описові характеристики не дають можливості
чітко визначитись у випадку класифікації кожної конкретної ІС, але дозволяють
зробити перші грубі припущення. Для більш точних класифікаційних оцінок
необхідно враховувати додаткові властивості, що відносяться до пошукового
процесу, а також до особливостей мов запитів, реалізованих в тій чи іншій
системі. Оскільки подальші наші розгляди будуть стосуватися переважно
фактографічних систем, тому зараз приділимо більше уваги саме документальним
системам.
Дескрипторні або документальні АІС (ДАІС) історично були
першими. Спочатку їх мовою була нічим не обмежена природна мова. Перші ДАІС
були призначені для пошуку книг та документів у бібліотеках і великих сховищах,
тому їх і почали називати документографічними.
Основним елементом інформаційного простору ДАІС була анотація
або реферат книги, документа, явища чи об'єкта. Реферат повинен відображувати
ті риси, які цікавлять користувача (як правило - людини). В ньому виділяються
слова чи словосполучення, які в сукупності майже однозначно (в ідеалі точно)
відповідають повному опису об'єкта, крім того, таких слів повинно бути відносно
небагато. Їх називають ключовими словами або дескрипторами. Запит для ДАІС
можна сформулювати у вигляді переліку дескрипторів, який на думку користувача
характеризує потрібний реферат, а значить, і відповідний об'єкт. Алгоритм
формування відповіді послідовно порівнює запит з кожним рефератом і вибирає
такі, що пройшли порівняння. В таких системах запит називають пошуковим
розпорядженням, а реферат - пошуковим образом.
) За мовами (замкнуті системи, системи з базовою мовою та
змішані);
Системи з базовою мовою передбачають взаємодію користувача з
СУБД з середовища якоїсь іншої мови програмування, де і виконуються більшість
постпошукових перетворень даних. Такий підхід зручний для розробки різного роду
систем як надбудов над СУБД, бо дає можливість створювати високоефективні
програми постпошукової обробки даних.
Замкнуті системи самостійно забезпечують користувача всіма
необхідними засобами як для локалізації даних, так і для їх постпошукової чи
передпошукової обробки. Недоліком таких систем є те, що в них відсутні (або
малоефективні) засоби для розробки надбудов - проблемно-орієнтованих
комплексів.
Змішані системи передбачають наявність обох можливостей двох
попередніх підходів і є найбільш поширеними на сьогодні.
) за локалізацією (локальні та розподілені);
Локальність передбачає розташування всього програмного
забезпечення і даних на одному ізольованому комп’ютері, а розподіленість
означає розташування системи на мережі комп’ютерів з певною стратегією
рознесення даних.
) за схемою додаткової обробки (постобробка та попередня
обробка);
Головним призначенням будь-якої системи баз даних є підтримка
функцій локалізації даних, що зберігаються, але дуже важливою властивістю, що
може значно підняти інтерфейсний рівень системи, є наявність постобробки даних
після їх локалізації в базі даних, чи попередньої обробки.
) за структурами даних (ієрархічні, мережного типу,
реляційні).
Структури даних, що підтримуються в системі бази даних, - це
важливий фактор, що впливає, як на виразову потужність, так і на ефективність
функціонування. Для систем з ієрархічною структурою базовою структурою даних є
дерево; як правило, вони мають найвищу ефективність функціонування, але
виразові можливості їх відносно низькі. Системи з структурами даних типу мережа
мають значно кращі виразові можливості, але дещо програють у ефективності
функціонування, точніше, від користувача вимагається значно вищий рівень
кваліфікації для ефективної експлуатації таких систем. В останні десятиріччя
найбільшого розповсюдження (особливо для персональних ЕОМ) зазнали СУБД
реляційного типу, для яких характерно щонайпростіша структура даних (плоский
файл), але одночасно суттєво підвищений рівень мов маніпулювання даними, що максимально
употужнює виразові можливості та знижує ефективність функціонування, тому для
таких систем потрібні потужні комп’ютери, і вони значно чутливіші (порівняно з
попередниками) до росту об’ємів даних.
2.2
Бази даних як складова частина інформаційної системи
Широке використання ЕОМ призвело до автоматизації обробки і
використання величезної кількості інформації у різних галузях діяльності
людини. Ще в початковий період розвитку автоматизованих інформаційних систем на
основі ЕОМ першого і другого поколінь (кінець 50-х - початок 60-х років) різні
організації почали накопичувати і зберігати дані про цікаві для них предметні
області. Дані або були „зашиті” безпосередньо в програми, або програми мали
змогу вибирати ці дані тільки з жорстко фіксованих (визначених усередині
програми) пристроїв (носіїв інформації).
Другий етап розвитку АІС (60-ті - початок 70-х років) фахівці
пов’язують із винаходом так званих файлових систем, що забезпечують
незалежність розміщення наборів даних, у яких міститься інформація, від конкретних
фізичних носіїв (так звана фізична незалежність даних і програм). Однак, кожна
така програма була розрахована на роботу тільки з файлами визначеного формату,
тобто зберігалася залежність програм від структури даних у файлах (логічна
взаємозалежність програм і даних).
Сформований у той період підхід до побудови АІС полягав у
автоматизації окремих процесів з предметної області або, як кажуть, у створенні
кількох слабко взаємозалежних локальних програмних додатків. У міру виникнення
нових потреб у збереженні й обробці даних створювалися все нові й нові
програмні додатки з необхідними для них файлами. Часто нові прикладні програми
створювалися з обліком уже існуючих файлів.
Користувачі АІС поступово усвідомлювали необхідність
централізації управління даними і програмними додатками. Розуміння цієї
необхідності приходило різними шляхами.
По-перше, користувачі АІС швидко виявили, що необхідну для
ухвалення та прийняття рішення інформацію не дуже легко отримати. Щоб виконати
запит на інформацію, необхідно було написати програму, здатну обробити кілька
файлів інших програм, здійснюючи перетворення форматів, сортування та вибірку
інформації. Відразу виникала проблема інтеграції різномовних програм, тому що
файли програм, написаних однією мовою програмування (наприклад, РL/1 або
FORTRAN), не могли безпосередньо використовуватися програмами, що були написані
іншими мовами програмування. У таких умовах швидко отримати відповідь на
заздалегідь непередбачений запит було практично неможливо. Дуже часто
користувачі навіть були змушені відмовитися від запиту тому, що за час,
протягом якого могла бути отримана відповідь, вона ставала непотрібною або
тому, що цінність інформації не відповідала витратам на її отримання
По-друге, використання АІС стримувалося отриманням найчастіше
суперечливих відповідей на запити. Суперечливість виникала через надмірність
даних, що призводила до того, що різні версії одного елемента даних у різних
файлах могли знаходитися на різних стадіях оновлення. Складно було підтримувати
несуперечливість, узгодженість і цілісність даних. Обчислювальні ресурси, такі,
як пам’ять і машинний час, витрачалися нераціонально.
По-третє, під час зміни структури записів деякого файла в
інтересах удосконалення одного програмного додатка, необхідно було вносити зміни
у всі інші прикладні програми, що працюють із цим файлом. Таким чином,
проявлялася логічна залежність програм від даних.
Відомо, що модернізація вже використовуваних програм - справа
складна і тонка, а іноді й неможлива через відсутність текстів програм і/або
авторів їх розробки. В останньому випадку доводилося або розробляти нову,
аналогічну за функціями програму, або взагалі відмовлятися від внесення змін у
дані. Ці обставини суттєво стримували розробку нових програмних додатків і
спричинили величезні витрати коштів на супровід і розвиток АІС.
Усвідомлення значимості, даних, необхідності централізованого
управління ними і прагнення розв’язати наведені вище проблеми розвитку АІС
призвели до виникнення нової концепції спільного використання даних - концепції
баз даних.
Таким чином, основною причиною закономірного виникнення
концепції баз даних є прагнення підвищити гнучкість автоматизованих
інформаційних систем, тобто зробити їх менш залежними від змін вимог до АІС з
обробки інформації і більш придатними для розвитку і подальшої модифікації.
Насамперед проголосимо основні ідеї, що лежать в основі
концепції бази даних:
. Ізолювати будь-яку прикладну програму від впливу змін в
інших програмах через спільні дані шляхом розмежування логічних записів, що
використовуються прикладними програмами, від записів, що реально (фізично)
запам’ятовуються на магнітних носіях.
. Усунути надмірне дублювання даних.
. Централізувати управління даними.
Отже, суть концепції баз даних полягає в інтегрованому
збереженні й диференційованому використанні прикладними програмами всієї
інформації про об’єкти предметної області, що представляють певний інтерес для
організації. За таких умов, з одного боку, формати представлення даних
описуються на логічному (зрозумілому) для кожної програми рівні, але, з іншого
боку, усі інші дані, що зберігаються у базі даних і не мають ніякого відношення
до певної прикладної програми, є для неї “прозорими”. Це означає, що їхню
присутність програма не відчуває.
Тобто всі дані розміщуються в єдиному сховищі. Користувачі
АІС мають можливість звертатися до будь-яких даних, що їх цікавлять.
Ті самі дані можуть бути в різних комбінаціях і по-різному
представлені відповідно до потреб користувачів (прикладних програм). Це
забезпечується за рахунок занурення бази даних у спеціальне програмне
середовище, що виконує функції доступу і перетворення структур даних, і
називається системою управління базами даних (СУБД).
На жаль, у більшості означень поняття бази даних, що
наводяться в літературі, не вказуються всі її суттєві ознаки. Також базу даних
часто просто ототожнюють із будь-якою сукупністю файлів, що містять деякий
набір відомостей про предметну область, яка має певний інтерес для організації.
Зі сказаного зрозуміло, що сукупність файлів не обов’язково автоматично утворює
базу даних. Щоб це відбувалося, файли повинні бути:
. Взаємопов’язаними (так, що має бути забезпечена повна й
узгоджена інформація про предметну область).
. Інтегрованими (за умови мінімальної надмірності, необхідної
для забезпечення взаємопов’язаності файлів).
. Незалежними (логічно та фізично від програм, у яких вони
використовуються, і від процесів, у яких вони підтримуються).
. Мати єдину централізовану програму управління, що
забезпечує логічну незалежність програм від даних, що знаходяться у файлах.
Наведемо означення основних понять, які пов’язані з
розглянутою концепцією.
Базою даних (БД) - називається пойменована сукупність даних,
з тією мінімальною надмірністю, що необхідна для взаємопов’язаності даних, яка
адекватно відображає стан об’єктів та їхні відношення у розглядуваній
предметній області.
Базу даних можна визначити як сукупність взаємопов’язаних
даних за наявності такої мінімальної надмірності, що допускає їхнє використання
оптимальним способом для одного або кількох додатків; дані запам’ятовуються
таким чином, щоб вони були незалежними від програм, що використовують ці дані,
а також для пошуку даних у базі даних застосовується єдиний керований спосіб.
Дані структуруються таким чином, щоб була забезпечена можливість подальшого
нарощування додатків.
Системою управління базами даних (СУБД)- називається
сукупність мовних і програмних засобів, призначених для створення, управління і
сумісного використання БД багатьма користувачами (програмами).
Банк даних (БнД) - система програмних, лінгвістичних,
інформаційних, організаційних і технічних засобів, призначених для
централізованого накопичення і колективного використання даних. Поняття банка
даних аналогічне поняттю АІС, побудованої на основі єдиної БД.
Бази даних є новим кроком у розвитку засобів обробки даних,
що сприяв подальшому розширенню галузей застосування ЕОМ і сприяв кращому
використанню даних у сфері управління й прийняття рішень.
Основними вимогами до баз даних та систем управління ними є:
. Можливість представлення адекватних реальній предметній
області структур даних (побудова адекватної інформаційної моделі предметної
області).
. Простота та малі витрати ресурсів на розвиток системи
(швидка і дешева модифікація старих та розробка нових програмних додатків у
рамках автоматизованої інформаційної системи).
. Простота та оперативність доступу до даних, можливість
пошуку інформації різними методами.
. Можливість одночасного ефективного обслуговування великої
кількості користувачів.
. Можливість використання у розподілених обчислювальних
мережах ЕОМ.
. Забезпечення режиму розмежованого доступу до даних і
програм та виключення можливості їхнього несанкціонованого застосування.
. Забезпечення представлення даних користувачам (людям або
програмам) у вигляді, зручному для їхнього подальшого застосування.
. Забезпечення необхідної продуктивності розв’язування задач
при обмежених витратах ресурсів ЕОМ.
. Забезпечення захисту інформації у БД від збоїв і відмов у
роботі технічних засобів та помилок користувачів.
Основними перевагами застосування БД та СУБД під час
реалізації на їхній основі АІС є:
. Скорочення зайвої надмірності даних, що зберігаються. Дані,
що використовуються кількома програмами, інтегруються і зберігаються в одному
місці. Надмірність даних є, вона мінімальна та необхідна тільки для
забезпечення взаємозв’язку різних даних певної предметної області.
. Усувається суперечливість даних. Вона може виникати, якщо
ті самі дані, що використовуються різними програмами подаються декілька разів,
і якщо у разі необхідності їхньої зміни не всі копії відновлені. Зрозуміло, що
за відсутності надмірності суперечливість неможлива принципово.
. Дані, що зберігаються, використовуються спільно. Це надає
можливість розробляти нові програмні додатки над вже існуючою базою даних із
мінімальними затратами.
. Забезпечується більш простий, швидкий і дешевий розвиток
автоматизованих систем за рахунок забезпечення логічної взаємної незалежності
програм і даних у БД.
. Спрощується підтримка цілісності (адекватності та
узгодженості) даних.
. Забезпечується можливість швидкого на дання даних на
нестандартні (заздалегідь непередбачені) запити користувачів без додаткової
розробки прикладних програм.
. Створюється можливість комплексної оптимізації параметрів
АІС. Це можливе завдяки централізованому управлінню базою даних, за якого можна
так структурувати і розміщувати дані, щоб для найважливіших (пріоритетних)
програмних додатків забезпечити найшвидший доступ.
. У разі централізованого управління базою даних спрощується
стандартизація та уніфікація представлення даних у АІС.
Основними недоліками, з якими можуть зустрітися користувачі
та розробники програмного забезпечення під час застосування БД та СУБД, є:
. Додаткові витрати ресурсів (оперативної та зовнішньої
пам’яті, загальної продуктивності ЕОМ) під час розміщення і роботи СУБД.
. Додаткові витрати на встановлення і підтримку СУБД у
робочому стані.
. Необхідність кваліфікованого персоналу для централізованого
управління базою даних (адміністрації бази даних).
. Додаткові накладні витрати (плата за гнучкість). Швидкодія
прикладної програми, що взаємодіє з БД, нижча ніж для однієї окремо взятої
аналогічної програми, що працює зі своїми файлами (однак це невірно для
великого числа взаємопов’язаних за даними програмних додатків).
Таким чином, використання БД та СУБД щодо створення великих
потужних АІС, що включають велику кількість взаємопов’язаних програмних
додатків, безперечно дає суттєві переваги порівняно з варіантами створення
таких самих АІС на основі файлових систем.
Однак, для окремих програмних додатків (невеликої кількості
непов’язаних або слабко пов’язаних програм), або програм, що виконують
специфічні прикладні функції та мало пов’язані з обробкою великих обсягів
даних, використання потужних СУБД може виявитися малоефективним тому, що
вимагає додаткових затрат часу і коштів. Вибір доцільних варіантів реалізації
системи обробки даних повинен здійснюватися на основі комплексного системного
підходу під час їхнього проектування.
3.
КОМАНДНА ОБОЛОНКА ТА МОВА СЦЕНАРІЇВ POWERSHELL
PowerShell - розширюваний засіб автоматизації від Microsoft,
що складається з оболонки з інтерфейсом командного рядка і супутньої мови
сценаріїв.PowerShell побудований на базі Microsoft .NET Framework і
інтегрований з ним. Додатково PowerShell надає зручний доступ до COM, WMI і ADSI,
рівно як і дозволяє виконувати звичайні команди командного рядка, щоб створити
єдине оточення, в якому адміністратори змогли б виконувати різні завдання на
локальних і видалених системах.
Ці адміністративні завдання звичайно виконуються за допомогою
командлетів (у оригіналі cmdlets), які є спеціалізованими класами .NET.
Користувач може комбінувати їх в скриптах (сценаріях), використовуючи різні
конструкції, утиліти командного рядка і звернення до звичайних класів .NET,
об'єктам WMI або COM. Крім того, можна використовувати різні сховища даних,
такі як файлова система або реєстр Windows, які надаються PowerShell за
допомогою постачальників.PowerShell також надає механізм вбудовування, завдяки
якому виконувані компоненти PowerShell можуть бути вбудовані в інші додатки. Ці
додатки потім можуть використовувати функціональність PowerShell для реалізації
різних операцій, включаючи ті, що надаються через графічний інтерфейс. Цей
підхід застосований в Microsoft Exchange Server 2007 для реалізації
функціональності у вигляді командлетів PowerShell і графічних утиліт управління
у вигляді оболонок PowerShell, які викликають необхідні командлети. Таким
чином, графічний інтерфейс управління знаходиться поверх проміжного шару -
PowerShell. Інші додатки Microsoft, включаючи Microsoft SQL Server 2008, System
Center Operations Manager і System Center Data Protection Manager також надають
доступ до своїх інтерфейсів управління через командлети PowerShell.
3.1
Історія розвитку
Кожна випущена версія MS-DOS і Microsoft Windows для
персональних комп'ютерів містила утиліту, що надає інтерфейс командного рядка.
Це були COMMAND.COM (у системах, заснованих на MS-DOS, включаючи Windows 9x) і
cmd.exe (у системах сімейства Windows NT). Це були звичайні інтерпретатори
командного рядка, що мали лише декілька базових команд. Для інших завдань були
потрібні окремі консольні додатки, які викликалися з цих оболонок. Вони також
мали мову сценаріїв (пакетні файли), за допомогою якої можна було
автоматизувати різні завдання. Проте ці інтерпретатори не були призначені для
повноцінної автоматизації - частково тому, що в них були відсутні еквіваленти
багатьох операцій графічного інтерфейсу, а також із-за слабкої функціональності
мови сценаріїв, що не дозволяла описувати достатньо складні алгоритми. У Windows
Server 2003 ситуація була покращена, проте підтримка сценаріїв все ще вважалася
недостатньою.намагалася вирішити деякі з цих недоліків за допомогою Windows
Script Host, що вийшов в 1998 році у складі Windows 98, і утиліт для роботи з
ним з командного рядка cscript.exe. Він інтегрується з Active Script і дозволяє
писати сценарії на сумісних мовах, таких як JScript і VBScript, використовуючи
API, що надається програмами через Component Object Model (COM). Проте у цього
рішення свої недоліки. Windows Script Host не інтегрований з оболонкою,
відсутня вбудована документація, і він швидко одержав репутацію вектора
уразливості після декількох комп'ютерних вірусів, що широко розповсюдилися та
використали уразливості в його моделі безпеки. Різні версії Windows також
надають командні інтерпретатори спеціального призначення (такі як netsh.exe і
WMIC) з своїми власними наборами команд. Вони не інтегровані з командною
оболонкою і не дають можливостей для взаємодії.
У 2003 Microsoft почала розробку нової оболонки, званої Monad
(також відомої як Microsoft Shell або MSH). Monad повинен був стати новою
розширюваною оболонкою командного рядка, зі свіжим дизайном, який дозволяв би
автоматизувати весь спектр адміністративних завдань. Microsoft опублікувала
першу публічну версію бети Monad 17 червня 2005 року. Друга і третя версії були
випущені 11 вересня 2005 і 10 січня 2006 відповідно. 25 квітня 2006 року було
оголошено, що Monad перейменований в Windows PowerShell для позиціонування його
як значної частини їх технологій управління. В цей же час була випущена версія
Release Candidate 1 («кандидат на випуск»). Release Candidate 2 послідував 26
вересня 2006 року. Фінальна версія (Release to Web, RTW) була випущена 14
листопада 2006 року для Windows XP SP2 і Windows 2003. Фінальна версія для
Windows Vista стала доступна тільки 30 січня 2007 року.
Останній CTP випуск Windows PowerShell версії 2.0 був
випущений в грудні 2008 року. Фінальна версія другої версії PowerShell була
випущена у складі систем Windows 7 і Windows Server 2008 R2 одночасно з їх
випуском. Для решти систем (Windows XP, Windows Server 2003, Windows Vista,
Windows 2008), друга версія PowerShell стала доступна у складі комплекту
Windows Management Framework 27 жовтня 2009 року. Окрім Windows PowerShell
другої версії, в цей комплект також входять WinRM версії 2.0 і BITS 4.0
(останній доступний тільки для Windows Vista і Windows 2008; у Windows 7 і
Windows Server 2008 R2 він вбудований).
3.2
Загальні відомості
Команди, що виконуються в Windows PowerShell, можуть бути у
формі командлетів, які є спеціалізованими класами .NET, створеними з метою
надання функціональності в PowerShell у вигляді сценаріїв PowerShell (.PS1) або
є звичайними виконуваними файлами. Якщо команда є виконуваним файлом, то
PowerShell запускає її в окремому процесі; якщо це командлет, то він
виконується усередині процесу PowerShell. PowerShell надає інтерфейс командного
рядка, в якому можна вводити команди і відображати дані, що виводяться ними, в
текстовому вигляді. Цей призначений для користувача інтерфейс, що базується на
стандартному механізмі консолі Windows, надає механізм автозавершення команд,
що настроюється, але не володіє можливістю підсвічування синтаксису, хоча при
бажанні її можна забезпечити. У PowerShell також можна створювати псевдоніми
(англ. alias) для командлетів, які при виклику перетворяться в оригінальні
команди. Крім того, підтримуються позиційні та іменовані параметри для
командлетів. При виконанні командлета робота по прив'язці значень аргументів до
параметрів виконується самим PowerShell, але при виклику зовнішніх виконуваних
файлів аргументи передаються їм для самостійного розбору.
Інше поняття, використовуване в PowerShell, - це конвейєр
(англ. pipeline). Подібно до конвейєрів в UNIX, вони призначені для об'єднання
декількох команд шляхом передачі вихідних даних однієї команди у вхідні дані
другої команди, використовуючи оператор |. Але на відміну від аналога в UNIX,
конвейєр PowerShell є повністю об'єктним, тобто дані між командлетами
передаються у вигляді повноцінних об'єктів відповідних типів, а не як потік
байтів. Коли дані передаються як об'єкти, елементи, що містяться в них,
зберігають свою структуру і типи між командлетами, без необхідності
використання якої або посимвольного розбору даних. Об'єкт також може містити деякі
функції, призначені для роботи з даними. Вони також стають доступними для
одержуючого їх командлета. Виведення останнього командлета в конвейєрі
PowerShell автоматично передає на командлет Write-Host, який створює текстове
представлення об'єктів і даних, що містяться в них, і виводить його на екран.
Оскільки всі об'єкти PowerShell є об'єктами .NET, вони
містять метод .ToString(), що повертає текстове представлення даних об'єкту.
PowerShell використовує цей метод для перетворення об'єкту в текст. Крім того,
він дозволяє вказати правила форматування, так що текстове представлення
об'єктів може бути настроєно. Проте, з метою підтримки сумісності, якщо в
конвейєрі використовується зовнішній виконуваний файл, то він одержує текстовий
потік, що представляє об'єкт, і не інтегрується з системою типів PowerShell.
Розширена система типів (англ. Extended Type System, ETS)
PowerShell базується на системі типів .NET, але реалізує деякі доповнення.
Наприклад, вона дозволяє створювати різні представлення об'єктів, відображаючи
лише деякі з їх властивостей і методів, а також застосовувати спеціальне
форматування і механізми сортування. Ці уявлення прив'язуються до оригінальних
об'єктів за допомогою конфігураційних файлів у форматі XML.
3.3
Командлети
Командлети (англ. cmdlets) - це спеціалізовані команди
PowerShell, які реалізують різну функціональність. Це вбудовані в PowerShell
команди. Командлети іменуються за правилом Дієслово-Іменник, наприклад
Get-ChildItem, завдяки чому їх призначення зрозуміло з назви. Командлети
виводять результати у вигляді об'єктів або їх колекцій. Додатково, командлети
можуть одержувати вхідні дані в такій же формі і, відповідно, використовуватися
як одержувачі в конвейєрі. Хоча PowerShell дозволяє передавати по конвейєру
масиви і інші колекції, командлети завжди обробляють об'єкти по черзі. Для
колекції об'єктів обробник командлета викликається для кожного об'єкту в
колекції по черзі.
Екземпляри об'єктів створюються в PowerShell і запускаються
їм при виклику. Командлети успадковуються від Cmdlet або від PSCmdlet, причому
останній використовується тоді, коли командлету необхідно взаємодіяти з
виконуваною частиною PowerShell (англ. PowerShell runtime). У цих базових
класах обумовлені деякі методи - BeginProcessing(), ProcessRecord() і EndProcessing(),
як мінімум один з яких реалізація командлета повинна перезаписати для надання
своєї функціональності. Кожного разу при запуску командлета ці методи
викликаються PowerShell по черзі. Спочатку викликається BeginProcessing(),
потім, якщо командлету передаються дані по конвейєру, ProcessRecord() для
кожного елементу, і у самому кінці - EndProcessing(). Клас, що реалізовує
Cmdlet, повинен мати один атрибут .NET - CmdletAttribute, в якому указуються
дієслово і іменник, що становить ім'я командлета. Популярні дієслова
(рекомендується використовувати тільки їх) представлені у вигляді переліку.
Реалізації командлетів можуть викликати будь-які доступні
.NET API і можуть бути написані на будь-якій мові .NET. PowerShell також надає
деякі додаткові API, такі як WriteObject(), які необхідні для доступу до
специфічної для PowerShell функціональності, наприклад для виведення
результуючих об'єктів в конвейєр. Командлети можуть використовувати API для
доступу до даних безпосередньо або скористатися інфраструктурою постачальників
PowerShell, які дозволяють звертатися до сховищ даних через унікальні шляхи.
Сховища даних представляються через букви дисків і ієрархічну структуру
усередині них (директорії). Windows PowerShell поставляється з постачальниками
для файлової системи, реєстру Windows, сховища сертифікатів, а також для
псевдонімів команд, змінних і функцій. Інші додатки можуть додавати свої
командлети і постачальників для доступу до своїх сховищ даних.
У PowerShell 2.0 була додана можливість створення командлетів
на самому PowerShell, без використання .NET мов.
3.4
Конвейєр
У PowerShell, як і в оболонках UNIX/Linux, присутній
конвейєр. Цей конвейєр служить для передачі вихідних даних одного командлета у
вхідні дані іншого командлета. Зокрема, користувач може вивести результати
командлета Get-Process в командлет Sort-Object (наприклад, для сортування
процесів по дескрипторах), потім в Where-Object, щоб відфільтрувати процеси,
які, наприклад, займають менше 1 МБ сторінкової пам'яті, і врешті-решт передати
результати в командлет Select-Object, щоб вибрати тільки перші 10 процесів (по
кількості дескрипторів). Концепція конвейєра спочатку використовується в
UNIX-подібних системах, концепція PowerShell відрізняється від даного.
У UNIX-подібних системах виведення однієї команди передається
на наступний етап конвейєра в бінарній формі, тобто являє собою фактично потік
даних. Приклад: dd if=/dev/zero bs=1M count=1M | bzip2 -z9 -c > ex.bz2, де
потік «нулів» блоками по 1 МБ в кількості 1-го мільйона разів (з пристрою
/dev/zero) командою dd (копіювання спеціальних файлів) передається на введення
команди Bzip2, яка їх стискає максимально можливо (з погляду алгоритму
стиснення bzip2, опція -z9) і результуючий потік передає на stdout (опція -с),
який в свою чергу перенаправляється у файл ex.bz2. Результатом виконання таким
щодо короткої команди стане створення архіву, усередині якого буде 1Т потік
нульових байтів. Сам процес створення такого архіву застосовує в даному випадку
2 послідовних конвейєра.
Реалізувати подібну функціональність і гнучкість в Windows
засобами самої Windows довгий час було практично неможливим. Закласти даний
пролом в середовищах Windows і був фактично покликаний PowerShell, що є якоюсь
подібністю UNIX shell.
3.5
Сценарії
включає мову сценаріїв з динамічними типами, на якому можна
реалізовувати складні операції з використанням командлетів. Мова сценаріїв
підтримує змінні, функції, конструкції розгалуження (if-then-else) цикли
(while, do, for і foreach), структуровану обробку помилок і безліч інших
можливостей, включаючи інтеграцію з .NET.
Змінні в PowerShell позначаються префіксом $ перед ім'ям; їм
може бути привласнене будь-яке значення, включаючи виведення командлетів. Хоча
сама мова не строго типізується, всередині змінні зберігаються з їх типами, які
можуть бути базовими типами (англ. primitive types) або об'єктами. Рядки можуть
бути поміщені в одиночні лапки або в подвійні лапки: при використанні подвійних
лапок змінні, що містяться в рядку, будуть замінені їх значеннями. Відповідно
до синтаксису змінних, якщо шлях до файлу поміщений у фігурні дужки з
попереднім знаком долара (тобто $C:\foo.txt), то це буде посиланням на вміст
файлу. Все, що буде призначено такою змінною, буде записано у файл, і навпаки -
при зверненні до її вмісту буде виданий вміст файлу.
До властивостей і методів об'єкту можна звертатися,
використовуючи крапку (.), як в синтаксисі C#. PowerShell надає спеціальні
змінні, такі як $args, що містить масив всіх неіменованих аргументів командного
рядка, переданих функції, або $_, що посилається на поточний об'єкт в конвейєрі
і інших конструкціях. У PowerShell також присутні масиви і асоціативні масиви.
Крім того, PowerShell автоматично обчислює арифметичні вирази, введені в
командному рядку, і розуміє популярні скорочення, такі як GB (ГБ), MB (МБ) і KB
(КБ).
У PowerShell можна створювати власні функції, що приймають
параметри за допомогою ключового слова function. Популярна проблема для
багатьох початківців - те, що функції приймають аргументи, розділені не комами,
а пропусками (як утиліти командного рядка або командлети):
<function> <param1> <param2>: Викликає
функцію з двома аргументами.
Ці аргументи можуть бути прив'язані до параметрів, вказаних в
оголошенні функції. Також до них можна звернутися через масив $args.
<function>(<param1>, <param2>): Викликає
функцію з одним аргументом, який є масивом з двох елементів.дозволяє викликати
будь-які методи .NET, уклавши їх простір імен в квадратні дужки ([]), і потім
використовуючи пару двокрапок (::) для вказівки статичного методу. Наприклад
[System.Console]::WriteLine("PowerShell"). Об'єкти створюються за
допомогою командлету New-Object, додавати до них нові властивості можна
використовуючи командлет Add-Member.
Для обробки помилок PowerShell надає механізм, заснований
.NET. У разі помилки видаються об'єкти, що містять інформацію про помилку
(об'єкт Exception), які перехоплюються ключовим словом trap. Проте поведінка
при виникненні помилок настроюється. Так, можна налаштувати PowerShell, щоб у
разі помилки він мовчки продовжував виконання без перехоплення помилки. У
другій версії PowerShell також була додана конструкція Try Catch Finally.
Сценарії, написані в PowerShell, можна зберігати між сесіями
у файлах .PS1. Потім можна використовувати весь сценарій або індивідуальні
функції з нього. Сценарії і функції використовуються подібно до командлетам,
тобто вони можуть бути командами в конвейєрі, їм можна передавати параметри.
Об'єкти можуть прозоро передаватися між сценаріями, функціями і командлетами в
конвейєрі. Проте виконання сценаріїв PowerShell за умовчанням заборонене, і
його треба включити за допомогою командлету Set-ExecutionPolicy. Сценарії
PowerShell можуть бути підписані цифровим підписом для перевірки їх цілісності.
4.
ДОСЛІДЖЕННЯ ТЕХНОЛОГІЇ COM ТА СТВОРЕННЯ КОНТРОЛЕРІВ АВТОМАТИЗАЦІЇ MS OFFICE
.1
Загальні принципи СОМ-технології
(Component Object Model) - це об'єктна модель компонентів.
Дана технологія є базовою для технологій ActiveX і OLE. Технології OLE і
ActiveX - всього лише надбудови над даною технологією. В якості прикладу можна
навести об'єкт TObject, як базовий об'єкт VCL Delphi. Так само технологія СОМ є
базовою по відношенню до OLE і ActiveX.
Технологія СОМ застосовується при описі API і двійкового
стандарту для зв'язку об'єктів різних мов і середовищ програмування. СОМ надає
модель взаємодії між компонентами і додатками. Технологія СОМ працює з так
званими СОМ-об'єктами. СОМ-об'єкти схожі на звичайні об'єкти візуальної
бібліотеки компонентів Delphi. На відміну від об'єктів VCL Delphi, СОМ-об'єкти
містять властивості, методи і інтерфейси. Звичайний СОМ-об'єкт включає один або
декілька інтерфейсів. Кожний з цих інтерфейсів має власний покажчик.
Технологія СОМ має два явні плюси:
створення СОМ-об'єктів не залежить від мови програмування.
Таким чином, СОМ-об'єкти можуть бути написані на різних мовах;
СОМ-об'єкти можуть бути використані в будь-якому середовищі
програмування під Windows. До числа цих середовищ входять Delphi, Visual C++,
C++Builder, Visual Basic, і багато інших.
Всі СОМ-об'єкти зазвичай містяться у файлах з розширенням DLL
або OCX. Один такий файл може містити як одиночний СОМ-об'єкт, так і декілька
СОМ-об'єктів. Ключовим аспектом технології СОМ є можливість надання зв'язку і
взаємодії між компонентами і додатками, а також реалізація клієнт-серверних
взаємодій за допомогою інтерфейсів. Технологія СОМ реалізується за допомогою
СОМ-бібліотек (до числа яких входять такі файли операційної системи, як
OLE32.DLL іAut32.DLL). СОМ-бібліотеки містять набір стандартних інтерфейсів,
які забезпечують функціональність СОМ-об'єкту, а також невеликий набір функцій
API, що відповідають за створення і управління СОМ-об'єктів. В Delphi
реалізація і підтримка технології СОМ називається каркасом Delphi ActiveX
(Delphi ActiveX framework, DAX). Реалізація DAX описана в модулі Axctris.
4.2
Розвиток СОМ-технологій
Однією з найважливіших задач, які ставила перед собою фірма
Microsoft, коли просувала операційну систему Windows, була задача по
забезпеченню ефективної взаємодії між різними програмами, що працюють в
Windows. Найпершими спробами вирішити цю непросту задачу були буфер обміну,
файли, що розділяються, і технологія динамічного обміну даними (Dynamic Data
Exchange, DDE). Після цього була розроблена технологія зв’язування і
запровадження об'єктів (Object Linking and Embedding, OLE). Перша версія OLE 1
призначалася для створення складних документів. Ця версія була визнана
недосконалою і на зміну їй прийшла версія OLE 2. Нова версія дозволяла вирішити
питання надання один одному різними програмами власних функцій. Дана технологія
активно впроваджувалася до 1996 року, після чого їй на зміну прийшла технологія
ActiveX, яка включає автоматизацію (OLE-автоматизацію), контейнери, управляючі
елементи, Web-технологію і т.д.
4.3.
Склад СОМ-додатку
При створенні СОМ-додатку необхідно забезпечити наступне:
· СОМ-інтерфейс;
· СОМ-сервер;
· СОМ-клієнт.
Розглянемо ці три складові СОМ-додатку.
4.3.1
СОМ - інтерфейс
Клієнти СОМ зв'язуються з об'єктами за допомогою
СОМ-інтерфейсів. Інтерфейси - це групи логічно або семантично зв'язаних
процедур, які забезпечують зв'язок між постачальником послуги (сервером) і його
клієнтом. На рис. 4.1 схематично зображено стандартний СОМ-інтерфейс.
Рис. 4.1 СОМ-інтерфейс
Ключовими аспектами СОМ-інтерфейсів є:
· Одного разу визначені, інтерфейси не можуть бути
змінені. Таким чином, на один інтерфейс можна покласти певний набір функцій.
Додаткова функціональність реалізовується за допомогою додаткових інтерфейсів.
· За взаємною домовленістю, всі імена
інтерфейсів починаються з букви I, наприклад IРersist, IМalloc.
· Кожен інтерфейс гарантовано має свій
унікальний ідентифікатор, який називається глобальним унікальним
ідентифікатором (Globally Unique Identifier, GUID). Унікальні ідентифікатори
інтерфейсів називають ідентифікаторами інтерфейсів (Interface Identifiers,
IIDs). Ці ідентифікатори забезпечують усунення конфліктів імен різних версій
додатку або різних додатків.
· Інтерфеси не залежать від мови
програмування. Для реалізації СОМ-інтерфейсу можна скористатися будь-якою мовою
програмування. Мова програмування повинна підтримувати структуру покажчиків, а
також мати можливість виклику функції за допомогою покажчика явно або неявно.
· Інтерфейси не є самостійними
об'єктами, вони лише забезпечують доступ до об'єктів. Таким чином, клієнти не
можуть безпосередньо звертатися до даних, доступ здійснюється за допомогою
покажчиків інтерфейсів.
· Всі інтерфейси завжди є нащадками
базового інтерфейсу IUnknown.
Базовий СОМ-інтерфейс IUnknown
Базовий інтерфейс IUnknown забезпечує механізм обліку
посилань (лічильник посилань на СОМ-об'єкт). При передачі покажчика на
інтерфейс виконується метод інтерфейсу ІUnknown AddRef. Після закінчення роботи
з інтерфейсом додаток-клієнт викликає метод Release, який зменшує лічильник
посилань.
Під час виклику методу Querylnterface інтерфейсу ІUnknown в
метод передається параметр IID, який має тип TGUID, тобто ідентифікатор
інтерфейсу. Параметр методу out повертає або посилання на інтерфейс, що
запрошувався, або значення NH.
Покажчики СОМ-інтерфейсу
Покажчик інтерфейсу - це 32-бітовий покажчик на екземпляр
об'єкту, який є, у свою чергу, покажчиком на реалізацію кожного методу
інтерфейсу. Реалізація методів доступна через масив покажчиків на ці методи,
який називається vtable. Використання масиву vtable схоже на механізм підтримки
віртуальних функцій в Object Pascal.
Рис. 4.2 Схема роботи покажчика СОМ-інтерфейсу
4.3.2
СОМ-сервери
СОМ-сервер є додатком або бібліотекою, яка надає послуги
додатку-клієнту або бібліотеці. СОМ-сервер містить один або більше
СОМ-об'єктів, де СОМ-об'єкти виступають як набори властивостей, методів і
інтерфейсів.
Клієнти не знають як СОМ-об'єкт виконує свої дії. СОМ-об'єкт
надає свої послуги за допомогою інтерфейсів. Крім того, додатку-клієнту не
потрібно знати, де знаходиться СОМ-об'єкт. Технологія СОМ забезпечує прозорий
доступ незалежно від місцезнаходження СОМ-об'єкту.
Коли клієнт запрошує послугу від СОМ-об'єкту, він передає
СОМ-об'єкту ідентифікатор класу (CLSID). CLSID - всього лише GUID, який
застосовується при зверненні до СОМ-об'єкту. Після передачі CLSID, СОМ-сервер
повинен забезпечити так звану фабрику класу, яка створює екземпляри
СОМ-об'єктів.
СОМ-сервер повинен виконувати наступне:
· реєструвати дані в системному реєстрі Windows для
зв’язування модуля серверу з ідентифікатором класу (CLSID);
· надавати фабрику СОМ-класу, що
створює екземпляри СОМ-об'єктів;
· забезпечувати механізм, який
вивантажує з пам'яті сервери СОМ, які у даний момент часу не надають послуг
клієнтам.
Фабрика класу
СОМ-об’єкти є екземплярами СoСlass. CoСlass - це клас, що
підтримує один або більш інтерфейсів. СОМ-об'єкти можуть надавати тільки ті
послуги, які визначені в інтерфейсах СoСlass. Екземпляри CoСlass створюються за
допомогою спеціального типу об'єкта, який називається фабрика класу.
Фабрика класу - це спеціальний СОМ-об'єкт, який підтримує
інтерфейс IСlassFactory і відповідає за створення екземплярів того класу, з
яким асоційована дана фабрика класу.
Інтерфейс IСlassFactory має два методи:
· Createlnstance, який створює екземпляр СОМ-об’єкта,
асоційованої фабрики класу
· LockServe, який застосовується для
зберігання СОМ-сервера в пам’яті. Якщо параметр метода fLock має значення true,
то лічильник посилань сервера збільшується, в іншому випадку - зменшується.
Коли лічильник досягає значення 0, сервер вивантажується з пам’яті.
Кожного разу, коли послуги СОМ-об'єкта запрошуються клієнтом,
фабрика класу створює і реєструє екземпляр об'єкту для конкретного користувача.
Якщо послуга того ж СОМ-об'єкту запрошує інший клієнт, фабрика класу створює
другий екземпляр об'єкту для обслуговування другого клієнта. СoСlass повинен
мати фабрику класу і ідентифікатор класу CLSID. Використання CLSID для СoClass
має на увазі, що вони можуть бути відкоректовані кожного разу, коли в клас
вводяться нові інтерфейси. Таким чином, на відміну від DLL, нові інтерфейси
можуть змінювати або додавати методи, не впливаючи на старі версії.
Локальні і віддалені сервери
З використанням СОМ клієнт не повинен турбуватися про те, де
розташовується об'єкт, він просто робить виклик інтерфейсу даного об'єкту.
Технологія СОМ забезпечує всі необхідні кроки для того, щоб зробити цей виклик.
Кроки можуть відрізнятися, залежно від місцезнаходження об'єкту. Об'єкт може
знаходитися в тому ж процесі, де і клієнт, в іншому процесі на тому ж
комп'ютері, де розташований клієнт, або на іншому комп'ютері в мережі. Залежно
від цього застосовуються різні типи серверів:
· внутрішній сервер (In-process server);
· локальний сервер (Local server);
· видалений сервер (Remote server).
Внутрішній сервер - це бібліотека DLL, яка запущена в одному
процесі разом з клієнтом. Додаток-клієнт зв'язується з сервером усередині
процесу за допомогою прямих викликів СОМ-інтерфейсу. На рис. 4.3. представлена
схема взаємодії клієнта з внутрішнім сервером.
Рис. 4.3 Схема взаємодії клієнта с внутрішнім сервером
Локальний сервер - це додаток ЕХЕ, який запущено в іншому
процесі, але на одному комп'ютері разом з клієнтом. Наприклад, лист електронної
таблиці Microsoft Excel пов'язаний з документом Microsoft Word. При цьому два
різні додатки працюють на одному комп'ютері. Локальні сервери використовують
СОМ для з'єднання з клієнтом.
Коли клієнт і сервер знаходяться в різних додатках, а також,
коли вони знаходяться на різних комп'ютерах в мережі, СОМ використовує
внутрішній проксі для реалізації процедури видаленого виклику. Проксі
розташовується в одному процесі разом з клієнтом, тому, з погляду клієнта,
виклик інтерфейсів здійснюється так само, як і у разі, коли клієнт і сервер
знаходяться усередині одного процесу. Задача проксі полягає в тому, щоб
перехоплювати виклики клієнта і перенаправляти їх туди, де запущено сервер.
Механізм, який дозволяє клієнту діставати доступ до об'єктів, розташованих в
іншому адресному просторі або на іншому комп'ютері, називається маршалінгом
(marshaling).
Функції маршалінга:
· приймати покажчик інтерфейсу з процесу серверу і
робити покажчик проксі в процесі клієнта доступним;
· передавати аргументи викликів
інтерфейсу таким чином, ніби вони відбулися від клієнта і розміщувати аргументи
в процес видаленого об'єкту.
Для будь-якого виклику інтерфейсу клієнт поміщає аргументи в
стек, викликає необхідну функцію СОМ-об'єкту через покажчик інтерфейсу. Якщо
виклик об'єкту відбувся не усередині процесу, виклик проходить через проксі.
Проксі пакує аргументи в пакет маршалінга і передає структуру, що вийшла,
видаленому об'єкту. Заглушка об'єкту розпаковує пакет маршалінга, вибирає
аргументи із стека і викликає необхідну функцію СОМ-об'єкту.
Таким чином, маршалінг - це процес пакування інформації, а
демаршалінг - процес розпакування інформації.
Тип маршалінга залежить від об'єктної приналежності СОМ.
Об'єкти можуть використовувати стандартний механізм маршалінга, що надається
інтерфейсом IDispatch. Стандартний маршалінг дозволяє встановлювати зв'язок за
допомогою стандартного системного видаленого виклику процедури (Remote
Procedure Call, RFC).
На рис. 4.4 зображена схема, що показує методику взаємодії
клієнта і серверу у разі, коли додатки працюють на одному комп'ютері, але в
різних процесах.
Рис. 4.4 Схема взаємодії клієнта з сервером в різних процесах
на одному комп’ютері
Видалений сервер - це бібліотека DLL або інший додаток,
запущений на іншому комп'ютері. Тобто клієнт і сервер працюють на різних
комп'ютерах в мережі. Видалений сервер використовує розподілені СОМ-інтерфейси
(Distributed COM, DCOM) для зв'язку з клієнтом.
Видалений сервер працює також з допомогою проксі. Відмінність
в роботі між локальним і видаленим сервером полягає в типі межпроцесного
зв'язку, що використовується. У разі локального серверу - це СОМ, а у разі
видаленого серверу - DCOM. Схема взаємодії клієнта і видаленого сервера
показана на рис. 4.5.
Рис. 4.5 Схема взаємодії клієнта з сервером на різних
комп’ютерах
4.3.3
СОМ-клієнти
Дуже важливим при розробці СОМ-додатків є створення додатків,
так називаємих СОМ-клієнтів, що можуть запрошувати інтерфейси об'єктів, щоб
визначити ті послуги, які може надати СОМ-об'єкт.
Типовим СОМ-клієнтом є диспетчер автоматизації (Automation
Controller). Диспетчер автоматизації - це частина додатка, яка «знає» який тип
інформації необхідний йому від різних об'єктів сервера, і вона запрошує дану
інформацію у міру потреби.
4.4
Об'єктна модель MS Excel
Об'єктна модель MS Excel за загальними принципами ідентична
об'єктній моделі MS Word. Ця модель також має ієрархічну структуру, в корені
якої знаходиться об'єкт Application (ExcelApplication), через який
забезпечується доступ до будь-якої колекції або внутрішнього об'єкту додатку MS
Excel або до компонентів відкритих робочих книг. Загальна структура об'єктної
моделі MS Excel представлена на рис. 4.6
Рис. 4.6 Об'єктна модель MS Excel
Як вже сказано, вершиною об'єктної моделі MS Excel є об'єкт
Application, що безпосередньо включає такі об'єкти і колекції, як Selection -
поточний виділений об'єкт, WorkBooks - колекція відкритих робочих книг,
колекції різних елементів управління, діалогових вікон і інші властивості додатку
MS Excel.
Об'єкт Selection має властивості поточного виділеного
об'єкту, тому немає сенсу розглядати тут структуру моделі цього об'єкту. Якщо
виділена комірка, то Selection = Комірка, якщо діаграма, то Selection =
Діаграма.
Коли виділена область комірок, Selection = Колекції стовпців
і рядків. Колекція робочих книг є списком відкритих робочих книг, доступ до
яких здійснюється по індексу. Кожен елемент такої колекції є об'єктом
"робоча книга". Панелі управління, меню, кнопки, діалоги і інші об'єкти,
призначені для управління додатком, зібрані у відповідні колекції елементів
управління.
Основним елементом об'єкту "робоча книга" є
колекція робочих аркушів. Елементом колекції є окремий робочий аркуш, який може
бути звичайним аркушем (у вигляді таблиці) або бути у вигляді діаграми. У
останньому випадку він нічого, окрім діаграми, містити не може. Розглянемо
варіант аркуша у вигляді таблиці (рис. 4.7).
Рис. 4.7 Об'єктна модель листа робочої книги
Основний об'єкт робочого аркуша, з яким доводиться працювати,
- комірка. Комірка як об'єкт сама володіє безліччю властивостей і об'єктів, що
входять в неї. З них найбільш важливими і часто використовуваними є: текст,
шрифт, стиль тексту, межі, заливка. Щоб дістати доступ до них, необхідно
дістати доступ до самої комірки, а потім змінювати її властивості. Комірки
об'єднані у області комірок Range. Властивості області комірок багато в чому
співпадають з властивостями самої комірки, але є і відмінності, що полягають в
завданні координат і розмірів області. Комірки об'єднані в рядки і стовпці.
Об'єднання рядків і стовпців є колекціями, доступ до яких проводиться по
числовому індексу або по буквеному позначенню стовпця. На робочому аркуші
можуть розташовуватися зовнішні об'єкти: малюнки, фрагменти документів Word,
звуки, відеозаписи і інші об'єкти, які об'єднані в колекцію зовнішніх
OLE-об'єктів. Прорисовка або, точніше, відтворення цих об'єктів повністю
виконується зовнішніми програмами, зареєстрованими в системі як OLE-сервери.
Доступ до таких об'єктів проводиться через елементи колекції OLEObjects, а
доступ до їх властивостей можливий тільки через ці OLE-сервери. Застосування
Excel володіє великим набором власних графічних об'єктів, які можна розмістити
на робочому аркуші. Ми можемо використовувати малюнки, написи, геометричні
фігури, діаграми, які звичайно об'єднані в колекції. Наприклад, колекція
ChartObjects містить набір діаграм, які розташовуються на робочому або на
окремому аркуші. Кожна діаграма, у свою чергу, також містить набір об'єктів і
колекцій.
Щоб переконатися в гнучкості, універсальності і великих
можливостях для програмування об'єктів MS Office, розглянемо ще одну колекцію
об'єктів, присутню як в Word, так і в Excel. Це колекція діалогів (діалогових
вікон), які користувач звичайно відкриває натисненням тієї або іншої кнопки або
вибором команди меню. Вона належить об'єкту Application. У об'єктній моделі всі
діалоги представлені у вигляді елементів колекції Dialogs, доступ до яких
забезпечується через числовий індекс. За допомогою параметрів методу Show
елементу колекції відбуваються передача параметрів в діалог і його виконання -
така модель діалогів для додатків Excel (рис. 4.8, а), для додатків Word модель
діалогу дещо відрізняється. Відмінність полягає в тому, що в Word параметри
передаються через властивості об'єкту-елементу колекції (рис. 4.8, б).
У об'єкту Item() разом з типовими властивостями і методами
присутні властиві тільки йому властивості і методи. Наприклад, у діалогу Знайти
і замінити є властивість Find, що визначає текст для пошуку - до запуску
діалогу.
У Excel об'єкт колекції Dialogs дещо відрізняється від
діалогів Word. Розглянемо об'єктну модель колекції діалогів для Ехсel в цілому
(рис. 4.9).
Рис. 4.8 Об’єктні моделі Знайти в Excel (а) и Знайти та
змінити в Word (б)
Рис. 4.9 Об’єктна модель діалогів MS Excel
На цьому рисунку представлена тільки мала частина всіляких
діалогів колекції - показані діалоги, найбільш часто використовувані програмістами
і користувачами. Звичайно в діалог передаються значення, які встановлюють
значення елементів управління, а повертаються значення True або False, залежно
від результату дії користувача.
4.5
Загальні принципи створення контролерів автоматизації MS Office
- це середовище, в якому більшість завдань можна вирішувати
без якого-небудь програмування. Але вся цінність застосувань Office для
розробника полягає в тому, що все, що можна зробити руками, можна зробити
програмним шляхом з використанням засобів VBA (Visual Basic for Application).
Крім того, додатки Office поставляють сервери COM, які надають інтерфейс
доступу до додатку і його об'єктів. Завдяки цьому, розробник в середовищі
Delphi має можливість, створивши контролер автоматизації, управляти сервером.
Насправді додаток розглядається як сукупність об'єктів зі своїми методами,
властивостями, подіями, які забезпечують скелет додатку. Програміст Office є не
творцем додатку, як, наприклад це робиться в Delphi, а він бере участь в
створенні системи документів. Таким чином, ДОКУМЕНТ, а не програма є метою
розробки. Спадкоємство - могутній інструмент побудови нового класу, проте
програмістам відомий ще один спосіб отримання класу - вбудовування. Як і
спадкоємство, вбудовування транзитивне відношення. У об'єктній моделі Office
немає спадкоємства в повному розумінні цього слова, а є тільки вбудовування.
Завжди існує кореневий об'єкт, він завжди називається
Application. Кожний додаток Office має свій власний кореневий об'єкт -
Word.Application, Excel.Application. Не дивлячись на це в об'єкт Application
вбудовується вся решта об'єктів (учасники), які є властивостями головного
об'єкту. У учасників можуть бути свої учасники і так далі.
Як тільки відкривається новий документ, будь то PowerPoint,
Excel, Word, автоматично створюється каркас нового документа, який є набором
бібліотек з класами.
Об'єкти цих класів будуть доступні в даному документі.
Завданням розробника контролера автоматизації є дати доступ до кореневого
об'єкту сервера, побудувати ланцюжок доступу до об'єктів - учасників
(вбудованих об'єктів), правильно передати параметри.
Контролер автоматизації - це програма, яка "уміє"
управляти додатками MS Office і процесом створення документів в середовищі Word
і Excel. Для того, щоб все це працювало коректно, програма-контролер повинна
виконати наступні функції:
· Перевірити, запущений додаток (Word, Excel) чи ні.
· Якщо додаток не запущено, запустити
його.
· Виконати ряд необхідних маніпуляцій
із додатком, документом.
· Закрити документ і додаток.
· Очистити пам'ять.
Використовуючи контролери автоматизації, в додатках,
створених в середовищі Delphi, можна так само просто, як при звичайній роботі з
Word і Excel, створювати документи зі всіма можливими елементами. Таблиці,
написи, текст, діаграми і інші компоненти повноцінних документів з'являться у
такому вигляді, неначе вони створені користувачем.
.6
Принципи створення контролерів автоматизації MS Excel
.6.1
Створення об'єкту Excel.Application, запуск і візуалізація вікна системи
Запуск і візуалізація додатку Excel проводиться аналогічно
запуску і візуалізації додатку Word, з тією лише різницею, що функція
CreateOleObject звертається до об'єкту Excel.Application.
Створений і запущений екземпляр додатку Excel не містить
жодної робочої книги. Всі робочі книги, які в даний момент можуть бути
активними або належати об'єкту Application, є приналежністю колекції WorkBooks,
яка у свою чергу належить кореневому об'єкту. Властивість Count:integer
колекції WorkBooks містить кількість відкритих робочих книг.
Метод Add колекції WorkBooks дозволяє створити нову робочу
книгу. При цьому якщо аргументом методу буде рядок, що вказує на файл шаблона,
то нова книга буде створена на основі цього шаблона. Якщо аргументів немає, то
буде створена звичайна книга в режимі "за умовчанням".
Використання методів колекції WorkBooks дозволяє не тільки
створювати, але і відкривати наявні робочі книги, які зберігаються у файлах.
Для цієї мети призначені методи Open і OpenText. Перший метод відкриває файл
формату XLS, а другий - звичайні текстові файли. Частіше за все
використовується метод Open з одним аргументом - рядком-покажчиком на файл.
Повна специфікація виклику методу Open має наступний
вигляд:(FileName, UpdateLinks, Readonly, Format, Password, WriteResPassword,
IgnoreReadOnlyRecommended, Origin, Delimiter, Editable, Notify, Converter,
AddToMRU);
Обов'язковим є перший аргумент. Для завдання специфічних
режимів відкриття файлу можна використовувати і інші аргументи.
Об'єкти Item(i:integer) містять посилання на всі робочі книги
колекції WorkBooks (i:integer - індекс книги в колекції). Як аргумент при
зверненні до Item може виступати і строкова змінна, що містить ім'я книги.
Властивість Count колекції містить кількість відкритих документів колекції.
Використовуючи ці властивості колекції ми можемо вивести список всіх робочих
книг і взятися до роботи з будь-якою з них.
Одержання списку робочих книг і посилання на обрану робочу
книгу:
TOKBottomDlg2.FormCreate(Sender:
TObject);a_:integer;:=Forml.E.WorkBooks;a_:=l to WorkBooks.count do begin.Items.Add(WorkBooks.Item[a_].name+
;
'+Workbooks.Item[a_].FullName);;;TOKBottomDlg2.ListBoxlClick(Sender:
TObject);.item[ListBoxl.Itemlndex+l].Activate;:=WorkBooks.item[ListBoxl.Itemlndex+l];;
Для активізації робочої книги із списку відкритих
використовується метод Activate об'єкту Item(i:integer), де i - індекс
відкритої робочої книги, а об'єкт Item(i:integer) є посиланням на робочу книгу.
Після того, як робоча книга вибрана, її можна редагувати,
зберегти під колишнім або іншим ім'ям і закрити. Для цього використовуємо
методи Save, SaveAs і Close.
Збереження робочої книги:
TOKBottomDlg2.Button2Click(Sender:
TObject);.Save;;TOKBottomDlg2.Button3Click(Sender: TObject);not
SaveDialogl.Execute then exit;.SaveAs(SaveDialogl.FileName);;
Закриття робочої книги:
TOKBottomDlg2.Button6Click(Sender: TObject);.Close;;
4.6.2
Робота з аркушами робочої книги
Аркуш, комірки якого безпосередньо зберігають інформацію, є
приналежністю книги. В робочій книзі може бути більше одного аркуша. Доступ до
списку аркушів або до будь-якого аркуша робочої книги можна отримати за
допомогою колекції Sheets. Як і будь-яка колекція, вона містить властивість
Count:integer (кількість елементів колекції) і набір об'єктів Item(i:integer) -
власне аркуши, де i - індекс вибраного аркуша (від 1 до Count). Деякі методи
колекції Sheets: Select - виділення всіх аркушів робочої книги, Copy -
копіювання всіх аркушів в нову робочу книгу, PrintPreview - попередній перегляд
друку, Printout - вивід на друк, Add - додавання нового аркушу в робочу книгу.
Розглянемо метод Add докладніше. Його можна використовувати
як без аргументів, так і з аргументами, що визначають місце, куди будуть додані
аркуші (аркуш), їх кількість і тип. Якщо використовувати метод Add так, як
показано в наступному прикладі, то буде додано аркуш перед аркушем Sheet:
TOKBottomDlg3.ButtonlClick(Sender:
TObject);.Add(Before:=Sheet);;
Додавши аркуші або просто відкривши або створивши робочу
книгу, ми можемо отримати список аркушів і доступ до будь-якого аркуша робочої
книги.
Отримання списку аркушів робочої книги:
TOKBottomDlg3.FormCreate(Sender: TObject);a_:integer;a_:=l to
Sheets.count do ListBoxl.Items.Add(Sheets.Item[a_].name);;
Отримання доступу до аркуша робочої книги:
Sheet:variant;TOKBottomDlg3.ListBoxlClick(Sender:
TObject);:=Sheets . item[List.Boxl. ItemІndex+l];;
Для того, щоб перейменувати вибраний робочий аркуш, у
властивість Name записується нове значення імені аркуша, наприклад:
.Name: = 'Новий аркуш';
За допомогою методу Сору об'єкту Sheet можна скопіювати аркуш
і його зміст. Цей метод дозволяє копіювати аркуш і вставляти копію або до, або
після оригіналу - це залежить від значення аргументу методу Сору:
.Copy(before:=Sheet);
або
Sheet.Copy(after:=Sheet);
Після роботи з книгою може знадобитися видалити деякі аркуші.
Для цього призначений метод Delete об'єкту Sheet: Sheet.Delete;
Для доступу до комірок можна використовувати два різні
об'єкти - об'єкт типа Range, який асоціюється з областю комірок, або
безпосередньо об'єкт Cell (комірка аркуша робочої книги). Якщо перший об'єкт
зручний для роботи з цілими областями комірок, то другий більше підходить для
роботи з окремо взятою коміркою. Ці об'єкти належать об'єкту "аркуш"
і вимагають завдання координат комірки або області комірок при зверненні до
них. Наприклад, для завдання об'єкту, асоційованого з областю комірок A1:D5
використовуємо наступний оператор:
:=Sheet.Range[Al:D5];
де Sheet - посилання на аркуш робочої книги. Після вдалого
виконання даного оператора змінна MyRange:variant містить посилання на об'єкт,
асоційований з вибраною областю комірок.
Забезпечити доступ до окремої комірки можна з допомогою як
об'єкту Range, так і об'єкту Cell. Використання останнього в операторі
отримання доступу до комірки може виглядати так:
:=Sheet.Cells[1,1];
При виконанні даного оператора змінна MyCell зберігатиме
посилання на комірку А1.
Запис інформації в комірки аркуша робочої книги:
T0KBottomDlg4.ButtonlClick(Sender: TObject);a_:integer;;a_:=l
to 100 do Sheet.Cells(a_,1):=random(10000);
;
Якщо для запису в комірки об'єкту Cells(row, column)
привласнюється значення, то для зчитування даних використовується оператор, в
якому строковій змінній привласнюється значення об'єкту Cells(row, column).
4.6.3
Робота з комірками
Основа введення і відображення інформації в робочих книгах
Excel - робота з комірками аркуша. Кожна комірка є об'єктом з безліччю
властивостей, необхідних для відображення інформації. Основною властивістю
кожної комірки є її зміст або значення. Але часто буває недостатньо просто
відобразити яке-небудь значення, будь то рядок або число, тому для кращого
сприйняття інформації використовується таке поняття, як спосіб відображення. На
спосіб відображення впливають такі чинники, як формат уявлення, різні способи
розміщення значення щодо меж комірки, шрифт, товщина і колір ліній меж, а також
колір і стиль заливки комірки.
Для доступу до всіх властивостей і вмісту комірок в Excel
використовуються два об'єкти - Range і Cells. Між ними є тільки одна
відмінність - перший об'єкт забезпечує доступ до області комірок, а другий -
тільки до однієї комірки. Для завдання адреси комірок, на які потрібно отримати
посилання, використовуються аргументи цих методів. Для Range аргументом є рядок
адреси, а для Cells - номери рядка і стовпця.
Так, наприклад, для отримання посилання на об'єкт-область можна
використовувати наступний оператор:
: =Е. ActiveSheet. Range [' В2 ' ] ;
Оператор з використанням об'єкту Cells:
:=E.ActiveSheet.Cells[2,2];
Змінна, яку відображає комірка, зберігається у властивостях
Text і Value об'єкту Range (Cells), тому для того, щоб її отримати, достатньо
зчитати значення однієї з цих властивостей. Якщо тип даних (формат) значення
комірки невідомий використовуємо властивість Text, щоб отримати його у вигляді
рядка. Коли тип даних відомий, можна спробувати використовувати властивість
Value.
Висота і ширина комірки
Використовуючи властивості ColumnWidth і RowHeight об'єктів
Range або Cells, можна змінити ширину і висоту комірки. Очевидно, що ці зміни
спричинять зміни ширини стовпця і висоти рядка. Як приклад використання цих
властивостей розглянемо процедури, що дозволяють змінити розміри заданої
комірки:
TOKBottomDlg5.ColumnWidthChange(Sender:
TObject);.Item(col).ColumnWidth:=StrToFloat(ColumnWidth.Text);;TOKBottomDlg5.RowHeightChange(Sender:
TObject);.Item(row).RowHeight:=StrToFloat(RowHeight.Text);;
Вирівнювання тексту в комірці
Значення, що відображається, можна розмістити в комірці Excel
по-різному. Звичайно спосіб розміщення відповідає типу і величині значення
комірки. Для числових даних текст зміщений до правої межі, а для строкових - до
лівої межі комірки, але бувають виключення. Виключення з правил визначаються
вимогами, що припускають ефективне відображення інформації для більш повного її
сприйняття. В таких випадках і використовують властивості комірки, що
дозволяють задати режими горизонтального і вертикального вирівнювання,
встановити режим переносу по словах і вибрати кут повороту тексту.
Розглянемо ці властивості. Наступний програмний код задає
режими горизонтального і вертикального вирівнювання тексту по центру.
Вирівнювання тексту в комірці:
= -4108;=
-4108;TOKBottomDlg8.HorizontalAlignmentChange(Sender:
TObject);.HorizontalAlignment:=xlHAlignCenter;;TOKBottomDlg8.VerticalAlignmentChange(Sender:
TObject);.VerticalAlignment:=xlVAlignCenter;;
Якщо довжина тексту перевершує ширину комірки, то це може
спричинити за собою спотворення відображення значення комірки. Для вирішення
цієї проблеми можна скористатися режимом переносу по словах. Він включається
коли властивість комірки WrapText встановлена в значення True, і відключається,
коли властивість WrapText встановлена в значення False.
Перенос по словах:
procedure TOKBottomDlg8.WrapTextClick(Sender:
TObject);.WrapText:=WrapText.Checked;;
Ще один спосіб зміни розташування тексту в комірці - його
поворот. Поворот тексту, що відображає значення комірки, визначається
властивістю Orientation і може бути заданий величиною від -90 до +90 градусів.
Поворот тексту в комірці:
TOKBottomDlg8.OrientationChange(Sender:
TObject);.Orientation:=Orientat ion.Value;;
Якщо довжина тексту, розміщуваного в комірці, настільки
велика, що він не може бути розміщений там без істотних змін розмірів комірки,
а за конкретних умов задачі розміри рядків і стовпців змінювати не можна, то
слід використовувати режим об'єднання комірок. Об'єднання комірок здійснюється
установкою в значення True властивості MergeCells об'єкту Range, асоційованого
з областю комірок:
T0KBottomDlg9.MergeCellsClick(Sender:
TObject);.MergeCells:=MergeCells.Checked;;
Межі комірки
Комірка є прямокутною областю. Ця область, окрім значень, які
відображаються в ній, має такі властивості, як заливка і межа. Як заливка
осередку, так і межа мають відповідні властивості (колір, товщину, тип, узор,
колір узору). Розглянемо ці властивості докладніше. Межі комірки є лініями, що
обмежують її з чотирьох сторін. Лінії з'єднані в колекцію Borders, доступ до
будь-якої з них здійснюється через елементи цієї колекції. Кожний елемент
колекції надає доступ до відрізка прямій, прилеглому до тієї або іншої сторони
комірки. Діагоналі комірки також є елементами цієї колекції. Кожний елемент
колекції Borders є об'єктом і має свої індивідуальні властивості, що дозволяє
задати тип лінії і колір окремо для кожної лінії межі комірки. Наступні
процедури дозволяють встановити товщину, тип і колір лінії межі вибраної
комірки:
Встановлюємо товщину лінії межі комірки:
TOKBottomDlg6.WeightChange(Sender:
TObject);.Weight:=Weight.Itemlndex;;
Встановлюємо тип лінії межі
комірки:T0KBottomDlg6.LineStyleChange(Sender: TObject);.LineStyle:=xlDouble;;
Встановлюємо колір лінії межі комірки
T0KBottomDlg6.ButtonlClick(Sender: TObject);not
ColorDialogl.Execute then exit;. Color: =ColorDialogl. Color;;
Заливка комірки
Заливка комірки визначається комбінацією наступних складових
- кольору, узору і кольору узору, що заповнює простір комірки. Програмний
доступ до параметрів заливки забезпечує властивість Interior об'єкту Range, де
Range - посилання на комірку або область. Властивість Interior представляє
собою об'єкт, властивості якого пов'язані з візуальними властивостями внутрішнього
простору комірки.
Колір заливки визначається властивістю Color об'єкту Interior
і задається як комбінація трьох кольорів: Color:=RGB(R, G, В); де R, G, В -
числові значення, відповідні червоному, зеленому і синьому кольорам. Колір
заливки можна також задати як вибраний на палітрі кольорів - для цього
використовується властивість ColorІndex об'єкту Interior.
Узор заливки області комірки визначається властивістю
Pattern, а її колір - властивістю PatternColor об'єкту Interior. Колір також
можна вибрати на палітрі кольорів Excel шляхом запису у властивість
PatternColorІndex індексу вибраного кольору.
4.6.4
Пошук і заміна тексту
Пошук тексту виконується шляхом виклику методу Find.
Повна специфікація виклику методу Find:(What, After, Lookln,
LookAt, SearchOrder, SearchDirection, MatchCase, MatchByte);
В найпростішому випадку метод Find повинен містити один
аргумент - шуканий текст. Якщо вимагається уточнити режим пошуку, то
використовуються додаткові необов'язкові аргументи цього методу, які дозволяють
визначити напрям пошуку, область пошуку і інші параметри.
Після успішного пошуку тексту метод Find повертає посилання
на об'єкт-комірку, використовуючи який можна змінити зміст комірки. Повторюючи
пошук і заміну багато разів, можна сформувати необхідний документ, але для
цього є більш ефективний спосіб - використання функції пошуку і заміни. Ця
функція в Excel реалізується методом Replace, який має два обов'язкові
аргументи - шуканий текст і текст для заміни. Повна специфікація методу
Replace:(What, Replacement, LookAt, SearchOrder, MatchCase, MatchByte);
4.6.5
Формули
Формула є математичним виразом, що складається з констант,
адрес комірок, стандартних функцій Excel, призначених для користувача функцій і
математичних символів, записаних у вигляді рядка. Для надання комірці таких
властивостей використовують запис рядка, що представляє формулу, у властивість
Formula об'єкту Range. Для зчитування формули також використовується
властивість Formula.
Можливо також використання майстра функцій, що є
послідовністю діалогових вікон, які дозволяють конструювати формулу для даної
комірки по кроках. Для активізації даного способу необхідно викликати метод
FunctionWizard об'єкту Range:
TOKBottomDlg2.ButtonlOClick(Sender:
TObject);.FunctionWizard;;
Іноді вимагається перевірити, що знаходиться в комірці -
значення, записане користувачем, або сформоване в результаті виконання формули.
Для цього можна аналізувати вміст властивості Formula об'єкту Range, але краще
використовувати властивість HasFormula. Якщо воно має значення True, то комірка
містить формулу, якщо False - то ні.
Перевірка наявності формули в комірці:
procedure TOKBottomDlg2.Button9Click(Sender:
TObject);Range.HasFormulamessagebox(handle, 'Дана комірка містить
формулу!','Увага!',0)messagebox(handle,'Дана комірка не містить
формулу!','Увага!',0);
Визначивши, що потрібна комірка містить формулу, ми можемо
прочитати цю формулу з метою коректування або аналізу її вмісту.
Процедура читання формули може бути такою:
TOKBottomDlg2.Button8Click(Sender: TObject);.Text:=Range.Formula;;
контролер автоматизація програмний захворювання
5.
ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ
.1
Функціональне призначення та технологічні особливості розробки
Метою виконання дипломної роботи є автоматизація збору
статистичних інформації в умовах неврологічного відділення Криворізького
інституту професійних захворювань.
В якості вхідних даних служать файли виписок з історії
хвороби у форматі MS Word, які містять більшість необхідної для статистичних
досліджень інформації і мають схожу структуру базових елементів. Також є список
захворювань і професій, для яких ведеться збір інформації, який формується
лікарем-дослідником та зберігається у базі даних.
Призначення системи - отримання лікарем-дослідником статистичного
ряду згідно обраним показникам, які в подальшому можуть бути передані до
обробки в пакети MS Excel та Statistica.
Інтерфейс системи був створений за допомогою
інструментального засобу прискореної розробки програмного забезпечення Delphi з
використанням пакетів альтернативних компонентів Development Express та
AlphaControls 2010. У зв’язку з великим об’ємом вхідних даних та тривалим часом
їх обробки пошук та збір даних був реалізований за допомогою системи пакетної
обробки PowerShell, що базується на основі технології .NET Framework. При цьому
скрипт сценарію генерується та виконується автоматично на основі умов, заданих
користувачем системи та під управлінням оболонки системи. В розробці також був
використаний безкоштовний конвертор файлів DocConverterX.exe
Вхідна інформація системи - виписки з історії хвороби у
вигляді файлів формату *.doc повинні зберігатися в каталозі doc, в тій же
директорії, де знаходиться виконавчий файл.
5.2
Розробка схеми інформаційних потоків та логіко-функціональної схеми роботи
системи
Рис. 5.1 Схема інформаційних потоків системи
Логіко-функціональна схема роботи системи наведена на рис.
5.2.
Рис. 5.2 Логіко-функціональна схема роботи системи
5.3
Опис інтерфейсу користувача
Після запуску оболонки системи на екрані з’являється наступне
вікно.
Рис. 5.3 Головне вікно оболонки системи
Спочатку користувачеві необхідно визначити список професій та
список захворювань, за якими буде проводитись пошук. Цей список зберігається у
відповідних таблицях баз даних та завантажується при відкритті форми.
У будь який момент рядок зі списку можна видалити (для цього
необхідно клацнути по ньому правою клавішею мишки та обрати пункт „Удалить”).
Також можна додати необхідне захворювання чи професію до переліку. Для цього
треба ввести назву у відповідному текстовому полі та натиснути кнопку „ОК”.
Якщо текст не буде введений на екрані з’явиться наступне
попередження.
Рис. 5.4 Попередження системи про некоректний ввод
Після формування вхідних даних необхідно нажати кнопку
„Преобразовать файлы в текстовый формат”. При цьому буде створений та
автоматично виконаний командний файл, який переконвертує файли формату *.doc до
формату *.txt. В нижній частині робочого вікна буде відображений статус роботи
системи, тобто кількість перетворюваних файлів та очікуваний час обробки.
Рис. 5.5 Відображення статусу системи - триває конвертація
файлів у текстовий формат
Оскільки оброблювані файли схожі за структурою та об’ємом, на
основі статистичних досліджень був зроблений висновок, що у середньому
конвертація файлу триває 0,25 с.
Це дозволило візуалізувати процес обробки файлів за допомогою
відповідних елементів інтерфейсу користувача. Після закінчення конвертації
файлів система виводить на екран відповідне повідомлення (рис. 5.6).
Рис. 5.6 Відображення статусу системи - конвертація файлів у
текстовий формат завершена
Після конвертації файлів в текстовий формат відбувається
наступний етап - формування та запуск скрипта PowerShell. Для цього необхідно
натиснути кнопку „Запустить скрипт”. Аналогічним чином (рис. 5.7 та 5.8) система
відображує статус виконання роботи. За статистичними даними обробка файлу
триває біля 0,77 с.
Рис. 5.7 Відображення статусу системи - пошук та обробка
даних за допомогою скрипта PowerShell
Після закінчення обробки система видає відповідне
повідомлення.
Рис. 5.8 Відображення статусу системи - обробка файлів
завершена
Після закінчення обробки за допомогою скрипту PowerShell буде
сформований файл statOut.csv, який містить всю необхідну інформацію.
Але проглядання, пошук та фільтрація даних у цьому форматі
має деякі незручності. Тому після формування вихідного фалу скрипта вся
необхідна інформація заноситься до бази даних. Для цього ми нажимаємо кнопку
„Сформировать базу данных на основе выходного файла” у головному вікні системи.
Система також дозволяє виключити із набору, що буде
відображений у вікні системи деякі групи полів. Інформація залишається в базі
даних, але не буде доки відображуватися для користувача. Ця можливість реалізована
для того, щоб, по перше зменшити „інформаційний шум” та зосередитись на
необхідній інформації, по друге - навіть використовуючи засоби PowerShell, час
обробки інформації є достатньо великим, у зв’язку з великим накопиченим об’ємом
даних. Тому в наступному вікні (рис. 5.9) користувач системи в змозі обрати
групи полів, що будуть відображені у вікні результатів пошуку.
Рис. 5.9 Вибір груп полів, що будуть відображені у вікні
результатів пошуку
Нарешті, після здійснення всіх операцій, ми можемо побачити
вікно із зібраними статистичними даними (рис. 5.10). Як вже було зазначено
вище, інтерфейс системи був спроектований за допомогою пакету альтернативних
компонентів Development Express. Використання компонентів Development Express
дозволило автоматизувати процес сортування та фільтрації даних в головній
таблиці. Після отримання необхідного набору, дані можна експортувати в MS
Excel, натиснувши відповідну кнопку.
Рис. 5.10 Вікно відображення результатів пошуку, фільтрації
та експорту статистичних даних
5.4
Програмна реалізація системи
.4.1
Реалізація інтерфейсної оболонки засобами Delphi
При роботі системи використовується файл бази даних формату
mdb, який містить три не пов’язані між собою таблиці. Розглянемо структуру
полів цих таблиць.
Перша таблиця - довідник професій - призначена для зберігання
інформації про професії, стосовно яких ведеться пошук.
Рис. 5.11 Структура полів таблиці - довідника професій
Аналогічну структуру має таблиця - довідник захворювань.
Рис. 5.12 Структура полів таблиці - довідника професій
Кожна з таблиць має спеціальне поле-ознаку, тобто назва
професії або захворювання може бути присутньою в базі даних, але пошук по цим
назвам здійснюватися не будить.
Третя таблиця призначена для зчитування інформації з
вихідного файлу statOut.csv та проміжного зберігання інформації. Розглянемо
призначення полів цієї таблиці більш детально.
Рис. 5.13 Структура полів таблиці для проміжного зберігання
інформації
Наступна подія відбувається при створенні головної форми
системи
Tmain.FormCreate(Sender:
TObject);f:TSearchRec;:=extractfilepath(Application.ExeName); // визначення
повного шляху
до виконавчого файлу системи;
При появі головної форми системи зчитуємо з таблиць бази
інформацію про те, для яких професій та захворювань вестиметься пошук и
формуємо відповідні списки. Також зчитуємо інформацію із ini-файлу про те, які
категорії полів нам потрібно експортувати в MS Excel.
Tmain.FormShow(Sender: TObject);j:integer;:=
TIniFile.Create(ExtractFilePath(ParamStr(0)) + 'my.ini'); // створення
об'єкту - ini-файлуj:=0 to
customize.sCheckListBox1.Items.Count-1 do // перебираємо в
циклі усі категорії полів, що знаходяться у
списку.sCheckListBox1.Checked[j]:=ini.ReadBool('pole','p'+inttostr(j),tr) ; //
зчитуємо інформацію з ini-файлу і, якщо поле активне,
встановлюємо наптроти його назви прапорець.Free; // знищуємо
об’єкт ini-файл.First; // перехід на перший запис таблиці - довідника
професій.Clear; // очищаємо список професійnot ADOTable1.Eof
do // перебираємо усі записи.Items.Add(ADOTable1prof.AsString); // додаємо
назву
професії в
список.Checked[ADOTable1.RecNo-1]:=checked.AsBoolean; // встановлюємо ознаку,
чи вестиметься
пошук для цієї професії.Next // перехід до наступного запису;
.First; // перехід на перший запис таблиці - довідника
захворювань.Clear; // очищаємо список захворюваньnot
ADOTable2.Eof do // перебираємо усі
записи.Items.Add(ADOTable2zabolevanie.AsString); // додаємо
назву захворювання в список.Checked[ADOTable2.RecNo-1]:=checked.AsBoolean;
// встановлюємо ознаку, чи вестиметься
пошук для цього захворювання.Next // перехід до наступного
запису;;
Розглянемо процедуру зберігання інформації в ini-файлі
Tcustomize.sButton1Click(Sender: TObject);j:integer;:=
TIniFile.Create(ExtractFilePath(ParamStr(0)) + 'my.ini'); // створення
об'єкту - ini-файлуj:=0 to sCheckListBox1.Items.Count-1 do //
перебираємо в циклі усі
елементи
списку.writebool('pole','p'+inttostr(j),sCheckListBox1.Checked[j]); // якщо
прапорець встановлений, записуємо відповідне значення в
ini-файл.Free; // знищуємо об’єкт ini-файл;
Додавання професій або захворювань в базу даних здійснюється
за допомогою наступних процедур.
Tmain.sButton1Click(Sender: TObject);sEdit1.Text='' then // якщо
поле назви професії пусте('Вы не ввели профессию');// завершення
процедури;.Insert; // додаємо запис в таблицю бази
данихprof.AsString:=sEdit1.Text; // заносимо введену інформацію
у відповідне поле.Post;.FormShow(Sender); // оновлення
списку;Tmain.sButton2Click(Sender: TObject);sEdit2.Text='' then // якщо поле
назви захворювання пусте('Вы не ввели болезнь!');// завершення
процедури;.Insert; // додаємо запис в таблицю бази
данихzabolevanie.AsString:=sEdit2.Text; // заносимо введену
інформацію у відповідне поле.Post;.FormShow(Sender); //
оновлення списку;
За допомогою наступних процедур здійснюється видалення
інформації.
Tmain.N1Click(Sender:
TObject);.Locate('prof',sCheckListBox1.Items[sCheckListBox1.ItemInde],[]); //
пошук в таблиці бази даних обраної в списку професії.Delete;// видалення
рядку.FormShow(Sender); // оновлення списку;
Tmain.MenuItem1Click(Sender:
TObject);.Locate('zabolevanie',sCheckListBox2.[sCheckListBox2.ItemIndex],[]);
// пошук в таблиці бази даних
обраного в списку захворювання.Delete; // видалення
рядку.FormShow(Sender); // оновлення списку;
Розглянемо процедуру перетворення вхідної інформації у
тестовий формат.
Tmain.sBitBtn1Click(Sender: TObject);:TSearchRec;.Clear; //
очищаємо компонент.Lines.Add('del '+path+'\doc\*.txt');// формуємо команду -
видалити усі текстові файли в заданому
каталозі_path:=path+'\delete_txt.bat'; // формуємо повний шлях до bat-файлу
(він з’явиться в тому ж каталозі, де і розташований
виконавчий файл
системи.Lines.SaveToFile(bat_path);// зберігаємо текст
команди в
зовнішньому bat-файлі(Handle, nil, PChar(bat_path), nil, nil,
SW_HIDE); //
виконуємо створений bat-файлFindFirst(path+'\doc\*.doc',
faAnyFile, f)<>0 then // проводимо
перевірку, чи присутні файли формату doc в робочому
каталозі('Исходных файлов в папке нет!');; // завершення роботи
процедури;_path:=path+'\conv.bat'; // формуємо повний шлях до командного
файлу, за допомогою якого будемо проводити конвертацію файлів
у
формат txt.Clear;.Lines.Add(path+'DocConverterX.exe
'+path+'doc\*.doc '+path+'doc\
cTXT'); // формуємо команду, де вказаний повний шлях до
зовнішнього конвертору та папки, де зберігаються
файли.Lines.SaveToFile(bat_path); // створюємо командний файл(Handle, nil,
PChar(bat_path), nil, nil, SW_HIDE); //
запускаємо файл на виконання.Caption:='Идет преобразование
данных в текстовый формат';.Visible:=true;.Visible:=true;:=0;// в цьому циклі
ми підраховуємо загальну кількість фалів, що
будуть конвертовані у текстовий формат:=ii+1;FindNext(f)
<> 0;(f);.Caption:='Количество файлов -'+inttostr(ii); // виводимо
кількість файлів з вхідною інформацією.Max:= ii div 4; //
вважаємо, що конвертація одного файлу
триває в середньому 0,25
с.Position:=0;.Visible:=true;.Caption:='Ориентрировочное время обработки -
'+inttostr(ii div
)+' c'; // виводимо орієнтований час обробки
даних.Enabled:=true; // запускаємо таймер, за допомогою якого буде
візуалізований час обробки даних;
Розглянемо процедуру, за допомогою якої можна визначити, чи
закінчилася конвертація файлів у текстовий формат.
Tmain.Timer1Timer(Sender: TObject);Wnd: hWnd;: array[0..127]
of Char;:=false;:= GetWindow(Handle, gw_HWndFirst);Wnd <> 0 do begin //
перебираємо усі процеси, що запущені в
системі, не враховуючи:(Wnd <> Application.Handle) and
// власне вікно системи
(GetWindow(Wnd, gw_Owner) = 0) and // дочірні вікна
(GetWindowText(Wnd, buff, sizeof(buff)) <> 0) // вікна
без заголовківbegin(Wnd, buff, sizeof(buff)); // отримуємо назву
процесуStrPas(buff)= 'Total Doc ConverterX' then flag:=true; // ознака того, що
конвертація ще не завершена - процес з назвою 'Total Doc
ConverterX'
запущений;:= GetWindow(Wnd,
gw_hWndNext);;.Position:=sProgressBar1.Position+1; // збільшуємо позицію
візуального елементу, що відображає процес виконанняnot flag
then // якщо процес закінчено.Enabled:=false; // зупиняємо
таймер.Caption:='Преобразование в текстовый формат закончено!'; //
виводимо відповідне повідомлення на екран;;
Схожим чином відбувається процедура запуску на виконання
сформованого скрипту PowerShell.
Tmain.sBitBtn2Click(Sender: TObject);:TSearchRec;FindFirst(path+'\doc\*.txt',
faAnyFile, f)<>0 then // визначаємо, чи є в
робочому каталозі текстові файли('Файлы для обработки данных
не найдены!');; // завершення роботи процедури;_path:=path+'\shell.bat'; //
визначаємо шлях до командного файлу.Clear;.Lines.Add('D:\WINDOWS\system32\WindowsPowerShell\v1.0\po.exe
'+path+'script.ps1'); // формуємо текст команди - повний
шлях до утиліти powershell.exe та шлях до виконуємого
скрипта.Lines.SaveToFile(bat_path); // створюємо командний файл(Handle, nil,
PChar(bat_path), nil, nil, SW_HIDE);//
запускаємо командний файл на виконання.Caption:='Идет сбор и
обработка данных';.Visible:=true;.Visible:=true;:=0;// в циклі визначаємо
кількість файлів, що будуть оброблені:=ii+1;FindNext(f) <> 0;(f);.Caption:='Количество
файлов -'+inttostr(ii); // виводимо
кількість файлів на екран.Position:=0;.Max:= round(ii *0.71);
// вважаємо, що середній час
обробки одного файлу - 0,71
с.Visible:=true;.Caption:='Ориентрировочное время обработки -
'+inttostr(round(ii *0.71))+' c'; // виводимо орієнтований
час обробки
файлів.Enabled:=true; // запускаємо таймер;
За допомогою наступної процедури можна визначити, чи
закінчена обробка файлів та візуалізувати процес виконання.
Tmain.Timer2Timer(Sender: TObject);Wnd: hWnd;: array[0..127]
of Char;a:=a+1;:=false;:= GetWindow(Handle, gw_HWndFirst);Wnd <> 0 do
begin // перебираємо в циклі всі процеси, що
запущені в системі, не враховуючи:(Wnd <>
Application.Handle) and // власне вікно системи
(GetWindow(Wnd, gw_Owner) = 0) and // дочірні вікна
(GetWindowText(Wnd, buff, sizeof(buff)) <> 0) // вікна
без заголовківbegin(Wnd, buff, sizeof(buff)); // отримуємо назву
процесуStrPas(buff)= 'Администратор: D:\WINDOWS\system32\cmd.exe' then :=true;
// якщо запущений процес cmd.exe, тоді bat-файл ще
виконується;:= GetWindow(Wnd,
gw_hWndNext);;.Position:=sProgressBar1.Position+1; // збільшуємо позицію
візуального елементу, що відображає процес виконанняnot flag
then // якщо процес закінчено.Enabled:=false; // зупиняємо таймер.Caption:='Обработка
данных завершена!';;;
Далі наведений текст процедури зчитування інформації з файлу,
сформованого засобами PowerShell в базу даних.
Tmain.sBitBtn4Click(Sender:
TObject);j:integer;:=CreateOleObject('excel.application'); // створюємо об’єкт
MS Excel_book:=e.workbooks.add(path+'statOut.csv'); // посилання на файл з
вихідною інформацією_sheet:=w_book.sheets.item[1]; //
посилання на лист в цьому файлі:=2; // номер рядкуnot ADOTable3.Eof do //
очищуємо таблицю.Delete;j<ii do // перебираємо усі рядки у вихідній таблиці
- їх кількість
відповідає кількості оброблених файлів.Insert; // додаємо
запис в таблицюgod_r.AsInteger:=m_sheet.cells[j,2]; // заносимо значення у
відповідні поляstag.AsInteger:=m_sheet.cells[j,3];
...kr_m.AsFloat:= m_sheet.cells[j,30];.Post;:=j+1; // перехід
на наступний рядок;.quit; // вивантажуємо MS Excel з пам’яті_form.ShowModal //
вивід на екран форми із зібраною інформацією;
Розглянемо процедуру зібраної інформації в базу даних та
процес її відображення користувачеві.
Tbaza_form.FormShow(Sender:
TObject);i,j,m:integer;,st:string;j:=0;:='select '; // текстова змінна, в якій
буде сформований SQL-запитi:=0 to customize.sCheckListBox1.Items.Count-1 do //
перебираємо
список полів, що доступні для відображенняi of // номер поля
: if customize.sCheckListBox1.Checked[i] // якщо поле
доступне для
відображення, в даному випадку - рік народженняbegin:=j+1; //
кількість стовпців в сітці, що відображується на
екрані[j]:=customize.sCheckListBox1.Items[i]; // назва стовпчику[j]:='god_r,'
// поле, яке з цим стовпчиком буде пов’язане;
: if customize.sCheckListBox1.Checked[i] then // аналогічним
чином
перевіряємо, чи буде відображений стовпець „загальний
стаж”j:=j+1;[j]:=customize.sCheckListBox1.Items[i];pole[j]:='stag,';
: if customize.sCheckListBox1.Checked[i] then // ця група
відповідає за
стаж роботи по обраній спеціальності.ADOTable1.First;
z:=0;not main.ADOTable1.Eof do // перебираємо усі записи таблиці -
довідника спеціальностейmain.ADOTable1checked.AsBoolean then //
якщо професія включена у
парамети пошукуj:=j+1;[j]:=main.ADOTable1prof.AsString; //
назва стовпця сітки, що буде
відображена - це назва
професії:=z+1;[j]:='p'+inttostr(z)+','; // в цьому масиві ми формуємо назви
полей,
що відповідають стажу по названій професії;.ADOTable1.Next;;;
: if customize.sCheckListBox1.Checked[i] then // аналогічним
чином
формуємо таблицю по заданим захворюванням (якщо захворювання
присутнє - ознака цього, поле дорівнює одиниці, інакше -
нулю.ADOTable2.First; z:=0;not main.ADOTable2.Eof
domain.ADOTable2checked.AsBoolean thenj:=j+1;
nazva[j]:=main.ADOTable2zabolevanie.AsString ;
z:=z+1;[j]:='b'+IntToStr(z)+',';;.ADOTable2.Next;;;
: if customize.sCheckListBox1.Checked[i] then // поле, яке
відповідає за
ознаку того, що захворювання є професійнимj:=j+1;
nazva[j]:='Проф.з-е'; pole[j]:='prizn_prof,' end;
: if customize.sCheckListBox1.Checked[i] then begin // ця
група полів
відповідає аналізам крові
:=j+1; nazva[j]:='Кровь НВ'; pole[j]:= 'kr_nv,';:=j+1;
nazva[j]:='Кровь ЕР'; pole[j]:= 'kr_er,';:=j+1; nazva[j]:='Кровь КП'; pole[j]:=
'kr_kp,';:=j+1; nazva[j]:='Кровь лейк'; pole[j]:= 'kr_le,';:=j+1;
nazva[j]:='Кровь ШОЕ'; pole[j]:= 'kr_sh,';:=j+1; nazva[j]:='Кровь П'; pole[j]:=
'kr_p,';:=j+1; nazva[j]:='Кровь С'; pole[j]:= 'kr_c,';:=j+1;nazva[j]:='Кровь
Е'; pole[j]:= 'kr_e,';:=j+1; nazva[j]:='Кровь Л'; pole[j]:= 'kr_l,';:=j+1;
nazva[j]:='Кров М'; pole[j]:= 'kr_m';;;;
.SQL.Clear;i:=1 to j do // формуємо в циклі SQL-запит,
додаючи ім’я полів:=s+pole[i];:=s+' from baza';.SQL.Add(s);.Open; // виконуємо
сформований SQL-запитi:=1 to j-1 do // видаляємо знак коми між назвами
полів:=pole[i]; delete(st,length(st),1);[i]:=st;;:='';:=0;m:=1 to j
do[i]:=_view.CreateColumn;[i].DataBinding.FieldName:=
pole[i];[i].Caption:=nazva[i]; // формуємо заголовки[i].Width:=75; // ширина
поля:=z+25;[1].Left:=z;;;
5.4.2
Здійснення пошуку та збору інформації засобами системи пакетної обробки
PowerShell
Розглянемо текст скрипту PowerShell, за допомогою якого
здійснюється пошук необхідної інформації. Скрипт являє собою звичайний
текстовий файл script.ps1 та повинен зберігатися в тому ж каталозі, що і
виконавчий файл системи.
Засобами оболонки, розробленої засобами Delphi, ми можемо
змінювати деякі фрагменти цього скрипту згідно даних, що отримано від
користувача системи.
$myWatcher = New-Object System.Diagnostics.Stopwatch
Шлях до пошуку вхідних даних
$myWorkingPath = "D:\stat\doc\"
Шлях до результативного файлу
$myOutputPath = "D:\stat\statOut.csv"
$myOutputEntry = @{}
Визначаємо ім’я полів вихідної таблиці
$myCSVOutput = "Імя файла;Рік н;Стаж;" +
Наступна стрічка може бути змінена засобами Delphi. Тут ми
визначаємо перелік професій, які цікавлять лікаря.
"Прохідник;ГРОВ;Кріпильник;Ел.слюсар;Слюсар;Бурильник;МГВМ;
Вибухівник;"
+
Аналогічним чином визначаємо перелік захворювань. Всі інші
поля, включаючи аналізи крові є фіксованими
"Радикулопатія;Вібраційна хвороба;Люмбоішіалгія;" +
"ЛЕК;Професійне захворювання;Діагноз;Суп д-з;" +
"Профмаршрут;" +
"Кров Нв;Кров ер;Кров кп;Кров лейк;Кров ШОЕ;Кров п;Кров
с;Кров
е;Кров л;Кров м;Кров РМП;"Content -Path $myOutputPath
-Value $myCSVOutput
Початок роботи скрипту
$myWatcher.Start()
Фільтрація - тільки текстові файли
$myAllFiles = Get-ChildItem -Path $myWorkingPath -Filter
*.txt -Recurse
Name
Підрахунок кількості файлів
$myAllFilesCount = $myAllFiles.Count
Початок циклу
$myAllFiles | ForEach-Object -Process {
Підраховуємо кількість оброблених файлів
$i++
$myTempContent = Get-Content -Path ( $myWorkingPath + $_ )
Взагалі алгоритм пошуку можна описати таким чином. Спочатку
здійснюється перевірка чи було рішення ВКК і вибірка останньої зустрінутої в
тексті згадки.
Якщо немає рішення ВКК те виконується пошук останнього
діагнозу. Перевіряється чи є в діагнозі, знайденому вище, згадка про
профзахворювання, береться перше входження. Якщо діагнозу немає, то
перевіряється наявність згадки про профзахворювання.
Якщо є рішення ВКК, то пошук ведеться тільки нижче за цю
згадку. Береться тільки перший згаданий діагноз і перше входження
профзахворювання якщо такі записи є.
Пошук рішення ВКК.
$myOutputEntry["lek"] = $myTempContent |
Select-String
"^\s*\t*РІШЕННЯ ЛЕК" -CaseSensitive | Select-Object
-Last 1( !$myOutputEntry.lek ) {
[Int32]$lek = 0
$myOutputEntry["diagnosis"] = $myTempContent |
Select-String
"ДІАГНОЗ:" -CaseSensitive | Select-Object -Last 1(
$myOutputEntry["diagnosis"] ) {
Визначення, чи є захворювання професійним
$profzah = $myTempContent | Select-Object -Skip $(
$myOutputEntry["diagnosis"].LineNumber - 1 ) |
Select-String "[Зз]ахв[а-я.
]*проф" -CaseSensitive | Select-Object -First 1
} else {
$profzah = $myTempContent | Select-String "[Зз]ахв[а-я.
]*проф" -| Select-Object -First 1
}( $profzah ) { $myOutputEntry["profzah"] = 1 }
else {
$myOutputEntry["profzah"] = 0 }
} else {
[Int32]$lek = $myOutputEntry.lek.LineNumber
Якщо немає рішення ВКК
$myOutputEntry["diagnosis"] = $myTempContent |
Select-Object -Skip
$lek | Select-String "ДІАГНОЗ:" -CaseSensitive |
Select-Object -First 1($myOutputEntry["diagnosis"]) { $tmpstrdiag =
$myOutputEntry["diagnosis"].toString() }
$profzah = $myTempContent | Select-Object -Skip $lek |
Select-String
"[Зз]ахв[а-я. ]*проф" -CaseSensitive |
Select-Object -First 1
Пошук згадки про діагноз у супутних діагнозах
( $profzah ) { $myOutputEntry["profzah"] = 1 } else
{
$myOutputEntry["profzah"] = 0 }( $profzah -and
$myOutputEntry["diagnosis"] ) {( ($profzah.LineNumber + $lek) -gt
($myOutputEntry["diagnosis"].LineNumber + $lek) ) {
[String]$tmpstrdiag += $myTempContent | Select-Object `
Skip $( $myOutputEntry["diagnosis"].LineNumber +
$lek ) `
First $( $profzah.LineNumber -
$myOutputEntry["diagnosis"].LineNumber
)
$myOutputEntry["diagnosis"] = $tmpstrdiag
}
}
$lek = 1
}
Пошук у супутних діагнозах
$myOutputEntry["supdiagnos"] = $myTempContent |
Select-String "Суп\.
д-з:" -CaseSensitive | Select-Object -Last 1
$myOutputEntry["analysis"] = $myTempContent |
Select-String "КРОВІ:" -| Select-Object -First 1
Встановлюємо дату народження
$myOutputEntry["birthday"] = $myTempContent |
Select-String "Дата
народ" -CaseSensitive | Select-Object -First 1
Загальний підземний стаж
$myOutputEntry["workyears"] = $myTempContent |
Select-String
"[вВуУ]сього[ ]+[0-9]{1,2}[ ]+[рР][оі]к"
-CaseSensitive | Select-Object -1
Пошук стажу по обраним професіям в розділі „Профмаршрут”
$myStartLine = $myTempContent | Select-String
"ПРОФМАРШРУТ" -| Select-Object -Property LineNumber -First 1
[Int32]$myStartLineIndex = $myStartLine.LineNumber
$myFinishLine = $myTempContent | Select-String
"ЄКТИВНО" -| Select-Object -Property LineNumber -First 1
[Int32]$myFinishLineIndex = $myFinishLine.LineNumber(
($myStartLineIndex -gt 0) -and ($myFinishLineIndex -gt 0) -and
($myFinishLineIndex -gt $myStartLineIndex) ) {
$myOutputEntry["profmarsh"] = $myTempContent |
Select-Object -Skip $(
$myStartLineIndex - 1 ) -First $( $myFinishLineIndex -
$myStartLineIndex
)
}
Далі відбувається заповнення визначених полів (кількості
років, яку було відпрацьовано за даною професією. Цей код також змінюється за
допомогою Delphi.
[Int32]$myOutputEntry["prohid"] =
[Int32]$myOutputEntry["grov"] =
[Int32]$myOutputEntry["krip"] =
[Int32]$myOutputEntry["eslsr"] =
[Int32]$myOutputEntry["slsr"] =
[Int32]$myOutputEntry["buryl"] =
[Int32]$myOutputEntry["mgvm"] =
[Int32]$myOutputEntry["vybuh"] = 0
$profession = $myTempContent | Select-String
"[пП]рохідник" -| Measure-Object | Select-Object -Property count
$myOutputEntry["prohid"] = $profession.count
...
Аналогічним чином підрахуємо стаж роботи за іншими професіями
...
$profession = $myTempContent | Select-String
"[вВ]ибухівник" -| Measure-Object | Select-Object -Property count
$myOutputEntry["vybuh"] = $profession.count
Встановлюємо ознаку, що відповідний діагноз знайдено
$diagnosis = $myOutputEntry["diagnosis"] -match
"[рР]ад[іи]кулопат[иі]я"
[Int32]$myOutputEntry["radykul"] = if (
$Matches.Count -ne 0 ) { 1 } else {
}
$Matches.Clear()
$diagnosis = $myOutputEntry["diagnosis"] -match
"[вВ]ібраційна
хвороба"
[Int32]$myOutputEntry["vb"] = if ( $Matches.Count
-ne 0 ) { 1 } else { 0 }
$Matches.Clear()
$diagnosis = $myOutputEntry["diagnosis"] -match
"[лЛ]юмбоішіалгія"
[Int32]$myOutputEntry["lmb"] = if ( $Matches.Count
-ne 0 ) { 1 } else { 0 }
$Matches.Clear()
Далі заповнюємо поля з аналізами крові, що є в документі
$myOutputEntry.analysis -match "[Нн]в-([0-9]{1,3})"
| Out-Null
$myOutputEntry["an_nv"] = $Matches[1] # Кровь Нв
$Matches.Clear()
Для кожного з аналізу використовуємо окреме поле
$myOutputEntry.analysis -match
"ер-([0-9]{1,3},[0-9]{1,3})" | Out-Null
$myOutputEntry["an_er"] = $Matches[1] #-replace
",","." # Кровь ер
$Matches.Clear()
Взагалі в системі передбачено пошук 10 різних аналізів
$myOutputEntry.analysis -match "\sкп-([0-9]{1,3},[0-9]{1,3})"
| Out-Null
$myOutputEntry["an_kp"] = $Matches[1] #-replace
",","." # Кровь кп
$Matches.Clear()
...
Частина аналогічна наведеному вище
...
$myOutputEntry.analysis -match "\sм-([0-9]{1,3})" |
Out-Null
$myOutputEntry["an_m"] = $Matches[1] # Кровь м
$Matches.Clear()
Далі нам залишається записати здобуті дані у вихідний файл
$myTempCSV = ( $_ -replace
"^[0-9]{4}\\","" -replace "\.txt$","" )
+
";" + $myOutputEntry["age"] +
";" + $myOutputEntry["workyears"] +
...
Далі йдуть ім’я полів таблиці
...
";" + $myOutputEntry["an_l"] +
";" + $myOutputEntry["an_m"] +
$myOutputEntry.Clear()Content -Path $myOutputPath -Value
$myTempCSV
}
Begin { $i = 0; Clear-Host }
Закінчення роботи скрипту
$myWatcher.Stop()
6.
ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ
Важливим фактором, що впливає на процес формування ціни, є
конкуренція на ринку, необхідність брати до уваги яку є очевидною. З метою
підвищення конкурентоспроможності продукту може виникнути необхідність зниження
його ціни на ринку. Важливо відмітити, що цілям підвищення
конкурентоспроможності служить не тільки зниження ціни, але, також, і якість
товару і його вигідні ознаки в порівнянні з аналогічним товаром конкурентів.
Найбільш важливим моментом для розроблювача, з економічної
точки зору, є процес формування ціни. Програмні продукти являють собою досить
специфічний товар з безліччю властивих їм особливостей. Багато їхніх
особливостей проявляються й у методах розрахунків ціни на них. На розробку
програмного продукту середньої складності звичайно потрібні досить незначні
засоби. Однак, при цьому вона може дати економічний ефект, що значно перевищує
ефект від використання досить дорогих систем.
Варто підкреслити, що у програмних продуктів практично
відсутній процес фізичного старіння й зношування. Для них основні витрати
доводяться на розробку зразка, тоді як процес тиражування являє собою,
звичайно, порівняно нескладну й недорогу процедуру копіювання магнітних носіїв
і супровідної документації.
Метою виконання дипломної роботи є автоматизація збору
статистичних інформації в умовах неврологічного відділення Криворізького
інституту професійних захворювань. В ході розробки програмного продукту було
використане програмне забезпечення Turbo Delphi 2006 Explorer, яке є
безкоштовним. Для функціонування системи також необхідне встановлення пакету
Microsoft Office.
Економічна доцільність розробки полягає в економії
трудовитрат в порівнянні з ручною обробкою і отриманні достовірнішої інформації
за коротший час. Для роботи системи необхідно: персональний комп’ютер на базі
процесору Intel з частотою не менше 2,4 ГГц, з ОЗУ рівним 512Мб, з SVGA -
відеоадаптером і монітором 17 дюймів.
Таблиця
6.1
Вартість устаткування
|
№ п/п
|
Найменування
|
Марка
|
К-ть
|
Ціна
|
Сума
|
|
1
|
ЕОМ (зі встановленою операційною системою Windows
XP)
|
|
1
|
3700,15
|
3700,15
|
|
2
|
Джерело безперебійного живлення
|
APC Back-Bk500 EI
|
1
|
343,00
|
343,00
|
|
Разом:
|
4043,15
|
Таблиця
6.2
Матеріали для роботи
|
№ п/п
|
Найменування
|
Норма витрати на виріб
|
Ціна
|
Сума
|
|
1
|
Компакт-диски
|
5
|
3
|
15
|
|
2
|
Література
|
1
|
1
|
127,2
|
|
Разом:
|
|
|
142,2
|
Вартість устаткування збільшується на вартість
транспортування - 10% і вартість монтажу - 15%. Разом вартість устаткування
складе:
Соб = 4043,15+404,32+606,47=5053,94 грн.
Амортизація комп'ютера складає 15% в квартал від
залишкової вартості, тобто
А = Фзал × Н,
де Фзал - залишкова вартість відповідно групи ОФ
на початок кварталу. Н - норма амортизації.
I квартал 5053,94 х 0.15 = 758,09квартал (5053,94 -758,09) х
0.15 = 644,37квартал (5053,94 -758,09 - 644,37) х 0.15 = 547,72квартал (5053,94
-758,09 - 644,37 - 547,72) х 0.15 =465,56
Разом річна амортизація складе: 2415,74
Матеріали для роботи списуються у міру витрат.
Вартість необхідного програмного забезпечення - пакету
Microsoft Office приймаємо рівним 2700 грн.
Амортизація програмного забезпечення на 3 роки складатиме:
Апр=2700/3=900,00 грн.
Витрати на електроенергію
Е = N х В х t,
де N - споживана об'єктом потужність від мережі (кВт/час)-
Тариф на електроенергію- Регламентований час роботи об'єкту протягом року.
ч/год.
В= кількість робочих днів в році х 8 годин =251 х 8 = 2008
(годин)
Е = 0,30 х 2008 х 0,9302 = 560,35 грн./год.
Нормативне споживання електроенергії комп'ютером - 300
вт/година або 0,3 квт/час. Вартість 1 кВт електроенергії для підприємства 93
копійки або 0,9302 грн.
Розрахунок заробітної плати
Для розробки, тестування, впровадження і супроводу системи
програмістові необхідні 30 робочих днів в році.
Кількість робочих днів в році визначається по формулі:
Тт = Тр -(Тв+Тн)
де Тн - кількість святкових днів в році;
Тр - кількість днів в році;
Тт - кількість днів в тиждень;
Тв - кількість вихідних днів в році;
Тт =365 - ( 104+10) =251
Кількість робочих днів в місяць: 21.
Таблиця
6.3
Співробітники
|
№п/п
|
Найменування посад
|
Посадовий оклад грн./місяць
|
Трудомісткість виконання
|
Сума зарплати, грн.
|
|
1.
|
Інженер - програміст
|
1800
|
30 днів
|
30 х 86 = 2580
|
Середня денна заробітна платня = 1800 : 21 = 86 грн.,
За виконання завдання виплачується премія у розмірі 50%
Сума премії = Зп х П% =2580 х 0,5 = 1290 грн.
Разом зарплата інженера програміста:
+ 1290=3870 грн.
Єдиний соціальне нарахування становить 36,77%, що дорівнює:
*36,77/100 = 1423,00 грн.
Зарплата інженера - програміста з нарахуваннями на соціальні
потреби.
Зп. відр = 3870 + 1423,00= 5 293,00 грн.
Раніше роботу виконували 2 співробітника. Було звільнено 1
співробітника, таким чином залишився працювати 1 робітник.
Таблиця
6.4
Економія заробітної плати
|
Кількість робітників
|
Місячна з/пл грн.
|
Премія 20%
|
Разом за рік
|
|
Заробітна плата
|
1
|
1200
|
240
|
17 280
|
|
Нарахування на соціальні потреби (37,6 %)
|
1
|
|
|
6 497,28
|
|
РАЗОМ:
|
23 777,28
|
Економія за рахунок зниження трудомісткості виконуваної
роботи =
777,28 - 5 293,00 =18 484,28 грн;
а річний ефект рівний:
484,28 - річна амортизація устаткування - річна амортизація
програмного забезпечення - поточні витрати на матеріали - споживана
електроенергія.
Е річн.еф. = 18 484,28- 2 415,74 - 900,00 - 142,2-
560,35 = 14 465,99грн.
,
де К - капітальні витрати, рівні
053,94 + 2700 = 7753,94 (вартість устаткування + вартість програмного
забезпечення)
=
0,54 року.
-
це термін окупності витрат.
Таким чином, впровадження розробленого програмного продукту є
економічно доцільним.
7.
ОХОРОНА ПРАЦІ
Вивчення і рішення проблем, пов'язаних із забезпеченням
здорових та безпечних умов, в яких протікає праця людини - одна з найбільш
важливих завдань у розробці нових технологій та систем виробництва. Вивчення та
виявлення можливих причин виробничих нещасних випадків, професійних
захворювань, аварій, вибухів, пожеж, і розробка заходів та вимог, спрямованих
на усунення цих причин дозволяють створити безпечні та сприятливі умови для
праці людини.
В Україні діють закони, які визначають права й обов'язки її
громадян, а також організаційну структуру органів влади і промисловості.
Конституція України декларує рівні права й свободи всім жителям країни: вільний
вибір роботи, що відповідає безпечним і здоровим умовам, на відпочинок, на
соціальний захист у випадку втрати працездатності й старості. Всі закони й
нормативні документи повинні узгоджуватися, базуватися й відповідати статтям
Конституції.
Законодавча база охорони праці України має ряд законів,
основним з яких є Закон України «Про охорону праці» і Кодекс законів про працю
(КЗпП). До законодавчої бази також належать Закони України: «Про
загальнообов'язкове страхування від нещасних випадків на виробництві й
професійних захворювань, які викликали втрату працездатності», «Про охорону
здоров'я», «Про пожежну безпеку», «Про забезпечення санітарного й
епідеміологічного добробуту населення», «Про використання ядерної енергії й
радіаційну безпеку», «Про дорожній рух», «Про обов'язкове страхування у зв'язку
з тимчасовою втратою працездатності й витратами, обумовленими народженням й
похоронами». Їх доповнюють стандарти, правила, норми, інструкції, положення,
статути й інші документи.
Найбільш важливим нормативним документом по забезпеченню
охорони праці користувачів ПК є «Державні санітарні правила й норми роботи з
візуальними дисплейними терміналами (ВДТ) електронно-обчислювальних машин»
ДСанПіН 3.3.2.007-98.
.1
Аналіз небезпечних й шкідливих виробничих факторів
Комфортні та безпечні умови праці-одна з основних факторів,
що впливають на продуктивність службовців обчислювальних центрів. Робота
співробітників обчислювальних центрів безпосередньо пов'язана комп'ютером, а
відповідно з додатковим шкідливим впливом цілої групи факторів, що істотно
знижує продуктивність їх праці.
Приміщення, в якому виконувалась науково-дослідна робота - це
інформаційно-обчислювальний центр (ІОЦ). У інформаційно-обчислювальному центрі
знаходиться 14 комп’ютерів з 14 робочими місцями. Розміри ІОЦ такі: довжина -
13 м, ширина - 7 м, висота - 3,2 м, таким чином, загальна фактична площа
складає 91 м2, загальний об’єм приміщення - 291,2 м3 .
Наведені розміри відповідають необхідним нормам СН 512-78 и
ДСанПіН 3.3.2.007-98, виходячи з яких, площа повинна бути не менше 6 м2
на одне робоче місце, об’єм не менше 20 м3 , таким чином, площа
робочого місця у приміщенні складає 6,5 м2, а об’єм 20,8 м3.
Робота з комп'ютером характеризується значною розумовою
напругою і нервово-емоційним навантаженням на людину, високою напруженістю
зорової роботи і достатньо великим навантаженням на м'язи рук при роботі з
пристроями введення комп'ютера. Велике значення має раціональна конструкція і
розташування елементів робочого місця, що важливе для підтримки оптимальної
робочої пози людини. Небезпечні і шкідливі виробничі чинники, класифікуються на
підставі ГОСТ 12.0.003-74. У таблиці 7.1 наведені небезпечні і шкідливі
чинники, які мають місце при роботі з ПЕОМ з вказівкою дії на організм людини.
Таблиця
7.1
Небезпечні і шкідливі чинники при роботі з ПЕОМ
|
№ п/п
|
Назва фактора
|
Джерела виникнення
|
Характер дії
|
|
1
|
Підвищення значення напруги в електричному ланцюзі
|
Мережа електричного струму(380/220 В)
|
Небезпечний
|
|
2
|
Підвищений рівень статичної електрики
|
Екран дисплея і діелектричні поверхні
|
Небезпечний
|
|
3
|
 Підвищена іонізація повітря
|
Статична електрика
|
Шкідливий
|
|
4
|
Підвищені рівні шуму та вібрації
|
Пристрої охолодження ЕОМ, друкувальні пристрої
|
Шкідливий
|
|
5
|
Пряме та відбите світло
|
Зовнішні джерела світла, діючі на екран
|
Шкідливий
|
|
6
|
Підвищена пульсація світлового потоку
|
Лампи денного світла (люмінесцентні), екран монітора
|
Шкідливий
|
|
7
|
Розумове перенапруження
|
Тривала розумова праця
|
Шкідливий
|
|
8
|
Підвищена запиленість повітря
|
Стан системи кондиціонування і вентиляції,
перевантаженість робочих місць
|
Шкідливий
|
|
9
|
Перенапруження аналізаторів
|
Тривале знаходження перед монітором, шум обладнання
|
Шкідливий
|
|
10
|
Монотонність праці
|
Тривале виконання однотипної праці, рідка зміна пози
|
Шкідливий
|
|
11
|
Емоційне перевантаження
|
Стреси, що виникають від монотонної праці, загальної
емоційної напруги, непередбачуваних невдач та проблем під час виконання
завдань
|
Шкідливий
|
Робота на ІОЦ, у відповідності до ДСН 3.3.6.042-99,
відноситься до категорії важкості робот 1б - легка. Енерговитрати складають
141-175 Вт (121-150 ккал/год.). Оптимальні значення параметрів мікроклімату для
теплого і холодного періодів року з урахуванням категорії робіт, приведені у
таблиці 7.2 згідно з вимогами ГОСТ 12.1.005-88 та ДСН 3.3.6.042-99.
Таблиця
7.2
Оптимальні значення параметрів мікроклімату
|
Період року
|
Температура, оС
|
Відносна вологість, %
|
Швидкість руху повітря, м/с
|
|
Холодний
|
21-23
|
40-60
|
<0,1
|
|
Теплий
|
22-24
|
40-60
|
<0,2
|
Норми рівнів іонізації повітря відповідно до СН 2152-80
приведені у таблиці 7.3.
Таблиця
7.3
Рівні іонізації повітря приміщення при роботі з ЕОМ
|
Рівні іонізації
|
Кількість іонів у  повітря
|
|
 
|
|
|
Максимально необхідні
|
400
|
600
|
|
Оптимальні
|
1500-3000
|
3000-5000
|
|
Допустимі
|
50000
|
50000
|
Поверхня підлоги в приміщеннях експлуатації ПЕОМ повинна бути
рівною, без вибоїн, неслизького, зручного для очищення і вологого прибирання,
володіти антистатичними властивостями.
Відповідно до ДСанПіН 3.3.2.007-98. встановлюються гігієнічні
вимоги, які регламентують допустиме значення поверхневого електростатичного
потенціалу не більше 500 В, а напруженість електростатичного поля 15 кВ/м.
Експлуатовані ЕОМ є однофазними споживачами трьохфазної
чотирьохпроводної мережі з глухозаземленою нейтраллю із напругою 380/220 В і
частотою 50 Гц.
Приміщення ІОЦ по ступеню небезпеки ураження людей
електричним струмом згідно з ПУЕ-87 належить до категорії приміщень з
підвищеною небезпекою, оскільки робочі місця розташовані таким чином, що існує
можливість одночасного дотику до металевих корпусів електроустаткування та до
металоконструкцій будівлі, що мають з'єднання з землею.
Джерелами шуму на ІОЦ є принтери та охолоджувальна система
ЕОМ. Згідно норм у приміщенні ІОЦ рівні звуку не повинні перевищувати 50 дБА.
Згідно ДОСТ 12.1.012-90 рівень вібрації для категорії 3, тип В, в умовах
“комфорту” не повинен перевищувати 75 дБ.
У світлий час доби на ІОЦ використовується бокове
одностороннє природне освітлення, а у темний час - загальне рівномірне штучне.
Освітлення повинне забезпечувати необхідний спектральний склад світла. Значення
нормативного показника КПО має бути не менш 1,5% при роботі з ЕОМ згідно нормам
НАОП 0.00-1.31-99.
Розряд зорової роботи, а також нормовані показники природного
та штучного освітлення відповідно до ДБН В.2.5-28-2006 приведені у таблиці 7.4.
Таблиця 7.4
Нормовані показники природного та штучного освітлення
|
Характеристика зорової роботи
|
Розряд зорової роботи
|
Розмір об’єкта розпізнавання, мм
|
Підрозряд зорової роботи
|
Характерис-тика фону
|
Контраст об’єкта розпізнавання з фоном
|
Освітлення
|
|
|
|
|
|
|
Штучне, загальне E, лк
|
Природне, бокове, КПО,%
|
|
Середньої точності
|
IІІ
|
0,5 - 1
|
г
|
світлий
|
великий
|
300
|
1,3
|
7.2
Заходи щодо нормалізації небезпечних і шкідливих факторів
Для забезпечення нормальних метеоумов в ІОЦ встановлений
кондиціонер, що постійно підтримує задані кліматичні параметри в робочому
просторі. У зимовий період у доповненні до центрального опалення використаються
електрообігрівачі масляного типу. У літній період при зниженні в повітрі
кількості водяної пари (низкою вологості повітря) застосовується зволожувач
повітря.
Основними джерелами шумів в приміщенні, де робота
здійснюється за допомогою ПЕОМ, є шум від самих ПЕОМ, розмова людей, система
кондиціонування, шум від працюючої друкарської техніки і шум з вулиці,
коридору.
Для пониження рівня шумів в приміщенні можна використовувати
наступні заходи:
. Використовуються звукоізоляційні пластикові вікна.
. Для зниження ефекту від шумів, що створюються усередині
приміщення стелі і стіни покриваються спеціальними звукопоглинальними матеріалами.
. Використання вентиляторів більшого діаметру, використання
пасивного охолоджування усередині ПЕОМ.
. Використання безшумної клавіатури і миші, сучасна
периферійні пристрої (принтер, сканер) теж значно тихіше раніше випущених
моделей.
Розрядні струми статичної електрики найчастіше виникають при
дотику до будь-якого з елементів ПЕОМ. Такі розряди небезпеки для людини не
представляють, але окрім неприємних відчуттів вони можуть привести до виходу з
ладу ПЕОМ. Для зниження величини виникаючих зарядів статичної електрики в
приміщенні покриття технологічної полови слід виконувати з одношарового
полівінілхлоридного антистатичного лінолеуму. Іншим методом захисту є
нейтралізація заряду статичної електрики іонізованим газом. У промисловості
широко застосовуються радіоактивні нейтралізатори. До загальних заходів захисту
від статичної електрики в приміщенні можна віднести зволоження повітря.
Відповідно до правил пристрою електроустановок для заземлення
електроустановок потужністю менш 1кВ рекомендується використовувати заземлення
з опором 4 Ом.
Таким чином, для захисту від дії статичної електрики
впроваджуються наступні заходи:
− заземлення електроприладів;
− протирання зовнішньої поверхні монітора,
клавіатури і інших пристроїв, вологою серветкою;
− щоденне вологе прибирання приміщення;
− покриття підлоги спеціальним антистатичним
лінолеумом.
Для захисту від поразки електричним струмом у разі
пошкодження ізоляції повинні бути застосовані окремо або в поєднанні наступні
заходи захисту при непрямому дотику:
− захисне заземлення;
− автоматичне відключення живлення;
− подвійна або посилена ізоляція;
− захисне електричне розділення ланцюгів.
При правильно розрахованому і виконаному освітленні очі
працюючого за комп’ютером протягом тривалого часу зберігають здатність добре
розрізняти предмети не втомлюючись. Це сприяє зниженню професійного
захворювання очей, підвищується працездатність. Раціональне освітлення
відповідає ряду вимог:
− достатнє, щоб очі без напруги могли розрізняти
деталі;
− постійна напруга в мережі не коливається більше
ніж на 4%;
− рівномірно розподілено по робочим поверхням,
щоб очам не приходилося зазнавати різкого контрасту кольорів;
− не викликає дії, яка сліпить органи зору
працюючого (зменшення блищання джерел, що відбивають світло, досягається застосуванням
світильників, які розсіюють світло);
− не викликає різких тіней на робочих місцях.
Задачею розрахунку є визначення необхідної потужності
електричної освітлювальної установки для створення у виробничому приміщенні
заданої освітленості. При проектуванні освітлювальної установки необхідно
вирішити наступні основні питання:
− вибрати тип джерела світла - рекомендуються
газорозрядні лампи, за винятком місць, де температура повітря може бути менш
+5°С і напруга в мережі падати нижче 90 % номінального, а також місцевого
освітлення (у цих випадках застосовуються лампи розжарювання);
− визначити систему освітлення (загальна
локалізована або рівномірна, комбінована);
− вибрати тип світильників з урахуванням
характеристик світорозподілення, умов середовища (конструктивного виконання) та
інше;
− розподілити світильники і визначити їх
кількість (світильники можуть матися в своєму розпорядженні рядами, в шаховому
порядку, ромбоподібно);
− визначити норму освітленості на робочому місці.
Для розрахунку штучного освітлення використовують в основному
три методи. Найчастіше її розраховують по світловому потоку. Для цього
визначається світловий потік кожної лампи по нормуючій мінімальній
горизонтальній освітленості Еmin (лк) з вираження:
= (Emin·S·K·z) / n1·n·N,(7.1)
де F - світловий потік лампи в світильнику, лм;- площа
приміщення, м2;- коефіцієнт запасу;- коефіцієнт нерівномірного
освітлення;1 - коефіцієнт використання світлового потоку;- кількість
ламп в світильнику;- число світильників.
Якщо освітлення здійснюється рядами люмінесцентних ламп, те
вираження вирішується відносно N. Значення коефіцієнта n1
визначається по довіднику в залежності від типу світильника, коефіцієнтів
відбивання стін Рс, стелі Рп, робітничій поверхні і від
розмірів приміщення. Показник приміщення fi визначається з виразу:
i= А·В/Нр·(А+В),(7.2)
де А і В - довжина і ширина освітленого приміщення, м;
Нр - висота підвісу світильника над робітничою
поверхнею, м.
У випадку застосування люмінесцентних ламп потрібна кількість
світильників N, яка визначається за формулою:
= Emin·S·K·z/F·n1·n(7.3)
Поділивши число світильників N на число вибраних рядів
світильників, визначають число світильників у кожному ряду.
Нехай зал має розміри А=13 м, В=7 м, h=3.2 м, стеля
обладнується світильниками Л201Б з люмінесцентними лампами ЛБ80.
Рівень робітничої поверхні над полом 0,8 м, при цьому Нр=2,4
м.
Показник приміщення рівний:
i=40/2,4 (8+5)=1,3986
По довіднику визначаємо значення коефіцієнта n1
(для значень Рс=0,5, Рп=0,3): n1=0,7. Значення
коефіцієнта нерівномірного освітлення приймаємо рівним 1,1, а коефіцієнта
запасу - 1,5. При загальному типі освітлення значення Emin=400 лк.
Знаючи значення світлового потоку кожної лампи, можемо визначити необхідну
кількість світильників:
=400·8·5·1,5·1,1/5220·0,7·2=3 (штук)
Загальна потужність освітлювальної установки рівна:
Р=2·80·3=480 (Вт)
По результатах проведеного розрахунку можна зробити висновок
про те, що освітлення в робочій зоні, знаходяться в межах допустимих норм.
7.3
Пожежна безпека
Пожежа в приміщенні обчислювального центру відноситися до
класу В - пожежі, пов'язані з горінням електроустановок, що знаходяться під
напругою.
В електронно-обчислювальній техніці пожежну небезпеку
створюють прилади, що нагріваються, електро- і радіотехнічні елементи. Вони
нагрівають навколишнє повітря і близько розташовані деталі і провідники. Все це
може призвести до займання означених елементів, руйнування ізоляції і короткого
замикання.
Для гасіння пожеж передбачена наявність первинних засобів
пожежегасіння, (згідно так і пожежні крани із брезентовими рукавами, пожежні
щити (1 щит на 5000м2). В кімнаті знаходиться вогнегасник (ВВ-5).
При розміщенні вогнегасників виключений безпосередній вплив на них сонячних
променів, опалювальних і нагрівальних пристроїв. За конструкцією, матеріалами,
методами контролю, умовами змісту, обслуговуванням вогнегасник відповідає
вимогам Правил пристрою і безпечної експлуатації судин, що працюють під тиском.
Відповідно до «Правил пожежної безпеки в Україні» при захисті
приміщень ЕОМ, слід використовувати порошкові та вуглекислові вогнегасники з
урахуванням гранично допустимої концентрації вогнегасної речовини. Розміщення
вогнегасників в коридорах, проходах не повинно перешкоджати безпечній евакуації
людей. Їх слід розташовувати на видних місцях поблизу від виходів з приміщень
на висоті не більше 1,5 м.
Для успішного гасіння пожежі велике значення має швидке
виявлення пожежі та своєчасний виклик пожежних підрозділів до місця пожежі.
Пожежний зв’язок і сигналізація можуть бути спеціального або загального призначення,
радіозв’язком, електричною пожежною сигналізацією (ЕПС), сиренами. ЕПС є
найбільш швидким та надійним засобом сповіщення про виникнену пожежу. В
залежності від схеми з’єднання розрізнюють променеві (радіальні) та шлейфні
(кільцеві) системи ЕПС.
ЕПС складаються з таких основних частин: сповіщувачів,
встановлених в приміщеннях; приймальної станції, яка знаходиться в черговій
кімнаті пожежної команди; блока поживи від сіті та від акумулятора (резервний);
системи переключення з одної поживи на іншу; електропровідній сіті, яка з’єднує
сповіщувачі з приймальною станцією.
В кімнаті з ПЕОМ розміщений сповіщувач (датчик) тепловий
легкоплавкий. При збільшенні температури легкоплавкий сплав розплавляється і
пружинячі пластинки, розмикаючись, вмикають ланцюг сигналізації.
Безпечна евакуація людей при пожежі має першорядне значення в
комплексі заходів щодо забезпечення пожежної безпеки. Досвід показує, що
недооцінка важливості або неправильне розуміння цього моменту може привести до
трагічних наслідків. Важливим і обов'язковим елементом забезпечення; безпечній
евакуації людей при пожежі і інших надзвичайних ситуаціях є грамотно
розроблений і правильно виконаний план евакуації.
Згідно БНіП 2.09.02-85, в будівлях і спорудах (окрім житлових
будинків) при одноразовому знаходженні на поверсі більше 10 чоловік повинні
бути розроблені і на видних місцях вивішені плани евакуації людей на випадок
пожежі.
На об'єктах з масовим перебуванням людей на додаток до
схематичного плану евакуації людей при пожежі повинна бути розроблена
інструкція, що визначає дії персоналу по забезпеченню безпечної і швидкої
евакуації людей, по якій не рідше за один раз в півріччя повинні проводитися
практичні тренування всіх задіяних для евакуації працівників.
Плани евакуації складаються, зважаючи на особливості
поведінки людей при пожежі, об'ємно-планувальні рішення будівлі (розміри і тип
комунікаційних шляхів і т.п.), потужності сформованих людських потоків, режим
експлуатації будівлі, що склався, активні і пасивні системи пожежної безпеки.
План розміщується на видному, доступному місці.
ВИСНОВКИ
Першою і головною проблемою обробки великої кількості
медичної інформації є відсутність єдиної системи зберігання даних, що надавала
б можливість швидко та зручно, а головне одноманітно і стандартизовано, їх
опрацьовувати.
Результатом виконання даної дипломної роботи є розробка
модулю автоматизація збору статистичних інформації в умовах неврологічного
відділення Криворізького інституту професійних захворювань.
Інтерфейс системи був створений за допомогою
інструментального засобу прискореної розробки програмного забезпечення Delphi.
За допомогою системи прискореної розробки Delphi можна розробляти додатки для
роботи, як з локальними, так і з видаленими базами даних, включаючи публікацію
баз даних в Internet. 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.
. Немнюгин С.А. Программирование - CПб.: Питер,
2000.
. Озеров В. Delphi. Советы программистов (2-е
издание). - СПб.: Символ- Плюс, 2002.
. Пономарев В. Самоучитель Delphi 7. CПб.:
БХВ-Петербург, 2005.
. Ревнич Ю.В. Нестандартные приемы
программирования на Delphi. - СПб.: БХВ-Петербург, 2005.
. Ремизов Н. Delphi - CПб.: Питер, 2000.
. Симонович С.В., Евсеев Г.А. Занимательное
программирование: Delphi. - М.: АСТ-ПРЕСС Кнрга, 2001.
. Фараонов В. Система программирования Delphi.
CПб.: БХВ-Петербург, 2005.
. Ханекамп Д. Вилькен П. Программирование под
Windows/ Пер. с нем. -М.: ЭКОМ, 1996.
. Хомоненко А.Д. Delphi 7. CПб.: БХВ-Петербург,
2005.
. Королевство Delphi. Виртуальный клуб
программистов
. //Профессиональные программы для
разработчиков
. Программирование на Delphi
. Справочник - «Основы Delphi»
. Мастера Delphi