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

Характеристика первичных документов с нормативно-справочной и входной оперативной информацией

Автоматизированная система торгового предприятия по реализации торгового оборудования разрабатывается не на пустом месте. В основу методики ее работы положены системы учета уже имеющие многолетний опыт применения, но не оформленные в виде компьютерных программ. Поэтому входными для данными для системы будут являться те же самые данные, которые использовались в неавтоматизированных системах. Каждая из подсистем имеет свой набор входных и выходных данных, причем выходные данные одной подсистемы могут являться входными данными другой подсистемы. Так, например, записи в справочнике контрагентов и номенклатурных позиций являются входными данными для построения отчета о состоянии реализованного оборудования или планах поставок, являющимся составной частью подсистемы аналитической отчетности. Опишем входные и выходные данные для каждой подсистемы.

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

Результатом ввода списка контрагентов в систему будет являться таблица контрагентов, которая в свою очередь выступает в качестве входных данных при составления плана покупок. Такая же ситуация и со справочником оборудования. Оба этих справочник должны быть предоставлены ответственному за введение информации в базу данных человеку руководством компании на бумажных носителях. Выходными данными являются соответствующие таблицы базы данных.

Для подсистемы составления аналитической отчетности входными данными являются записи в таблицах контрагентов и всех таблицах связанных с реализацией оборудования.

Используя массив этих данных, система строит отчеты, которые можно посмотреть на экране монитора или распечатать на принтере. Готовые отчеты и является выходными данными подсистемы аналитической отчетности и всей системы в целом.

Сводная таблица справочников показана далее

Таблица 4.1. Сводная таблица справочников

№	Полное наименование справочника	Краткое наименование	Ответственный
1	Invoice (Реализация оборудования, приход)	Реализация	Оператор ИС
2	Plan (план продаж, расход)	План продаж	Оператор ИС
3	Product (оборудование)	оборудование	Оператор ИС
4	Provider (контрагенты, поставщики)	контрагенты	Оператор ИС
5	Klient (покупатели, клиенты)	покупатели	Оператор ИС
6	Dvigenie tovara (движение товара)	Движение товара	Оператор ИС

Характеристика базы данных

Инфологическая модель применяется после словесного описания предметной области.

Между сущностями могут быть установлены связи - бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. [29]

Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М). [29]

Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. [29]

Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи. [29]

Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. [29]

Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной - если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.

Проведем инфологическое проектирование базы данных автоматизированной системы по учету реализации торгового оборудования.

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

В качестве настольной базы данных выбрана база данных формата MS ACCESS. То есть база данных является файлом на диске, в котором сосредоточены таблицы базы данных в виде файлов данных и индексов к ним.

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

Разработанная нами база данных является реляционной и, как и другие реляционные базы данных состоит из таблиц. Ниже приведена таблица сущностей базы данных.

Таблица 4.2 - Поля таблицы «Поставки оборудования (приход, реализация)»

Название	Тип	Размер
№п_п	Счетчик
Оборудование	Текстовый	255
Количество	числовой
Дата	Дата/время	255
№Поставщика	числовой
Информация	Текстовый	255
Накладная	Текстовый	255

Таблица 4.3 - Поля таблицы «План поставок(расход)»

Название	Тип	Размер
№п_п	Счетчик
Оборудование	Текстовый	255
Количество	числовой
Дата	Дата/время
Накладная	Текстовый	255
Информация	Текстовый	255
№Покупателя	числовой

Таблица 4.4 - Поля таблицы «Реквизиты оборудования»

Название	Тип	Размер
№п_п	Счетчик
Название	Текстовый	255
Штрих-код	Числовой
Информация	Текстовый	255

Таблица 4.5 - Поля таблицы «Реквизиты поставщиков»

Название	Тип	Размер
№п_п	Счетчик
Название	Текстовый	255
Адрес	Текстовый	255
Телефон	Числовой
Информация	Текстовый	255

Таблица 4.6 - Поля таблицы «Реквизиты покупателей»

Название	Тип	Размер
№п_п	Счетчик
Название	Текстовый	255
Адрес	Текстовый	255
Телефон	Числовой
Информация	Текстовый	255

Таблица 4.7 - Поля таблицы «Движение товара (приход, расход)»

Название	Тип	Размер
№п_п	Счетчик
№ оборудования	Числовой
№ прихода оборудования	Числовой
№ расхода оборудования	Числовой
Цена	Числовой

4.2 Программное обеспечение задачи

Общие положения (дерево функций и сценарий диалога)

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

Приложение обеспечивает удобный и понятный диалог пользователя с программой для вызова всех функций. Доступ пользователя к функциям производится через главное меню главной формы приложения. Главная форма приложения кроме предоставления основного интерфейса доступа ко всем функциям приложения выполняет также роль контейнера для всех остальных экранных форм.

Первая группа экранных форм предоставляет пользователю доступ к подсистеме ведения справочников системы. Эта группа экранных форм вызывается из главного меню программы «Реквизиты». Каждый подпункт этого пункта меню соответствует вызову экранной формы, которая позволяет редактировать соответствующий справочник.

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

