3.2 Моделирование учёта приобретения материалов подотчетным лицом в розничной торговле

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

Модель (лат. “modulus” – мера) – объект-заместитель объекта-оригинала, обеспечивающий изучение некоторых свойств последнего; упрощенное представление системы для её анализа и предсказания, а также получения качественных и количественных результатов, необходимых для принятия правильного управленческого решения.

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

Единая классификация видов моделей затруднительна в силу многозначности понятия “модель” в науке и технике. Её можно проводить по различным основаниям: по характеру моделей и моделируемых объектов; по сферам приложения и др.

Моделирование – представление объекта моделью для получения информации о нём путём проведения экспериментов с его моделью.

Под термином “моделирование” обычно понимают процесс создания точного описания системы; метод познания, состоящий в создании и исследовании моделей.

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

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

В таблице 2 приведена модель Захмана, соответствующая теме «Учет затрат на приобретение материалов подотчетным лицом в розничной торговле». В модели были выделены 4 столбца, 3 из них отвечают на вопросы: Кто? Что? Когда?, а один описывает функции, соответствующие определенному этапу информационной системы.

Кто?	Функции	Что?	Когда?
Руководитель Секретарь Подотчетное лицо Бухгалтер Поставщик	Проверка документов Написание Доверенности Составление расходного кассового ордера Выдача наличных денежных средств Приобретение материалов Получение необходимых документов при приобретении материалов Составление Авансового отчета Передача Авансового отчета и других документов в кассу Проверка предоставленных документов Составление Приходного (или Расходного) кассового ордера	Приказ Заявление Доверенность Расходный кассовый ордер Наличные денежные средства Материалы Счет-фактура Авансовый отчет Чек, товарная накладная и т.д. Приходный кассовый ордер	Создание приказа о подотчетных лицах Утверждение приказа Передача приказа в кассу Написание Заявления подотчетным лицом Проверка документов подотчетного лица Написание Доверенности на подотчетное лицо Составление расходного кассового ордера Выдача наличных денежных средств Приобретение материалов Получение Счет-фактуры, товарного чека, накладной и т.д. Составление Авансового отчета Передача Авансового отчета и других документов в кассу Проверка предоставленных документов бухгалтером Составление Приходного (или Расходного) кассового ордера

Таблица 2 - Модель Захмана. Учет затрат на приобретение материалов подотчетным лицом в розничной торговле.

Диаграмма деятельности UML

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

Деятельность выполняется, только тогда, когда готовы все его «входы», после выполнения, деятельность передает управление и (или) данные на свои «выходы». Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали слева направо или сверху вниз.

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

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

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

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

Рисунок 15 – Диаграмма деятельности

Диаграмма вариантов использования

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

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

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

• каждый вариант использования относится как минимум к одному действующему лицу,

• каждый вариант использования имеет инициатора,

• каждый вариант использования приводит к соответствующему результату (результату с «бизнес-значением»).

На рисунках 16.1, 16.2, 16.3 представлены диаграммы вариантов использования, которые отражают графическое представление взаимодействия, так называемых, актеров и системой. В качестве актеров данной системы могут выступать два субъекта, один из которых является бухгалтером, а другой – подотчетным лицом (подотчетным лицом – поставщиком, подотчетным лицом – бухгалтером). Каждый из этих актеров взаимодействует с рассматриваемой системой и является ее пользователем, т. е. они оба обращаются к соответствующему сервису "Выдать денежные средства» («Приобрести материалы», «Отчет перед кассой»). Далее этот вариант использования уточняется более детально на 4-5 вариантов использования, выделяя в качестве отдельных серверов проверку подотчетного лица на задолженность, составление расчетного кассового ордера, выписку доверенности и получение расписки, например.

Рисунок 16.1 – Диаграмма вариантов использования

Рисунок 16.2 – Диаграмма вариантов использования

Рисунок 16.2 – Диаграмма вариантов использования

Диаграмма иерархии функций BFD

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

1. Функция – некоторое действие ИС, необходимое для решения экономической задачи;

2. Декомпозиция функций – разбиение функций на множество подфункций;

Рисунок 17 – Диаграмма иерархии функций

Диаграмма переходов состояний

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

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

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

На диаграммах 18.1 и 18.2 представлены диаграммы переходов состояний для задачи автоматизации документов, которые являются основными при учете затрат на приобретение материалов подотчетным лицом – Расходный (приходный) кассовый ордер и Авансовый отчет.

