Лабораторна робота _ проект

Постановка завдання

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

В загальних рисах робота системи: у користувача виникає проблема, він її вносить в систему підприємства, і потім хтось ( сисадмін , спец. працівник ) усуває дану проблему. Звичайна програма по роботі з БД. Великі складнощі представляють різні супутні умови і загальна реалізація програми.

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

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

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

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

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

Це короткий опис системи, яку ми будемо створювати.

І тепер почнемо, як звичайно, з створення нового проекту: створимо новий проект по типу Basic, так як він має всі необхідні файли, і як-небудь назвемо. Проект буде називатися AppUsersProblem. Надалі ми його будемо розвивати і наповнювати.

Виділення сутностей і створення бд

Виділення сутностей

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

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

Створимо для всіх сутностей класи.

Отже, сутність Користувач у нас буде з такими властивостями:

• Id

• ім'я користувача

• Логін, під яким користувач буде входити в систему

• Пароль для входу в систему

• Посада

• Відділ, в якому користувач працює

• Роль (адміністратор, модератор, виконавець, простий користувач)

Тому додамо в проект в папку Models перший клас - назвемо його User:

Тепер додамо другу модель Role, яка представлятиме статус користувача:

Клас заявки

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

Отже, додамо в папку Models наступний клас Request:

public string File { get; set; } - дана властивість у нас буде зберігати шлях до файлу зображення з помилкою (за наявності).

Для властивості public DateTime Date додатково атрибутом визначається формат дати, оскільки система може неправильно працювати з датою. А таким чином ми даємо детальну вказівку, як дату треба інтерпретувати.

Тепер у файл з класом Request додамо клас Lifecycle, який відповідатиме за життєвий цикл заявки:

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

Також в файл класу заявки додамо два допоміжних перерахування:

// Перерахування для статусу заявки

// Перерахування для пріоритету заявки

Перерахування RequestStatus місти всі статуси заявки. Воно ув'язується з властивістю Status у класу Request .

Перерахування RequestPriority містить всі можливі пріоритети, які користувач може присвоїти заявці: низький, середній, високий, критичний. Для установки пріоритету в класі Request призначене властивість Priority.

Інші класи

Тепер додамо всі інші класи сутностей. Ці класи будуть виглядати набагато простіше. Отже, додамо в папку Models клас Category:

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

Тепер додамо модель відділу Department :

Тут же визначимо пов'язаний з цим клас Activ :

Ця модель буде представляти актив - кабінет, що належить певному відділу. У процесі заповнення заявки користувач зможе вказати кабінет, в якому відбувається проблема.

Таким чином, ми створили весь набір моделей, які будуть використовуватися в додатку, і можемо перейти до етапу - створення БД і таблиць.