Описание программных модулей

В основу программной реализации решения задачи был положен событийно-ориентированный подход. Выбранный в качестве языка программирования язык Delphi включает в себя мощный аппарат для поддержания этой наиболее перспективной технологии. Событийно-ориентированное программирование (англ. event-driven programming) - это способ построения компьютерной программы, при котором в коде (как правило, в головной функции программы) явным образом выделяется главный цикл приложения, тело которого состоит из двух частей: выборки события и обработки события. Как правило, в реальных задачах оказывается недопустимым длительное выполнение обработчика события, поскольку при этом программа не может реагировать на другие события. В связи с этим при написании событийно-ориентированных программ часто применяют автоматное программирование. В современных языках программирования события и обработчики событий являются центральным звеном реализации графического интерфейса пользователя. Рассмотрим, к примеру, взаимодействие программы с событиями от мыши. Нажатие правой клавиши мыши вызывает системное прерывание, запускающее определенную процедуру внутри операционной системы. В этой процедуре происходит поиск окна, находящегося под курсором мыши. Если окно найдено, то данное событие посылается в очередь обработки сообщений этого окна. Далее, в зависимости от типа окна, могут генерироваться дополнительные события. Например, если окно является кнопкой (в Windows все графические элементы являются окнами), то дополнительно генерируется событие нажатия на кнопку. Отличие последнего события в том, что оно более абстрактно, а именно, не содержит координат курсора, а говорит просто о том, что было произведено нажатие на данную кнопку. Событийно-ориентированное программирование, как правило, применяется в трех случаях:

· при построении пользовательских интерфейсов (в том числе ГПИ);

· при создании серверных приложений в случае, если по тем или иным причинам нежелательно порождение обслуживающих процессов;

· при программировании игр, в которых осуществляется управление множеством объектов.

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

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

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

В подсистему ведения справочников входят следующие модули:

Модуль просмотра и редактирования списка оборудования предназначен для просмотра списка номенклатуры, а также для выбора товара в какую-либо вызывающую форму;

Модуль контрагентов предназначен для просмотра и редактирования списка контрагентов.

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

Модуль документов реализации содержит список документов реализации оборудования, которые записаны в таблицу реализации базы данных;

Модуль документов поступления товаров предназначен для просмотра и редактирования операции по поступлению товаров на склад. Подсистема аналитической отчетности включает в себя следующие модули:

Модуль составления отчета по учету состояния реализации оборудования;

Модуль составления отчета по срочности поставок.

В визуальной интегрированной среде разработки Delphi основной составной частью программы является форма. Форма инкапсулирует в себе элементы интерфейса пользователя и программный код, заключающий в себе реакцию на действия пользователя. Это полностью отвечает принципам событийно-ориентированного программирования. Delphi автоматически создает для формы класс формы, который содержит компоненты, размещенные на форме, свойства и методы формы как автоматически создаваемые Delphi, так и определяемые пользователем. В разработанном приложении определены следующие формы:

· Форма main - главная форма приложения, реализованная в файле Main.pas выполняет функции основного интерфейса доступа пользователя ко всем функциям программы через главное меню приложения и панель кнопок быстрого доступа. Кроме того, главная форма выполняет роль контейнера всех остальных форм, в которых происходит ввод и обработка данных. А также вывод аналитической информации в виде диаграмм. [10]

· Форма FormProductDlg, реализованная в файле FormProductDlg.pas, выполняет функции просмотра списка оборудования, введенных в таблицу оборудования базы данных системы. Главным элементом формы является компонент DBGrid палитры компонентов Delphi, который отображает таблицу товаров в виде списка. Колонки компонента DBGrid отображают соответствующие поля таблицы товаров: наименование, штрихкод и дополнительную информацию. Эта же форма служит для выбора товара в случае вызова этой формы из других форм для выбора того или иного товара например в форму документа реализации. [10]

· Форма FormProviderDlg, реализованная в файле FormProviderDlg.pas, предназначена для просмотра и редактирования данных о контрагентах. В этой форме расположены органы управления, в которых отображаются основные данные контрагентов, такие как наименование, адрес, номер контактного телефона и дополнительную информацию. [10]

· Форма FormInvoiceDlg, реализованная в файле FormInvoiceDlg.pas, предназначена для регистрации данных об реализованном оборудовании. Следует отметить, что выбор оборудования и контрагентов выполнено в виде выбора из выпадающего списка. [10]

· Форма FormPlanDlg, реализованная в файле FormPlanDlg.pas, предназначена для просмотра и редактирования данных о планируемых поставках оборудования. Следует отметить, что выбор оборудования и контрагентов выполнено в виде выбора из выпадающего списка. [10]

Каждая форма выполняет функции соответствующего модуля при помощи компонентов среды Delphi, помещенных на форму из палитры компонентов. Среда быстрого создания приложений или RAD-среда (Rapid Application Development - RAD) Delphi используют библиотеку визуальных компонентов VCL (Visual Component Library - VCL), которая состоит из готовых к употреблению визуальных и не визуальных объектов и оболочек. Она позволяет с минимальными затратами создавать приложения, в то же время предоставляя определенную степень независимости от библиотеки VCL. [10]

