г
. Вибір послуг
. Підрахунок вартості слуг
. Висновок вартості послуг
. Проведення робіт згідно послугу
. Вибір матеріалу для усунення дефектів/несправностей
. Виявлення дефектів/несправностей
. Обчислення кінцевої суми за послуги
. Верифікація виконаної послуги
. Формування наряду виконаних робіт
. Зміна статусу послуги
. Друк звітів
. Контроль послуг
. Смс-оповіщення
. Бекап БД
. Журналювання
Інтерфейс програми повинен бути інтелектуально зрозумілий користувачеві. При вході в систему повинна з'явитися форма авторизації, на якій повинні бути два текстових поля, призначені для введення в них логіна і пароля. Після того як користувач пройшов аутентифікацію, він потрапляє на особисту сторінку з можливістю як вибору нової послуги, так і відмови від раніше обраних.
4.2 D-вимоги
Розробникам програмного забезпечення потрібна база для проектування та розроблення. Ця база складається з детальних вимог. Їх також називають конкретними вимогами, функціональними специфікаціями, вимогами розробниками або D-вимогами. D-вимоги складаються з повного списку конкретних властивостей і функціональності, яку повинна мати програма, сформульованих в подробицях. D-вимоги повинні бути погоджені з С-вимогами.
Існують декілька типів вимог:
) функціональні вимоги - описані в C-вимогах (Див. 4.1 С-вимоги).
) Нефункціональні вимоги:
- продуктивність - програма повинна миттєво реагувати на дії користувача.
- надійність і безпека - програма повинна забезпечувати надійність і таємність зберігання і передачі інформації.
- обробка помилок - у разі помилки програма повинна запропонувати користувачеві відправити звіт.
- інтерфейсні вимоги - для зв'язку з БД використовується SQL контролер. SQL вибраний як унікальний засіб запитів до БД.
- обмеження - програма повинна бути написана на Java. Це дозволить створити додаток, яке задовольняє вимогам замовника та тимчасовим обмеженням.
) зворотні вимоги:
Програма не повинна формувати звіти по керуючому персоналу.
. Чернової ескіз
Проектування графічного інтерфейсу користувача (ГПИ) зараз представляє собою міждисциплінарний напрям, що включає до свого складу аспекти дизайну, аналізу вимог, системного проектування, програмування, ергономіки, соціальної психології та багато інших питань.
Для ГПИ при вирішенні даної задачі немає необхідності підключати якісь спеціалізовані графічні бібліотеки, достатньо коштів HTML, CSS і JavaScript.
На малюнку 5.1 представлений чорновий ескіз ГПИ одній зі сторінок особистого кабінету директора.
Малюнок 5.1 - Друк звітів, права доступу Директор
6. Ескізний проект
6.1 Діаграма використання
Діаграма Use Case відображає всі дії, використовувані в інформаційній системі. Діаграма варіантів використання наведена в додатку Г.
6.2 Діаграма діяльності для системи в цілому
Діаграми діяльності (activity diagram) UML відображають управлінський аспект реалізації варіанту використання і включають в свій склад діяльності, стану, рішення, знаки синхронізації, а також переходи між ними. Діаграма діяльності для системи наведена в додатку Д. [1]
6.3 Діаграма стану для одного варіанта використання
В UML під станом розуміється абстрактний метаклассом, використовуваний для моделювання окремої ситуації, протягом якої має місце виконання деякої умови. Стан може бути задане у вигляді набору конкретних значень атрибутів класу або об'єкта, при цьому зміна їх окремих значень буде відображати зміну стану модельованого класу або об'єкта. Діаграма стану для варіанту використання Формування наряду виконаних робіт наведена в додатку Ж.
6.4 Діаграми послідовності
Діаграми послідовності (sequence diagram) UML відображають комунікаційний аспект реалізації варіанту використання і включають в свій склад об'єкти і сполучення між ними. Діаграми послідовності наведені в додатку Е.
