Требования к аппаратному обеспечению автоматизированной системы управления торговой деятельностью предприятия вытекают из текущего состояния технической оснащенности предприятий, поэтому, на сегодняшний день, эти требования не должны быть очень высокими. Минимальные требования к компьютеру для работы с автоматизированной системой - Intel Pentium I 200MHz, 32Mb ОЗУ. Обязательным условием является наличие локальной сети Ethernet спецификации IEEE 802.3(10 Мбит/с) или выше и оборудования для обеспечения ее функционирования. Требования к топологии сети отсутствуют.

1.5.5 Требования к информационно-программной совместимости

Требования к программной совместимости: возможность внедрения на платформе Windows 2000 Server; поддержка работы с СУБД Oracle 8i; возможность подключения автоматизированной системы управления торговой деятельностью предприятия как модуля для любой ERP-системы;

В процессе эксплуатации программного продукта, зачастую возникают задачи, которые невозможно решить внутренними средствами. Интеграция средств сторонних разработчиков для решения этих задач приводит к значительному увеличению цены разработки. Поэтому автоматизированная система должна иметь интерфейсы для обмена информацией с наиболее распространенными приложениями для хранения и обработки информации: MSWord, MSExcel. Должна быть реализована поддержка программных средств сторонних производителей: FastReport, ExcelReport.

1.5.6 Требования к программной документации

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

Глава 2. Проектирование автоматизированной системы торговой деятельности

2.1 Принципиальное проектное решение

В качестве автоматизированной системы управления торговой деятельностью предприятия предлагается использовать многопользовательское клиент-серверное приложение(двухуровневая архитектура), разработанное с помощью интегрированной среды Borland Delphi 7 Enterprise Edition. В качестве системы управления базами данных предполагается использование продукта Oracle 8i Enterprise, на базе которого будет развернута комбинированная OLAP\OLTP информационная система, где OLAP-компонента(Online Analytical Process) - обеспечит аналитические функции работы системы(небольшое число запросов, время отклика некритично)

OLTP-компонента (Online Transaction Process) - обеспечит функции оперативного доступа большого числа клиентов(большое число запросов, минимальное время отклика)

Информационная система будет развернута на основе операционной системы Windows 2000 Server платформы Intel. Аппаратная часть: сервер - минимальные требования к конфигурации Intel Pentium-3 450 MHz, 128 Mb ОЗУ. Рекомендуемая конфигурация - Intel Pentium-4 2,4 GHz, 512 Mb ОЗУ. В качестве операционной системы клиентской части предполагается использовать Windows 98 и выше, поэтому требования к аппаратному обеспечению таковы: минимальные - Intel Pentium-2MMX 200MHz, 32Mb ОЗУ. Рекомендуемые - Intel Pentium-3 450 MHz, 128 Mb ОЗУ.

2.1.1 Выбор архитектуры программного обеспечения

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

Рис.1 Архитектура информационной системы

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого выступает Oracle. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть может быть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает недостатками, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе. Поэтому я решила отступить от классического варианта “толстого” клиента и постарался максимально переместить бизнес-логику на сервер, тем самым снизив требования к аппаратному обеспечению клиента и пропускной способности сети. Логика работы системы реализована в виде пакетов хранимых процедур, каждый из вместе с триггерами таблиц которых реализует функционал одного из модулей системы. Таким образом на клиентскую машину будут передаваться не данные для обработки, а обработанные данные.

2.1.2 Выбор программной среды для создания информационной системы

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

Oracle Developer.

Borland Delphi 5-8.

Borland C++ Builder 4-6

Microsoft Visual Studio 6.0

Microsoft Visual Studio .Net