Расходный (приходный) кассовый ордер

Рисунок 18.1 - Расходный (приходный) кассовый ордер

Авансовый отчет

Рисунок 18.2 – Авансовый отчет

Инфологические модели

Процесс разработки информационно-логической модели предметной области (далее – ИЛМ) является творческим и трудно поддается

формализации. Для построения ИЛМ необходимо знание предметной

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

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

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

Строго в соответствии с потребностями выявляются информационные

объекты, из которых должна состоять БД. При втором подходе изучается предметная область, производится анализ её данных и устанавливаются типовые объекты предметной области. Возможно сочетание обоих подходов. При разработке ИЛМ в соответствии с первым подходом сначала осуществляется выявление форм документов – источников, содержащих необходимых данные. Данные в документах представлены в виде реквизитов. Далее могут быть установлены функциональные зависимости реквизитов, которые используются для выделения нормализованных информационных объектов. Последующее определение структурных связей между объектами позволяет закончить построение информационно-логической модели (ИЛМ).

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

При проектировании БД применяются понятия “Сущность” и

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

Информационный объект (ИнО) является информационным описанием некоторой сущности. Информация об ИнО представляется совокупностью экземпляров записей данных. Информационные объекты и

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

логической моделью БД предметной области (ИЛМ ПО). Выделение информационных объектов ПрО, отвечающих требованиям нормализации, может производиться на основе различных под-

ходов, требующих разных трудозатрат и имеющих различную степень

формализации действий.

Интуитивный подход к выделению информационных объектов

предполагает непосредственное выявление реальных объектов, а также

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

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

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

связей объектов типа “М : M” к связям типа “1: М”. При таком подходе,

если отсутствует достаточный опыт, возможны существенные ошибки.

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

сразу выделять информационные объекты, отвечающие требованиям

третьей нормальной формы (3НФ) и соответственно строить ИЛМ.

В результате анализа предметной области должен быть выявлен

состав форм документов и их реквизитов, подлежащих хранению в базе

данных. Для выделения ИнО надо произвести семантический анализ и

выявить функциональные зависимости реквизитов.

В результате анализа предметной области должен быть выявлен

состав форм документов и их реквизитов, подлежащих хранению в базе

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

что форма документа уже отображает структуру данных, так как любой

документ объединяет логически взаимосвязанные реквизиты. Как правило, в качестве аргументов выступают ключевые реквизиты.

Ключом в документе является подмножество, состоящее из одного

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

Ключ документа позволяет выделить документ из множества других

подобных документов, а ключ строки документа – строку из множества

строк в его табличной части. Очевидно, что ключевым называется рек-

визит, входящий в состав ключа. Ключ, состоящий из одного реквизита,

называется простым, а из нескольких реквизитов – составным. В ряде

случаев ключом может нескольких подмножеств ключевых реквизитов

документа. Такие подмножества называются возможными,

потенциальными или альтернативными ключами. Ключ, выбранный из

множества альтернативных в качестве ключа ИнО, называется

выделенным ключом.

Совокупность всех ИнО одного типа в заданной ПрО образует

множество ИнО, элементы которого называются экземплярами ИнО.

При выбор ключа из альтернативных следует руководствоваться:

- ограничениями предметной области,

- минимизацией объёма внешней памяти, занимаемой базой

данных,

- использованием ключа в СУБД при решении задач

пользователей.

Совокупность всех значений ключа ИнО образует множество, в

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

ИнО, образованного из справочного документа, может быть использовано наименование или код номенклатуры1. Наименования всегда используются в документах, и их следует применять в экранных формах

документов и отчётах приложений СУБД.

Использование наименования в качестве ключа ИнО имеет следующие недостатки:

- наименования могут иметь повторяющиеся значения, напри-

мер, ФИО студента или работающего;

- они имеют большой размер (занимают много места во внешней

памяти);

- не позволяют производить отбор данных из базы данных в соответствии с заданными значениями классификационных при-

знаков.

Использование кодов номенклатуры в качестве ключа лишено перечисленных выше недостатков ключей-наименований:

- коды не имеют повторяющихся значений;

- они существенно короче наименований;

- коды позволяют производить отбор данных из базы данных в

соответствии с заданными значениями классификационных

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

да.

Из сказанного выше следует, что в качестве ключа следует использовать коды номенклатуры, а не их наименования. Если код номенклатуры отсутствует в документе, то его следует ввести в ИнО, соответствующий этому документу, для использования кода в качестве

