Здесь немного про RAD.
Для проведения структурного анализа, построим диаграммы потоков данных:
Контекстная диаграмма - отражает связи информационной системы с внешними сущностями.
Рис.2 Контекстная диаграмма потоков данных
Анализ функциональных требований показывает, что система управления должна иметь возможность взаимодействия с поставщиками товаров, что отражено на диаграмме двумя потоками данных с внешней сущностью “Distributor” (Поставщик). Первый из них определяет список товаров и услуг, которые необходимо получить у поставщика(“Заказы”), а второй несет информацию о фактически полученных товарах(“Поставки”). Связи с внешней сущностью “Клиент” осуществляют:
поток данных, отвечающий за предоставление входной информации о требованиях клиента(“Список товаров”)
поток данных выходной информации о предоставленных клиенту товарах и услугах
Взаимодействие с внешней сущностью (“Бухгалтерия”) осуществляется за счет выгрузки сведений о продажах потоком данных “Книга продаж”. Подтверждение безналичных платежей от внешней сущности “Банк” выполняет поток данных (“Платежи”).
2. Диаграмма потоков - детализация контекстной диаграммы. Она представляет собой множество процессов и хранилищ данных, объединенных потоками данных, что позволяет отобразить структуру функционирования информационной системы. Процесс “Сформировать склад” на основе внешнего потока данных “Поставки” формирует хранилище данных “Склад”. Таким образом, склад товаров формируется не из отдельных товаров, а из их групп - поставок, что позволяет точно определить дату прибытия и поставщика товара, а также контролировать не только состояние склада, но и процесс работы с поставщиками. На основании данных этого хранилища, формируется выходной документ - “Счет-фактура” (“Чек”), отражающий реальный отпуск товаров по позициям счета. Процесс “Получить прайс” выполняет обработку хранилища данных “Склад” для формирования прайс-листа товаров на текущий момент. Обработка заключается в определении наличия каждого товара на складе, подсчете количества товара, определении количества свободных и зарезервированных по счетам товаров, преобразовании входных цен в выходные, поддержке мультивалютной системы расчетов (конвертации цен). Результатом этого процесса является хранилище данных “Прайс”. Именно с его помощью, входной поток данных “Список товаров и услуг” от клиента преобразуется в счет - одну из основных сущностей информационной системы. Процесс “Сформировать счет” на основании требований клиента и информации хранилища “Прайс” получает счет клиента, который заносится в хранилище данных - “Счета”. По окончании расчетного периода (месяц) из него происходит выгрузка данных в бухгалтерию потоком данных “Книга продаж”. На основе списка выписанных счетов происходит формирование заказов - процесс “Сформировать заказ” для заполнения хранилища данных “Заказы”. Этот процесс автоматически формирует список закупок, которые после корректировки поставщика и количества товаров образуют выходной поток данных “Заказы”.
Рис.3 Диаграмма потоков данных первого уровня
На основе диаграммы потоков данных первого уровня можно выделить контрольные точки функционирования информационной системы:
Экраны. Очевидно, что для работы с системой необходимо иметь следующие экранные формы:
Для работы со складом
Для работы с прайс-листом
Для работы со счетами
Для работы с заказами
Запросы. Для получения требуемой информации в каждой форме необходимо предусмотреть запросы
Для формирования наборов данных при работе со складом
Для удобной работы с прайс-листом и группами товаров
Для работы с группами счетов
Для автоматической генерации заказов.
2.3 Проектирование структуры программного обеспечения
На основании анализа контрольных точек и результатов обследования предметной области, я пришла к выводу, что наиболее удобной структурой для информационной системы управления торговой деятельностью предприятия является программный комплекс, состоящий из четырех независимых по сути приложений, обеспечивающих выполнение всех функциональных требований. В пользу этого решения говорит необходимость разделения должностных обязанностей специалистов по закупкам, менеджеров по работе с клиентами, заведующего складским учетом. С точки зрения внутренней архитектуры программного комплекса, каждое из четырех приложений представляет собой динамически загружаемую библиотеку, подключаемую по мере надобности к родительскому приложению . Графически это показано на рис. 4.
Рис.4 Связь приложений программного комплекса
Приложение “Склад”. Предназначено для работы со складом: регистрации факта прихода поставок на склад, регистрации факта отпуска товаров со склада по счетам и чекам, формирования выходной документации - счет фактур, накладных отпуска, формирования аналитических отчетов о состоянии склада в разрезах товаров, поставок, поставщиков и объемов товарооборота. Пользователи - заведующие складским учетом.
Приложение “Прайс-лист”. Используется для оперативного получения информации о ценах на товары, находящихся на складе. Играет роль основного справочника по товарам. Все операции по внесению, редактированию и удалению информации о товарах производятся именно с помощью этого приложения. Смысловая нагрузка - информация о ценах, по которой поставщики готовы продать данный товар(входные цены) и информация о ценах, по которым товар может быть продан(выходные цены). Пользователи - менеджеры по закупкам, менеджеры по продажам.
Приложение “Счета”. Предназначено для формирования списка счетов, регистрации операций при работе с клиентами(выписки, оплаты, выполнения), ведения клиентской базы, работы с банком, формирования выходных документов - счетов/чеков, списка счетов, формирования аналитически отчетов по счетам в разрезе товарооборота за период и клиентов, формирования книги продаж. Пользователи - менеджеры по продажам.
Приложение “Заказы”. Предназначено для формирования плана закупок по счетам, возможности редактирования заказов, работы с поставщиками, формирования выходных документов - списков заказов(плана закупок) и аналитических отчетов по закупкам в разрезе поставщиков и отчетных периодов. Пользователи - менеджеры по закупкам.
Основное приложение включает в себя функции администрирования: соединения, управления пользователями, управление правами доступа, манипуляции справочной информацией - курсы валют и фирмы-производители.
2.4 Проектирование информационного обеспечения
Для разработки моделей данных и обеспечения стандартного способа определения данных и отношений между ними построим диаграмму сущность-связь (ERD).
Рис.5 ER-модель информационной системы
На рисунке 5 изображены основные сущности информационной системы и их атрибуты. Сущность “Счет” имеет ключевой атрибут “Номер” и связан с сущностью “Клиент” отношением многие - к - одному (атрибут “Клиент”). Она отражает абстрактный объект - счет клиента, с его свойствами: суммой счета и датой выписки. Атрибут состояние отражает текущее состояние счета: “Выписан”, “Оплачен”, “Выполнен”. Сущность “Клиент” отражает реальный объект - покупателя, то есть физическое или юридическое лицо (определяется атрибутом “Тип”) и его реквизиты: для физического лица - Ф.И.О., для юридического лица - “Имя”, “Расчетный счет”, ”ИНН”, “Телефон” и “Ф.И.О. руководителя”. Сущность “Книга продаж” представляет собой список счетов за период. Сущность “Товар” - одна из основных сущностей системы отражает реальный объект - товар с атрибутами “Наименование” и “Входная цена”. “Счет” связан с этой “Сущностью” отношением один -ко- многим. Сущность “Прайс” описывает свойства абстрактного объекта прайс-лист и связана отношением один - ко - многим с сущностью “Товар”. Для формирования сущности “Заказ” необходима его связь с сущностью “Счет” отношением один-ко- многим с сущностью “Счет”. Реальный объект - поставщик определяется с помощью одноименной сущности с атрибутами, отражающими реквизиты организации-поставщика. Так как поставщик может одновременно выполнять несколько заказов, то соответствующая ему сущность связана с сущностью “Заказ” отношением один -ко- многим. Сущность “Поставка” описывает абстрактный объект - поставку, которая имеет свойства(атрибуты) “Дата” и “Поставщик”. Таким образом сущность “Склад” состоит из абстрактных объектов-поставок, которые состоят из реальных объектов - товаров. Необязательная связь между сущностью “Склад” и сущностью “Товары” отражает альтернативный способ пополнения склада - вне поставок.
2.5 Проектирование структуры БД
Таблица “Товар”.
Назначение: Хранение информации о товарах.
Поля:
Номер - уникальный номер товара в таблице
Наименование - наименование товара
Входная цена, USD - текущая входная цена товара
Тип - определяет, является ли товар конечным или группой
Группа - ссылка на группу товара.
Первичный ключ: Содержит поле “Номер”
Внешние ключи: Ключ FK_NUM реализует связь один-ко-многим по полю “Номер”. С ее помощью можно представить реляционную таблицу в виде дерева.
Рис.5 Структура базы данных.
Таблица “Книга продаж”
Назначение: хранение информации о проданных товарах. Фактически, используется для хранения содержимого по каждому счету.
Номер счета - ссылка на счет, которому принадлежит данный товар
Количество товара -количество единиц товара
Номер товара- ссылка на товар
Внешние ключи: Ключ FK_Товар реализует связь один-ко-многим по полю “Номер” с таблицей “Товар”.
Таблица “Счет”
Назначение: хранение списка счетов клиентов.
Номер - уникальный номер счета в таблице
Клиент - ссылка на клиента, которому счет выписан счет
Дата - дата выписки счета
Сумма - суммарная стоимость товаров, включенных в счет
Состояние - “выписан”, “оплачен”,”выполнен”
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