При разработке информационной системы с использованием СУБД Oracle, было бы вполне логично остановиться на первом - “родном” варианте этой компании. В пользу этого варианта говорит и то, что в пакете представлены профессиональные CASE-средства для моделирования и анализа бизнес-процессов(Oracle Designer) с последующей генерацией скриптов для создания базы данных и автоматического формирования макета приложения в соответствии с моделью автоматизированной системы(Oracle Forms), наличие средств генерации отчетов(Oracle Reports) и работы с графикой(Oracle Graphics). Однако, при более детальном изучении этих продуктов становиться ясно, что их использование приведет, во-первых к жесткой привязке программного продукта к политике лицензирования компании Oracle(что на деле выливается в значительные финансовые вложения), а, во-вторых, поскольку это средства с закрытым программным кодом, к уменьшению гибкости приложения. Встает проблема информационной совместимости с другими программными продуктами. Переход компании Oracle к ориентации на средства Java-разработки для приложений работающих в гетерогенных средах, вылился в отказ от поддержки и развития этого пакета. Становится ясно, что этот продукт не подходит для разработки нашей информационной системы.

Borland Delphi 8 for .Net Architect Edition и Microsoft Visual Studio .Net я решила не использовать из-за их сильной ориентации на платформу .NET. Хотя они и позволяют разрабатывать обычные приложения с использованием библиотек WinForms и VCL, для нашей задачи они сильно перегружены средствами для этой платформы.

Я остановила свой выбор на среде Delphi 7 Enterprise Edition. И вот почему:

Ориентация на разработку Win32-приложений

Самые развитые(на мой взгляд) средства для разработки приложений баз данных

Наличие 4 альтернативных интерфейсов работы с СУБД Oracle: ODBC, ODAC, DOA, CLI.

Компонентная технология и необычайно быстрый компилятор [8]

Открытый код и, как следствие, возможность гибкого использования объектно-ориентированного подхода.

2.1.3 Выбор системы управления базами данных

В предыдущих пунктах часто упоминалось, что основным инструментом для полного контроля над данными будет выступать СУБД Oracle 8i. Стоит отметить, что по экспертным оценкам собственные разработки автоматизированных систем управления в 53% базируются на СУБД Oracle, около 15% на Informix, 22% - другие СУБД. Я остановилась на этом решении по следующим соображениям:

На первом месте конечно же стоят требования к объемам данных с которыми предстоит работать. Поскольку речь идет о масштабируемой системе управления предприятием крупного бизнеса, то, очевидно, что только документооборот предполагает обработку миллионов записей ежегодно. Для примера, размер корпоративной информационной системы Омского нефтеперерабатывающего завода в год увеличивается на миллионы записей. Сервер Oracle 8i, традиционно ориентирован на работу с очень большими объемами информации [7]. MSSQLServer 2000, Interbase-Firebird-Yaffil, mySQL не предназначены для работы с такими информационными массивами.

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

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

2.2 Структурный анализ точек функциональности

Здесь немного про RAD.

Для проведения структурного анализа, построим диаграммы потоков данных:

Контекстная диаграмма - отражает связи информационной системы с внешними сущностями.

Рис.2 Контекстная диаграмма потоков данных

Анализ функциональных требований показывает, что система управления должна иметь возможность взаимодействия с поставщиками товаров, что отражено на диаграмме двумя потоками данных с внешней сущностью “Distributor” (Поставщик). Первый из них определяет список товаров и услуг, которые необходимо получить у поставщика(“Заказы”), а второй несет информацию о фактически полученных товарах(“Поставки”). Связи с внешней сущностью “Клиент” осуществляют:

поток данных, отвечающий за предоставление входной информации о требованиях клиента(“Список товаров”)

поток данных выходной информации о предоставленных клиенту товарах и услугах

Взаимодействие с внешней сущностью (“Бухгалтерия”) осуществляется за счет выгрузки сведений о продажах потоком данных “Книга продаж”. Подтверждение безналичных платежей от внешней сущности “Банк” выполняет поток данных (“Платежи”).