При работе с компонентами Delphi широко использует принцип повторного использования объектов. Компоненты являются экземплярами классов, которые доступны с помощью палитры компонентов Component Palette. Что может быть проще при создании приложения, чем просто опустить нужный компонент на форму, задав его свойства, затем определив, обработчики событий. Именно при помощи компонентов формы выполняют те функции, которые заложены в них. [10]

4.3 Технологическое обеспечение задачи (комплекса задач, АРМ)

Организация технологии сбора, передачи, обработки и выдачи информации

Разработка сложных программных комплексов вызывает необходимость решения ряда организационных, технологических и технических проблем, связанных со значительной трудоемкостью разработки программ и сложностью выявления в них ошибок. Решение этих проблем возможно при внедрении любой технологии программирования, которая позволит повысить производительность труда программистов и надежность программ. Кроме того, внедряемая технология должна упростить планирование работ и организацию взаимодействия всех членов коллектива, позволить четко контролировать сроки выполнения каждого этапа разработки, оперативно доводить до исполнителей все изменения в общих концепциях на создаваемое программное изделие и изменения в соглашениях о связях между программой и внешней средой или между отдельными структурными элементами программы. Технология должна обеспечить простоту и однозначность прочтения всей документации.

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

Технология разработки сложных программных комплексов требует разбиения программного изделия на отдельные модули. При этом часто модули создаются независимо друг от друга разными программистами. Для объединения модулей в программный комплекс необходимо разработать правила вызова модулей и правила передачи параметров между отдельными модулями. Эти правила образуют внутри - программный интерфейс.

Внутри - программный интерфейс должен разрабатываться на начальном этапе проектирования программы. Разработка его включает:

· анализ обрабатываемой информации и выбор логической организации данных;

· выбор абстрактных структур данных для представления информации в соответствии с используемым языком программирования равной логической организацией данных;

· выбор физической организации данных;

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

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

· Модуль - независимая программа, которая может вызываться операционной системой или другим программным модулем. Ссылки на модуль выполняются по имени модуля.

· Модуль должен возвращать управление тому модулю, который его вызвал.

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

· Модуль должен иметь ограниченные размеры. Это требование определяется тем, что каждый модуль организует отдельную, сравнительно небольшую функцию. Кроме того, текст модуля должен быть обозримым для облегчения его понимания и сопровождения.

· Работа модуля не должна зависеть от его предыдущих вызовов.

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

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

Наиболее широко распространенным подходом к проектированию является нисходящее программирование.

Этот подход интуитивно привлекателен, за последние несколько лет он подвергался неоднократному обсуждению в литературе. Нисходящее проектирование известно и под другими названиями, например «конструктивное программирование», «программирование пошаговым совершенствованием» и «иерархическое проектирование».

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

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

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

Нисходящее программирование позволяет создавать достаточно сложные программы.

Схемы технологического процесса сбора, передачи, обработки и выдачи информации

В данном разделе представлены функционально-технологические схемы решения задачи.

В первую очередь рассмотрим задачу ведения справочников, назовем ее А1. Для ее реализации менеджер по ведению каталогов сортирует данные, а затем вводит данные в соответствующие таблицы. Задача ввода данных может быть разбита на несколько этапов.

Для модуля А1.1:

Процесс: Проверка и внесение данных об оборудовании.

Вход: информация об оборудовании.

Выход: сформированные данные об оборудовании в БД

Алгоритм:

· Проверка наличия данных об оборудовании в БД

· Если данные отсутствуют, то внести новую запись в БД

· Вывести данные об оборудовании на экран.

Для модуля А 1.2:

Процесс: Проверка и внесение данных о контрагентах.

Вход: информация о контрагенте.

Выход: сформированные данные о контрагенте в БД

Алгоритм:

· Проверка наличия данных о контрагенте в БД

· Если данные отсутствуют, то внести новую запись в БД

· Вывести данные о контрагенте на экран.

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

4.4 Описание контрольного примера реализации проекта

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

Реализация контрольного примера состоит из трех этапов:

· Ввод тестовой информации в справочники;

· ввод тестовых примеров движения оборудования на складе;

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

Первый этап реализации контрольного примера заключается во вводе тестовых данных в справочники системы. Тестовые данные были подобраны таким образом. Чтобы задействовать все справочники, как основные, так и хранящие дополнительную информацию. В справочник оборудования были введены шесть позиций оборудования:

· Швейный станок;

· оверлок;

· гладильная доска;

· утюг;

· стол для раскроя;

· сушильный станок.

В справочник контрагенты были введены пять позиций:

· АРМАТОР-М, ООО;

· Линар, ООО;

· ПРИМА-БУТ, ООО;

· SHARK, ПК;

· КОЛОКОЛ, ООО.

5. Обоснование экономической эффективности проекта