ключа.

Один и тот же реквизит в разных ИнО объектах может быть ключевым и не ключевым (описательным). Замена наименования номенклатуры её кодом целесообразна и в том случае, если этот реквизит не

ключевой, т.к. в этом случае он будет занимать меньше места на машинном носителе.

Счёт-фактура

Поставщик

Поставщик	Адрес	Телефон	ИНН
ПСТ	АДРПСТ	ТЕЛПСТ	ИННПСТ

Таблица 3.1 - Поставщик

Счет-фактура

№ Счет-фактуры	Дата выписки счет-фактуры	НДС	Наименование товара	Единица измерения	Количество	Цена
№ СФ	ДАТА	НДС	НАИМТ	ЕИ	КОЛ	ЦЕНА

Таблица 3.2 – Счет-фактура

База данных ведется у покупателя

Функциональные зависимости:

ИННПСТ -> {ПСТ, АДРПСТ, ТЕЛПСТ}

{№ СФ, ИННПСТ} -> {ДАТА, НДС}

КОДТ -> {НАИМТ, ЕИ}

{№ СФ, ИННПСТ, КОДТ} -> {КОЛ, ЦЕНА}

Графическое изображение

Документ	Наименование реквизита	Обозначение реквизита	Ф ункциональная зависимость
Счет-фактура	№ Счет-фактуры Дата выписки счет-фактуры НДС ИНН поставщика Поставщик Адрес поставщика Телефон поставщика Код товара Наименование товара Единица измерения Количество Цена	№ СФ ДАТА НДС ИННПСТ ПСТ АДРПСТ ТЕЛПСТ КОДТ НАИМТ ЕИ КОЛ ЦЕНА

Таблица 3.3 – Графическое изображение Счет-фактуры

Функциональная зависимость

	Название ИнО	Имя ИнО	Семантика ИнО
ИННПСТ -> {ПСТ, АДРПСТ, ТЕЛПСТ}	Поставщик	ПСТ	Общие сведения о поставщике
{№ СФ, ИННПСТ} -> {ДАТА, НДС}	Счет-фактура	СФ	Сведения о покупке товара по счет-фактуре
КОДТ -> {НАИМТ, ЕИ}	Товар	ТОВАР	Справочные сведения о товаре
{№ СФ, ИННПСТ, КОДТ} -> {КОЛ, ЦЕНА}	Покупка	ПОК	Общие сведения о документе

Таблица 3.4 – Функциональная зависимость

Связываемые ИнО

Связываемые ИнО	Общие реквизиты
Счет-фактура - Поставщик	ИННПСТ
Товар – Покупка	КОДТ
Счет-фактура - Покупка	№ СФ

Таблица 3.5 - Связываемые ИнО

С чет-фактура

П оставщик

Т овар

Покупка

С чет-фактура

Покупка

Связи: М:1, М:1, 1:М соответственно

Товар		Поставщик		Покупка		Сет-фактура
К ОДТ НАИМТ ЕИ		И ННПСТ ПСТ АДРПСТ ТЕЛПСТ		№ СФ ИННПСТ КОДТ КОЛ ЦЕНА		№ СФ ИННПСТ ДАТА НДС

Поставщик

Т овар

Счет-фактура

П окупка

Расходный кассовый ордер

Поставщик

Организация	ИНН
ОРГ	ИННОРГ

Таблица 4.1 - Поставщик

Расходный кассовый ордер

№ Расходного кассового ордера	Дата выписки РКО	НДС	Сумма
№ РКО	ДАТА	НДС	СУМ

Таблица 4.2 - Расходный кассовый ордер

База данных ведется у покупателя

Функциональные зависимости:

ИННОРГ -> {ОРГ }

{№ РКО, ИННОРГ} -> {ДАТА, СУМ}

Графическое изображение

Документ	Наименование реквизита	Обозначение реквизита	Функциональная зависимость
Расходный кассовый ордер	№ Расходного кассового ордера Дата выписки РКО НДС Сумма Организация Расходный кассовый ордер ИНН организации	№ РКО ДАТА НДС СУМ ОРГ РКО ИННОРГ

Таблица 4.3 - Графическое изображение РКО

Функциональная зависимость

	Название ИнО	Имя ИнО	Семантика ИнО
ИННОРГ -> {ОРГ }	Организация	ОРГ	Общие сведения о поставщике
{№ РКО, ИННПСТ} -> {ДАТА, СУМ}	Расходный кассовый ордер	ПКО	Сведения о выдаче денег по РКО