2. Диаграмма потоков - детализация контекстной диаграммы. Она представляет собой множество процессов и хранилищ данных, объединенных потоками данных, что позволяет отобразить структуру функционирования информационной системы. Процесс “Сформировать склад” на основе внешнего потока данных “Поставки” формирует хранилище данных “Склад”. Таким образом, склад товаров формируется не из отдельных товаров, а из их групп - поставок, что позволяет точно определить дату прибытия и поставщика товара, а также контролировать не только состояние склада, но и процесс работы с поставщиками. На основании данных этого хранилища, формируется выходной документ - “Счет-фактура” (“Чек”), отражающий реальный отпуск товаров по позициям счета. Процесс “Получить прайс” выполняет обработку хранилища данных “Склад” для формирования прайс-листа товаров на текущий момент. Обработка заключается в определении наличия каждого товара на складе, подсчете количества товара, определении количества свободных и зарезервированных по счетам товаров, преобразовании входных цен в выходные, поддержке мультивалютной системы расчетов (конвертации цен). Результатом этого процесса является хранилище данных “Прайс”. Именно с его помощью, входной поток данных “Список товаров и услуг” от клиента преобразуется в счет - одну из основных сущностей информационной системы. Процесс “Сформировать счет” на основании требований клиента и информации хранилища “Прайс” получает счет клиента, который заносится в хранилище данных - “Счета”. По окончании расчетного периода (месяц) из него происходит выгрузка данных в бухгалтерию потоком данных “Книга продаж”. На основе списка выписанных счетов происходит формирование заказов - процесс “Сформировать заказ” для заполнения хранилища данных “Заказы”. Этот процесс автоматически формирует список закупок, которые после корректировки поставщика и количества товаров образуют выходной поток данных “Заказы”.

Рис.3 Диаграмма потоков данных первого уровня

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

Экраны. Очевидно, что для работы с системой необходимо иметь следующие экранные формы:

Для работы со складом

Для работы с прайс-листом

Для работы со счетами

Для работы с заказами

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

Для формирования наборов данных при работе со складом

Для удобной работы с прайс-листом и группами товаров

Для работы с группами счетов

Для автоматической генерации заказов.

2.3 Проектирование структуры программного обеспечения

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

Рис.4 Связь приложений программного комплекса

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

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

Приложение “Счета”. Предназначено для формирования списка счетов, регистрации операций при работе с клиентами(выписки, оплаты, выполнения), ведения клиентской базы, работы с банком, формирования выходных документов - счетов/чеков, списка счетов, формирования аналитически отчетов по счетам в разрезе товарооборота за период и клиентов, формирования книги продаж. Пользователи - менеджеры по продажам.

Приложение “Заказы”. Предназначено для формирования плана закупок по счетам, возможности редактирования заказов, работы с поставщиками, формирования выходных документов - списков заказов(плана закупок) и аналитических отчетов по закупкам в разрезе поставщиков и отчетных периодов. Пользователи - менеджеры по закупкам.

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

2.4 Проектирование информационного обеспечения

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

Рис.5 ER-модель информационной системы

На рисунке 5 изображены основные сущности информационной системы и их атрибуты. Сущность “Счет” имеет ключевой атрибут “Номер” и связан с сущностью “Клиент” отношением многие - к - одному (атрибут “Клиент”). Она отражает абстрактный объект - счет клиента, с его свойствами: суммой счета и датой выписки. Атрибут состояние отражает текущее состояние счета: “Выписан”, “Оплачен”, “Выполнен”. Сущность “Клиент” отражает реальный объект - покупателя, то есть физическое или юридическое лицо (определяется атрибутом “Тип”) и его реквизиты: для физического лица - Ф.И.О., для юридического лица - “Имя”, “Расчетный счет”, ”ИНН”, “Телефон” и “Ф.И.О. руководителя”. Сущность “Книга продаж” представляет собой список счетов за период. Сущность “Товар” - одна из основных сущностей системы отражает реальный объект - товар с атрибутами “Наименование” и “Входная цена”. “Счет” связан с этой “Сущностью” отношением один -ко- многим. Сущность “Прайс” описывает свойства абстрактного объекта прайс-лист и связана отношением один - ко - многим с сущностью “Товар”. Для формирования сущности “Заказ” необходима его связь с сущностью “Счет” отношением один-ко- многим с сущностью “Счет”. Реальный объект - поставщик определяется с помощью одноименной сущности с атрибутами, отражающими реквизиты организации-поставщика. Так как поставщик может одновременно выполнять несколько заказов, то соответствующая ему сущность связана с сущностью “Заказ” отношением один -ко- многим. Сущность “Поставка” описывает абстрактный объект - поставку, которая имеет свойства(атрибуты) “Дата” и “Поставщик”. Таким образом сущность “Склад” состоит из абстрактных объектов-поставок, которые состоят из реальных объектов - товаров. Необязательная связь между сущностью “Склад” и сущностью “Товары” отражает альтернативный способ пополнения склада - вне поставок.

