Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Пояснительная записка.docx
Скачиваний:
8
Добавлен:
28.10.2018
Размер:
1.17 Mб
Скачать

2 Постанова задачі

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

Користувачу буде надана можливість створення довільного запиту, яка допоможе досвідченому користувачу зробити свою роботу з даними простішою.

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

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

  1. Додавання, редагування та видалення: Заяв, Клієнтів, Типів заяв, Пільг для клієнта;

  2. Оформлення заяви про втрату чи знахідку: ID-заяви, тип заяви, категорія, заголовок заяви, її опис, ПІБ клієнта;

  3. Перегляд даних про заяви, клієнтів, можливі типи (знахідка чи втрата) заяви;

  4. Пошук за всіма таблицями;

  5. Можливість звернення до бази даних з довільним запитом;

  6. Видача інформації за запитами:

  1. Для обраної заяви вивести усі дані про клієнта, що її оформив;

  2. Для обраного клієнта вивести усі оформлені ним заяви;

  1. Формування звітів:

  1. Інформація про клієнтів та заяви, які він оформив;

  2. Звіт по витратам клієнтів на оформлення заяв з урахуванням пільг;

  3. Звіт за обраною заявою;

  4. Функція посилання повідомлення клієнту на електронну пошту, що його заява була видалена з бази даних через закінчення строку її дії (один рік).

Система має наступні обмеження:

  1. Один клієнт може мати багато оформлених ним заяв;

  2. Кожен тип заяви включає у себе багато оформлених заяв;

  3. Різні клієнти можуть мати однаковий вид пільги;

Кольорова схема в програмному продукті буде відповідати основним принципам розробки інтерфейсів та передбачає наявність стандартних елементів розробки та ОС Windows. Відсутність платних компонентів. Користувач не буде повинен адаптуватися до різноманітних особливостей програмного продукту.

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

Системою управління була обрана MS ACCESS. Мовою реалізації була обрана С#, оскільки є її хороші знання, які дають можливість створити програмний продукт з реалізацією повного функціоналу. Середою розробки була обрана MS Visual Studio 2010, яка є на цей час поширеною та популярною серед розробників програмного забезпечення.

3 Проектування бази даних

  1. UML – моделювання

Щоб мати більше уявлення о програмі та розширеного розуміння задачі, були построєні наочні UML - діаграми, які дають більш повний опис програмного продукту, який буде створений у графічному вигляді.

UML – мова графічного опису для об’єктного моделювання в області розробки програмного забезпечення. UML використовує графічні позначення для створення абстрактної моделі системи, яку називають UML - моделлю.

На рисунку 3.1 представлена діаграма прецедентів, яка більш наочно показує функціонал розробляє мого додатку.

Рисунок 3.1 – Діаграма прецедентів

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

На рисунку 3.4 приведена діаграма, котра показує, яким чином буде проводитися фільтрація в програмі.

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

Выход

Выход

Удаление

Добавление

Редактирование

Заполнение

Заполнено корректно

Выбор элемента

Заполнено корректно

Выбор элемента

Да

Нет

Подтверждение

Да

Нет

Внесение изменений

Внесение в базу

Удаление из базы

Внесение в базу

Нет

Да

Рисунок 3.2 – Діаграма діяльності для додавання, редагування та видалення

Не выбрана

Выбор таблицы

Выбрана

Заполнение полей

Поиск в базе

Выдача результатов в таблицу

Рисунок 3.3 – Діаграма діяльності для пошуку

Выбор таблицы

Выбор полей

Выдача результатов

Выбор типа фильтрации

Рисунок 3.4 – Діаграма діяльності задачі фільтрації

Поиск просроченной заявки

Верная почта

Да

Нет

Формирование текста письма с предупреждением

Отправка письма клиенту, который оформил это заявление

Рисунок 3.5 – Діаграма діяльності задачі автоматизації

  1. ER - діаграма

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

Є такі сутності: «Клієнт» з властивостями ПІБ, Місто, Адреса, Ел. пошта, Телефон та Код пільги, які є мінімальним та оптимальним набором даних при використовуванні у базі даних; «Заява» з властивостями ID – заяви, Тип, Категорія, Заголовок, Опис, Дата оформлення, ПІБ; «Тип заяви» з властивостями Назва типу та Вартість послуги; «Пільги» з властивостями ID – пільги, Назва та Вартість знижки.

Сутність «Клієнт» пов’язана з сутністю «Заява» як один до багатьох. Сутність «Клієнт» з сутністю «Пільги» як багато до одного. Сутність «Заява» відноситься до її «Типу» як багато до одного. На рисунку 3.6 представлена ER – діаграма.

Пільги

Клієнт

1

1

Заява

1

Типи

Рисунок 3.1 – ER - діаграма ІС «Бюро знахідок»

  1. Схема бази даних у третій нормальній формі

В процесі побудови бази даних для програми та побудови ER – діаграми, ми отримали 4 таблиці: «Заява», «Клієнт», «Тип заяви» та «Пільги», кожна з котрих має свої ключі, свої унікальні назви полів. Розглянемо першу таблицю «Заява», щоб доказати, що вона знаходиться у третій нормальній формі.

Таблиця «Заява» має свій унікальний ключ – «ID – заяви», який ніколи не повторюється, тобто виключає можливість виникнення однакових кортежів. Також у таблиці нема упорядкування за рядками та стовпцями. Кожен з атрибутів таблиці має значення, які не повторюються, та мають різні назви (ID – заяви, Тип, Категорія, Заголовок, Опис, Дата оформлення, ПІБ), а також у таблиці рядки не мають ідентифікаторів окрім звичайних значень потенційних ключів. У таблиці усі атрибути залежать від одного ключа (ID – заяви) і немає транзитивної залежності, тобто таблиця «Заява» знаходиться у третій нормальній формі.

Таблиця 3.1 – Заява

ID-код *

Тип

Категорія

Заголовок

Опис

Дата оформлення

ПІБ

Таблиця 3.2 – Клієнт

ПІБ*

Місто

Адреса

Телефон

Ел. пошта

Код пільги

Таблиця 3.3 – Тип заяви

Тип*

Вартість

Таблиця 3.4 – Пільги

Код пільги*

Назва пільги

Розмір знижки

Рисунок 3.7 – Схема бази даних

Оптимізувавши структуру бази даних можна починати розробляти програмний продукт.