Програмний модуль "Автосервіс"

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

АНОТАЦІЯ

Розроблений програмний модуль «Автосервіс» має за мету проведення обліку користувачів, працівників, послуг, та заявок автомобільного сервісу.

Для централізованого зберігання даних використовується система керування базами даних MS SQL версії 2008 R2. Клієнтська частина програми написана на мові C++ з використанням інтегрованого середовища Builder версії 6.0.

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

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

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

Ключові слова: облік даних, формування квитанцій, формування звіту, автосервіс, MS SQL Server.

ВСТУП

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

1. ПІДСТАВИ ДО РОЗРОБКИ

Підставою до розробки програмного модулю “Автосервіс” було технічне завдання, одержане від керівника і затверджене на засіданні кафедри “Комп'ютерні системи та мережі” від __ _______20__ року, протокол №_.

2. ПРИЗНАЧЕННЯ РОЗРОБКИ

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

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

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

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

3. ВИМОГИ ДО ПРОГРАМИ АБО ПРОГРАМНОГО ПРОДУКТУ

3.1 Вимоги до функціональних характеристик

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

забезпечення збереження та ефективний пошук усіх даних; 

підвищення швидкості опрацювання даних;

захист бази даних від несанкціонованого доступу за допомогою паролю;

друк чеків та іншої звітності.

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

3.2 Вимоги до надійності

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

Часто оцінюють статистичну надійність програми, яка вимірюється як додаткова ймовірність виявлення нової помилки, не врахованої у попередніх корекціях, в разі чергового зверненні до програми. Це відповідає підходу до програми як до чорного ящика, що іноді видає помилки. Недоліком такого підходу є неявно використана модель “урни з поверненням куль”, яка не враховує коректування кортежу після виявлення кожної нової помилки.

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

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

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

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

3.2.1 Основні принципи проектування

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

Попередження помилок.

Виявлення помилок.

Виправлення помилок.

Забезпечення стійкості до помилок.

Збої і помилки в програмі обробляються в такий спосіб :

а) при виявленні дії програми, яка не відповідає її призначенню, реєструється помилка (у протоколі);

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

в) якщо необхідне виправлення інструкції небажане, можна спробувати змінювати операційну систему, чи транслятори з відповідною зміною інструкції;

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

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

3.3 Умови експлуатації

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

Основним обладнанням робочого місця користувача комп'ютера є монітор, системний блок та клавіатура.

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

Монітор повинен бути розташований на робочому місці так, щоб поверхня екрана знаходилася в центрі поля зору на відстані 400-700 мм від очей користувача.

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

Згідно статті 18 Закону України “Про охорону праці” працівник зобов'язаний:

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

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

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

3.3.1 Вимоги до транспортування і зберігання

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

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

Для нормального функціонування програми “Магазин побутової техінки” потрібен комп'ютер з такими характеристиками:

пам'ять (ОЗП) - 2 Гб;

300 Mb вільного простору на жорсткому диску;

процесор - 1 ГГц.

3.5 Вимоги до інформаційної програмної сумісності

Необхідною вимогою до програмного забезпечення є встановлена операційна система класу Windows. Проект створеної програми матиме вигляд стандартного віконного інтерфейсу Windows, а тому він зручний в роботі i зрозумілий навіть недосвідченому користувачу. Обов'язковою вимогою для функціонування програми є встановлена система керування базами даних Microsoft SQL Server 2008.

4. ВИМОГИ ДО ПРОГРАМНОЇ ДОКУМЕНТАЦІЇ

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

До основних термінів та визначень ЄСПД, згідно ДЕСТ 19.004-80, що використовуються в науці, техніці та виробництві належать:

Алгоритм - згідно ГОСТ 19781-74 - послідовність дій, що приводять від початкових умов до шуканого результату.

Програма обчислювальної машини (програма) -- це алгоритм, тобто послідовність інструкцій, які написані мовою, що зрозуміла комп'ютеру (див. ГОСТ 19781-74).

Програмування -- це процес створення послідовності команд, необхідних для розв'язування поставленої задачі. (див. ГОСТ 19781-74)

Програмний продукт: програма на носії даних - продукт програмного виробництва.

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

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