2.5 Проектирование структуры БД

Таблица “Товар”.

Назначение: Хранение информации о товарах.

Поля:

Номер - уникальный номер товара в таблице

Наименование - наименование товара

Входная цена, USD - текущая входная цена товара

Тип - определяет, является ли товар конечным или группой

Группа - ссылка на группу товара.

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_NUM реализует связь один-ко-многим по полю “Номер”. С ее помощью можно представить реляционную таблицу в виде дерева.

Рис.5 Структура базы данных.

Таблица “Книга продаж”

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

Поля:

Номер - уникальный номер товара в таблице

Номер счета - ссылка на счет, которому принадлежит данный товар

Количество товара -количество единиц товара

Номер товара- ссылка на товар

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Товар реализует связь один-ко-многим по полю “Номер” с таблицей “Товар”.

Таблица “Счет”

Назначение: хранение списка счетов клиентов.

Поля:

Номер - уникальный номер счета в таблице

Клиент - ссылка на клиента, которому счет выписан счет

Дата - дата выписки счета

Сумма - суммарная стоимость товаров, включенных в счет

Состояние - “выписан”, “оплачен”,”выполнен”

Скидка - скидка по счету

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Клиент реализует связь многие-к-одному по полю “клиент” с таблицей “Клиент”.

Таблица “Клиент”

Назначение: хранение списка клиентов.

Поля:

Номер - уникальный номер клиента таблице

Тип - признак физического или юридического лица

ФИО\Наименование - ФИО\Наименование клиента

Телефон - телефон юридического лица

Адрес - адрес юридического лица

Р\С - расчетный счет юридического лица

ИНН - Индивидуальный номер налогоплательщика

Директор - директор организации-клиента

Гл. бухгалтер - гл. бухгалтер организации-клиента

Первичный ключ: Содержит поле “Номер”

Внешние ключи: отсутствуют

Таблица “Заказ”

Назначение: используется для хранения списка заказов

Поля:

Номер - уникальный номер заказа в таблице

Дата - Дата формирования заказа

Поставщик - ссылка на поставщика, которому будет передан заказ

Сумма - суммарная стоимость заказа в ценах поставщика

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставщик реализует связь один-ко-многим по полю “Поставщик” с таблицей “Поставщик”.

Таблица “Содержимое заказа”

Назначение: предназначена для хранения списка товаров (ссылок), которые вошли в заказы.

Поля:

Номер - уникальный номер товара в таблице

Номер товара - ссылка на товар

Количество товара - количество единиц товара

Входная цена - цена на товар в момент заказа

Номер заказа - ссылка на заказ, которому принадлежит товар

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Заказ реализует связь один-ко-многим по полю “Номер заказа” с таблицей “Заказ”.

Таблица “Поставка”

Назначение: хранение списка поставок.

Поля:

Номер - уникальный номер поставки в таблице

Дата прихода поставки на склад

Номер поставщика - ссылка на поставщика

