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

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

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

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

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

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

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

Далее представлен сценарий диалога.

Далее представлено дерево функций.

2.2.2               Структурная схема проекта

На рисунке 2.14 приведена структурная схема проекта.

Рисунок 2.1. Схема вызова модулей.

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

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

Для реализации каждой подзадачи в проекте были созданы несколько классов, наследников стандартного класса библиотеки VCL TForm.

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

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

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

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

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

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

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

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

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

·           Модуль свойств проекта предназначен для ведения списка свойств проекта;

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

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

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

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

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

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

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

·           Модуль редактирования складов предназначен для редактирования данных конкретного склада;

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

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

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

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

Подсистема аналитической отчетности включает в себя следующие модули:

·           Модуль составления отчета по остаткам товаров на складах;

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

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

·           Форма Fmain – главная форма приложения, реализованная в файле UnitMain.cpp выполняет функции основного интерфейса доступа пользователя ко всем функциям программы через главное меню приложения и панель кнопок быстрого доступа. Кроме того, главная форма выполняет роль контейнера всех остальных форм, в которых происходит ввод и обработка данных.

·           Форма FTovar, реализованная в файле UnitTovar.cpp, выполняет функции просмотра списка товаров, введенных в таблицу товаров базы данных системы. Главным элементом формы является компонент DBGrid палитры компонентов C++ Builder, который отображает таблицу товаров в виде списка. Колонки компонента DBGrid отображают соответствующие поля таблицы товаров: наименование, англоязычное наименование, штрихкод и производитель. Эта же форма служит для выбора товара в случае вызова этой формы из других форм для выбора того или иного товара например в форму отчета по остаткам.

·           Форма FTovarEdit, реализованная в файле UnitTovarEdit.cpp, предназначена для просмотра и редактирования данных о товаре. В этой форме расположены органы управления, в которых отображаются основные данные товара, такие как наименование, англоязычное наименование, подробное описание, синонимы, штрих-код и цена и производитель. Отметим, что производитель выбирается путем открытия формы производителей и выбора его из предлагаемого списка. Кроме основных данных в форме редактирования товара отображаются и данные связанных справочников, записи, которых связаны с данным товаром: аналоги, проекты, к которым относится товар и свойства этого товара с их значениями. Отображении данных связанных справочников в одной форме очень удобно, так как все необходимые данные о товаре находятся вместе. Их можно просмотреть и отредактировать.

·           Форма FormClients, реализованная в файле FormClientsU.cpp, предназначена для просмотре и редактирования данных о контрагентах системы: поставщиках и покупателях. Форма построена таким образом, что позволяет просматривать в левой своей части список покупателей, а в правой подробные данные о текущем покупателе. В списке выводится только наименование покупателя из поля наименования таблицы базы данных, в органах управления в правой части выводятся данные из всех остальных полей. Такой подход весьма удобен, так как позволяет просматривать и редактировать полные данные о клиенте в одной форме. Кнопки «Добавить», «Сохранить» и «Удалить» вызывают процедуры, выполняющие SQL-запросы на добавление, изменение и удаление записей из базы данных.

·           Форма FormVendirs, реализованная в файле FormVendirsU.cpp, предназначена для просмотре и редактирования данных о производителях товаров. Форма построена таким образом, что позволяет просматривать в левой своей части список производителей , а в правой подробные данные о текущем производителе. В списке выводится только наименование производителя из поля наименования таблицы базы данных, в органах управления в правой части выводятся данные из всех остальных полей. Такой подход весьма удобен, так как позволяет просматривать и редактировать полные данные о производителе в одной форме. Кнопки «Добавить», «Сохранить» и «Удалить» вызывают процедуры, выполняющие SQL-запросы на добавление, изменение и удаление записей из базы данных.

·           Форма FProj, реализованная в файле FProjU.cpp, выполняет функции просмотра списка проектов, введенных в таблицу проектов базы данных системы. Главным элементом формы является компонент DBGrid палитры компонентов C++ Builder, который отображает таблицу проектов в виде списка. Колонки компонента DBGrid отображают только поле «Наименование» таблицы проектов. Эта же форма служит для выбора проекта в случае вызова этой формы из других форм для выбора того или иного проекта например в форму редактирования данных о товаре.

·           Форма FProjEdit, реализованная в файле UnitProjEdit.cpp, предназначена для просмотра и редактирования полных данных проекта, а также для назначения проекту свойств проекта. В левой части формы в соответствующих органах управления отображаются все данные проекта из таблицы проектов: наименование, подробное наименовании и подробное описание, а в левой части располагается список свойств этого проекта. По кнопке «Добавить свойство» открывается форма для выбора справочника свойств проектов, которая позволяет выбрать и назначить проекту свойство. Удаление свойства из списка свойств проекта происходит при нажатии кнопки «Удалить свойство».

