76
Функции инженера
Регистрация заказа
Редактирование заказа
Закрытие заказа
Прогноз количества
заказов
Учет клиента
Работ а со
справочниками
(добавление данных
)
Оборудовнаие
Бренды
Мод е ли
Запчасти
Неисправности
Рисунок 2.5 Дерево функций системы для инженера
Администратор системы обладает более расширенными возможностями.
Он производит первичное наполнение справочников, а также обеспечивает их
дальнейшую эксплуатацию. Кроме того, он также имеет возможность
регистрации пользователей, определение прав их доступа к системе. Дерево
функций для администратора представлено на Рисунке 2.6.
77
Функции
администратора
Регистрация заказа
Редактирование заказа
Закрытие заказа
Прогноз количества
заказов
Учет клиента
Управлени е
справочниками
Оборудование
Бренды
Мод е ли
Запчасти
Неисправности
Работ а с
пользователями
Добавление
Удалени е
Редактирование
Назначение
моду лей
Назначение прав
доступа
Рисунок 2.6 Дерево функций системы для администратора
Сценарии диалога, формирующиеся на основе деревьев функций,
приведены на Рисунках 2.7 и 2.8.
78
Авториза ция
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 Сценарий диалога для администратора
79
2.3.2 Характеристика базы данных
Первый этап проектирования базы данных состоит в разработке
концептуальных моделей данных для каждого из существующих типов
пользователей создаваемого приложения.
Концептуальное проектирование – это конструирование информационной
модели предприятия, не зависящей от каких-либо условий реализации.
Логический уровень – точка зрения пользователя. Это абстрактный взгляд
на данные. На нем используются данные в таком виде, в каком они известны в
реальном мире. Объектам модели (сущностям и атрибутам) даются имена,
понятные широкому кругу специалистов.
Создание локальных концептуальных моделей данных полностью не
зависит от типа СУБД, языка программирования, типа компьютера, ОС,
приложений и т.д.
Связи между сущностями представляют специфические отношения
(отношение типа родитель - потомок), то есть когда каждый экземпляр
родительской сущности ассоциирован с произвольным количеством экземпляров
второй сущности, называемой потомком, а каждый экземпляр сущности - потомок
ассоциирован с одним экземпляром сущности-родителя. Неспецифические
отношения (отношения типа много ко многому) заменяются на специфические
при помощи введения связной сущности.
Специфические отношения могут быть идентифицирующими, не
идентифицирующими, так же возможны отношениями категоризации.
Идентифицирующие отношения подразумевают, что сущность-потомок
однозначно определяется своей связью с сущностью-родителем.
Не идентифицирующие отношения подразумевают, что каждый экземпляр
сущности-потомка может быть однозначно идентифицирован без связанного с
ним экземпляра сущности-родителя. Не идентифицирующее отношения
отображаются на диаграмме пунктиром.
Установив связи, которые будут иметь место в создаваемой модели,
необходимо определить кардинальность каждой из них. Каждая связь может
иметь кардинальность либо "один к одному" (1:1), либо "один ко многим" (1:М),
80
либо "многие ко многим" (М:N). Кроме того, следует проанализировать степень
участия каждой из сущностей в конкретном типе связи. Отношения связи
характеризуются мощностью отношения, которая служит для обозначения
количества экземпляров сущностей-потомков, которые могут существовать для
каждого экземпляра сущности-родителя. Существуют следующие варианты
указания мощности:
• “ “ – 0,1 или более;
• “P” 1,2 или более;
• “Z” 0 или 1;
• “N” в качестве N указывается конкретное число.
В ходе анализа функций программы были выделены следующие сущности
и реквизиты (Таблица 2.3):
Таблица 2.3
Сущности и реквизиты
Клиент
Код_клиента
Фамилия
Имя
Отчество
Номер_телефона
Город
Улица
Дом
Квартира
Код_телефона
Код_модели
Код_бренда
Модели_оборудования
Код_модели
Наименование
Код_бренда
Бренды
Код_бренда
Наименование
Дефекты
Код_дефекта
Наименование
Стоимость_ремонта
Дефекты_в_заказе
Код_записи
Код_дефекта
Код_заказа
Код_клиента
Код_оборудования
Код_модели
81
Код_бренда
Код_запчасти
Код_сотрудника
Код_типа
Заказ
Код_заказа
Дата_начала_работы
Дата_окончания_работы
Стоимость
Код_клиента
Код_оборудования
Код_модели
Код_бренда
Код_запчасти
Код_сотрудника
Код_типа
Запчасти
Код_запчасти
Наименование
Стоимость
Код_ оборудования
Код_модели
Код_бренда
Оборудование
Код_ оборудования
Код_модели
Код_бренда
Сотрудники
Код_сотрудника
Логин
Пароль
Номер_телефона
Фамилия
Имя
Отчество
Код_типа
Схема связи Таблиц базы данных представлена на Рисунке 2.9.
82
Рисунок 2.9 Схема связи Таблиц базы данных
Характеристика Таблиц базы данных представлена на Рисунках ниже.
Рисунок 2.10 Таблица Client
Рисунок 2.11 Таблица Brands
83
Рисунок 2.12 Таблица Defect
Рисунок 2.13 Таблица Mobile
Рисунок 2.14 Таблица Model
Рисунок 2.15 Таблица Order
Рисунок 2.16 Таблица OrderDefect
84
Рисунок 2.17 Таблица Order_spare_part
Рисунок 2.18 Таблица Spare_part
Рисунок 2.19 Таблица Staff
2.3.3 Структурная схема пакета (дерево вызова программных
модулей)
Структурная схема пакета ИС приведена на Рисунке 2.20.
85
Программные модули
Серверный
компонент
TdmServer
TdssmRemoteData
Клиентский
компонент
TdmData
SQLConnection
TClientDataSet
TDataSetDrovider
TDataSource
Рисунок 2.20 Структурная схема пакета ИС учета ремонта компьютерного
оборудования
Программная система состоит из следующих уровней: клиент; сервер
приложений; сервер базы данных (Рисунок 2.21).