5.1 Выбор и обоснование методики расчёта экономической эффективности

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

При оценке эффективности ЭИС используют обобщающие и частные показатели.

К основным обобщающим показателям экономической эффективности относятся:

· годовой экономический эффект;

· расчетный коэффициент эффективности капитальных вложений;

· срок окупаемости системы. [34]

Годовой экономический эффект от разработки и внедрения ЭИС служит для сравнения различных направлений капитальных вложений и рассчитывается по формуле:

Э = П - К * Е_н

где Э - годовой экономический эффект;

П - годовая экономия, руб.;

К - единовременные капитальные затраты, руб.;

Е_н - нормативный коэффициент эффективности капитальных вложений.

Значение Е_н принимается равным 0.15. Е_н представляет собой минимальную норму эффективности капитальных вложений, ниже которой они нецелесообразны. [27]

Расчетный коэффициент эффективности капитальных вложений определяется по формуле:

Е_р = П / К

Полученное значение сравнивается со значением Е_н. Если Е_р ? Е_н, то капитальные затраты можно считать целесообразными, в противном случае они экономически необоснованные. [34]

Срок окупаемости Т представляет собой период времени (в годах), в течение которого капитальные затраты на разработку ЭИС полностью окупятся, и рассчитывается по формуле: [34]

Т = К / П

Данный способ расчета выбран потому, что при внедрении системы известна только расходная часть (затраты на оборудование, установку и сопровождение аппаратной части, разработку программного обеспечения, заработная плата сотрудников предприятия и др.), а входящие денежные потоки (выгоды, полученные в результате внедрения информационной системы) не могут быть определены.

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

5.2 Расчёт показателей экономической эффективности проекта

Единовременные затраты на создание и внедрение информационной системы приведены в таблице 5.1

Таблица 5.1 - Единовременные затраты на создание и внедрение информационной системы

№ п/п	Затраты проекта	Стоимость
1	Закупка и настройка сервера для постоянного доступа к базе данных	125 000 р
2	Закупка и настройка персональных компьютеров для установки информационной системы	52 000 р
3	Разработка программы автоматизированной системы	68 000 р
	Итого:	245 000 р

Ожидаемая годовая прибыль в следствии введения информационной системы (за счёт уменьшения простоя работы предприятия по причине отсутствия поставки оборудования) составляет 500 000.

Годовой экономический эффект от разработки и внедрения интернет - магазина составит:

Э = П - К * Ен = 500 000 - 245 000*0,15 = 463 250 руб.

Расчетный коэффициент эффективности капитальных вложений:

Ер = П / К = 500 000/245 000 = 2,04

Ер > Ен, это значит, что капитальные затраты можно считать целесообразными.

Срок окупаемости проекта:

Т = К / П =245 000/500 000 = 0,49 года или 6 месяцев.

Внедрения данной системы даёт значительную экономическую выгоду.

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

Заключение

В дипломном проекте было рассмотрено проектирование и разработку информационной системы учёта реализации торгового оборудования.

В результате выполненной разработки можно сделать следующие выводы:

1. При разработке экономической информационной системы был пройден полный цикл проектирования программы от постановки задачи до введения информационной системы в эксплуатацию.

2. Разработанная информационная система позволяет достигнуть следующих эффектов:

· уменьшение времени необходимого для учета реализации торгового оборудования;

· автоматизация контроля реализации;

· возможность длительного хранения информации о поставках на предприятие большого срока давности, для возможности более полного расчета эффективности деятельности предприятия;

· своевременное получение информации о возможности срыва выполняемого проекта за счёт отсутствия поставки оборудования.

3. Целесообразность разработки обуславливается наличием свободного сегмента рынка для реализации разработанной информационной системы. Также было показано, что окупаемость информационной системы планируется в течение 6 месяцев.

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

Список использованной литературы

1. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам.

2. ГОСТ 19.103-33 ЕСПД. Обозначение программ и программных документов.

3. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем.

4. Агальцов В.П. Базы данных. - М.: Мир, 2002.

5. Архангельский П.А. Программирование в Delphi 5. - M.: Наука, 2000.

6. Бобровский С.И. Delphi 5. - М.: Питер, 2002.

7. Гаевский A. Разработка программных приложений на Delphi 6. - М.: Киев, 2000.

8. Гагарина Л.Г., Киселёв Д.В. Разработка и эксплуатация автоматизированных информационных систем. - М.: ИНФРА-М. 2007.

9. Горев А., Макащарипов С., Владимиров Ю. Microsoft SQL. Server 6.5 для профессионалов. - СПб.: Питер, 1998.

10. Дарахвелидзе П.Г. Программирование в DELPHI 5. - СПб.: Бином, 2000.

11. Евдокимова В.В. Информационные системы в экономике. - СПб.: Питер 2007.

12. Емельянова Н.З., Партыка Т.Л., Попов И.И. Основы построения автоматизированных информационных систем. - М.: ИНФРА-М. 2005.