·           Форма FSimp, реализованная в файле UnitSimp.cpp предназначена для просмотра списка свойств проектов, которые дополнительно характеризуют проект.

·           Форма FSimpEdit предназначена для просмотра и редактирование одного конкретного свойства проекта, которое выбрали для редактирования. Форма позволяет задать основные и дополнительные данные свойства проекта.

·           Форма FProperty, реализованная в файле UnitProperty.cpp, представляет из себя список свойств товаров. В этой форме присутствует лишь список наименований свойств, который пользователь может просмотреть и выбрать одно из этих свойств в вызывающую форму, если форма была открыта для выбора свойства из какой-либо другой формы.

·           Форма FPropertyEdit, реализованная в файле UnitPropertyEdit.cpp предназанчена для редактирования наименования свойства и подробного описания свойства товара, а также для задания значений свойства товаров в списке в правой части формы. Кнопки управления списком позволяют открыть форму значений свойств для выбора значения свойства. Которое может быть назначено данному свойству, а также для редактирования значения свойства, удалить значение свойства.

·           Форма FSklad, реализованная в файле UnitSklad.cpp предназначена для просмотра списка складов, в котором представлены наименования складов. Эта же форма позволяет выбирать текущую запись склада в вызывающую форму

·           Форма FSkladEdit, реализованная в файле UnitSkladEdit.cpp предназначена для просмотра подробных данных и редактирования как наименования, так и дополнительных данных склада.

·           Форма FVals, реализованная в файле UnitVals.cpp предназначена для выбора значения свойства для элемента справочника товаров и вызывается только из формы товаров. Форма значений свойств отображает список свйоств товаров либо полностью, либо только тех значений, которые подчитнены определенному свойству, которое можно выбрать нажав кнопку открытия для выбора формы свойств. После того как свойство выбрано в списке значений свойств отображаются только те значения, которое может принимать данное свойство.

·           Форма FValsEdit, реализованная в файле UnitValsEdit.cpp предназначена для редактирования значения свойства товаров, путем задания его наименования и подробного описания.

·           Форма FormFilter, реализованная в файле FormFilterU.cpp предназначена для решения задачи отбора товаров по совокупности их свойств. Для отбора могут использоваться как основные данные товара (наименование, англоязычное наименование, синонимы, полное наименование, подробное описание) так и связанные данные товара: аналогии и свойства товаров. Так как основные данные товара представляют из себя строковые значения, то форма предлагает пользователю организовать гибкий отбор по этим данным. Можно организовать отбор записей таблицы товары по точному совпадению на введенную фразу, по вхождению введенной фразы в поле отбора, по вхождению в поле отбора всех слов из введенной фразы в любой последовательности или по вхождению в поле отбора хотя бы одного из слов введенной фразы. Такой отбор можно организовать по любому из полей таблицы отбора. Кроме отбора по основным свойствам форма фильтра предоставляет возможность организовать отбор по проектам, которым относится товар. Для этого заполняется список проектов, записи в который добавляются путем выбора проектов из формы списка проекта, когда она открывается для выбора. Органы управления списка проектов позволяют добавлять в список записи, удалять записи из списка, отметить все записи или полностью очистить список. Все записи списка могут имеют отметку использования в отборе или не использования (галочку), сняв которую пользователь может исключить отбор по данному проекту. В результате в отбор записей справочника товаров попадут только те товары, которые относятся к перечисленным в списке проектам. Также в форме реализована отбор по свойствам товаров и их значениям. В список свойств товаров можно добавлять записи из справочника свойств путем открытия формы списка свойств для выбора и выбора из нее определенного свойства. Для текущей записи в списке свойств отображаются все значения, которое может принимать данное свойство из которых пользователь выбирает путем проставления в них отметок нужные. В результате в сформированный отбор попадут только те товары, которые имеют перечисленные в списке значения перечисленных свойств. Форма фильтра не вызывается из главного меню непосредственно, а вызывается только из формы списка товаров, в том числе, когда она открывается для выбора, в случае, если в этой форме нужно организовать отбор товаров по совокупности каких-либо критериев.