Сумма - суммарная стоимость товаров в поставке

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставщик реализует связь один-ко-многим по полю “Номер поставщика” с таблицей “Поставщик”.

Таблица “Поставщик”

Назначение: хранение информации о поставщиках

Поля:

Номер - уникальный номер поставщика в таблице

Наименование - наименование поставщика

Телефон - телефон поставщика

Адрес - адрес поставщика

Р\С - расчетный счет поставщика

ИНН - Индивидуальный номер налогоплательщика

Контактное лицо - контактное лицо

Первичный ключ: Содержит поле “Номер”

Внешние ключи: отсутствует

Таблица “Содержимое поставки”

Назначение: хранение информации о списке товаров по каждой поставке

Поля:

Номер - уникальный номер товара в таблице

Номер поставки - ссылка на поставку

Количество товара - количество единиц товара

Номер товара - ссылка на товар

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Поставка реализует связь один-ко-многим по полю “Номер поставки” с таблицей “Поставка”.

Таблица “Банк”

Назначение: хранение списка банков, с которыми работает организация

Поля:

Номер - уникальный номер банка в таблице

Наименование - наименование банка

Номер вх. счета - номер счета входящих платежей

Номер исх. счета - номер счета исходящих платежей

Телефон - телефон

Первичный ключ: Содержит поле “Номер”

Внешние ключи: отсутствует

Таблица “Платеж”

Назначение: хранение реестра входящих и исходящих платежей.

Поля:

Номер - уникальный номер платежа в таблице

Сумма - сумма платежа

Банк - ссылка на банк

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

Дата - дата платежа

Тип - входящий\исходящий

Описание - для пользователя

Первичный ключ: Содержит поле “Номер”

Внешние ключи: Ключ FK_Банк реализует связь один-ко-многим по полю “Банк” с таблицей “Банк”.

Таблица “Счет-фактура”

Назначение: хранение списка счет-фактур

Поля:

Номер - уникальный номер счет-фактуры в таблице

Дата формирования

Номер поставщика - ссылка на поставщика

Сумма - суммарная стоимость товаров в поставке

Первичный ключ: Содержит поле “Номер”

2.6 Проектирование приложения “Прайс”

В этом приложении, в качестве структуры данных для хранения товаров было выбрано дерево. Физически, дерево представляет собой реляционную таблицу с дополнительным полем ”Родитель”, которое позволяет организовать связь между группами \ подгруппами и товарами. Первый узел - “Все товары” не имеет родителя и все группы или товары первого уровня являются его потомками. Как следует из анализа требований приложение “Прайс” должно выполнять определенные функции, вызов которых осуществляется из главного меню приложения (рис. 6).

Рис.6 Приложение “Прайс” - главная форма.

Для удобства, функции логически сгруппированы по объекту применения: товары, группы товаров, другие.

Товары

Добавление товара в прайс-лист. Позволяет внести новое наименование в прайс-лист. Служит основным средством для манипуляции ассортиментом. Родитель товара - текущая группа. Входная информация: Наименование и цена товара. Выходная информация - измененный прайс-лист.

Удаление. Позволяет удалить товар из прайс-листа. Не влечет за собой изменения склада\поставок. Отражает факт прекращения работы с данным товаром. Входная информация: товар(номер). Выходная информация - измененный прайс-лист.

Редактирование свойств товара. Позволяет изменить входную цену и наименование товара. Входная информация: Наименование и цена товара. Выходная информация - измененный прайс-лист.

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

Группы товаров

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

Удаление. Позволяет удалить группу товаров из прайс-листа. Удаляет все товары, содержащиеся в группе и все подгруппы. Входная информация: группа(номер). Выходная информация - измененный прайс-лист.

Редактирование группы. Позволяет изменить наименование группы. Входная информация: Наименование группы. Выходная информация - измененный прайс-лист.

Другие

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

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

Для более детального описания приложения рассмотрим его UML-диаграмму, представленную на рисунке 7.

Рис.7 UML-диаграмма приложения “Прайс”.