13. Зуев В. A. Turbo Pascal 6.0, 7.0. - М.: Москва, 1998.

14. Карпова Т.С. Базы данных: модели, разработка. - СПб.: Питер, 2001.

15. Коноплева Е.А., Хохлова О.А., Денисов А.В. Информационные технологии. - М.: Проспект. 2007.

16. Коцюбинский А.О., Грошев С.В. Язык программирования Delphi 5. - М.: Москва, 1999.

17. Культин Н. Основы программирования в Delphi 7. - СПб.: БХВ, 2003.

18. Леонтьев В.И. Delphi 5. - М.: Москва, 1999.

19. Моисеев А.С. Object Pascal. - М.: Москва, 2000.

20. Немнюгин С.А. Программирование. - М.: Питер, 2000.

21. Петров В.Н. Информационные системы. - СПб.: Питер, 2002.

22. Понамарев В. Базы данных в Delphi 7. - СПб.: Питер, 2003.

23. Ремизов Н. C. Delphi. - М.: Питер, 2000.

24. Романова М.В. Управление проектами. - М.: ИНФРА-М. 2007.

25. Советов Б.Я., Цехановский В.В. - Базы данных. - М.: Высшая школа. 2005.

26. Тейксейра С.Т. DELPHI 5. Руководство разработчика. - М.: Вильямс, 2000.

27. Тиори Т., Фрай Дж. Проектирование структур баз данных: В 2-х кн. Пер. с англ. - М.: Мир, 1985.

28. Угринович Н. Информатика и информационные технологии. Набор базовых знаний. - М.: Радио и связь, 2000.

29. Фаронов В.В. Программирование баз данных в Delphi 7: Учебный курс. - СПб.: Питер, 2004.

30. Харитонова И.А. Михеева В.Д. Microsoft Access 2000. - СПб.: БХВ - Санкт-Петербург, 1999.

31. Харрингтон Дж. Проектирование реляционных баз данных. - М.: ЛОРИ, 2000.

32. Шумаков В.П. Delphi 3 и создание приложений баз данных. - М.: Нолидж, 1998.

33. Шумаков П.В. Delphi 3 и разработка приложений баз данных. - М.: Нолидж, 1998.

34. Ломакин В.К. Мировая экономика: Учебник для вузов. - М.: Финансы, ЮНИТИ, 2008.

Интернет-источники

35. http://ru.wikipedia.org. Википедия

36. http://v8.1 c.ru. 1С: Предприятие 8 [Электронный курс]

37. http://freqlist.ru. Библиотека онлайн для студентов

38. http://office.microsoft.com. Официальный сайт Microsoft Office

39. http://easyprog.ru.

Приложение

Исходный код Delphi

unit DataModule;

interface

uses

SysUtils, Classes, DB, ADODB;

type

TDM = class(TDataModule)

ADOConnection: TADOConnection;

ADOTableProvider: TADOTable;

DataSourceProvider: TDataSource;

ADOTableProviderID: TAutoIncField;

ADOTableProviderPrName: TWideStringField;

ADOTableProviderPrAdress: TWideStringField;

ADOTableProviderPrPhone: TIntegerField;

ADOTableProviderPrInfo: TWideStringField;

ADOTableProduct: TADOTable;

DataSourceProduct: TDataSource;

ADOTableProductID: TAutoIncField;

ADOTableProductPrName: TWideStringField;

ADOTableProductPrCode: TIntegerField;

ADOTableProductPrInfo: TWideStringField;

ADOTablePlan: TADOTable;

DataSourcePlan: TDataSource;

ADOTablePlanID: TAutoIncField;

ADOTablePlanPlProduct: TWideStringField;

ADOTablePlanPlCount: TIntegerField;

ADOTablePlanPlDate: TDateTimeField;

ADOTablePlanPlProductView: TWideStringField;

ADOCommand: TADOCommand;

ADOTableInvoice: TADOTable;

DataSourceInvoice: TDataSource;

ADOTableInvoiceID: TAutoIncField;

ADOTableInvoiceIbProduct: TWideStringField;

ADOTableInvoiceIbCount: TIntegerField;

ADOTableInvoiceIbDate: TDateTimeField;

ADOTableInvoiceIbProvider: TWideStringField;

ADOQuery: TADOQuery;

DataSource: TDataSource;

ADOTableInvoiceProductView: TStringField;

ADOTableInvoiceIbProviderView: TWideStringField;

private

{Private declarations}

public

{Public declarations}

end;

var

DM: TDM;

implementation

{$R *.dfm}

end.

unit FormInvoiceDlg;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, DataModule, ExtCtrls, DBCtrls;

type

TFormInvoice = class(TForm)

DBGrid: TDBGrid;

DBNavigator: TDBNavigator;

private

{Private declarations}

public

{Public declarations}

end;

function FormInvoiceDlgOpen: Boolean;

implementation

{$R *.dfm}

function FormInvoiceDlgOpen: Boolean;

var

FormInvoice: TFormInvoice;

begin

FormInvoice:= TFormInvoice. Create(Application);

