«Учет товаров»

Содержание:

Введение

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

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

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

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

Предметом исследования является операция по выполнению учета товаров на складе магазина. Целью курсовой работы является смоделировать предметную область «Учет товаров на складе магазина» с помощью UML. Для достижения цели необходимо выполнить следующие задачи:

1) Сбор и анализ предметной области по учету товаров;

2) построить диаграмму вариантов использования;

3) построить диаграмму деятельности;

4) построить диаграмму последовательности;

5) построить диаграмму состояний;

6) построить диаграмму классов

1    Аналитическая часть

1.1 Описание предметной области. Постановка задачи

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

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

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

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

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

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

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

В магазине для товара фиксируется место хранения (склад), количество товара и его поставщик.

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

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

Выяснив особенности данной системы, теперь можно приступить к ее проектированию.

1.2 Предлагаемые мероприятия по улучшению технологии решения задачи

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

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

Преимущества автоматизации учета товаров: помогает вести учет движения товаров; фиксирует процесс продажи товара в кассовой зоне; контролирует остатки товара; помогает проводить инвентаризацию; позволяет рассчитать оборачиваемость товара - на основе анализа продаж показывает востребованность продукции; помогает контролировать взаимозачеты с поставщиками; позволяет контролировать деятельность сотрудников магазина, фиксируя все произведённые ими операции; показывает финансовый результат торговой деятельности, рентабельность работы предприятия.

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

2 Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

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

Среди case – средств различают как дорогостоящие, кроссплатформенные, так и недорогие системы. В настоящий момент их около 300 во всём мире.

К CASE-средствам относят любое программное средство, которое автоматизирует некие процессы жизненного цикла ПО, характеризуются они следующим:

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

2.1.1 Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)

ERwin – это средство для концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и реинжиниринг существующей БД. Возможно генерировать формы и прототипы приложений для определённых средств разработки.

Различают сетевую версию Erwin для организации совместной разработки и локальную.

Рис. 2.1.1.1 – Окно Erwin

Наряду с ERWIN существует продукт BPwin - средство функционального моделирования, которое реализует методологию IDEF0.

Рис. 2.1.1.2– Окно BPwin

S-Designor 4.2 не далеко ушёл по своим возможностям от case-инструмента ERwin. Главное отличие – внешнее различие используемыхнтоаций. S-Designor реализует стандартную методологию моделирования данных. Данный продукт генерирует описание БД для большинства СУБД.

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

Существует так же и отечественный продукт, практически единственный, который может конкурировать с американскими - CASE.Аналитик 1.1. Данный продукт способен строить и редактироватьDFD, анализировать диаграммы и спецификации, выдавать различные отчёты по проекту, генерировать макеты документов в соответствии с ГОСТами.

Рис. 2.1.1.3– Окно CASE.Аналитик

Ориентировочная стоимость отечественного продукта составляет однопользовательская версия - 605 $ для однопользовательской версии и 535 $ для многопользовательской версии (одно рабочее место)

База данных проекта реализована в формате СУБД Paradox и является открытой для доступа.

Используя отдельную программу (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

2.1.2 Объектно-ориентированные CASE-средства (RationalRose)

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

Рис. 2.1.2.1 – Окно RationalRose

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

CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Рис. 2.1.1.2 – Окно Designer/2000

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов.

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

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

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

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

Основными элементами диаграммы вариантов использования являются

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

На диаграмме вариантов использования присутствуют три действующих лица: «Пользователь» системой, «Поставщик» и «Покупатель».

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

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

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

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

2.2.2. Диаграмма последовательности

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Каждое сообщение представляется в виде стрелки между линиями жизни

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

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

Рис. 2.2.1.1. – Диаграмма последовательности для варианта

использования «Заказ и хранение товара»

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

Рис. 2.2.1.2. – Диаграмма последовательности для варианта

использования «Продажа товара»

2.2.3. Диаграмма состояний

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

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

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

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

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

Диаграммы состояний представлены на рисунках 2.2.3.1 и 2.2.3.2

Рис. 2.2.3.1. – Диаграмма состояний для варианта использования «Заказ и хранение товара»

Рис. 2.2.3.2. – Диаграмма состояний для варианта использования «Продажа товара»

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

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

Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности.

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

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

Проектируя заданную систему, следует внести на диаграмму деятельности следующие элементы: «Ввод данных поставщика», «Заключение договора», «Оплата услуги», «Приём товара на позицию», «Хранение товара», «Проверка срока годности», «Продажа товара», «Приём платежей за товар», «Формирование справочной информации» и «Завершение деятельности». А также необходимо добавить ветвления и переходы. Диаграмма деятельности приведена на рис. 2.2.4.1.

Рис. 2.2.4.1. – Диаграмма деятельности

В процессе проектирования системы «Учёт товаров» средствами RationalRose были созданы такие типы диаграмм как: диаграмма вариантов использования, диаграмма классов, диаграмма коопераций, диаграмма последовательностей, диаграмма состояний и диаграмма деятельности.

2.2.5. Диаграмма классов

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

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

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

В нашем случае на диаграмму следует нанести такие классы: «Поставщик», «Приём товара», «Товар», «Транзакт», «Продажа товара».

Все классы «Поставщик», «Приём товара», «Товар», «Транзакт», «Продажа товара» имеют стереотип Entity, означающий, что данные классы предназначены для хранения информации, которая должна сохраняться в системе после уничтожения объектов данного класса. Класс «Транзакт» хранит информацию о выполненных пользователем транзакциях.

Зададим для классов значения атрибутов и операции (процессы, реализуемые классом), добавим ассоциации. Все атрибуты будут иметь квантор видимости public. Для класса «Транзакт» квантор видимости private. Диаграмма классов приведена на рисунке 2.2.5.1.

Рис. 2.2.5.1 – Диаграмма классов

Заключение

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

Список литературы

1. Вендеров, А. М. Проектирование программного обеспечения экономических информационных систем [Текст] / А. М. Вендеров. - М. : Финансы и статистика, 2002. – 352 с.

2. Кватрани, Т. Rational Rose 2000 и UML. Визуальное моделирование [Текст] / Т. Кватрани. - М. : ДМК Пресс, 2001. - 176 с.

3. Ломакин, В. К. Мировая экономика: Учебник для вузов[Текст] / В. К. Ломакин. — М: ЮНИТИ, 2000. — 727 с.

4. Мацяшек, А. П. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML [Текст] / А. П. Мацяшек, А. Н. Лешек. – М. : Издательский дом «Вильямс», 2002. – 432 с.

5. Проектирование информационных систем: курс лекций [Текст] / В. И. Грекул, Г. Н.Денищенко, Н. Л. Коровкина. - М. : Интернет-Ун-т Информ технологий, 2005. - 304 с.

6. Титова, Н. Е. История экономических учений: курс лекций [Текст] / Н. Е. Титова. — М.: Гуманит. изд. центр ВЛАДОС, 2007. — 288 с.

7. Трофимов, С. А. CASE-технологии: практическая работа в RationalRose [Текст] / С. А. Трофимов. - М. : Бином-Пресс, 2002. - 288 с.

8. Федотова, Д. Э. CASE-технологии: Практикум [Текст] /Д. Э. Федотова, Ю. Д. Семенов, К. Н. Чижик. - М. : Горячая линия-Телеком, 2005.— 160 с.

9. Шишкин, А. Ф. Экономическая теория: Учебное пособие для ву-2-е изд.: В 2 кн. Кн. 1 [Текст] / А. Ф. Шишкин. - М.: Гуманит, изд. зов.центр ВЛАДОС, 2006. - 656 с.