89
Функции
менеджера
Регистрация заказа
Редактирование заказа
Закрытие заказа
Прогноз количества
заказов
Учет клиента
Работа со
справочниками
(добавление данных)
Оборудовнаие
Бренды
Модели
Запчасти
Неисправности
Рисунок 2.5 Дерево функций системы для менеджера.
Администратор системы обладает более расширенными возможностями.
Он производит первичное наполнение справочников, а также обеспечивает их
дальнейшее ведение, Кроме того, он также имеет возможность регистрации
пользователей, определение прав их доступа к системе. Дерево функций для
администратора представлено на Рисунке 2.6.
90
Функции
администратора
Регистрация заказа
Редактирование заказа
Закрытие заказа
Прогноз количества
заказов
Учет клиента
Управление
справочниками
Оборудование
Бренды
Модели
Запчасти
Неисправности
Работа с
пользователями
Добавление
Удаление
Редактирование
Назначение
модулей
Назначение прав
доступа
Рисунок 2.6 Дерево функций системы для администратора.
Сценарии диалога, формирующиеся на основе деревьев функций,
приведены на Рисунках 2.7 и 2.8.
91
Авторизация
1. Клиент
1.1 Добавить
1.2 Удалить
1.3 Редактировать
1.4. Обновить
1.5 Сохранить
Выход
Основные функции:
1.Клиент
2.Оборудование
3.Заказ
4.Анализ
5.Справочник
6.Выход
5. Справочник
1. Телефоны
2. Модели
3. Бренды
4.Запчасти
5. Неисправность
2. Оборудование
2.1 Добавить
2.2 Удалить
2.3 Редактировать
2.4. Обновить
2.5 Сохранить
3. Заказ
3.1 Добавить
3.2 Удалить
3.3 Редактировать
3.4. Обновить
3.5 Сохранить
5.1-5.5 Операции
1 Добавить
2. Обновить
3 Сохранить
4.Анализ
4.1-4.3 Операции
1 Выбор периода
2 Печать
3 Диаграмма
Рисунок 2.7 Сценарий диалога для инженера.
Авторизация
1. Клиент
1.1 Добавить
1.2 Удалить
1.3 Редактировать
1.4. Обновить
1.5 Сохранить
Выход
Основные функции:
1.Клиент
2.Оборудование
3.ЗАЯВКА
4.Анализ
5.Справочник
6.Пользователь
7.Выход
5. Справочник
1. Телефоны
2. Модели
3. Бренды
4.Запчасти
5. Неисправность
2. Оборудование
2.1 Добавить
2.2 Удалить
2.3 Редактировать
2.4. Обновить
2.5 Сохранить
3. ЗАЯВКА
3.1 ПРИНЯТЬ
3.2 Удалить
3.3 Редактировать
3.4. Обновить
3.5 Сохранить
5.1-5.5 Операции
1 Добавить
2 Удалить
3 Редактировать
4. Обновить
5 Сохранить
6.Пользователь
6.1 Добавить
6.2 Удалить
6.3 Редактировать
6.4. Обновить
6.5 Сохранить
6.6 Назначить права доступа
4.Анализ
4.1-4.3 Операции
1 Выбор периода
2 Печать
3 Диаграмма
Рисунок 2.8 Сценарий диалога для администратора.
92
2.3.2 Характеристика базы данных
Первый этап проектирования базы данных состоит в разработке
концептуальных моделей данных для каждого из существующих типов
пользователей создаваемого приложения.
Концептуальное проектирование – это конструирование информационной
модели предприятия, не зависящей от каких-либо условий реализации.
Логический уровень – точка зрения пользователя. Это абстрактный взгляд
на данные. На нем используются данные в таком виде, в каком они известны в
реальном мире. Объектам модели (сущностям и атрибутам) даются имена,
понятные широкому кругу специалистов.
Создание локальных концептуальных моделей данных полностью не
зависит от типа СУБД, языка программирования, типа компьютера, ОС,
приложений и т.д.
Связи между сущностями представляют специфические отношения
(отношение типа родитель - потомок), то есть когда каждый экземпляр
родительской сущности ассоциирован с произвольным количеством экземпляров
второй сущности, называемой потомком, а каждый экземпляр сущности -
потомок ассоциирован с одним экземпляром сущности-родителя.
Неспецифические отношения (отношения типа много ко многому) заменяются
на специфические при помощи введения связной сущности.
Специфические отношения могут быть идентифицирующими, не
идентифицирующими, так же возможны отношениями категоризации.
Идентифицирующие отношения подразумевают, что сущность-потомок
однозначно определяется своей связью с сущностью-родителем.
Не идентифицирующие отношения подразумевают, что каждый экземпляр
сущности-потомка может быть однозначно идентифицирован без связанного с
ним экземпляра сущности-родителя. Не идентифицирующее отношения
отображаются на диаграмме пунктиром.
Установив связи, которые будут иметь место в создаваемой модели,
необходимо определить кардинальность каждой из них. Каждая связь может
иметь кардинальность либо "один к одному" (1:1), либо "один ко многим" (1:М),
либо "многие ко многим" (М:N). Кроме того, следует проанализировать степень
93
участия каждой из сущностей в конкретном типе связи. Отношения связи
характеризуются мощностью отношения, которая служит для обозначения
количества экземпляров сущностей-потомков, которые могут существовать для
каждого экземпляра сущности-родителя. Существуют следующие варианты
указания мощности:
“ “ – 0,1 или более;
“P” 1,2 или более;
“Z” 0 или 1;
“N” в качестве N указывается конкретное число.
В ходе анализа функций программы были выделены следующие сущности
и реквизиты (Таблица 2.3):
Таблица 2.3
Сущности и реквизиты
Клиент
Код_клиента
Фамилия
Имя
Отчество
Номер_телефона
Город
Улица
Дом
Квартира
Код_телефона
Код_модели
Код_бренда
Модели_оборудования
Код_модели
Наименование
Код_бренда
Бренды
Код_бренда
Наименование
Дефекты
Код_дефекта
Наименование
Стоимость_ремонта
Дефекты_в_заказе
Код_записи
Код_дефекта
Код_заказа
Код_клиента
Код_оборудования
Код_модели
Код_бренда
Код_запчасти
94
Код_сотрудника
Код_типа
Заказ
Код_заказа
Дата_начала_работы
Дата_окончания_работы
Стоимость
Код_клиента
Код_оборудования
Код_модели
Код_бренда
Код_запчасти
Код_сотрудника
Код_типа
Запчасти
Код_запчасти
Наименование
Стоимость
Код_ оборудования
Код_модели
Код_бренда
Оборудование
Код_ оборудования
Код_модели
Код_бренда
Сотрудники
Код_сотрудника
Логин
Пароль
Номер_телефона
Фамилия
Имя
Отчество
Код_типа
Схема связи Таблиц базы данных представлена на Рисунке 2.9.
95
Рисунок 2.9 Схема связи Таблиц базы данных
Соответствие таблиц приведено ниже:
Таблица Client - клиенты
Таблица Brands - бренды
Таблица Defect - неисправности
Таблица Mobile - оборудование
Таблица Model - модель
Таблица Order - заявка
Таблица OrderDefect – неисправности в заявке
Таблица Spare_part – запасные части
Таблица Staff – сотрудники.
Характеристика Таблиц базы данных представлена на Рисунках ниже.
96
Рисунок 2.10 Таблица Client
Рисунок 2.11 Таблица Brands
Рисунок 2.12 Таблица Defect
Рисунок 2.13 Таблица Mobile(Оборудование)
Рисунок 2.14 Таблица Model
97
Рисунок 2.15 Таблица Order
Рисунок 2.16 Таблица OrderDefect
Рисунок 0.17 Таблица Spare_part
Рисунок 2.18 Таблица Staff
98
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
Структурная схема пакета ИС приведена на Рисунке 2.19.
Программные модули
Серверный
компонент
TdmServer
TdssmRemoteData
Клиентский
компонент
TdmData
SQLConnection
TClientDataSet
TDataSetDrovider
TDataSource
Рисунок 2.19 Структурная схема пакета ИС учета ремонта компьютерного
оборудования
Программная система состоит из следующих уровней: клиент; сервер
приложений; сервер базы данных (Рисунок 2.20).
Клиент
Сервер приложение
Сервер баз данных
Рисунок 2.20 Структура программной системы
Клиент это интерфейсный компонент, который представляет первый
уровень, собственно приложение для конечного пользователя. Первый уровень
не имеет прямых связей с базой данных и бизнес-логики.