Result:= FormInvoice. ShowModal = mrOk;

FormInvoice. Free;

end;

end.

unit FormPlanDlg;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Grids, DBGrids, ExtCtrls, DBCtrls, DataModule, ComCtrls;

type

TFormPlan = class(TForm)

DBGrid: TDBGrid;

DBNavigator: TDBNavigator;

private

{Private declarations}

public

{Public declarations}

end;

function FormPlanDlgOpen (IsCanEdit: Boolean): Boolean;

implementation

{$R *.dfm}

function FormPlanDlgOpen (IsCanEdit: Boolean): Boolean;

var

FormPlan: TFormPlan;

begin

FormPlan:= TFormPlan. Create(Application);

if IsCanEdit then FormPlan.DBGrid. Options:= FormPlan.DBGrid. Options+[dgEditing]

else FormPlan.DBGrid. Options:= FormPlan.DBGrid. Options - [dgEditing];

FormPlan.DBNavigator. Visible:= IsCanEdit;

Result:= FormPlan. ShowModal = mrOk;

FormPlan. Free;

end;

end.

unit FormProductDlg;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, DBCtrls, Grids, DBGrids, DataModule;

type

TFormProduct = class(TForm)

DBGrid: TDBGrid;

DBNavigator: TDBNavigator;

private

{Private declarations}

public

{Public declarations}

end;

function FormProductDlgOpen: Boolean;

implementation

{$R *.dfm}

function FormProductDlgOpen: Boolean;

var

FormProduct: TFormProduct;

begin

FormProduct:= TFormProduct. Create(Application);

Result:= FormProduct. ShowModal = mrOk;

FormProduct. Free;

end;

end.

unit FormProviderDlg;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ExtCtrls, DBCtrls, Grids, DBGrids, DataModule;

type

TFormProvider = class(TForm)

DBGrid: TDBGrid;

DBNavigator: TDBNavigator;

private

{Private declarations}

public

{Public declarations}

end;

function FormProviderDlgOpen: Boolean;

implementation

{$R *.dfm}

function FormProviderDlgOpen: Boolean;

var

FormProvider: TFormProvider;

begin

FormProvider:= TFormProvider. Create(Application);

Result:= FormProvider. ShowModal = mrOk;

FormProvider. Free;

end;

end.

unit Main;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Menus, ComCtrls, DataModule, StdCtrls, DBCtrls, Grids, DBGrids,

TeEngine, Series, ExtCtrls, TeeProcs, Chart, TeeTools, Printers;

const

Period1 = 7;

Period2 = 8;

type

TProductState = record

Product: String;

InvoiceCount: Double;

PlanCount: Double;

end;

type

TFormMain = class(TForm)

StatusBar: TStatusBar;

MainMenu: TMainMenu;

N1: TMenuItem;

N2: TMenuItem;

N3: TMenuItem;

N4: TMenuItem;

N5: TMenuItem;

N6: TMenuItem;

N7: TMenuItem;

N8: TMenuItem;

N9: TMenuItem;

GroupBox: TGroupBox;

StringGrid: TStringGrid;

ChartProgres: TChart;

Series1: TBarSeries;

Series2: TBarSeries;

Chart1: TChart;

GridBandTool1: TGridBandTool;

GroupBox1: TGroupBox;

StringGrid1: TStringGrid;

GroupBox2: TGroupBox;

GroupBox3: TGroupBox;

Series3: TPieSeries;

N10: TMenuItem;

N11: TMenuItem;

PrintDialog: TPrintDialog;

N12: TMenuItem;

procedure N4Click (Sender: TObject);

procedure N5Click (Sender: TObject);

procedure N6Click (Sender: TObject);

procedure N7Click (Sender: TObject);

procedure N9Click (Sender: TObject);

procedure FormDestroy (Sender: TObject);

procedure FormCreate (Sender: TObject);

procedure StringGrid1DrawCell (Sender: TObject; ACol, ARow: Integer; Rect: TRect; State: TGridDrawState);

procedure N11Click (Sender: TObject);

procedure PrintGrid (sGrid: TStringGrid; sTitle: string);

procedure N12Click (Sender: TObject);

procedure N2Click (Sender: TObject);

private

procedure NewProject;

procedure ClearPlanTable;

procedure Prepeare;

procedure PrepeareProductState;

procedure PrepeareFastNeed;

public

ProductsState: array of TProductState;

end;

var

FormMain: TFormMain;

implementation

{$R *.dfm}

uses

FormProviderDlg, FormProductDlg, FormPlanDlg, FormInvoiceDlg;

procedure TFormMain. ClearPlanTable;

begin

DM.ADOCommand. CommandText:= 'DELETE FROM Plan';

DM.ADOCommand. Execute;

DM.ADOTablePlan. Active:= False;

DM.ADOTablePlan. Active:= True;

{}

DM.ADOCommand. CommandText:= 'DELETE FROM Invoice';

DM.ADOCommand. Execute;

DM.ADOTableInvoice. Active:= False;

DM.ADOTableInvoice. Active:= True;

