Рисунок 3.22 - Структура таблиці OBMEJ
Рисунок 3.23 - Структура таблиці IPR
Рисунок 3.24 - Структура таблиці REABIL
Поля таблиць, які є індивідуальними ідентифікаторами, не відображаються в ході виконання програми, так як служать для зв’язування таблиць за ключовими полями та не несуть змістовного значення для користувача.
Для підключення бази даних до програми використано
SQL-запити, приклад якого приведено в лістингу 3.1
Лістинг 3.1 - Властивість SQL компоненту TIBQuery
SELECT os.id_chel, os.fio, os.dr, sex.sex as sex1, obl.obl as
obl1, osv.osvita as osvita1, os.work, os.street, os.index1, os.tel,
ro.rajon_obl as r_obl1, np.nas_punkt as punkt1, r.rajon as r_punkt1, gr.gr_inv
as gr_inv1, prof.prof as id_prof1 From Os_karta osJOIN Spr_sex sex ON os.sex =
sex.id_sexJOIN Spr_GR_INV gr ON os.gr_inv = gr.id_gr_invJOIN Spr_osvita osv ON
os.osvita = osv.id_osvitaJOIN Spr_obl obl ON os.obl = obl.id_oblJOIN
Spr_rajon_obl ro ON os.r_obl = ro.id_rajon_oblJOIN Spr_rajon r ON os.r_punkt =
r.id_rajonJOIN Spr_nas_punkt np ON os.punkt = np.id_nas_punktJOIN Spr_prof prof
ON os.id_prof = prof.id_prof
Зручно не використовувати один шлях доступу до таблиць бази даних, а мати для цього файл налаштувань, який дозволяє вказати з програми шлях доступу до бази даних. Такий підхід дає можливість розташовувати дані в будь-якому місці, не перекомпільовуючи при цьому програму. Приклад вхідних даних міститься у додатку А.
Згідно з постановкою задачі доцільно розробити інтерфейс програми, який би складався з форм, описаних нижче.
До складу інтерфейсу повинно входити 15 форм, список та
призначення яких приведено у таблиці 3.1.
Таблиця 3.1 - Призначення форм
|
Назва форми |
Призначення форми |
|
AboutForm |
Відображення інформації про програму |
|
DataModule1 |
Розташування не візуальних компонентів |
|
FormAddDov, FormAddDovMKH |
Додавання та редагування даних у довідниках |
|
FormAddIPR |
Додавання та редагування інформації про індивідуальну програму реабілітації |
|
FormAddPacient |
Додавання даних про пацієнта |
|
Назва форми |
Призначення форми |
|
FormAvtoriz |
Авторизація |
|
FormDovidnik |
Перегляд довідників |
|
FormIPRView |
Перегляд ІПР |
|
FormNastr |
Вибір шляху до БД |
|
FormReabil |
Форма реабілітаційних заходів ІПР |
|
FormRedPac |
Редагування інформації про пацієнта |
|
MainForm |
Основна форма |
|
FormRedPas |
Форма зміни пароля |
|
FormPath |
Налаштування для збереження довідок |
Основна форма Main зображена на рисунку 3.1. Вона містить такі компоненти [7] як:
- TMainMenu - для забезпечення відображення головного меню уверху форми для переходів на інші форми;
- TStatusBar - для відображення поточної інформації системи у нижній частині вікна;
- TToolBar - для відображення кнопок під головним меню для швидкого доступу до деяких функцій;
- TDBNavigator - для переходу по таблиці;
- TEdit - для вводу інформації;
- TImageList - для збереження зображень у форматі *.bmp для іконок;
- TDateTimePicker - для вибору коректної дати;
- TBitBtn - кнопка із іконкою для виконання дій;
- TGroupBox - для візуально відділення інформації;
- TPopupMenu - для спливаючого меню, що викликається правою кнопкою миші;
- TDBGrid - для відображення таблиці із бази даних;
- TImage - для розміщення зображень, зокрема фону форми;
- TXPManifest - для придання формі стилю Windows XP;
- TLabel - для розміщення пояснювального тексту;
- TComboBox - для вибору значення зі списку;
- TPanel - для розміщення та вирівнювання компонентів один відносно одного.
Рисунок 3.25 - Основна форма Main
Для вирівнювання вікна при появі його властивість Position була встановлена у poScreenCenter, для того, щоб користувач не міг змінити розмір вікна, його властивість BorderStyle була встановлена у Single для відповідних форм. Також при розміщенні компонентів на формі властивість Align в залежності від потреб була встановлена у alBottom, alClient, alLeft , alRight чи alTop для компонентів.
Головне меню містить такі пункти меню:
- «Авторизація» - має підпункти для виходу із програми та для реєстрації нового користувача;
- «Заповнити» - має підпункти для виклику вікна заповнення даних про пацієнта та заповнення ІПР пацієнта;
- «Пошук» - показує чи скриває панель пошуку;
- «Довідники» - через підпункти викликає вікно перегляду для конкретного довідника;
- «Про програму» - викликає вікно «Про програму»;
- «Конфігурація» - викликає вікно конфігурації;
- «Вихід» - закриває програму.
Компонент TPopupMenu призначений для виконання дій над записами та містить такі пункти:
- «Додати пацієнта»;
- «Додати ІПР»;
- «Редагувати»;
- «Видалити».
Для зручності невізуальні компоненти [8] було розміщено на
спеціальній формі DataModule, яку зображено на рисунку 3.26.
Рисунок 3.26 - Форма з невізуальними компонентами DataModule
Форма додавання інформації [9] про пацієнта містить такі компоненти, як TImage, TGroupBox, TMainMenu, TLabel, TDateTimePicker, TEdit, TComboBoх.
Форма додавання інформації про ІПР містить такі компоненти як TLabel, TEdit, TDateTimePicker, TUpDown - для завдання числового значення кліком по стрілкам, TGroupBox, TImage, TMainMenu, TDBListBox - для відображення інформації із таблиці обмежень, TMemo - для вводу ступеня обмеження, TSpeedButton - кнопка-зображення для відкриття довідників, TComboBox, TDBNavigator.
Вибір реабілітаційних засобів, їх термінів, обсягу та місця проведення виконується на формі додавання інформації про реабілітаційні заходи, їх обсяги, терміни та місця проведення «Реабілітація», яка зображена на рисунку 3.29. Дана форма містить такі компоненти, як TTreeView - призначений для відображення довідника реабілітації у вигляді дерева, TImage, TMainMenu, TComboBox, TLabel, TBitBtn, TSpeedButton.
Перегляд довідників виконується на формі FormDovidnik, в якій відкривається тільки той, що буде обрано у підменю «Довідники». Ця форма мітить такі компоненти як TPageControl - для вибору вкладок, TDBGrid, TBitBtn.
Форма містить такі компоненти, як TMainMenu, TImage, TGroupBox, TLabel, TEdit.
Форма додавання до інших довідників, а саме: «Професії», «Терміни реабілітації», «Обсяги реабілітації», «Місця реабілітація», «Працівники», «Область», «Район області», «Населений пункт» та «Район населеного пункту». Вона містить такі ж самі компоненти, що й попередня і відрізняється лише тим, що містить тільки одне поле для заповнення.
Форма редагування інформації [10] про пацієнтів відображає дані про конкретного пацієнта, що занесені в таблицю, та дозволяє змінити їх. На формі містяться такі компоненти, як TMainMenu, TGroupBox, TLabel, TDateTimePicker, TImage, TComboBox, TEdit.
Форма перегляду інформації про ІПР містить такі компоненти, як TMainMenu, TPanel, TMemo, TDBGrid.
Форма авторизації дозволяє виконати вхід до програми. Вона містить такі компоненти, як TLabel, TEdit, TImage, TMainMenu.
Форма зміни пароля має такі компоненти, як TImage, TLabel, TGroupBox, TEdit, TMainMenu.
Форма інформації про програму містить інформацію про програму. На формі містяться такі компоненти, як TLabel, TImage.
Форма конфігурації містить інформацію про шлях до БД. Вона містить такі компоненти, як TLabel, TButton, TImage,TEdit та TOpenDialog - для відкриття діалогу вибору шляху.
Форма конфігурації містить інформацію про шлях для збереження довідок ІПР. Вона містить такі компоненти, як TLabel, TButton, TBitBtn, TEdit та TOpenDialog - для відкриття діалогу вибору шляху, TCheckBox - для відмічання прапорцем настройки.
3.1.2 Опис вхідних та вихідних даних
Вхідними даними у даній програмі є інформація для чотирьох основних таблиць: «Особиста картка пацієнта», «Обмеження», «ІПР» та «Реабілітація», яку користувач вводить з клавіатури, а також дані, якими заповнюються довідники.
Приклад вхідних даних приведено у додатку А.
Вихідними даними є документ сформований в Excel-документі,
фрагмент шаблону документу ІПР зображено на рисунку 3.40.
Рисунок 3.40 - Фрагмент шаблону документу
3.1.3 Контроль коректності вхідних та вихідних даних
Контролю коректності даних, необхідно приділяти чималу увагу, оскільки необроблені помилки, приводять до критичних ситуацій при роботі в роботі програмі.
Тестування програмного забезпечення - це процес, що використовується для виміру якості розроблюваного програмного забезпечення. Зазвичай воно проводиться протягом всієї розробки та супроводу на різних рівнях. Рівень тестування визначає "над чим" виробляються тести: над окремим модулем, групою модулів або системою, в цілому. При цьому жоден з рівнів тестування не може вважатися пріоритетним. Важливі всі рівні тестування, незалежно від використовуваних моделей і методологій.
Модульне тестування (Unit testing) дозволяє перевірити функціонування окремо взятого елемента системи. Що вважати елементом - модулем системи визначається контекстом. Найбільш повно даний вид тестів описаний в стандарті IEEE 1008-87 "Standard for Software Unit Testing", задаючому інтегровану концепцію систематичного і документованого підходу до модульного тестування.
Інтеграційне тестування (Integration testing) є процесом перевірки взаємодії між програмними компонентами / модулями. Класичні стратегії інтеграційного тестування - "зверху-вниз" і "знизу-вгору" - використовуються для традиційних, ієрархічно структурованих систем і їх складно застосовувати, наприклад, до тестування слабозв'язаних систем. Інтеграційне тестування - постійно проводиться діяльність, що передбачає роботу на досить високому рівні абстракції. Найбільш успішна практика інтеграційного тестування базується на інкрементальних підході, що дозволяє уникнути проблем проведення разових тестів, пов'язаних з тестуванням результатів чергового тривалого етапу робіт, коли кількість виявлених дефектів призводить до серйозної переробки коду (традиційно, негативний досвід випуску та тестування тільки великих релізів називають "big bang").
Системне тестування (System testing) охоплює цілком всю систему. Більшість функціональних збоїв повинна бути ідентифікована ще на рівні модульних та інтеграційних тестів. У свою чергу, системне тестування, зазвичай фокусується на нефункціональних вимогах - безпеки, продуктивності, точності, надійності т.п.
Існує кілька методів тестування:
- тестування методом «чорної скриньки» (Black box testing);
- тестування методом «білого ящика» (White box);
- тестування методом «сірого ящика» (Grey box).
У термінології професіоналів тестування (програмного і деякого апаратного забезпечення) фрази "тестування білого ящика" і "тестування чорного ящика" ставляться до того, чи має розробник тестів і тестувальник доступ до вихідного коду тестованого ПО, або ж тестування виконується через інтерфейс користувача або прикладної програмний інтерфейс, наданий тестуємим модулем.
При тестуванні білого ящика (англ. white-box testing, також кажуть - прозорого ящика), розробник тесту має доступ до вихідного коду і може писати код, який пов'язаний з бібліотеками тестованого ПЗ. Це типово для юніт-тестування, при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції - працездатні і стійкі, до певної міри.
При тестуванні чорного ящика (англ. black-box testing), тестувальник має доступ до ПЗ тільки через ті ж інтерфейси, що і замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншого комп'ютера або іншому процесу підключитися до системи для тестування. Наприклад, тестуючий модуль може віртуально натискати клавіші або кнопки миші в програмі, що тестується за допомогою механізму взаємодії процесів, з упевненістю в тому, чи все йде правильно, що ці події викликають той же відгук, що й реальні натискання клавіш і кнопок миші. Як правило, тестування чорного ящика ведеться з використанням специфікацій або інших документів, що описують вимоги до системи.
Що стосується самих помилок, то вони можуть бути синтаксичними та логічними. Перші легко визначаються, так як компілятор вказує на них, та легко усуваються, якщо проаналізувати текст помилки. Другі ж потребують значної уваги. Як правило вони виражаються не появою повідомлень, а роботою програми, яка на практиці не відповідає очікуванням. В такому разі може допомогти покроковий запуск програми, трасування, відстеження значень змінних і тому подібне.
Для забезпечення надійності програми потрібно передбачити дії
у разі невдалої спроби підключитися до бази даних, невірно введених або не
введених даних. Прикладом логічної помилки служить, наприклад, випадок, коли
програма не може підключитися до бази даних через те, що база даних відсутня у
місці, де прописана програма. Цю помилку можна вирішити передбачивши, щоб
програма спочатку перевіряла наявність в базі даних файлу, а потім з’являлося
вікно, в якому можна обрати новий шлях до бази даних.
3.1.4 Опис структури та складових системи
Система ділиться на підсистему адміністрування та підсистему користувача.
Спочатку користувач повинен ввести пароль на формі авторизації, після чого йому буде відображена основна форма. З основної форми через пункти головного меню викликаються всі інші форми для забезпечення виконання таких функцій, як:
- додавання даних у систему;
- редагування;
- видалення;
- пошук, сортування, фільтрація;
Для користувача, що авторизувався як адміністратор, доступні всі функції, для звичайного, що не вводить паролю, доступні лише деякі функції. Схема взаємодії складових частин програми приведена на рисунку 3.41, 3.42.
Рисунок 3.42 - Продовження схеми взаємодії складових частин
програми
3.2 Опис модулів програми
Програма містить 15 модулів, перелік обробників подій
приведено у таблиці 3.2. Основними подіями є обробка події натискання на
кнопку, зміни вмісту поля та активація форми.
Таблиця 3.2 - Вміст модулів програми
|
Назва |
Перелік обробників подій |
|
Main |
m_exitClick, m_aboutClick, tb_view_iprClick, m_add_iprClick, m_zmin_korClick, m_poiskClick, FormCreate, m_add_pacClick, pop_delClick, tb_excelClick, m_zmin_korClick, DBGrid_InfTitleClick, BitBtn_filtrClick, pop_add_iprClick, pop_add_pacClick, m_konfClick, tb_add_pacClick, m_diagnozClick, m_mkhClick, m_profClick, m_terminClick, m_obClick, m_miscClick, m_pracClick, pop_redClick, BitBtn_cancelClick, c_sexChange, m_r_oblClick, m_oblClick, m_nas_punktClick, m_r_punktClick, c_grChange, c_osvChange, c_oblChange, fio |
|
About |
- |
|
AddDov |
m_cancelClick, m_ addClick, FormActivate |
|
AddDovMKH |
m_cancelClick, m_addClick, FormActivate |
|
Назва |
Перелік обробників подій |
|
AddPacient |
m_exitClick, FormShow, m_add_pacClick, FormCreate, c_sexChange, c_osvChange, c_grChange, c_profChange, c_oblChange, c_r_oblChange, c_nas_punktChange, c_r_nas_punktChange, m_dd_iprClick, SpeedButton_profClick, SpeedButton_oblClick, SpeedButton_r_oblClick, SpeedButton_punktClick, SpeedButton_r_punktClick |
|
Avtoriz |
m_exitClick, m_enterClick, RGClick, FormCreate |
|
DataModule |
DataModuleCreate |
|
Dob_IPR |
m_exitClick, m_reabilClick, FormCreate, DBNavigator1Click, Memo3KeyPress..Memo16KeyPress, m_addClick, s_zahChange pr_sklChange, r_potencialChange, diagnozChange, c_pracChange, metaChange, sp_diagnozClick, sp_mkhClick, sp_pracClick |
|
Dovidnik |
FormClose, BitBtn_add_mClick, BitBtn_del_mClick, BitBtn_addClick, BitBtn_delClick, BitBtn_red_mClick, BitBtn_redClick |
|
IPRView |
m_exitClick, m_redClick, FormActivate, m_obmejClick, m_reabilClick, m_excelClick |
|
Nastr |
B_obzorClick |
|
PathEx |
FormShow, zberejClick, obzorClick |
|
Reabil |
m_exitClick, FormCreate, TreeViewChange, m_addClick, BitBtnAddClick, c_obmChange, c_terminChange, miscChange, B_obClick, B_tClick, B_mClick, c_obmDropDown, TreeViewClick |
|
RedPac |
m_exitClick, FormActivate, m_red_pacClick, SpeedButton_profClick, SpeedButton_oblClick, SpeedButton_r_oblClick, SpeedButton_punktClick, SpeedButton_r_punktClick |
|
AddPas |
m_exitClick, m_enterClick |