Розробка автоматизованого модулю обліку сервісного обслуговування автомобілів (стр. 5 из 6)
11. Схема інформаційних зв’язків представлена на рис.2.6
Рис.2.7 Схема інформаційних зв’язків
По цих зв’язках передається наступна інформація:
1 – Паспорт, технічний паспорт автомобіля, договір на обслуговування, заявка на обслуговування.
2 – Акт технічного стану автомобіля
3 – файли НДІ: довідник-клієнтів, довідник товарів, довідник запчастин, довідник цін на обслуговування, довідник майстрів сервісу.
4 – Оперативна таблиця замовлень, оперативна таблиця специфікацій замовлень.
5 – Звіт по клієнтам, звіт по запчастинами.
6 – Звіти за замовленнями.
По зв’язках 1, 2, 3 - йде вхідна інформація, 4, 5, 6 - вихідна інформація.
Вихідна інформація.
Облік та опис вихідних повідомлень наведені у таблиці 2.1.
Вхідна інформація.
Вхідною інформацією для даної задачі є пакет документів, необхідний для проведення сервісного обслуговування.
Облік та опис вхідних документів наведені в таблиці 2.2.
Таблиця 2.1.
Облік та опис вихідних повідомлень
| Ідентифікатор (код повідомлення) | Назва вихідного повідомлення | Форма представлення | Періодичність | Термін видачі | Одержувач | Призначення |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 0219901 | «Звіт за замовленнями» | ВК | Щоденно | Щоденно | Керівник сервісного центру | Для виявлення поламок, які найчастіше стаються та аналізу діяльності підприємства. |
| 0219902 | «Звіт по клієнтам» | ВК | Щоденно | Щоденно | Менеджер відділу сервісного обслуговування | Для визначення найчастіше звертающихся аналізу діяльності підприємства. |
| 0219903 | «Звіт по запчастинам» | ВК | Щоденно | Щоденно | Менеджер відділу сервісного обслуговування | Для визначення запчастин, які найчастіше виходять зі строю. |
Таблиця 2.2.
Облік та опис вхідних документів
| Ідентифікатор документу | Назва документу | Термін надання | Частота надання | Постачальник документа |
| 1 | 2 | 3 | 4 | 5 |
| 1 | 2 | 3 | 4 | 5 |
| 0219701 | Заявка на обслуговування | за запитом | за запитом | Клієнт |
| 0219702 | Паспорт | за запитом | за запитом | Клієнт |
| 0219703 | Технічний паспорт автомобіля | за запитом | за запитом | Клієнт |
| 0219704 | Договір на обслуговування | за запитом | за запитом | Клієнт |
| 0219705 | Акт технічного стану автомобіля | За запитом | За запитом | Робітник сервісу |
Характеристика масиву вхідної інформації представлена в таблиці 2.3
Таблиця 2.3
Характеристика масивів вхідної інформації
| Назва масиву | Ідентифікатор | Тип масиву | Технологія формування |
| 1 | 2 | 3 | 4 |
| Довідник клієнтів | SPR_KLIENTI | НДІ | Формується в єдиній базі даних на підставі - паспорту, техпаспорту |
| Довідник моделей автомобілів | SPR_MODEL | НДІ | Формується в єдиній базі даних. |
| Довідник автомобілів клієнтів | SPR_AVTO | НДІ | Формується в єдиній базі даних на базі документу «Технічний паспорт автомобіля» |
| Довідник запчастин | SPR_ZAPCHASTI | НДІ | Формується в єдиній базі даних. |
| Довідник робітників | SPS_MASTERA | НДІ | Формується в єдиній базі даних. |
| Довідник робіт | SPR_ROBOT | НДІ | Формується в единій базі даних. |
| Оперативна таблиця специфікацій замовлень | OPR_SPEC | Оперативний | Формується в єдиній базі даних на підставі акту технічного стану. |
| Оперативна таблиця замовлень | OPR_ZAKAZ | Оперативний | Формується в единій базі данних на підставі заявки клієнта, паспорту, договору на обслуговування та специфікації. |
Форми вхідних документів представлені у додатках.
Форми вихідних документів представлені у додатках (Д, Е, Ж)
Математична постановка задачі.
В даній дипломній роботі розглядається задача «Облік сервісного обслуговування автомобілів», в якій використовуються формули для розрахунку загальної вартості робіт за замовленнями та загальна вартість запчастин за замовленням сервісного центру.
Для підрахунку загальної вартості замовлень використовується формула:
де:
- загальна сума робіт за замовленнями; 
- сума робіт першого замовлення; 
- сума робіт другого замовлення; 
- сума робіт n-ого замовленням. 
де:
- загальна сума запчастин за замовленнями; 
- сума запчастин за першим замовленням; 
- сума запчастин за другим замовленням; 
- сума запчастин n-го замовлення2.1.4 Опис інформаційних потоків
Опис інформаційних потоків представлений на діаграмах DFD.
Рис.2.9. Контекстна діаграма DFD модуля «Облік сервісного обслуговування авто мілів»
Рис.2.10. Діаграма DFD декомпозиції 1-го рівня модуля «Облік сервісного обслуговування автомобілів»
2.1.5 Проектування структури бази даних
Логічна модель БД розробляємого модуля «Облік сервісного обслуговування автомілів» відображен на рис. 2.11.
Рис.2.11 Логічна модель БД розробляє мого модуля «Облік сервісного обслуговування автомобілів»
Фізична модель БД розробляємого модуля «Облік сервісного обслуговування автомобілів» відображена на рис. 2.12
Рис.2.12 Фізична модель БД розробляємого модуля «Облік сервісного обслуговування автомобілів».
2.2 Розроблення програмного продукту «Облік сервісного обслуговування автомобілів»
2.2.1 Розроблення інтерфейсу програмного продукту
Схема діаграм технологічного процесу UML реалізовується в програмному середовищі RationalRose 2003. Задача відображається за допомогою Activity diagram - діаграми описів технологій, процесів, функцій. У даних діаграмах (рис. 2.13 – 2.16) показуються процеси та технологія взаємодії користувача з програмним продуктом поетапно по кожному пункту меню.
Рис.2.13. Схема технологічного процесу. Головне меню системи
Рис.2.14. Схема технологічного процесу. Довідники
Рис.2.15. Схема технологічного процесу. Оперативна інформація
Рис.2.16. Схема технологічного процесу. Меню «Формування звітів»
2.2.2 Склад та взаємодія програмних модулів
Діаграми станів визначають всі можливі стани, у яких може знаходитися конкретний об'єкт, а також процес зміни станів об'єкта, в результаті настання деяких подій.
На рис.2.17 наведено діаграми станів програмного продукту «Облік сервісного обслуговування автомобілів». На малюнку можна спостерігати процес зміни станів об'єкту в залежності від впливу зовнішніх факторів.
Діаграма класів з операціями та атрибутами наведена в п. 2.1.4. «Опис інформаційних потоків» на рис. 2.8.
2.2.3 Результати тестування програмного продукту
В ході розробки програмного продукту модуля «Облік сервісного обслуговування автомобілів» було виконано:
- функціональне тестування програмного продукту;
- тестування графічного інтерфейсу;
- тестування введення даних.
Всі види тестування виконувались вручну.
Функціональне тестування полягало в розробці контрольного прикладу заповнення БД даними контрольного прикладу, отримання вихідних документів.
В результаті функціонального тестування програмного продукту модуля «Облік сервісного обслуговування автомобілів» було зроблено висновок, що розроблений програмний продукт має повну функціональність, передбачену проектною документацією, всі звіти формуються вірно і в повному обсязі.
Тестування графічного інтерфейсу полягало в перевірці:
- розміру і правильності розміщення компонентів на формах, зручності доступу до них;
- правильності роботи всіх елементів і компонентів (випадаючих списків, полів введення і кнопок).
В результаті тестування графічного інтерфейсу було зроблено висновок, що графічний інтерфейс програмного продукту модуля «Облік сервісного обслуговування автомобілів» реалізовано в обсязі, передбаченому проектною документацією. Функціонування графічного інтерфейсу виконується без помилок.
Заповнені даними первинні документи, автоматизовано сформовані в задачах модуля, наведені в табл. 2.3 − 2.4