Файл: Проектирование реализации операций бизнес-процесса «Складской учет» (на примере ОАО «ТесКом»).pdf

>| - один или более объектов могут участвовать в связи,

>0 – ноль или более, то есть любое число объектов может участвовать в связи.

Например, связь между заказчиком и его заявками можно представить

следующей схемой.

«Рис.12 Представление связи «один ко многим» с обязательным участием в связи сущности «Заявка»

Установленный тип связи утверждает, что экземпляры сущности «Заказчик» могут появиться в БД без связанных экземпляров сущности «Заявка», но каждый экземпляр сущности «Заявка» должен быть связан точно с одним экземпляром сущности «Заказчик». Это связь типа «один ко многим» (1:М) со слабой сущностью «Заявка».

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

Таким образом, связь между экземплярами этих сущностей является «один к одному» (1:1) с обязательным участием обоих объектов в связи (рис. 13).

«Рис.13 Представление связи «один к одному» с обязательным участием обеих сущностей в связи»

В третьем примере рассматривается взаимодействие между сущностью «Договор» и «Типовая конструкция». В одном договоре может не быть типовых конструкций, а в другом использоваться их любое число, типовая конструкция может не применяться, если она только что разработана, или применяться во многих договорах. Эту связь следует представить бинарным отношением типа «многие ко многим» с «сильными» сущностями, необязательно участвующими в связи (рис.14).

«Рис.14 Представление необязательной связи «многие ко многим»

Приведенные примеры взаимодействий (связей) сущностей являются наиболее распространенными и поэтому именно они являются основой другого типа схем для представления информационной модели ПО - ER диаграммы.

Диаграмма «сущность связь» (Essence Relation) или ER диаграмма также представляет собой граф, вершинами которого являются сущности ПО, взаимодействия которых задаются только бинарными связями, не имеющими имен и атрибутов. Поэтому для отображения произвольных связей объектов ПО в схему должны вводиться дополнительные сущности, представляющие связи. Бинарные связи в ER диаграмме задаются непоименованными линиями.

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

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

Выясняется круг специалистов – пользователей автоматизированной

системы.

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

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

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

Анализируя взаимодействия объектов, образовавших сущности, выясняются связи между сущностями и создается концептуальная схема ПО, например, в виде диаграммы Чена. При необходимости сложные сущности декомпозируются на более простые посредством их детализации и конкретизации с соответствующей декомпозицией связей. На рис. 15 приведен пример концептуальной схемы данных в виде диаграммы Чена для процесса приема и исполнения.

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

ЗАКАЗЧИК

Обязательные атрибуты:

Номер – целое (1 – 100000), первичный ключ,

Наименование - строка не более 60 символов,

ИНН – индивидуальный номер налогоплательщика, 12 десятичных цифр, может служить дополнительным (вторичным) ключом,

Адрес - строка до 40 символов,

ФИО контактного лица – строка до 50 символов,

. . . . . . . .

Необязательные атрибуты:

Телефоны – строка до 20 символов

Реквизиты банка – строка до 28 символов

. . . . . . . .

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

«Рис. 15 Концептуальная схема (диаграмма Чена) для процесса приема и исполнения заказа»

Характеристика результатной информации

В данном пункте рассматривается документ формирование заказа на поставку. В стандартной конфигурации “1С: Торговля и склад” уже имелся такой документ, но он не удовлетворял потребностям “Теском”. Поэтому были разработаны «Формы» «Отчеты» «Запросы», отвечающий потребностям данной организации (Рис.16).

«Рис.16 Главная кнопочная форма»

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

При нажатие кнопки запрос выбирается ряд запросов различных типов (см. рис. 17)

«Рис. 17 Запросы»

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

«Рис.18 Формы»

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

При получении товара по данному заказу (то есть, при проведении выписанной на основании данного заказа приходной накладной или приходной реализатора) количество ожидаемого товара автоматически уменьшается. В конфигурации предусмотрена возможность снятия заказа, с помощью формирующегося на его основании документа – «Снятие заказа».

Документ Заказ может быть заполнен ручным способом: путем построчного ввода, подбором или по прайс-листу.

На основании заказа на поставку могут быть выписаны следующие подчиненные документы:

«Расходный кассовый ордер» – для фиксации наличной оплаты по заказу.

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

«Приходная накладная» или «Приходная реализации» для регистрации получения товаров по заказу.

«Заказ на поставку» для корректировки ранее выписанного заказа.

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

2.2. Программное обеспечение задачи (комплекса задач)

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

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

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

Список функций, реализованный в программе, представлен в таблице 6

Таблица 6

Функции БД

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

«Рис.20 Структура главного меню БД»

Структурная схема пакета (дерево вызова процедур и программ)

Рассмотрим систему меню автоматизируемой системы на рисунке 21.

Главная кнопочная форма

О программе Выход из

программы

Таблицы Запросы Формы Отчеты

Аксус Самара

Аксус Самара

Поиск по всей БД

Аксус-Самара

Фам -копи

Фам -копи

Аксус Самара

Фам -копи

Эврика

Эврика

Назад

Поставщики

Плательщики

Назад

Назад

Поставщики

Плательщики

Эврика

Фам -копи

Назад

Эврика

«Рис. 21 Система меню автоматизируемой системы»

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

Взаимодействие пользователя с системой осуществляется в диалоговом режиме. Основным связующим элементом разрабатываемой АИС является система меню, состоящего из главного меню и подменю. Разработанная система является меню - ориентированной.

При выборе меню Таблицы пользователь попадает в подменю, в котором определены:

• приходные накладные;
• назад.

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

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

• поиск по № документа;
• поиск по дате документа;
• поиск по поставщику.

Обработанная информация выдается в виде отчета.

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

При выборе меню Запросы пользователь попадает в подменю, в котором определены:

• поиск по всей БД;
• товарные накладные;
• поиск документов;
• назад.

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