Перевірка програми: перевірка правильності реалізації заданого алгоритму виконання програм на ЕОМ.

Відладка програми: виявлення, локалізація і усунення помилок в програмі ЕОМ.

Випробування програми: встановлення відповідності програми ЕОМ заданим вимогам і програмним документам.

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

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

5. ТЕХНІКО-ЕКОНОМІЧНІ ПОКАЗНИКИ

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

Трудомісткість розробки програмного продукту (t) визначається за формулою (2), люд.-міс.

t=3,6•(зт.в.к)1,2, (5.1)

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

Загальна тривалість розробки ПП (T) розраховується за формулою (2), міс.:

T=2,5•t 0,32, (5.2)

Середня кількість виконавців (PLвик) розраховується виходячи з трудомісткості та тривалості розробки ПП за формулою (3), люд.

PLвик =t/T, (5.3)

Продуктивність праці групи розробників ПП (Пр), вихідних команд/люд.-міс. Визначається за формулою (4):

Пр=1000•зт.и.к /t (5.4)

6. СТАДІЇ І ЕТАПИ РОЗРОБКИ

Розробка програмного продукту складалася зі стадій наведених в таблиці 6.1.

Таблиця 6.1. Стадії розробки програмного продукту

№ п./п.	Назва етапів курсової роботи	Примітка
1.	Одержання технічного завдання
2.	Аналіз літератури
3.	Розробка схеми бази даних. Створення структури бази даних
4.	Розробка алгоритму роботи програми. Вибір програмних засобів
5.	Розробка інтерфейсу програми
6.	Тестування та відладка програми
7.	Оформлення програмної документації
8.	Представлення готової роботи
9.	Попередній захист
10.	Коректування програмної документації
11.	Захист роботи

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

Програмне забезпечення необхідне для функціонування програми

Для функціонування програми необхідна наявність MS SQL Server не нижче версії 2008 R2 і відлагодженого механізму ADO.

Мови програмування, на яких написана програма

Дана програма написана мовою програмування С++ з використанням інтегрованого середовища Builder версії 6.0. Зв'язок з SQL - сервером відбувається через компоненту ADOQuery, за допомогою мови структурованих запитів до бази даних SQL.

7.ОПИС ЛОГІЧНОЇ СТРУКТУРИ

Структура даних складається з 7 таблиць і показана на рис. 2.1.

Рис. 2.1. Діаграма «сутність - зв'язок» бази даних «Автосервіс».

В таблиці Marku зберігається перелік марок автомобіляв, які зазначаються при оформленні заявки.

В таблиці Stan зберігається перелік станів виконання робі, якими позначаються заявки.

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

В таблиці Robitnuk зберігається опис співробітників автосервісу, а саме повне ім'я, посада, дата влаштування, адреса та телефон, заробітня плата, логін та пароль, які використовуються при авторизації та поле «rob_rang», що також використовуються при авторизації для надання доступу до певного функціоналу.

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

Таблиця Zajavka складається в основному з зовнішніх ключів: номеру постійного клієнта з таблиці Klient, номеру працівника, який оформив заявку (таблиця Robitnuk), порядкового номеру марки автомобіля з таблиці Marku, унікального номеру послуги з відповідної таблиці Poslugu, та стан виконня робіт, що описаний в таблиці Stan та декількох власних полів, а саме: номеру автомобіля, дата прийому, номеру квитанції, скарги та дати виконання послуг.

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

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

Рис. 2.2. Діаграма модулів програми.

В кожному з цих модулів описано клас-форма кожного вікна програмного продукту.

Центральним модулем є DataModule - модуль, що зв'язується з базою даних. Зв'язок відбувається за допомогою компонента ADOConnection, що належить до стандартного набору. Даний компонент зв'язується з сервером MS SQL. Як видно з діаграми, усі інші модулі зв'язуються з даним модулем і через цей компонент виконують роботу з даними.

Інтерфейс даного програмного продукту побудований за стандартом MDI (MultiDocument Interface). Такий підхід забезпечує доступ користувачу до довільного вікна програми. Основне вікно програми описане в модулі Авторизація. Як видно з рис. 2.2 з цього вікна здійснюється доступ до проміжних, а від них до всіх інших дочірніх вікон.