·           Форма DM, реализованная в файле UnitDM.cpp представляет из себя модуль хранения компонентов С++ Builder, обеспечивающих доступ к базе данных. Для каждой таблицы базы данных выделен отдельный компонент TQuery, который позволяет вводить и выполнять SQL-запросы, которые позволяют выбирать, редактировать и удалять записи в таблицах базы данных. То что для каждой таблицы выделен лишь один компонент доступа и то что они все объединены в одном модуле связано с тем, что программа имеет MDI-интерфейс и изменении данных в одной форме приводит к моментальному изменению их отображения во всех остальных формах. Кроме компонентов доступа к данным в этой форме хранятся и компоненты, служащие источником данных для компонентов отображения данных в формах. Компонент Database обеспечивает физическую связь всех остальных компонентов программы с базой данных.

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

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

·           Форма FJornalEdit, реализованная в файле UnitJornalEdit.cpp предназначена для редактирования одной строки операции. Эта форма вызывается из формы FJornal для редактирования текущей строки. Форма предоставляет простой интерфейс для ввода и изменения товара и количества в строке. Для выбора товара вызывается форма списка справочника товаров, выбранная запись в которой переносится в форму FJornalEdit.

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

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

·          Форма FRepForm, реализованная в файле UnitRepForm.cpp предназначена для подготовки и формирования отчета по движения товара по складам. Органы управления этой формы позволяют пользователю задать условия формирования отчета, а именно выбрать клиента, с которым была проведена операция прихода или расхода, а также склад, с которого была проведена эта операция. В нижней части формы содержится таблица, в которую пользователь может выбрать несколько записей из справочника товаров, в этом случае отчет по движениям будет строиться именно по этим товарам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2.2. Функционально-технологическая схема задачи А1 «Ведение справочников»

Для каждого выделенного модуля разработана функционально-технологическая схема и детальный алгоритм ее кодирования. Блок-схема задачи А1 приведена на рисунке 2.14, а функционально-технологические схемы всех модулей задачи А1 – на рисунке 2.15.

Рисунок 2.3. схема решения задачи А1 «Ведение справочников»

Рисунок 2.4. Функционально-технологические схемы модулей задачи А1

Опишем подробнее полученные схемы.

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

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

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

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

Алгоритм:

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

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

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

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

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

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

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

Алгоритм:

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

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

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

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

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

Вход: информация о свойстве товаре.

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

Алгоритм:

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

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

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

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

Процесс: Проверка и внесение данных о пользователе.

Вход: информация о пользователе.

Выход: сформированные данные о пользователе в БД

Алгоритм:

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

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

·          Вывести данные о пользователе на экран.

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

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

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

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

Алгоритм:

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

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

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

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

Процесс: Проверка и внесение данных о подразделении.

Вход: информация о подразделении.

Выход: сформированные данные о подразделении в БД

Алгоритм:

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

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

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

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

Процесс: Проверка и внесение данных о производителях.

Вход: информация о производителе.

Выход: сформированные данные о производителе в БД

Алгоритм:

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

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

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

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

Рисунок 2.5. Функционально-технологическая схема задачи Б1 «Введение документов».

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

Рисунок 2.6. Блок схема решения задачи Б1 «Введение документов»

Рисунок 2.7. Функционально-технологические схемы модулей задачи Б1

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

Рисунок 2.8. Функционально-технологическая схема задачи В1 «Формирование отчетов»

Блок-схема задачи В1 приведена на рисунке 2.20, а функционально-технологические схемы всех модулей задачи В1 – на рисунке 2.21

Рисунок 2.9. Блок-схема задачи В1

Рисунок 2.10. Функционально-технологические схемы модулей задачи В1

 

2.4      Контрольный пример реализации проекта и его описание

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

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

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

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

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

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

В справочник товаров были введены три товара:

·           Дверь «Клинкор» металлическая;

·           Дверь «Базель» деревянная;

·           Дверь «Вегас» металлическая

На рисунке 2.24 приведена экранная форма со списком товаров.

Рисунок 2.11. Список товаров

В таблице 17 приведены тестовые данные по свойствам товаров и значениям, которые могут принимать эти свойства

Таблица 17. Тестовые данные по свойствам товаров.

Название свойства	Принимаемые свойством значения
Замок 1	Замок «Тайсон» Замок «Вегас» Замок «Верита» Отсутсвует
Замок 2
Вес	500 кг 120 кг 150 кг
Внешняя обивка	Пластик Декоративный пластик Ковролин Краска эмаль Отсутсвует
Внутренняя обивка
Утепление	Отсутствует Паралон Полистирол

В таблице 18 приведены назначенные товарам свойства и их значения.

Таблица 18. Тестовые данные назначения свойств товаров товарам.

Товар	Свойство	Назначенное значение свойства
Дверь «Клинкор» металлическая	Замок 1	Замок «Тайсон»
	Замок 2	Замок «Верита»
	Вес	500 кг
	Внешняя обивка	Пластик
	Внутренняя обивка	Отсутсвует
	Утепление	Отсутсвует
