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

Такие сущности называют обязательно участвующими (существующими только) в связи с другими сущностями или «слабыми». Напротив, объект сущности «Заказчик» может появиться и без связи с заявкой как возможный будущий заказчик. Такие сущности называют не обязательно участвующими в связи, или «сильные» сущности.

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

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

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

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

>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 Концептуальная схема (диаграмма Чена) для процесса приема и исполнения заказа»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 6

Функции БД

№ п/п	Служебные функции	Название окна приложения
	Ввод исходных данных	Окно формирования справочных данных
	Формирование учетных данных	Окно формирование учетных данных
	Выбор типа операций	Меню системы
	Изменение, удаление, добавление записей в таблицах	Окно формирования справочных данных
	Изменение, удаление, добавление записей учетной информации	Окно формирование учетных данных
	Получение данных по запросам	Окно главной формы
	Получение отчетной информации	Окно подменю отчеты

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

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

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

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

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

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

программы

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

Аксус Самара

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

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

Фам -копи

Аксус Самара

Фам -копи

Эврика

Поставщики

Плательщики

Поставщики

Плательщики

Эврика

Фам -копи

Эврика

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

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

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

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

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

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