Этап 1. Анализ и проектирование ИС

Назначение анализа

Анализ нужен, чтобы до написания кода понять, какие данные хранит система, кто с ними работает и какие ограничения должны выполняться. Для настольной ИС важно заранее определить не только таблицы, но и окна приложения: вход, регистрацию, главное меню, справочники, операции и административные разделы.

Например, в предметной области «Библиотека» нельзя начать с формы BooksForm, пока не определено, что книга связана с автором, имеет инвентарный номер и может быть выдана читателю.

Роли и права

Роль определяет, какие окна и действия доступны пользователю. Роль хранится в базе данных, а интерфейс приложения при запуске скрывает или блокирует недоступные элементы.

Роль	Возможности
admin	управление пользователями, просмотр журнала входов, полный CRUD
operator	работа с основными данными без управления пользователями
user	просмотр или ограниченные действия по варианту

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

Функциональные и нефункциональные требования

Функциональные требования описывают, что делает система. Нефункциональные требования описывают, как именно она должна работать.

Тип требования	Пример для настольной ИС
Функциональное	пользователь может зарегистрироваться
Функциональное	оператор может добавить запись предметной области
Функциональное	администратор может открыть журнал входов
Нефункциональное	пароль хранится только в виде хэша
Нефункциональное	форма входа показывает понятное сообщение об ошибке
Нефункциональное	таблицы не теряют данные после перезапуска приложения

Требование должно быть проверяемым. Формулировка «сделать удобный интерфейс» слишком общая. Лучше: «в главном окне есть меню перехода к основным разделам, а в списках есть поиск по названию или ФИО».

Сущности и операции

Сущность — объект предметной области, который хранится в отдельной таблице. Операция — действие пользователя с сущностью.

Для библиотеки:

Сущность	Операции
Автор	добавить, изменить, удалить, найти
Книга	добавить, изменить, отметить доступность
Читатель	зарегистрировать, изменить контакты
Выдача книги	оформить выдачу, отметить возврат

Переход от предметной области к окнам

После выбора сущностей нужно понять, какие окна потребуются. Обычно одна справочная сущность превращается в форму списка и форму редактирования. Операционная сущность требует больше проверок.

Сущность	Окно списка	Окно редактирования	Особенность
Автор	AuthorsForm	ФИО, страна	простая справочная таблица
Книга	BooksForm	название, автор, год, номер	проверка уникального номера
Читатель	ReadersForm	ФИО, телефон, номер карты	проверка номера карты
Выдача	BookIssuesForm	книга, читатель, даты	нельзя выдать недоступную книгу

Такой переход помогает не потерять связь между анализом и будущим кодом.

Связь между проектированием и кодом удобно показать на модели. Если в таблице Books есть название, автор, год и инвентарный номер, то в приложении появляется такой класс:

public class Book
{
    public int Id { get; set; }
    public string Title { get; set; } = "";
    public int AuthorId { get; set; }
    public string AuthorName { get; set; } = "";
    public int? Year { get; set; }
    public string InventoryNumber { get; set; } = "";
    public bool IsAvailable { get; set; }
}

Ограничение «книгу нельзя выдать, если она недоступна» затем превращается в проверку перед сохранением операции:

if (!selectedBook.IsAvailable)
{
    MessageBox.Show("Эту книгу нельзя выдать: она уже недоступна.");
    return;
}

Границы системы

В проект не нужно включать все возможные функции предметной области. Достаточно выбрать завершенный фрагмент: справочники, одну основную операцию и системный модуль входа.

Граница примера для библиотеки:

• входит: книги, авторы, читатели, выдачи, пользователи;
• не входит: интеграция со сканером штрихкодов, печать актов, онлайн-каталог.

Жизненный цикл пользователя

В системах с авторизацией полезно описывать путь пользователя:

1. Пользователь открывает приложение.
2. Приложение показывает форму входа.
3. Новый пользователь переходит к регистрации.
4. После успешного входа открывается главное окно.
5. Главное окно настраивает меню по роли.
6. Пользователь работает с доступными разделами.
7. При выходе приложение возвращается к форме входа или закрывается.

Если этот сценарий описан заранее, проще реализовать переходы между формами и не открыть предметные разделы до авторизации.

В главном окне роль пользователя влияет на видимость разделов:

usersMenuItem.Visible = currentUser.RoleName == "admin";
loginAttemptsMenuItem.Visible = currentUser.RoleName == "admin";
booksMenuItem.Visible = currentUser.RoleName is "admin" or "operator";

Ошибки проектирования

Типичные ошибки:

• хранить роль пользователя текстом в каждой форме, а не в таблице ролей;
• хранить пароль открытым текстом;
• делать одну таблицу Data для разных сущностей;
• не задавать уникальность логина и инвентарного номера;
• создавать формы без связи с бизнес-сценариями.