Доступ до даних забезпечується компонентами ADOTable та ADOQuery. Перший з них призначений для роботи з таблицями в цілому, а другий для задання SQL-запитів. Також компонент ADOQuery підтримує параметризовані запити, тобто запити певні параметри яких можна задати із зовнішньої програми. Як видно з назви дані компоненти використовують механізм ADO, та потребують посилання на компонент ADOConnection, що утворює зв'язок з базою даних.

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

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

Рис. 2.3. Вікно авторизації (модуль Avtor)

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

а) б)

в)

Рис. 2.4.Головні вікна: а)адміністратора (модуль GVA); б) робітника (модуль GVP); в) клієнта (модуль GVK)

Модуль ObRob (рис. 2.5) призначений для виведення інформації про робітників автосервісу. За його допомогою ми можемо додавати, видаляти та редагувати інформацію про працівників автосервісу.

Рис. 2.5. Вікно обліку робітників (модуль ObRob)

Модулі ObKl (рис. 2.6) та ObPos (рис. 2.7) аналогічні до попереднього, відмінність тільки в полях таблиці, з якою відбувається взаємодія.

Рис. 2.6. Вікно обліку клієнтів (модуль ObKl)

Рис. 2.7. Вікно обліку послуг (модуль ObPos)

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

Рис. 2.8. Вікно формування звіту (модуль Zvit)

При відкритті вікна StanZvern (рис. 2.9) адміністратор має можливість переглянути які клієнти вже оплатили надані автосервісом послуги.

Рис. 2.9. Вікно стану оплати квитанцій (модуль StanZvern)

Для користувача, що ввійшов під статусом «робітник» доступний модуль NovZaj (рис. 2.10), в якому відображаться тільки ті заявки, що позначені статусом «Нова».

Рис. 2.10. Вікно нових заявок (модуль NovZaj)

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

Рис. 2.11. Вікно перегляду не виконаних заявок (модуль ZajVProc)

Наступним модулем, доступним для працівника, являється Anketa (рис. 2.12) за допомогою цього модуля працівник додає нового клієнта до бази даних.

Рис. 2.12. Вікно реєстрації клієнта (модуль Anketa)

В разі успішної реєстрації працівнику відкривається вікно NovKl (рис. 2.13), в якому зазначається унікальний номер постійного клієнта.

Рис. 2.13. Вікно успішної реєстрації (модуль NovKl)

Останнім модулем, який доступний для працівника являється OformlZ (рис. 2.14). В даному вікні працівник зазначає номер постійного клієнта, який звернувся до автосервісу, зазначає номер квитанції, номер та марку автомобіля, з яким буде відбуватись робота, вказується причина звернення та вид передбачених робіт, а також дата прийому, термін виконання послуг та унікальний номер працівника, який оформив заявку.

Рис. 2.14. Вікно оформлення заявки (модуль OformlZ)

Після заповнення полів попередньої форми працівнику за допомогою модуля Zvern (рис. 2.15) надається інформація про успішне оформлення заявки.

Рис. 2.15. Вікно сформованого звернення (модуль Zvern)

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

Рис. 2.16. Вікно оплати послуг (модуль Kvut)

Рис. 2.17. Приклад сформованої квитанції

8. ВИКЛИК І ЗАВАНТАЖЕННЯ ПРОГРАМИ

Для виклику програми потрібно запустити на виконання файл Avtoservis.exe. Після цього з'явиться вікно авторизацції.

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

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

Рис. 3.1. Діаграма прецедентів.

9. ВХІДНІ ДАНІ

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

10. ВИХІДНІ ДАНІ

Вихідними даними даної програми є звіт сформований на основі наданих послуг за зазначений період та квитанції оплати послуг

11. ОБ'ЄКТ ВИПРОБУВАНЬ

Об'єктом випробувань є програмний модуль «Автосервіс».

12. МЕТА ВИПРОБУВАНЬ

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

13. ВИМОГИ ДО ПРОГРАМИ

Вимоги до програми визначаються технічним завданням виданим на кафедрі КСМ. Програмний продукт повинен володіти наступними особливостями:

- цілісність даних;