Из рисунка видно, что дерево товаров является классом, унаследованным от абстрактного класса “Дерево”. Оно использует класс “Группа” для описания каждого элемента дерева и хранит атрибут “Текущая группа” для определения элемента-родителя каждого товара в списке, представленного классом “Список товаров”. В свою очередь, для хранения товаров класс “Список товаров” использует класс “Товар”, а для описания параметров поиска, сортировки и фильтрации класс “Интерфейс”. Еще два класса “Интерфейс” отвечают за пользовательский интерфейс для работы с деревом и списком товаров. Таким образом, реализовано взаимодействие классов внутри приложения.

2.7 Проектирование приложения “Счета”

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

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

Рис.7 Приложение “Счет” - список счетов.

Основные операции для работы со списком счетов:

Добавить счет - создание нового счета. Входные данные: дата. Выходные данные - новый счет, измененный список счетов.

Удалить счет - удаляет счет из списка. Входные данные: счет(номер). Выходные данные - измененный список счетов.

Копировать счет - создает копию счета с теми же параметрами, но другим порядковым номером. Входные данные: счет(номер). Выходные данные - измененный список счетов.

Печать - вызывает диалог выбора отчета и его формата для печати. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные - *.xls или *.rtf файл или печатная форма.

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

Редактировать счет - вызывает форму для работы со счетом. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные - *.xls или *.rtf файл или печатная форма.

Рис.8 Приложение “Счет” - работа со счетом.

Основные операции для работы с содержимым счета:

Добавить товар - добавляет товар в счет. Входные данные: товар(номер). Выходные данные - измененный счет.

Удалить товар - удаляет товар из счета. Входные данные: товар(номер). Выходные данные - измененный счет

Сумма - вычисляет сумму товаров, включенных в счет. Входные данные: счет(номер). Выходные данные - сумма в долларах, рублях и евро.

Печать - вызывает диалог выбора отчета и его формата для печати счета. Входные данные: Шаблон для печати, если *.xls-отчет, форма, если *.frf-отчет. Выходные данные - *.xls или *.rtf файл или печатная форма.

Скидка - пересчитывает позиции счета с учетом скидки. Входные данные: размер скидки. Выходные данные - измененный счет.

Состояние - позволяет изменить состояние счета вручную. Входные данные: состояние. Выходные данные - счет.

UML-диаграмма приложения “Счет” представлена на рисунке 9.

Рис.9 UML-диаграмма приложения “Счет”.

2.8 Проектирование приложения “Склад”

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

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

Рис.10 Приложение “Склад” - Главная форма.

Основные операции для работы со складом перечислены ниже.

Со списком поставок:

Добавить поставку - создание новой поставки и включение ее в список. Входные данные: дата. Выходные данные - новая поставка, измененный список поставок.

Удалить поставку - удаляет поставку из списка. Входные данные: поставка(номер). Выходные данные - измененный список поставок.

Копировать поставку - создает копию поставки с теми же параметрами, но другим порядковым номером. Входные данные: поставка(номер). Выходные данные - измененный список поставок.

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

Редактировать поставку - вызывает форму для работы с содержимым поставки. Входные данные: поставка(номер). Выходные данные содержимое поставки.

Пункты меню формы для работы с содержимым поставки:

Добавить товар - добавляет товар в поставку. Входные данные: товар(номер). Выходные данные - измененная поставка.

Удалить товар - удаляет товар из поставки. Входные данные: товар(номер). Выходные данные - измененная поставка.

Сумма - вычисляет сумму товаров, включенных в поставку. Входные данные: поставка(номер). Выходные данные - сумма товаров в долларах, рублях и евро.

Печать - вызывает диалог выбора отчета и его формата для печати поставки. Входные данные: Шаблон для печати, если *.xls-отчет, то шаблон, если *.frf-отчет. Выходные данные - *.xls или *.rtf файл или печатная форма.

Страницы: 1, 2, 3, 4