Таблица 4.4 - Функциональная зависимость

Связываемые ИнО

Связываемые ИнО	Общие реквизиты
Расходный кассовый ордер - Организация	ИННОРГ

Таблица 4.5 - Связываемые ИнО

Ниже представлена информационно-логическая модель (ИЛМ),

отображённая в графическом виде в соответствии с выявленными

связями.

Р КО

О рганизация

Связи: М:1

РКО		Организация
№ РКО ДАТА СУМ ИННОРГ		ИННОРГ

Расходный кассовый ордер

О рганизация

Авансовый отчет

Организация

Наименование организации	ИНН
НОРГ	ИННОРГ

Таблица 5.1 - Организация

Авансовый отчет

№ Авансового отчета	Дата выписки авансового отчета	Наименование расходов	Номер расходов	Сумма расходов
№ АО	ДАТА	НАИМР	НОМР	СУМ

Таблица 5.2 – Авансовый отчет

База данных ведется у покупателя

Функциональные зависимости:

ИННОРГ -> {НОРГ}

{№ АО, ИННОРГ} -> {ДАТА}

{№ АО, ИННОРГ, НОРГ} -> {НАИМР, СУМ}

Графическое изображение

Документ	Наименование реквизита	Обозначение реквизита	Функциональная зависимость
Авансовый отчет	Наименование организации ИНН организации № Авансового отчета Дата выписки Авансового отчета Наименование расходов Номер расходов Сумма расходов	НОРГ ИННОРГ № АО ДАТА НАИМР НОМР СУМ

Таблица 5.3 – Графическое изображение АО

Функциональная зависимость

	Название ИнО	Имя ИнО	Семантика ИнО
ИННОРГ -> {НОРГ}	Организация	ОРГ	Общие сведения о оргнизации
{№ АО, ИННОРГ} -> {ДАТА}	Авансовый отчет	АО	Сведения о покупке товара по Авансовому отчету
{№ АО, ИННОРГ, НОРГ} -> {НАИМР, СУМ}	Расходы	НАИМР	Справочные сведения о расходах

Таблица 5.4 - Функциональная зависимость АО

Связываемые ИнО

Связываемые ИнО	Общие реквизиты
Организация – Авансовый отчет	ИННОРГ
Организация- расходы	ИННОРГ, № АО
Авансовый отчет - расходы	№ АО

Таблица 5.5 - Связываемые ИнО

Ниже представлена информационно-логическая модель (ИЛМ),

отображённая в графическом виде в соответствии с выявленными

связями.

А вансовый отчет

О рганизация

Р асходы

Организация

Р асходы

Авансовый отчет

Связи: М:1, М:1, М:1 соответственно

Авансовый отчет		Организация		Расходы
ИННОРГ № АО ДАТА		И ННОРГ ОРГ		№ АО ИННОРГ НАИМР НОМР СУМ

О рганизация

Авансовый отчет

Р асходы

Доверенность

Организация

Организация	Адрес	ИНН
ОРГ	АДРОРГ	ИННОРГ

Таблица 6.1 - Организация

Получатель

Ф.И.О	Паспорт	Дата выдачи	Срок действия доверенности
ФИО	ПРТ	ДАТАВ	СРД

Таблица 6.2 - Получатель

Доверенность

№ доверенности	Код товара	Наименование товара	Единица измерения	Количество
№ ДВ	КОДТ	НАИМТ	ЕИ	КОЛ

Таблица 6.3 - Доверенность

База данных ведется у покупателя

Функциональные зависимости:

ИННОРГ -> {ОРГ, АДРОРГ}

{№ ДВ, ПРТ} -> {ФИО, ДАТАВ, СРД }

КОДТ -> {НАИМТ, ЕИ, КОЛ}

{№ДВ, ИННОРГ} -> {КОЛ}

Графическое изображение

Документ	Наименование реквизита	Обозначение реквизита	Ф ункциональная зависимость
Доверенность	№ Доверенности Дата выписки доверенности ИНН организации Код товара Количество Наименование товара Единица измерения Паспорт Ф.И.О Срок действия доверенности	№ ДВ ДАТАВ ИННОРГ КОДТ КОЛ НАИМТ ЕИ ПРТ ФИО СРД

Таблица 6.4 – Графическое изображение

Функциональная зависимость

	Название ИнО	Имя ИнО	Семантика ИнО
