87
Рис. 2.15. Макет документа Договор стр. 7
Документ Заявка является оперативным и служит для учета заказов. Он
определяет тип транспортных средств, стоимость перевозки грузов,
наименование и характеристики груза, условия его перевозки, тоннаж груза, его
объем, дата, время и адрес погрузки, дата и адрес разгрузки для каждой
конкретной внутригородской или междугородной перевозки грузов
автомобильным транспортом. Заявка считается подтвержденной и принятой к
исполнению Исполнителем после сообщения им Заказчику информации о
водителе (включая паспортные данные) и регистрационных данных о
транспортном средстве, предоставляемом для внутригородских и
междугородних перевозок грузов автомобильным транспортом. Желтым
выделен текст, который заполняется разрабатываемой программой.
Документ формируется из полей:
88
ID, Дата заказа, Дата перевозки, Тип транспорта, Наименование
груза, Количество груза, Пункт погрузки, Пункт назначения, Отправитель,
Получатель, Требования к перевозке, Стоимость поставщика, Дата выполнения
таблицы Заказы;
Наименование, Телефон, Факс, Контакт ФИО, Условия оплаты,
Санкции таблицы Поставщики;
ФИО таблицы Менеджеры;
Марка, Грузоподъемность, Номер авто, Номер прицепа таблицы
Транспорт;
Тип транспорта таблицы Тип транспорта;
ФИО, Паспортные данные, ВодитУдостов, Телефон таблицы
Водители.
Макет документа Заявка представлен на рис. 2.16
Рис. 2.16. Образец документа Заявка
89
Документ Счет является оперативным и служит для оплаты заказов. Он
определяет реквизиты и сумму перевода денежных средств для оплаты
выполненных работ и услуг по выполнению внутригородских и междугородних
перевозок грузов автомобильным транспортом. Желтым выделен текст, который
заполняется разрабатываемой программой.
Документ Счет формируется из полей:
ID, Дата выполнения, Пункт погрузки, Пункт назначения, Дата
перевозки, № ТТН, Сумма заказа таблицы Заказы;
Наименование таблицы Заказчики;
Номер авто, Номер прицепа таблицы Транспорт;
ФИО таблицы Водители.
Образец документа Счет представлен на рис 2.17
Рис. 2.17 Образец документа Счет
90
Документ Акт является оперативным и служит для оплаты заказов. Он
определяет реквизиты и сумму перевода денежных средств для оплаты
выполненных работ и услуг по выполнению внутригородских и междугородних
перевозок грузов автомобильным транспортом. Желтым выделен текст, который
заполняется разрабатываемой программой.
Документ Акт формируется из полей:
ID, Дата выполнения, Пункт погрузки, Пункт назначения, Дата
перевозки, № ТТН, Сумма заказа таблицы Заказы;
Наименование, № договора, Дата договора, Адрес, Контакт ФИО,
ИНН, КПП, Р/с, К/с, Банк, Адрес банка, БИК таблицы Заказчики;
Номер авто, Номер прицепа таблицы Транспорт;
ФИО таблицы Водители.
Макет документа Акт приведен на рис. 2.18
Рис. 2.18 Макет документа Акт оказанных услуг
91
Документ Счет-фактура является оперативным и служит для оплаты
заказов. Он определяет реквизиты и сумму перевода денежных средств для
оплаты выполненных работ и услуг по выполнению внутригородских и
междугородних перевозок грузов автомобильным транспортом. Желтым
выделен текст, который заполняется разрабатываемой программой.
Документ Счет-фактура формируется из полей:
ID, Дата выполнения, Пункт погрузки, Пункт назначения, Дата
перевозки, № ТТН, Сумма заказа таблицы Заказы;
Наименование, Адрес, ИНН, КПП таблицы Заказчики;
Номер авто, Номер прицепа таблицы Транспорт;
ФИО таблицы Водители.
Макет документа Счет-фактура приведен на рис. 2.19
Рис. 2.19. Образец документа Счет-фактура
2.4. Программное обеспечение задачи
2.4.1. Общие положения (дерево функций и сценарий диалога)
Основная функция системы – это учет заказов заказчиков и распределение
их между поставщиками с построением отчетов. Данную функцию осуществляет
оператор системы (менеджер). Описание дерева функций приведено на рис.
92
Функции ИС
документооборота
Работа со
справочниками
Учет заказов
Заказчики
Поставщики
Менеджеры
Ввод данных
заказа
Выбор
поставщика
Статусы
заказа
Шаблоны
документов
Тип
транспорта
Получение
отчетов
Список
поставщиков
ТТН
Список
заказчиков
Счет-фактура
Договор
Список
заказов
Заявка
Счет
Рис. 2.20 Дерево функций ИС
Сценарий диалога ИС разработан на основании дерева функций и
приведен на рис.
93
Главное меню
Справочники
Заказы
Заказчики
Поставщики
Менеджеры
Новый
Изменить
Статусы
заказа
Шаблоны
документов
Тип
транспорта
Отчеты
Список
поставщиков
ТТН
Список
заказчиков
Счет-фактура
Удалить
Документы
Список
заказов
Договор
Заявка
Счет
Рис.2.21. Сценарий диалога для ИС
2.4.2. Характеристика базы данных
Сущность структурного подхода к разработке информационных систем
заключается в ее декомпозиции (разбиении) на автоматизируемые функции:
система разбивается на функциональные подсистемы, которые в свою очередь
делятся на подфункции, подразделяемые на задачи и так далее. Процесс
разбиения продолжается вплоть до конкретных процедур. При этом
автоматизируемая система сохраняет целостное представление, в котором все
составляющие компоненты взаимоувязаны. Основные этапы, на которые
разбивается процесс проектирования информационной системы, следующие:
94
концептуальное проектирование – сбор, анализ и редактирование
требований к данным (обследование предметной области, изучение ее
информационной структуры, выявление всех фрагментов, каждый из которых
характеризуется пользовательским представлением, информационными
объектами и связями между ними, процессами над информационными
объектами, моделирование и интеграция всех представлений);
логическое проектирование – преобразование требований к данным
в структуры данных. На выходе получаем СУБД – ориентированную структуру
базы данных и спецификации прикладных программ;
физическое проектирование – определение особенностей хранения
данных, методов доступа и т.д.
Основными конструктивными элементами моделей являются сущности,
связи между ними и их свойства (атрибуты). Сущность – любой различимый
объект (объект, который мы можем отличить от другого), информацию о
котором необходимо хранить в базе данных. Логическая структура базы данных
– это описание состава, типа и длины информационных единиц базы данных и
связей между ними.
Сущности и связи модели данных представляются в виде реляционной
таблицы (отношения). Отношение, соответствующее сущности, содержит
атрибуты (столбцы), являющиеся атрибутами сущности и описывающие
сущность (объект). Атрибут или множество атрибутов, которые однозначно
определяют объект, называются ключом.
Удобно представлять отношение как таблицу, где каждая строка есть
кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом
называются атрибутами и им присваивают имена. Список имён атрибутов
называется схемой отношения. Совокупность схем отношений, используемых
для представления информации, называются схемой базы данных, а текущие
значения соответствующих отношений – базой данных.
Процесс построения инфологической модели состоит из следующих
шагов:
определение сущностей;
определение зависимостей между сущностями;
95
задание первичных и альтернативных ключей;
определение атрибутов сущностей;
приведение модели к требуемому уровню нормальной формы.
Логический уровень представления модели – это абстрактный взгляд на
данные, на нем данные представляются так, как выглядят в реальном мире.
Логическая модель данных является универсальной и никак не связана с
конкретной реализацией СУБД. Физическая модель данных, напротив, зависит
от конкретной СУБД, фактически являясь отображением системного каталога. В
физической модели содержится информация обо всех объектах БД. Поскольку
стандартов на объекты БД не существует (например, нет стандарта на типы
данных), физическая модель зависит от конкретной реализации СУБД.
Следовательно, одной и той же логической модели могут соответствовать
несколько разных физических моделей.
Дальнейший перевод закономерностей предметной области,
представленных в семантической схеме, на язык системы управления БД (СУБД)
может происходить в достаточной степени формально одним из следующих
способов:
вручную человеком по фиксированным правилам семантической
методики;
полностью автоматически с использованием CASE-инструмента
(Computer Aided Software Engineering - разработка программного обеспечения с
помощью компьютера);
в ходе человеко-машинной процедуры под управлением CASE-
системы.
Для достижения поставленной цели, как минимум, необходимо
синтезировать мощную семантическую модель и разработать для нее набор
детальных правил трансформации схемы в реляционную модель. Программой-
максимумом является реализация CASE-системы, позволяющей вводить в
удобной для человека форме семантику ПО и генерировать элементы схемы на
языке конкретной СУБД.
Схема связи таблиц базы данных представлена на рис. 2.22
96
Рис. 2.22 Схема связи таблиц базы данных
Характеристика таблиц базы данных представлена на рисунках 2.23-2.31.
Рис. 2.23 Таблица Документы