Дверь «Вегас» металлическая	Замок 1	Замок «Тайсон»
	Замок 2	Замок «Вегас»
	Вес	150 кг
	Внешняя обивка	Декоративный пластик
	Внутренняя обивка	Ковролин
	Утепление	Полистирол
Дверь «Базель» деревянная	Замок 1	Замок «Тайсон»
	Замок 2	Отсутсвует
	Вес	120 кг
	Внешняя обивка	Отсутсвует
	Внутренняя обивка	Ковролин
	Утепление	Паралон

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

 

Таблица 19. Тестовые данные по проектам.

Название типового проекта	Свойства проекта
Загородный дом	Размеры проема 100х200
	Требования к надежности: средние
Квартира в многоквартирном доме	Размеры проема 100х250
	Требования к надежности: средние
Хранилище (нежилое)	Размеры проема 150х250
	Требования к надежности: высокие

Отнесение товара к тому или иному проекту представлено в таблице 20.

 

Таблица 20. Тестовые данные по отнесению товаров к проектам.

Товар	Проект, к которому относится товар
Дверь «Базель» деревянная	Загородный дом
	Квартира в многоквартирном доме
Дверь «Вегас» металлическая	Загородный дом
	Квартира в многоквартирном доме
Дверь «Клинкор» металлическая	Хранилище (нежилое)

Назначение товару всех данных, задание ему аналогов, свойств, отнесение его к тому или иному проекту приведено на рисунке 2.25.

Рисунок 2.12. Тестовая Форма редактирования товара

Также для полноты тестового примера необходимо заполнить справочники производителей, клиентов, складов и пользователей. Их заполнение приведено на рисунках 2.26 – 2.29.

Рисунок 2.13. Тестовое заполнение справочника производителей

Рисунок 2.14. Тестовое заполнение справочника клиентов.

Рисунок 2.15. Тестовое заполнение справочника складов.

Рисунок 2.16. Тестовое заполнение справочника пользователей.

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

·           все изделия, имеющие замок «Тайсон» (форма фильтра приведена на рисунке ).

·           все изделия, относящиеся к проекту «Загородный дом» или к проекту «Квартира в многоквартирном доме»

·           все изделия производителя «Клондайк».

Рисунок 2.17. Задание фильтра товаров.

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

Рисунок 2.18. Журнал документов.

Рисунок 2.19. Форма документа.

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

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

Заключение

В результате выполнения дипломного проекта изучена методика ведения складского учета в ООО «Юнион-двери».

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

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

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

Программа работает в операционной системе Windows 95/98, NT, 2000 , XP и выполнена в среде Borland C++ Builder. Результатами работы программы являются таблицы документов движения по складам и остатков товаров на складах.

Разработанное приложение в ближайшее время будет внедрено на ООО «Юнион-двери». Руководство ООО «Юнион-двери» ожидает от внедрения разработанного приложения большого качественного скачка в организации складского учета. За счет того, что работа персонала будет значительно облегчена за счет автоматизации ведения справочной информации, оформления документов и получения отчетов качество работы персонала значительно улучшится. Разработанное приложение позволит навести порядок в организации работы всех подразделений и каждого конкретного сотрудника, разграничит сотрудников по полномочиям и выполняемым функциям, выявит узкие места в организации деятельности подразделений. Возможность мгновенного получения актуальных остатков на складе позволит устранить хищения продукции, а возможность получения отчетов по движениям товара позволит составлять аналитические отчеты по анализу продаж и делать прогнозы на будущие периоды.

Список использованных источников

1.  Подбельский В.В., Фомин С.С. Программирование на языке Си: Учеб. Пособие. – 2-е доп. Изд. – М: Финансы и статистика, 2002. – 600с.

2.  Герберт Шилдт Программирование на C и C++ для Windows 95 - К.: Торгово - издательское бюро BHV, 1996

3.  Ч. Петзолд Программирование для Windows 95; в двух томах - СПб.: BHV - Санк-Петербург, 1997

4.  Архангельский П.А. «Программирование в Borland C++ 4.0» M. Наука, 2000

5.  Страуструп Б. «Язык программирования С++: Пер. с англ.» М. Радио и связь, 1991.-352с.:ил.

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

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

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

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

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

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

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

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

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

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

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

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

18.  Фаронов В.В. Delphi 3. Учебный курс. М., Нолидж, 1998

19.  Фаронов В.В. Delphi 4. Учебный курс. М., Нолидж, 1998

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

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

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

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

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

Приложение

Диаграмма потока данных «как есть»

Диаграмма потока данных «как должно быть».

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