- достовірність даних;

- зручність інтерфейсу.

14. ЗАСОБИ І ПОРЯДОК ВИПРОБУВАНЬ

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

Клієнтська ЕОМ з наступними характеристиками:

процесор Intel Pentium, з тактовою частотою 1,86 ГГц;

жорсткий диск об'ємом 500 Гб

оперативна пам'ять - 3 Гб

Сервер, технічні характеристики якого визначаються вимогами до MS SQL Server.

Випробування проводились в такому порядку:

завантаження програми;

ввід даних про нового працівника;

реєстрація нового клієнта;

оформлення заявки;

зміна стану заявки;

оплата заявки та перегляд квитанції;

перегляд звіту щодо наданих послуг в визначений період.

15. РЕЗУЛЬТАТИ ВИПРОБУВАНЬ

При введенні даних про нового працівника вони додаються до бази даних (рис. 5.1)

Рис. 5.1. Новий працівник в таблиці робітників

Далі при повторному вході в програму вносимо авторизаційні дані нового робітника (рис.5.2)

Рис. 5.2. Внесення авторизаційних даних нового робітника

Реєструємо нового клієнта, як показано на рис. 5.3.

Рис. 5.3. Реєстрація нового клієнта

В результаті програма присвоює нашому клієнту його персональний номер, який використовується при оформленні заявок (рис. 5.4)

Рис. 5.4. Повідомлення про успішну реєстрацію нового клієнта

Тепер формуємо заявку для нового клієнта, вказавши в полі «номер працівника» номер щойно зареєстрованого працівника (рис.5.5)

Рис. 5.5. Реєстрація нової заявки

Після натиснення кнопки «ОК» програма повідомляє на про формування нового звернення (рис. 5.6.)

Рис. 5.6. Повідомлення про сформоване звернення

Далі від імені працівника ми змінюємо стан заявки з «Нова» на «В процесі» та «Виконана» як показано на зображеннях рис. 5.7 (а) та рис 5.7. (б) відповідно.

(а)

(б)

Рис. 5.7. Зміна стану заявки на: а) в процесі; б) виконана

Розлогінюємось та заходимо під іменем нового клієнта, як це показано на рис 5.8.

Рис. 5.8. Вхід в програму під іменем клієнта

Перевіряємо чи з'вилась заявка для даного клієнта і чи знаходиться вона у стані «виконана» (рис. 5.9)

Рис. 5.9. Перевірка заявок

Так як заявка вже виконана то ми можемо її оплати, для цього в вікні оплати вносимо номер квитанції, яку ми збираємось оплатити на натискаємо «Перевірити» для того щоб переконатись втому що це потрібна нам квитанція, як це показано на рис. 5.6.

Рис. 5.6. Перевірка даних в квитанції

Натискаємо кнопку «Оплатити» і квитанція змінює свій стан на «оплачена». Також при бажанні ми можемо отримати квитанцію для друку, для чого натискаємо на відповідну кнопку в вікні (рис. 5.7).

Рис.5.7. Сформована квитанція

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

Рис. 5.8. Перевірка активних заявок

Тепер заходимо від імені адміністратора і перевіряємо стан оплати квитанцій (рис. 5.9)

Рис. 5.9. Стан оплати квитанцій

І останнє що залишилось перевірити - формування звіту за визначений період, як це показано на рис. 5.10.

Рис. 5.10. Формування звіту

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

ДЖЕРЕЛА ВИКОРИСТАНІ ПРИ РОЗРОБЦІ

Энго Ф. Как программировать на C++ : Пер. с англ. - К.: ДиаСофт, 1999. - 430 с.

Баас Р., Фервай М., Гюнтер Х. C++: для пользователя: Пер. с нем. - К.: BHV, 2000 - 496 с.

Гофман В.Э., Хоменко А. Д. C++ 6. - СПб.: Питер, 2003.

- 1145 с.

Вескес Дж. Л., Гандерлоу М., Чипмен М. Access и SQL Server. Руководство разработчика. - М.: Лори, 1997. - 362 с.

Мартин Грабер. Справочное руководство по SQL. - М.: Лори, 1997. - 291 с.

Размещено на Allbest.ru

...