предприятии
1. Состояние проблемы учета поставок на предприятие.
Введение
Хозяйство Украины представляет собой совокупность предприятий и организаций
отдельных отраслей народного хозяйства различных форм собственности. Предприятия
государственной формы собственности находятся в ведении различных министерств и
ведомств, а также в ведении местных исполкомов. Производственная деятельность
как и хозяйственная, направлены на выпуск предметов культурно-бытового
назначения, хозяйственного обихода и др.
Таким образом, в состав хозяйства Украины входят предприятия и организации, как
сферы материального производства, так и сферы обслуживания, как хозрасчетные,
так и состоящие на государственном бюджете. Наибольшее число госбюджетных
организаций находится в ведении Министерства образования и науки Украины: школы,
детские сады, педагогические институты, техникумы, училища и т.п. (около 30%
общего количества организаций); министерства здравоохранения Украины – больницы,
санатории, госпитали и др. лечебные учреждения (около 20%); министерства
культуры и просвещения Украины – театры, библиотеки, музеи и др. (более 25%
общего количества организаций) [3].
Руководство местным хозяйством страны организовано как по отраслевому принципу
(через соответствующие министерства и ведомства), так и по территориальному
(через местные органы управления).
Предприятия хозяйства Украины производят разнообразную продукцию. В ее числе
можно найти средства производства: станки, машины, металлопродукцию, товары
народного потребления, предметы бытовой химии и т.п.
Для производства всей вышеперечисленной продукции предприятия, независимо от
форм собственности, для своего нормального и стабильного функционирования
нуждаются в сырье, комплектующих, запчастях и т.п. Иными словами для организации
своей деятельности предприятия сталкиваются с проблемой своевременной поставки
продукции. Для этих целей предприятия государственной формы собственности
используют снабженческие организации (в настоящее время данными организациями
пользуются специализированные государственные предприятия), предприятия же
частных форм собственности проводят соответствующие мероприятия, направленные на
своевременное и непрерывное обеспечение необходимым сырьем или материалами. Но в
настоящее время практически все предприятия любой формы собственности
самостоятельно занимаются поиском предприятий-поставщиков, а также по мере
необходимости организацией поставок.
Одним из показателей характеризующих работу предприятия является товарооборот,
который представляет собой планово организационный процесс обращения средств
производства [2], от которого во многом зависят и другие экономические
показатели. В общий объем товарооборота включают все товары, реализованные
предприятием, т.е. полученные от предприятий поставщиков продукции. Также
товарооборот показывает насколько быстро предприятие использует полученную
продукцию, т.е. какими темпами оно осуществляет свою деятельность, чем больше на
предприятие осуществляется поставок, тем более стабильно работает данное
предприятие.
При осуществлении поставок на предприятие производится обработка и хранение
большого количества информации, связанной с поставками, которая в себя включает:
своевременное и правильное оформление документов и контроль за каждой операцией
поступления товаров от поставщиков, из переработки и других источников,
выявление расхождения фактического наличия и количества, указанного в
сопроводительных документах;
контроль за своевременным, полным и правильным оприходованием поступивших
товаров;
своевременное и правильное оформление документации и контроль за каждой
операцией отпуска, отгрузки или реализации товара;
контроль за соблюдением нормативов запаса товаров.
В связи с этим для надежного функционирования системы поставок необходимо вести
их систематический и непрерывный учет, что и будет выполнять разрабатываемое ПО.
Разрабатываемый программный продукт будет отличаться от аналогичного
программного обеспечения возможностью применения на современной
электронно-вычислительной технике [1], удобным интерфейсом, низкой стоимостью,
возможностью его использования на любом предприятии.
1.1 Общая характеристика проблемы
При осуществлении поставок предприятия изготовители продукции
производственно-технического назначения вступают в договорные отношения с
предприятиями потребителями (покупателями) как поставщики заключают прямые
договора с предприятиями потребителями для сбыта продукции и комплексного
снабжения предприятий-заказчиков.
Договоры о поставках необходимо заключать своевременно. В них указываются
условия поставки товаров, их количество, ассортимент, качество, комплектность и
сроки поставки. Кроме того, в договорах предусмотрены цены на товары, общая
сумма, порядок расчетов, платежные и отгрузочные реквизиты поставщика и
получателя продукции. Договора подлежат обязательному выполнению по всем
указанным в них пунктам. Нарушение сроков договоров и обязательств влечет
ответственность, предусмотренную “Положением о поставке продукции
производственно-технического назначения” и “Особыми условиями поставки.”
Контроль за выполнением договоров осуществляют товарные отделы.
Рациональная организация приемки продукции от поставщиков имеет важное значение
для своевременного, полного, комплексного снабжения предприятий сырьем,
материалами, топливом, инструментами, оборудованием и другими средствами
производства.
Правильная приемка и оформление документами поступивших товаров
Является надежной основой сохранности товарно-материальных ценностей.
Общий порядок приемки товарно-материальных ценностей установлен “Положением о
поставке продукции производственно-технического назначения”. Порядок и сроки
приемки товарно-материальных ценностей в определенном количестве и качестве,
оформление актов приемки и предъявление претензий определены инструкцией о
порядке приемки продукции производственно-технического назначения и товаров
народного потребления по количеству и инструкцией о порядке приемки продукции
производственно-технического назначения по качеству. Особенности приемки
отдельных видов продукции определяются в ГОСТах [12.01.005-89], технических
условиях, Особых условиях поставки и договорах поставки, предусматривающих
особые порядки приемки продукции при поставках.
На предприятиях государственной формы собственности осуществлением всех действий
связанных с поставками и оформлением необходимых документов , при наличии
соответствующего программного обеспечения, занимается определенное количество
персонала предприятия, но , как правило, разработка такого программного
обеспечения велась на языках низкого уровня программирования, а за последние 6-8
лет развитие машинных средств (ПЭВМ), программных средств резко увеличилась,
поэтому ранее разработанное ПО не отвечает более высоким требованиям,
предъявляемым к современным программным продуктам. Что же касается предприятий,
фирм различный форм частной собственности, то они зачастую не имеют вовсе
соответствующего программного обеспечения, что значительно увеличивает
трудоемкость процесса контроля и учета проведения поставок. Разрабатываемый
программный продукт и призван решать данные проблемы.
1.2 Формулировка задач
Любое предприятие, осуществляя свою деятельность, для получения продукции от
поставщиков должно заключить с последними договор на поставку продукции. Обычно
на одноименную продукцию предприятие-заказчик заключает несколько договоров с
предприятиями-поставщиками. Затем заказчик по мере потребности в определенной
продукции высылает поставщику заявку на поставку продукции и получает от
последнего счет-фактуру, в котором указано наименование продукции и ее отпускная
цена. На основании этих счетов предприятие-заказчик определяет оптимальную
заявку и высылает поставщику заказ на поставку продукции. После получения
заказанной продукции заказчик отправляет счет в бухгалтерию, которая оплачивает
его в банке в течении срока, предусмотренного договором. Поэтому для
документального обеспечения процесса поставок на предприятие программа должна
создавать (распечатывать) следующие необходимые документы:
бланк договора предприятия-заказчика с фирмой-поставщиком (с указанием
наименования и юридических адресов сторон, ассортимента продукции для поставок,
ее количества и предположительной стоимости, а так же условия и сроки действия
договора);
заказ на поставку необходимой продукции (указывается количество, наименование,
номенклатура, сроки поставки).
Также создаваемая автоматизированная система по имеющимся данным о поставщиках и
вновь полученным данным должна определять оптимальный счет-фактуру с точки
зрения количество-цена.
Любую поставку предприятие-заказчик обязано оплатить в установленные договором
сроки, поэтому АС должна осуществлять подсчет суммы долга (денег к выплате) на
текущую дату.
1.3 Мотивация задач.
Предприятие или фирма, производя свою продукцию, нуждается в поставках сырья от
других предприятий. Но на одно и тоже сырье у разных производителей-поставщиков
различная отпускная цена, поэтому в целях снижения себестоимости выпускаемой
продукции предприятие заказчик заключает договора с большим количеством
поставщиков и затем высылает поставщикам заявку на поставку продукции с
указанием типа и ее количества. Поскольку предприятие-заказчик при получении
грузов так или иначе связано с документами, с документальным оформлением
поставок, то проектируемая АСИС должна создавать все бланки документов,
связанных с поставками.
Поскольку все поставщики высылают заказчику счета-фактуры (прейскурант цен на
заказанную продукцию), то среди их множества необходимо определить наиболее
выгодное для предприятия-заказчика, как по цене, так и по качеству, что и должна
выполнять создаваемая АС.
Так как договора с поставщиками заключаются на определенный срок, предполагаемое
количество поставляемой продукции и на определенную сумму, то при осуществлении
заказа на поставку продукции, в договоре оговаривается срок, в течении которого
заказ должен быть оплачен, поэтому необходимо знать сумму к оплате на указанное
число, как общую так и по различным поставщикам в отдельности.
Так как все вышеперечисленные действия осуществляются на протяжении длительного
времени, то при приятии решения о продлении срока действия договора
целесообразно принимать во внимание следующие факторы: качество поставок
конкретными поставщиками (имеется ввиду выполнение сроков осуществления
поставок, соответствие номенклатуры поставленной продукции заказанной,
отсутствие или процент брака), его терпимость по отношению к оплате по
поставкам. Поэтому необходимо сохранять всю информацию о поставках на
предприятие, что бы в дальнейшем ее можно было бы использовать.
1.3. Техническое задание.
Введение.
Автоматизированная справочно-информационная система (АСИС) “Учет поставок” будет
использоваться на предприятиях различных форм собственности и обеспечивать
контроль и учет поставок производимых на предприятие. Также при использовании
данного ПО будет иметься возможность составления отчетности о поставках на
предприятие, выявление задолженности по оплате поставок. Разрабатываемое ПО
может быть использовано как руководителем предприятия, для осуществления
контроля производимых поставок на предприятие, так и начальниками цехов, для
ведения учета поставок.
1.3.1. Основания для разработки.
Основанием для выполнения работы является приказ о базе преддипломной практики
от 10 июня 1999 г. № 270 по Государственному аэрокосмическому университету и
приказ о дипломном проектировании от 26 июня 2000 г. № 271.
1.3.2. Назначение разработки.
Целью дипломного проектирования является разработка и создание программного
продукта “Учет поставок”. Данный программное обеспечение предназначено для
контроля, учета, автоматизации и систематизации информации о поставках
различного вида продукции на предприятие любой формы собственности, занимающимся
любым видом производства или деятельности.
Разрабатываемый программный продукт должен обеспечивать создание информационной
базы об осуществленных поставках на предприятие, а также осуществлять создание
следующих документов :
бланк договора предприятия заказчика с фирмой-поставщиком (с указанием
наименования и юридических адресов сторон, участвующих в договоре,
ассортимента продукции для поставок, ее количества, предположительной
стоимости, условия и сроки действия договора);
заявку на поставку необходимой продукции (указывается количество,
наименование, номенклатура, сроки поставки, сумма поставки);
заказ на поставку.
Коммерческая версия программного продукта позволит производить:
более полный контроль и организацию учета о поставках на предприятие;
автоматизировать процесс оформления поставок на предприятие;
уменьшит временные затраты на оформление документов, связанных с поставками;
вычислять задолженность по оплате осуществленных поставок на указанный период;
обеспечить пользователя системой помощи как по понятиям предметной области,
так и по пользованию программным продуктом.
Разрабатываемый автоматизированная система должна будет реализовать следующие
функции:
Обеспечение ввода данных о поставках на предприятие;
Анализ введенной информации;
Подсчет задолженности предприятия за осуществленные поставки;
Определять оптимальный счет-фактуру с точки зрения “количество-цена”;
Производит печать документации, связанной с организацией поставок (бланк
договора, заказа, заявки).
1.3.3. Исходные данные и источники.
Данная работа базируется на теме преддипломной практики и является ее
продолжением с учетом рекомендаций по улучшению ранее разработанного ПО,
предложенных руководителем практики от предприятия и группой сотрудников этого
предприятия и рассмотренных руководителем практики от института.
1.3.4. Исходные требования к конечному результату.
Требования по функциональности.
Разрабатываемая АСИС должен обеспечивать автоматизированный контроль, а так же
учет поставок на предприятие (цех этого предприятия), для этого создаваемая
система должна:
Обеспечивать ввод, связанных с поставками на предприятие и обработку этих
данных;
Создавать отчетные документы и документы для организации грузопоставок; (
Приложение А)
Иметь систему помощи по программе;
При вводе данных об наименовании товаров должен использоваться справочник
“Номенклатура товаров”;
Создаваемые документы должны отвечать отраслевым стандартам, принятым на
предприятии.
Условия эксплуатации
Создаваемый программный продукт должен будет использоваться директором
предприятия, начальником цеха, начальником склада, в зависимости от места
эксплуатации продукта. Заданные характеристики функционирования должны
обеспечиваться при условиях, которые определяются конкретным носителем данных,
на котором хранятся данные. Наиболее распространенными носителями данных в
настоящее время являются жесткие диски, для которых оптимальным является
функционирование при температурах от 5 до +35оС и относительной влажности от 10
до 60 процентов.
Требования к составу и параметрам технических средств
Программа должна функционировать на персональных компьютерах со следующей
конфигурацией:
IBM PC/AT совместимых ПЭВМ не ниже Pentium 100;
с объемом ОЗУ не менее 16 мегабайт;
Объем необходимого дискового пространства - не менее 10 мегабайт.
Требования к информационной и программной совместимости
Создаваемая программа должна функционировать, легко инсталлироваться,
настраиваться и корректно работать при выполнении следующих требований:
наличие операционной системы типа Windows 95, Windows 98, Windows NT 4.x,
Windows 2000 и совместимых с ними;
наличие базы данных LocalInterBase или совместимых с ней;
ввод даты обязателен в форме маски;
ввод цифр обязателен.
Требования по защите.
Для обеспечения защиты от несанкционированного доступа к информации, связанной с
поставками на предприятие будет предусмотрена система паролей при загрузке
программы в оперативную память. Для обеспечения защиты данных про сбое в сети
питания ПК либо аварийном завершении работы программы будет предусмотрен режим
автосохранения.
1.3.5. Этапы проведения работ.
Этапы проведения работы представлены в таблице 1.2.
Таблица 1.2. Этапы проведения работы.№ЭтапыСроки выполненияОтчетность
1Изучение принципов системы грузопоставок на предприятие07.07.1999 –
14.07.1999
2Ознакомление с ранее проделанной работой01.09.1999– 08.09.1999
3Определение требований к разработке9.09.2000– 19.09.1999Техническое
задание
4Разработка информационной модели предметной области (построение
концептуальной модели)20.09.200– 09.10.1999
5Выбор алгоритмических средств10.10.1999– 28.10.1999
6Определение программных средств29.10.99– 07.11.1999
7Выбор методики испытания и тестирования08.11.1999– 15.11.1999Техническое
предложение
8Разработка алгоритмов, связанных с реализацией учета поставок16.11.1999–
9.12.1999
9Проектирование алгоритмов, связанных с формированием тестовых
заданий10.12.1999 – 20.12.1999
10Определение средств проведения тестирования и анализа его
результатов11.12.1999– 30.12.1999
11Разработка программного обеспечения связанного с реализацией учета
поставок на предприятие31.12.1999– 15.02.2000
12Разработка программного обеспечения связанного с формированием тестовых
заданий16.02.2000– 3.03.2000
13Реализация программного обеспечения проведения тестирования и анализа
его результатов4.03. 2000– 4.04.2000
14Проведение тестирования и испытаний разработанного программного
обеспечения5.04.2000– 19.04.2000
16Написание расчетно-пояснительной записки20.04.2000–
21.05.2000Расчетно-пояснительная записка
17Подготовка плакатов22. 05.2000– 29.05.2000Плакаты
18Подготовка доклада29.05.2000– 11.06.2000Доклад
19Предзащита дипломного проекта12.06.2000
20Защита дипломного проекта20.06.2000
1.3.6. Планируемые показатели эффективности.
В результате выполненной работы предполагается достигнуть следующих эффектов:
уменьшение времени необходимого для учета поставок произведенных на
предприятие;
автоматизация контроля поставок;
возможность длительного хранения информации о поставках на предприятие
большого срока давности, для возможности более полного расчета эффективности
деятельности предприятия;
постоянная известность о сроках оплаты осуществленных поставок.
1.3.7. Порядок приемки результатов работы.
Приемка результатов работы осуществляется в соответствии с планом приемки,
утвержденным на кафедре и согласованным с руководителем практики. Этот план
включает следующие пункты:
Сдача технического задания, технического предложения, журнала по преддипломной
практике и содержания расчетно-пояснительной записки после прохождения
преддипломной практики.
Сдача программы.
Предзащита дипломного проекта. Предоставляются :расчетно-пояснительная записка,
плакаты, доклад, рецензия, отзыв руководителя.
Защита дипломного проекта. Предоставляются: дипломный проект с документами,
замечания, допуск на защиту, карточка учета деканата, демонстрационный образец.
1.3.8. Документация, предъявляемая по окончанию работы.
После окончания работы предоставляется следующая документация:
Техническое задание;
Расчетно-пояснительная записка;
Описание применения;
Руководство системного программиста;
Руководство оператора;
Также предоставляются:
Плакаты;
Доклад;
Рецензия;
Текст программы;
Дискета с программным продуктом и сопроводительной документацией.
2. Моделирование.
2.1 Анализ представления моделей данных.
Для эффективного функционирования разрабатываемой АСИС “Учет поставок” будет
разработана СУБД [24]. Поэтому ниже рассмотрены логические и концептуальные
модели данных.
2.2 Выбор логической модели данных.
2.2.1 Иерархическая модель данных.
Иерархическая модель [6] данных представляет собой иерархию в виде дерева.
Данная модель данных базируется на сегменте, который представляет собой
совокупность полей, характеризующих данный сегмент. Сегменты различаются по
типу, а каждый тип характеризуется фиксированной длиной и конкретным разбиением
на поля данных. Два связанных сегмента, расположенных на смежных уровнях
называются исходным (более высокого уровня) и порожденным (более низкого).
Иерархическая запись – система взаимосвязанных сегментов, в которой каждый
порожденный сегмент представлен столько раз, сколько необходимо для полного
раскрытия данного сегмента. В иерархической структуре есть сегмент, который не
имеет исходного и называется головным или корневым. В этом сегменте обычно
располагается идентификатор объекта, свойства которого раскрываются в сегментах
второго и более низких уровней иерархии.
Для реализации данной модели на физическом уровне используется ряд стандартных
методов размещения данных на запоминающих устройствах, которые могут размещать
сегменты следующими иерархическими способами доступа: последовательный,
индексно-последовательный, прямой, индексно-прямой. В соответствии со способами
размещения сегментов устанавливается порядок доступа к ним. Установленный
порядок доступа к сегментам обуславливает процедурность языка запросов и требует
от пользователя знания путей доступа к данным, проходящим по ветвям дерева
иерархической записи. Что является одним из недостатков данной модели. В
качестве других недостатков можно отметить следующие:
Сложность реализации “многие ко многим”, требующая избыточности данных на
физическом уровне, что приведет к нежелательному и не оправданному увеличению
БД;
требование повышенной корректности к операции удаления, поскольку удаление
исходного сегмента влечет за собой удаление порожденных;
доступ к любому порожденному сегменту возможен только через исходный, что
увеличивает время ответа а запрос к БД.
В связи с тем, что иерархическая модель обладает большим количеством недостатков
она не будет применятся для моделирования разрабатываемой АСИС.
2.2.2 Сетевая модель данных.
Сеть [5] – более общая структура в сравнении с иерархией. Узлами сети являются
отдельные экземпляры записи. Узлы записи являются единицей доступа к БД.
Поскольку отдельный узел может иметь несколько непосредственно старших узлов,
так же, как и несколько непосредственно подчиненных, то данная структура
обеспечивает прямое представление отношения “многие ко многим”. Для связи между
записями-узлами существует связующая запись, все экземпляры которой помещаются в
цепочку для связи двух экземпляров.
Основной конструкцией сетевой модели данных является набор. Для каждого типа
набора, определяемого в схеме, должен быть указан определенный тип записи
владельца набора, а так же произвольное число типов записи членов набора. Каждый
экземпляр набора состоит из одного экземпляра-владельца и одного или более
экземпляров записей-членов.
Каждый экземпляр записи-набора представляет иерархические связи между
экземпляром записи-владельца и соответствующими экземплярами записей-членов. Это
является следствием того ограничения, что ни один экземпляр записи-члена из
набора на может принадлежать более, чем одному экземпляру набора. Способ,
которым каждый экземпляр записи владельца связывается с соответствующими
экземплярами записей-членов, определяется в схеме сети. Одним из способов
организации таких связей является установление цепочки указателей, выходящих из
экземпляра записи-владельца, проходящих через все экземпляры записей-членов и
возвращающихся обратно к экземпляру записи-владельца, что обеспечивает высокую
скорость обработки запросов.
Главный недостаток сетевой модели заключается в сложности структур памяти.
Пользователь должен знать, какие цепочки существуют и какие отсутствуют. В
результате язык запросов процедурный и требует программистских навыков.
2.2.3 Реляционная модель данных.
Реляционная модель – множественное отношение которое представляет собой
подмножество декартова произведения списка доменов [27,20]. Домен – это
множество значений, из которого извлекаются значения для данного атрибута.
Другими словами в основе реляционной модели лежат простые таблицы, которые
удовлетворяют определенным ограничениям, а потому могут рассматриваться как
математические отношения. Строки таких таблиц называются кортежами, имена
столбцов – атрибутами. Следует отметить, что все кортежи различны, а порядок
столбцов произволен, чем упрощается процесс обработки кортежей. В отношении
(таблице) выделяется несколько атрибутов, однозначно идентифицирующих кортежи и
называемых ключами.
Особенность реляционной модели заключается в том, что в отличии от сетевой и
иерархической моделей реальные объекты и взаимосвязи между ними представляются в
базе данных единообразно в виде нормализованных отношений [24].
Основной недостаток реляционной модели данных связывается с низкой
производительностью реляционной СУБД. Но разработка современных СУБД таких как,
ORACLE, InterBase, Acsses и др. позволило преодолеть и этот недостаток.
Достоинства реляционной модели можно разделить на две группы:
достоинства для пользователя:
реляционная БД представляет собой набор таблиц с которыми пользователь привык
работать;
не нужно помнить пути доступа к данным и строить алгоритмы и процедуры
обработки своего запроса;
реляционные языки легки для изучения и освоения, в то время как языки общения
с иерархической и сетевой моделями предназначены для программистов и мало
пригодны для пользователей;
достоинства обработки данных реляционной БД:
связность. Реляционное представление дает ясную картину взаимосвязей атрибутов
из различных отношений;
точность. Направленные связи в реляционной БД отсутствуют. Отношения по своей
природе обладают более точным смыслом и поддаются манипулированию с
использованием таких средств, как алгебра и исчисление отношений [5],
обеспечивающих наглядность и гибкость модели данных;
гибкость. Операции проекции и объединения [17] позволяют разрезать и склеивать
отношения, так что программист может получать разнообразные файлы в нужной
форме;
секретность. Контроль секретности упрощается. Для каждого отношения имеется
возможность задания правомерности доступа, засекреченные показатели можно
выделить в отдельные отношения с проверкой прав доступа.
Простота внедрения. Физическое размещение однородных (табличных) файлов
намного проще, чем размещение иерархических и сетевых структур.
Независимость данных. БД должна допускать возможность расширения, т.е.
добавления новых атрибутов и отношений.
Вывод: поскольку среди перечисленных логических моделей данных реляционная
обладает значительными преимуществами и малыми недостатками, то она и будет
взята в основу для построения СУБД.
2.3 Выбор концептуальной модели.
Для выбора концептуальной модели данных рассмотрим три их разновидности:
Семантическая модель;
Фреймы;
Модель “сущность-связь”.
Семантическая модель основывается на построении семантической сети. Под
семантической сетью понимают ориентированный граф, состоящий из помеченных
вершин и дуг и задающий объекты и отношения предметной области. Семантические
сети обладают рядом достоинств, а именно:
Описание объектов предметной области происходит естественным языком;
Все записи, поступающие в БД накапливаются в относительно однородной структуре.
Но несмотря на эти преимущества, семантическая модель данных обладает рядом
недостатков, один из которых и наиболее существенный, заключается в том, что
построение реляционной модели данных на основе семантических сетей затруднено.
Фреймы выражаются структурами данных с привязанными процедурами обработки этих
данных. Фреймы могут быть следующих видов: событийные, характеристики,
логические предикаты. Использование фреймовой модели так же нецелесообразно,
поскольку данная модель не отражает типы связей [14] в реляционной модели
данных.
Модель “сущность-связь” описывается в терминах сущность, связь, значение.
Сущность – понятие которое может быть идентифицировано. Связь – соединение
сущностей. Для представления связей и сущностей введен специальный метод:
ER-диаграма [27]. Различаются сущности трех основных классов: стержневые,
ассоциативные и характеристические. Стержневая сущность – это независимая
сущность (ей свойственно независимое существование). Ассоциативная сущность или
ассоциация рассматривается как связь между двумя или более сущностями типа
"многие -ко- многим" или подобные им. Характеристическая сущность (или
характеристика) представляет собой сущность, единственная цель которой, в рамках
рассматриваемой предметной области, состоит в описании или уточнении некоторой
другой сущности. ER-диаграма – графическое представление взаимосвязей сущностей.
Каждое множество сущностей представляется прямоугольником, а множество связей –
ромбом. Связи могут быть трех типов: “один к одному”, “один ко многим”, “многие
ко многим”. данные типы связи присущи реляционной модели, как и сущности,
которым в реляционной модели соответствуют таблицы.
Вывод: в связи с тем, что модель “сущность-связь” наиболее близка по принципам
организации к реляционной модели и реализация последней на основе первой
наиболее удобна, то в качестве концептуальной модели выбрана модель
“сущность-связь”.
2.4 Процесс моделирования.
2.4.1 Выделение сущностей.
Сущность “поставщик” является стержневой сущностью разрабатываемой модели. С
поставщиком заключается договор, на основании которого ведется вся остальная
деятельность предприятии по поставкам, отправление заявки поставщикам, получение
от них счета-фактуры, отправление заказа на поставку, получение товара, оплата
поставки. В качестве ключа для данной сущности вводится атрибут № Поставщика.
Все сущности , их атрибуты и ключи представлены в табл. 2.1.
Таблица 2.1
Название сущностиАтрибутКлюч
Договор №Договора, дата договора, сумма договора, срок действия.№Договора
Поставщик №Поставщика, наименование поставщика, адрес, телефон.№Поставщика
Ассортимент товаров №Товара, наименование товара.№Товара
Заявка№Заявки, ассортимент заявки, номер договора, дата заявки.№Заявки
Заказ №Заказа, №Договора, ассортимент заказа, дата заказа, номер счета.
№Заказа
Счет-фактура №Счета, ассортимент счета, цена за единицу товара, сумма
счета.№Счета
2.5 Построение логической модели.
Выполнив анализ сущностей и связей меду ними построим логическую модель, в виде
отношений (таблица 2.2)
Таблица 2.2
Название сущностиАтрибутКлюч
Договор №Договора, дата договора, сумма договора, срок действия.№Договора
Поставщик №Поставщика, наименование поставщика, адрес, телефон.№Поставщика
Ассортимент товаров №Товара, наименование товара.№Товара
Заявка№Заявки, номер договора, дата заявки.№Заявки
Заявка №Заявки, №товара, количество.№Заявки, №Товара
Ассортимент заявки№Заказа, №Договора, дата заказа, номер счета. №Заказа
Ассортимент заказа№Заказа, №Заявки, №товара.№Заказа, №Заявки, №товара.
Счет-фактура№Счета, сумма счета.№Счета
Цены поставщика№Счета, №Заявки, №Товара.№Счета, №Заявки, №Товара.
Для построения логической модели данных использовалось case - средство
[17] ER-Win, которое позволяет проектировать реляционные модели данных как
на физическом уровне (ER-диаграмы), так и на физическом (проектирование
таблиц БД).
Логическая модель данных представлена в виде ER-диаграмы на рис. 2.2.
Рис 2.2 ER-диаграмма модели данных АСИС “Учет поставок”
3. Проектирование алгоритмов справочно-информационной системы учета и контроля
поставок на предприятие.
Алгоритмизация в самом общем виде может быть определена как процесс
направленного действия проектировщика (группы проектировщиков), необходимый для
выработки алгоритмов, достаточных для реализации создаваемого объекта (системы),
удовлетворяющего заданным требованиям [19]. Завершающим этапом алгоритмизации
является выпуск набора алгоритмов, отображающий решения, принятые
проектировщиком, в форме, необходимой для производства объекта (системы). При
проектировании системы я использовал три класса алгоритмов:
Алгоритмы, связанные с проектированием АСИС;
Алгоритмы реляционной алгебры, необходимые для работы с БД;
Алгоритмы расчета необходимых показателей (вычисление задолженности предприятия
по оплате поставок, определение оптимального счета-фактуры).
3.1 Выбор метода проектирования АСИС.
Метод — это последовательный процесс создания моделей, которые описывают вполне
определёнными средствами различные стороны разрабатываемой программной системы
[18]. Методы важны по нескольким причинам. Во-первых , они упорядочивают процесс
создания сложных программных систем. Во-вторых , они позволяют менеджерам в
процессе разработки оценить степень продвижения и риск.
Обычно методы проектирования делятся на три основные группы;
Метод проектирования сверху вниз;
Метод потоков данных;
Объектно-ориентированное проектирование.
Для структурного проектирования характерна алгоритмическая декомпозиция. Следует
отметить , что большинство программ написано в соответствии с этим методом. Тем
не менее структурный подход не позволяет выделить абстракции и обеспечить
ограничение доступа к данным; он также не предоставляет достаточных средств для
организации параллелизма. Структурный метод не может обеспечить создание
предельно сложных систем , и он, как правило, неэффективен в объектных и
объектно-ориентированных языках программирования. Поэтому данный метод не
использовался для проектирования АСИС “Учет поставок”.
В методе потоков данных программная система рассматривается как преобразователь
входных потоков в выходные. Метод потоков данных с успехом применялся при
решении ряда сложных задач, в частности , в системах информационного
обеспечения, где существуют прямые свя