end;

procedure TFormMain. FormCreate (Sender: TObject);

begin

Prepeare;

end;

procedure TFormMain. FormDestroy (Sender: TObject);

begin

SetLength (ProductsState, 0);

end;

procedure TFormMain.N11Click (Sender: TObject);

begin

if PrintDialog. Execute then begin

PrintGrid (StringGrid, 'Состояние реализации оборудования');

end;

end;

procedure TFormMain.N12Click (Sender: TObject);

begin

if PrintDialog. Execute then begin

PrintGrid (StringGrid1, 'Срочность реализации');

end;

end;

procedure TFormMain.N2Click (Sender: TObject);

begin

Close;

end;

procedure TFormMain.N4Click (Sender: TObject);

begin

FormProviderDlgOpen;

Prepeare;

end;

procedure TFormMain.N5Click (Sender: TObject);

begin

FormProductDlgOpen;

Prepeare;

end;

procedure TFormMain.N6Click (Sender: TObject);

begin

NewProject;

Prepeare;

end;

procedure TFormMain.N7Click (Sender: TObject);

begin

FormPlanDlgOpen(False);

Prepeare;

end;

procedure TFormMain.N9Click (Sender: TObject);

begin

FormInvoiceDlgOpen;

Prepeare;

end;

procedure TFormMain. NewProject;

begin

if MessageDlg ('База данных по текущему плану будет очищенна! Создать новый план?', mtWarning, mbOKCancel, 0) = 1 then begin

ClearPlanTable;

FormPlanDlgOpen(True);

end;

end;

procedure TFormMain. Prepeare;

begin

PrepeareProductState;

PrepeareFastNeed;

end;

procedure TFormMain. PrepeareFastNeed;

var

i: Integer;

S: String;

begin

DM.ADOQuery.SQL. Clear;

DM.ADOQuery. Active:= False;

DM.ADOQuery.SQL. Clear;

DM.ADOQuery.SQL. Add ('SELECT * FROM Plan ORDER BY PlDate');

DM.ADOQuery. Active:= True;

{}

StringGrid1. ColCount:= 4;

StringGrid1. RowCount:= DM.ADOQuery. RecordCount+2;

StringGrid1. Cells [0, 0]:= '№';

StringGrid1. Cells [1, 0]:= 'Оборудование';

StringGrid1. Cells [2, 0]:= 'Количество';

StringGrid1. Cells [3, 0]:= 'Крайний срок';

StringGrid1. ColWidths[0]:= 25;

StringGrid1. ColWidths[1]:= 277;

StringGrid1. ColWidths[2]:= 80;

StringGrid1. ColWidths[3]:= 80;

DM.ADOQuery. First;

for i:= 0 to DM.ADOQuery. RecordCount-1 do begin

StringGrid1. Cells [0, i+1]:= IntToStr (i+1);

StringGrid1. Cells [1, i+1]:= DM.ADOQuery. FieldValues['PlProduct'];

StringGrid1. Cells [2, i+1]:= DM.ADOQuery. FieldValues['PlCount'];

StringGrid1. Cells [3, i+1]:= DM.ADOQuery. FieldValues['PlDate'];

DM.ADOQuery. Next;

end;

end;

procedure TFormMain. PrepeareProductState;

function IsFindProductPlan (aNameProduct: String): Integer;

var

i: Integer;

begin

Result:= -1;

for i:= 0 to Length(ProductsState) - 1 do

if ProductsState[i].Product = aNameProduct then begin

Result:= i;

Exit;

end;

end;

var

i, Indx: Integer;

Sum1, Sum2: Double;

begin

SetLength (ProductsState, 0);

DM.ADOQuery. Active:= False;

DM.ADOQuery.SQL. Clear;

DM.ADOQuery.SQL. Add ('SELECT Invoice. IbProduct, Invoice. IbCount, Invoice. IbDate, ');

DM.ADOQuery.SQL. Add ('Plan. PlProduct, Plan. PlCount, Plan. PlDate');

DM.ADOQuery.SQL. Add ('FROM Plan');

DM.ADOQuery.SQL. Add ('LEFT OUTER JOIN Invoice ON Invoice. IbProduct = Plan. PlProduct');

DM.ADOQuery. Active:= True;

{}

DM.ADOQuery. First;

for i:= 0 to DM.ADOQuery. RecordCount-1 do begin

if IsFindProductPlan (DM.ADOQuery. FieldValues['PlProduct']) = -1 then begin

SetLength (ProductsState, Length(ProductsState)+1);

ProductsState [Length(ProductsState) - 1].Product:= DM.ADOQuery. FieldValues['PlProduct'];

ProductsState [Length(ProductsState) - 1].PlanCount:= DM.ADOQuery. FieldValues['PlCount'];

end;

DM.ADOQuery. Next;

end;

DM.ADOQuery. First;

for i:= 0 to DM.ADOQuery. RecordCount-1 do begin

if DM.ADOQuery. FieldValues['IbProduct'] <> NULL then begin

