71
Рис. 2.6 Дерево функций администрат ора
Основными функциями менеджера яв ляется работа с проект ами.
Рис. 2.7 Дерево функций менеджера
Исполнитель выполняет проект и делает отметку об этом.
Функции
администратора
Служебные Общие
Работа со справочниками
Работа с проектами
Добавление
Удаление
Просмотр по статусам
Формирование нового
проекта
Удаление
Формирование базы
знаний
Добавление/
редактирование
разделов и
подразделов
Добавление/
редактирование
записей
Функции
менеджера
Служебные Общие
Просмотр
справочников
Работа с проектами
Клиенты
Просмотр по
статусам
Формирование
нового проекта
Назначение
инженера
Просмотр базы
знаний
Просмотр
разделов и
подразделов
Просмотр записей
Просмотр файлов
проекта
72
Рис. 2.8 Дерево функций сотрудника
Минимизация трудовых затрат и цены будет н апрямую зависеть от того,
как точно и рацион ал ьно подготовлен технологический процесс.
Подобный процесс, обычно, включает нескольких самостоятельных
этапов. Главным достижением первого этапа считается регистрация, п ол учени е
и передача данных для их последующего анализа. Итогом всего этого становится
подготовка отдельного документа. Суть второго этапа заключается в переносе
данных из аналоговой формы на цифровые носители и начальное внедрение БД.
На третьем этапе уже происходит накопление, изменение и обработка
полученных данных.
Чтобы верно определить вариант технологического проц ес са, важно
учесть ряд требовании:
• Отслеживание точности обрабатываемой информации;
• Описание задач в часы, отведенные для этих дел;
• Малые трудовые и стоимостные затраты на создание;
• Подде ржка ЭВМ для повышения оператив ности процесса
обраб отки;
• Выполнение задачи в разных режимах.
Функции
специалиста
Служебные Общие
Просмотр
справочников
Работа с проектами
Клиенты
Просмотр по
статусам
Формирование
нового проекта
Удаление своего
проекта
Просмотр базы
знаний
Просмотр
разделов и
подразделов
Просмотр записей
Проекты
Добавление файлов
в проект
73
Исходя из описанных выше треб ований, лучше всего спроектировать
АРМ, помогающий поднять общ ую производит ел ьность и разд ел ить проц ес с
решения задачи.
На этапе анализа данных важно примен ять нормативно-справочную
информацию. Такой подход даст ряд преимуществ относительно скорости
выбора и сортировки. При этом требуется и начальный предварительный
просмотр пришедши х данных перед их описанием и выдачей. На этом этапе
производится важный выбор оправданного режима – диа л огового или пакетного.
Первый в а риант выступ ае т за минимизацию вмешательства пользователя в
технологию принятия ращения и процесс реализации задачи, отражая лишь
возможность в водить и исправлять данные, что часто проблемати чно для самого
исполнителя. На практике лучше и результатив нее справляется диалоговый
режим, поддерживающий гибкую связь и предоставляющий множест во
функций: удобств о в работе, защита от НСД, полноценное участие в решении
задачи, операт ивный доступ к данным в онла йн-режиме и адекватная
управляемость процессом, а также отличное осуществление переходов от одной
операции к другой.
Сейчас есть несколько диалоговых окон: меню, диалог на привычном
языке, меню команд.
В этом проекте применяется методика меню с многоуровневой
структурой.
Реализация подобного проекта упростит работу сотрудника, который
занимается с материалами и оборудованием. По итогу создается БД, где
хранятся все сведения об договорах, клиентах, расчетах, что повышает удобство
хранения данных, а также заметно увеличивает скорость поиска и выборки
данных, минимизирует расходы труда на поиск данных.
На основ ании данных функций формируется сценари й д иалога, схема
которого для каждого из пользователей представлена на рисунках 2.5- 2.8.
74
Рис. 2.9 Сценарий диалога администратора
Рис. 2.10 Сценарий диалога менеджера
Главное меню
Справочники
Отделы
Категории
Клиенты
Проекты
Новые
Удаленные
Закрытые
Сформировать
База знаний
Разделы
Добавить
запись
Редактировать
запись
Пользователи
Добавление
Редактирова
ние
Выход
Главное меню
Проекты
Новые
Сформировать
Назначенные
База знаний Пользователи Выход
75
Рис. 2.11 Сценарий диалога исполн ителя
Рис. 2.12 Сценарий диалога клиента
Таким образом, каждый сотрудник выполняет назначенные ему функции,
для каждого типа сотрудника предусмотрен свой набор диалога.
2.3.2 Характеристика базы данных
Инфологическая (концептуальная) модель — это формализованное
описание пред метной области, выполненное безотносительно к используемым в
дальнейшем программным и техническим средствам.[3] Инфологическая модель
должная быть динамической и позволять легкую корректировку. К основным
требованиями, предъявляемым к инфологической модели, можно отнест и
следующие:
Главное меню
Проекты
Назначенные
Выполненные
В процессе
База знаний
Пользователи
Выход
Клиенты
Главное меню
Создать проект
Закрытые
Удаленные
Проекты Архив проектов ВыходБаза знаний
76
• инфологическая модель должна содержать всю необходимую и
достаточную информацию для последующего проектирования базы данных;
• инфологическая модель должная быть понятна лицам,
принимающим участ ие в создании системы.
ER-модель предста вляет собой логическую структуру информации об
объектах си стемы. Компонентами ER-модели являются сущности (объекты) и
отношен ия (связи между объектами). Объект имеет множеств о реал и заций или
экземпляров. Экземпляр объекта образуется совокупностью конкретных
значений реквизитов и должен однозначно определяться, т.е.
идентифицироваться значением ключа объекта, кот орый состоит из одного ли
нескольких ключевых реквизитов.
Для отображения отношений между сущностя ми используются связи.
Связи с уществуют, если экземпляры сущностей логически взаимосвязаны.
Для Хранения данных в базе данных необход имо предусмотреть
следующие сущности и атрибуты:
1. Проекты:
2. Категория проекта
3. Клиенты
4. Пользователи
5. Специализация
6. Статус проекта
7. Статья
8. Раздел
9. Файлы
Инфологическая схема базы данных представлена на рисунке 2.2.
77
Рис. 2.13 Инфологическая схема базы данных
ER-модель разработанной базы данных представлена на рисунке 2.3.
Рис. 2.14 Даталогическая модель разраб отанной базы данных
78
Далее опред ел им для каждой таблицы тип поля и формат содержащихся в
нем данных.
Таблица 2.4
Характеристика и описание полей таблицы Proekts
№
Название столбца
поля
Идент ификатор
Тип
Примечание
1.
Код записи
idzav
int(10)
auto_increment
2.
Описание прое кта
desczav
text
3.
Приоритет
priorzav
int(1)
4.
Актив
activzav
int(7)
5.
Категория
katzav
int(7)
6.
Ссылка на
прикрепленный
файл
filezav
text
7.
комментарий
commzav
text
8.
Код добавившего
клиента
iduzav
int(3)
9.
Дата
формирования
datezav
timestamp
10.
Наименование
namezav
varchar(255)
11.
Дата окончания
преокта
Datedl
date
12.
Признак удаления
deletz
int(1)
Таблица 2.5
Характеристика и описание полей таблицы Klient
№
Название столбца
поля
Идент ификатор
Тип
Примечание
1.
Код записи
ida
int(1)
auto_increment
2.
Код компании
idoa
int(7)
3.
ФИО
nomkab
varchar(6)
4.
Признак удаления
dela
int(1)
Таблица 2.6
Характеристика и описание полей таблицы status
№
Название столбца поля
Идент ификатор
Тип
Примечание
1.
Код записи
ids
int(10)
auto_increment
2.
Дата и время открытия
openz
varchar(45)
3.
Код пользователя
iduopen
int(7)
4.
Дата и время
распределения
rasp
varchar(45)
5.
Код пользователя
idrasp
int(7)
6.
Дата и время приема
proz
varchar(45)
7.
Код пользователя
idproz
int(7)
79
8.
Дата и время проверки
test
varchar(45)
9.
Код пользователя
idtest
int(7)
10.
Дата и время закрытия
clos
varchar(45)
11.
Код пользователя
idclos
int(7)
12.
Признак удаления
flag
int(1)
13.
Номер проекта
nomzav
int(3)
Таблица 2.7
Характеристика и описание полей таблицы user
№
Название столбца
поля
Идент ификатор
Тип
Примечание
1.
Код сотрудника
idu
int(11)
auto_increment
2.
ФИО сотрудника
nameuser
varchar(25)
3.
Дата регистраци и
datereg
timestamp
4.
Логин для доступа в
систему
login
varchar(25)
5.
Пароль для доступа в
систему
password
varchar(25)
6.
Дата рождения
status
int(1)
7.
Признак удаления
udaluser
int(1)
Таблица 2.8
Характеристика и описание полей таблицы news
№
Название
столбца поля
Идент ификатор
Тип
Примечание
1.
Код записи
idn
int(11)
auto_increment
2.
Дата
daten
timestamp
3.
Код
пользователя
idun
int(10)
4.
Заголовок
zagn
varchar(255)
5.
Тело записи
bodyn
text
6.
Признак
удаления
udaln
int(1)
7.
Номер раздела
newsrazdel
varchar(12)
Таблица 2.9
Характеристика и описание полей таблицы razdel
№
Название столбца поля
Идент ификатор
Тип
Примечание
1.
Код раздела
idr
int(100)
auto_increment
2.
Наименование
namer
varchar(100)
3.
Логотип
logor
varchar(255)
4.
Тип раздела
tipr
int(1)
1 – основной ,
2 - подраздел
5.
Номер основного
раздела
podraz
int(10)
При наличии
6.
Признак удаления
udalr
int(1)
80
Таблица 2.10
Характеристика и описание полей таблицы Spez
№ пп
Название столбца
поля
Идент ификатор
Тип
Примечание
1.
Код
ido
int(1)
2.
Наименование
nameo
varchar(255)
3.
Признак удаления
delo
int(1)
Таблица 2.11
Характеристика и описание полей таблицы Kategoria
№ пп
Название столбца
поля
Идент ификатор
Тип
Примечание
1.
Код категории
idpr
int(1)
2.
Наименование
nameprez
varchar(255)
3.
Признак удаления
delprez
int(1)
Таблица 2.12
Характеристика и описание полей таблицы File
№
Название столбца
поля
Идент ификатор
Тип
Примечание
1.
Код записи
namefile
varchar(255)
auto_increment
2.
Название файла
filezav
int(11)
3.
Дата и время
доба вления
datefile
timestamp
4.
Описание
descfile
text
5.
Ссылка
linkfile
text
6.
Признак удаления
udalfile
int(1)
2.3.3 Структурная схема пакета (дерево вызова прог раммных
модулей)
Система состоит из двух модулей – базы данных MySQL и приложения
для взаимодействия с базой данных, реализованного на языке программирования
PHP и c использованием HTML.
Структурная схема пакета предс тавлена на рис.. 2.11.