ИННОРГ -> {ОРГ, АДРОРГ}	Организация	ОРГ	Общие сведения о поставщике
{№ ДВ, ПРТ} -> {ФИО, ДАТАВ, СРД }	Получатель	ПОЛ	Сведения о покупке товара по счет-фактуре
КОДТ -> {НАИМТ, ЕИ, КОЛ}	Товар	ТОВАР	Справочные сведения о товаре
{№ДВ, ИННОРГ} -> {КОЛ}	Доверенность	ДВ	Общие сведения о документе

Таблица 6.5 – Функциональная зависимость

Связываемые ИнО

Связываемые ИнО	Общие реквизиты
Организация - Доверенность	ИННОРГ
Получатель - Доверенность	№ ДВ

Таблица 6.6 - Связываемые ИнО

Ниже представлена информационно-логическая модель (ИЛМ),

отображённая в графическом виде в соответствии с выявленными

связями.

Д В

О РГ

Д В

ПОЛ

Связи: М:1, М:1, соответственно

Доверенность		Организация		Получатель
№ ДВ ИННОРГ КОЛ		ИННОРГ ОРГ АДРОРГ		№ДВ ПРТ ФИО ДАТАВ СРД

Получатель

Д оверенность

Организация

Товарный чек

Организация	Адрес	ИНН
ОРГ	АДРОРГ	ИННОРГ

Таблица 7.1 - Организация

Товарный чек

№ Товарного чека	Дата выписки	Код товара	Наименование товара	Единица измерения	Количество	Цена
№ ТЧ	ДАТА	КОДТ	НАИМТ	ЕИ	КОЛ	ЦЕНА

Таблица 7.2 –Товарный чек

Функциональные зависимости:

ИННОРГ -> {ОРГ, АДРОРГ}

{№ ТЧ, ИННОРГ} -> {ДАТА}

КОДТ -> {НАИМТ, ЕИ}

{№ ТЧ, ИННОРГ, КОДТ} -> {КОЛ, ЦЕНА}

Графическое изображение

Документ	Наименование реквизита	Обозначение реквизита	Ф ункциональная зависимость
Товарный чек	№ Товарного чека Дата выписки товарного чека ИНН организации Адрес организации Код товара Наименование товара Единица измерения Количество Цена Организация	№ ТЧ ДАТА ИННОРГ АДРОРГ КОДТ НАИМТ ЕИ КОЛ ЦЕНА ОРГ

Таблица 7.3 – Графическое изображение товарного чека

Функциональная зависимость

	Название ИнО	Имя ИнО	Семантика ИнО
ИННОРГ -> {ОРГ, АДРОРГ}	Поставщик	ПСТ	Общие сведения о поставщике
{№ ТЧ, ИННОРГ} -> {ДАТА}	Покупка	ПОК	Сведения о покупке товара
КОДТ -> {НАИМТ, ЕИ}	Товар	ТОВАР	Справочные сведения о товаре
{№ ТЧ, ИННОРГ, КОДТ} -> {КОЛ, ЦЕНА}	Товарный чек	ТЧ	Общие сведения о товарном чеке

Таблица 7.4 – Функциональная зависимость

Связываемые ИнО

Связываемые ИнО	Общие реквизиты
Поставщик - Покупка	ИННОРГ
Покупка – Товарный чек	№ ТЧ
Товар – Товарный чек	КОДТ
Поставщик – Товарный чек	ИННОРГ

Таблица 7.5 - Связываемые ИнО

Ниже представлена информационно-логическая модель (ИЛМ),

отображённая в графическом виде в соответствии с выявленными

связями.

П оставщик

П окупка

П окупка

Товарный чек

Т овар

Товарный чек

П оставщик

Товарный чек

Связи: 1:М, М:1, М:1, 1:М, соответственно

Товар		Поставщик		Покупка		Товарный чек
К ОДТ НАИМТ ЕИ		И ННОРГ О РГ АДРОРГ		№ ТЧ ИННОРГ ДАТА		№ ТЧ ИННОРГ КОДТ КОЛ ЦЕНА

П окупка

Т овар

П оставщик

Т оварный чек

Контекстная диаграмма (DFD)

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

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

· Размещать на каждой диаграмме от 3 до 6-7 процессов. Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.

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

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

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

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

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

Рисунок 19.1 - Назначение работника подотчетным лицом

Рисунок 19.2 - Выдача наличных денежных средств подотчетному лицу

Рисунок 19.3 - Приобретение материалов и отчет перед кассой