Indx:= IsFindProductPlan (DM.ADOQuery. FieldValues['IbProduct']);

if Indx <> -1 then ProductsState[Indx].InvoiceCount:= ProductsState[Indx].InvoiceCount+DM.ADOQuery. FieldValues['IbCount'];

end;

DM.ADOQuery. Next;

end;

{}

StringGrid. ColCount:= 5;

StringGrid. RowCount:= Length(ProductsState)+2;

StringGrid. Cells [0, 0]:= '№';

StringGrid. Cells [1, 0]:= 'Оборудование';

StringGrid. Cells [2, 0]:= 'Реализовано';

StringGrid. Cells [3, 0]:= 'Запланир.';

StringGrid. Cells [4, 0]:= 'Остаток';

StringGrid. ColWidths[0]:= 25;

StringGrid. ColWidths[1]:= 257;

StringGrid. ColWidths[2]:= 60;

StringGrid. ColWidths[3]:= 60;

StringGrid. ColWidths[4]:= 60;

for i:= 0 to Length(ProductsState) - 1 do begin

StringGrid. Cells [0, i+1]:= IntToStr (i+1);

StringGrid. Cells [1, i+1]:= ProductsState[i].Product;

StringGrid. Cells [2, i+1]:= FloatToStr (ProductsState[i].InvoiceCount);

StringGrid. Cells [3, i+1]:= FloatToStr (ProductsState[i].PlanCount);

StringGrid. Cells [4, i+1]:= FloatToStr (ProductsState[i].PlanCount-ProductsState[i].InvoiceCount);

end;

{}

Sum1:= 0;

Sum2:= 0;

Series1. Clear;

Series2. Clear;

for i:= 0 to Length(ProductsState) - 1 do begin

Sum1:= Sum1+ProductsState[i].InvoiceCount;

Sum2:= Sum2+ProductsState[i].PlanCount;

Series1. Add (ProductsState[i].InvoiceCount, Copy (ProductsState[i].Product, 1, 100));

Series2. Add (ProductsState[i].PlanCount-ProductsState[i].InvoiceCount, Copy (ProductsState[i].Product, 1, 100));

end;

{}

Series3. Clear;

if Sum1 > 0 then Series3. Add (Sum1, 'Принято', clGreen);

if Sum2-Sum1 > 0 then Series3. Add (Sum2-Sum1, 'Остаток', clRed);

end;

procedure TFormMain. PrintGrid (sGrid: TStringGrid; sTitle: string);

var

X1, X2: Integer;

Y1, Y2: Integer;

TmpI: Integer;

F: Integer;

TR: TRect;

begin

Printer. Title:= sTitle;

Printer. BeginDoc;

Printer. Canvas. Pen. Color:= 0;

Printer. Canvas. Font. Name:= 'Times New Roman';

Printer. Canvas. Font. Size:= 12;

Printer. Canvas. Font. Style:= [fsBold, fsUnderline];

Printer. Canvas. TextOut (0, 100, Printer. Title);

for F:= 1 to sGrid. ColCount - 1 do

begin

X1:= 0;

for TmpI:= 1 to (F - 1) do

X1:= X1 + 5 * (sGrid. ColWidths[TmpI]);

Y1:= 300;

X2:= 0;

for TmpI:= 1 to F do

X2:= X2 + 5 * (sGrid. ColWidths[TmpI]);

Y2:= 450;

TR:= Rect (X1, Y1, X2 - 30, Y2);

Printer. Canvas. Font. Style:= [fsBold];

Printer. Canvas. Font. Size:= 7;

Printer. Canvas. TextRect (TR, X1 + 50, 350, sGrid. Cells [F, 0]);

Printer. Canvas. Font. Style:= [];

for TmpI:= 1 to sGrid. RowCount - 1 do

begin

Y1:= 150 * TmpI + 300;

Y2:= 150 * (TmpI + 1) + 300;

TR:= Rect (X1, Y1, X2 - 30, Y2);

Printer. Canvas. TextRect (TR, X1 + 50, Y1 + 50, sGrid. Cells [F, TmpI]);

end;

end;

Printer. EndDoc;

end;

procedure TFormMain. StringGrid1DrawCell (Sender: TObject; ACol, ARow: Integer; Rect: TRect; State: TGridDrawState);

var

D: TDateTime;

begin

D:= Now;

if ARow > 0 then begin

StringGrid1. Canvas. Brush. Color:= clWhite;

if StringGrid1. Cells [3, ARow] <> '' then begin

if StrToDate (StringGrid1. Cells [3, ARow]) - D <= Period1 then StringGrid1. Canvas. Brush. Color:= clRed

else if StrToDate (StringGrid1. Cells [3, ARow]) - D <= Period2 then StringGrid1. Canvas. Brush. Color:= clGreen;

end;

StringGrid1. Canvas. FillRect(Rect);

StringGrid1. Canvas. TextOut (Rect. Left, Rect. Top, StringGrid1. Cells [ACol, ARow]);

end;

end;

end.

Размещено на Allbest.ru