Система складского учета

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  И НАУКИ, МОЛОДЕЖИ И СПОРТА УКРАИНЫ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  И НАУКИ, МОЛОДЕЖИ И СПОРТА

АВТОНОМНОЙ РЕСПУБЛИКИ КРЫМ

РВУЗ «КРЫМСКИЙ ИНЖЕНЕРНО-ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ»

 

 

 

 

Проект

по дисциплине «Технология  разработки программного обеспечения»

на тему

«Система складского учета»

 

 

 

 

 

 

 

Выполнил:

студент I курса

группы C-И-13

Заиров Эдем

 

 

 

 

 

Симферополь, 2013

Содержание

 

Техническое задание 3

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

Создание  схемы последовательности 5

Диаграмма классов UML 6

Схема активности UML 8

Скетч интерфейса 10

Схемы компонентов UML 10

D-требования  «Складской учет» 11

Составление модели реализации USDP 13

Составление плана тестирования 13

Глоссарий 15

Заключение 17

Список использованных источников 18

 

 

Техническое задание

Вариант 7. Система  складского учета

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

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

Система учета по требованию пользователя формирует и выдает на печать следующую справочную информацию:

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

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

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

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

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

В качестве актеров на диаграмме (рисунок 1) используется объект «Пользователь, который управляет вариантами использования:

  • «Удаление» (удаление информации о товаре, поставщиках);
  • «Редактирование» (изменение информации о поставщике, товаре);
  • «Добавление» (добавление информации о товаре, поставщике);
  • «Оформление прихода» (оформление приходных накладных);
  • «Оформление расхода» (оформление расходных накладных).

Также необходимо выделить варианты использования: «Обновление инвентаризационной описи», «Справочная информация», «Поиск», «Просмотр», «Печать».

Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.

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

Создание схемы последовательности

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

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

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

В данной модели для создания диаграммы последовательности был  использован вариант использования  «Оформление прихода» (прием товара), взятый из предыдущей диаграммы прецедентов (рисунок 2).

Рис. 2. Схема последовательности

На данную диаграмму помещены следующие объекты:

«Пользователь» (работник склад) - действующее лицо;

«Доб./Изм. информацию о товаре» - содержит форму ввода или выбора товара;

«Доб./Изм. информацию о поставщиках» - содержит форму ввода или выбора поставщика товара;

«Формирование накладных» - форма карты складского учета, которая  создается после ввода всех данных и является итоговым документом;

«БД» - содержит информацию о поставщиках и товарах, на основании  информации этого объекта формируется  окончательная документация складского учета.

Сообщения между объектами  на диаграмме:

«Открыть форму» - открытие формы;

«Отмена» - отмена действия;

«Запрос к БД» - запрос к базе данных на выбор тех или иных данных;

«Результат запроса» - наименование товара;

«Запрос к БД для генерации справочной информации» - запрос к базе данных на выбор поставщика и генерацию справочной информации.

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

Выводы:

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

2. Каждый объект был соотнесен с классом, а сообщение с операцией.

Диаграмма классов UML

Диаграммы классов (class diagram) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (сlasses) и интерфейсов (interfaces). На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Данный тип диаграмм противоположен по содержанию диаграмме сотрудничества, на которой отображаются объекты системы.

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

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

Рис. 3. Диаграмма классов  UML

Выводы:

1. На диаграмме классов представлены все классы и взаимосвязи между ними.

2. Указанная множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Так же были добавлены атрибуты и методы классов.

Схема активности UML

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

На диаграмме имеются  два специальных состояния - начальное (start) и конечное (stop). Процессы, происходящие в тот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать  следующие данные: деятельность, входное  действие, выходное действие и событие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

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

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

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

Диаграмма деятельности для  системы складского учета представлена на рисунке 4.

Рис. 4. Схема активности

Выводы:

На диаграмме состояний  расположены следующие состояния:

  • начальное состояние «Start»;
  • «Аутентификация» (вход в систему);
  • конечное «Exit» состояние;
  • «Добавить» (добавление данных о поставщика, товарах);
  • «Удалить» (удаление данных о поставщиках, товарах);
  • «Редактировать» (редактирование содержимого);
  • «Принять товар» (прием товара);
  • «Отгрузить товар» (отгрузка товара);
  • «Печать» (печать накладных, справочной информации).

Для каждого из состояний  созданы следующие действия:

  • «Обновление инвентаризационной описи» (обновление содержимого БД после оформления прихода, расхода);
  • «Генерация справочной информации» (карта учета) - на выходе формируется справочная информация.

Скетч интерфейса

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

Рис. 5. Система складского учета

Схемы компонентов UML

Диаграммы компонентов (component diagram) предназначены для распределения классов и объектов по компонентам при физическом проектировании системы. На них изображены компоненты программного обеспечения и связи между ними. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Часто данный тип диаграмм называют диаграммами модулей.

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

Каждый класс модели (или  подсистема) преобразуется в компонент  исходного кода. После создания они  сразу добавляются к диаграмме  компонентов.

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

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

Рис. 6. Схемы компонентов  UML

Для каждого класса была создана спецификация пакета и тело пакета. Они соединены с помощью  связей.

D-требования «Складской учет»

  • Функциональные требования:
  • Целостность содержимого базы данных;
  • Возможность генерации отчетов;
  • Предоставление полученной информации в графическом виде;
  • Индивидуальные права доступа;
  • Надежная обработка данных (удаление, добавление, изменение);
  • Архивирование накладных;
  • Возможность отправки отчетов на E-mail руководителя, менеджера;
  • Возможность настройки интерфейса;
  • Корректная обработка исключений;
  • Работа системы с периферийными устройствами (принтеры – вывод на печать).

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

Нефункциональные  требования:

  • Дизайн приложения не должен содержать более 4 цветов;
  • Для работоспособности приложения на жестком диске должно иметься 400 Мб;
  • Наличие доступа к сети интернет;
  • Для передачи данных использовать лишь шифрованный канал передачи данных SSL;
  • В случае обнаружения ошибки система должна вывести некоторое оповещение;
  • Интерфейс должен быть строго структурированным и понятным;
  • Система должна разрабатываться при помощи платформы 1С;
  • Функциональность системы на ОС Windows XP, Windows 7, Windows Vista, Windows 8.

Обратные требования:

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

Составление модели реализации USDP

Модель реализации состоит  из вложенных подсистем. Они состоят  из таких компонентов, как файлы  и интерфейсы реализации.

 

 







 




 


 

 

Рис.7. Модели реализации USDP

Составление плана тестирования

Начальный этап тестирования - основные принципы работы

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

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

Требования к  персоналу

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

Выбор аппаратной платформы

Система должна быть установлена  лишь на машинах с операционной системой Windows XP, Windows Vista, Windows 8.

Обработка функций

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

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

Документ (версия)

Создан или доступен

Использовался при  составлении плана 

Автор ресурса 

Спецификация требований

да 

да 

Заиров Э.Р.

Функциональная спецификация

да 

Да

Заиров Э.Р.

Спецификации прецедентов 

да 

да 

Заиров Э.Р.

План проекта 

да 

да 

Заиров Э.Р.

Проектная спецификация

нет

нет

Заиров Э.Р.

Прототип 

да 

да 

Заиров Э.Р.

Руковдство пользователя

нет

нет

Заиров Э.Р.

Бизнес-модель

да 

Да

Заиров Э.Р.

Модель данных

да 

Да

Заиров Э.Р.

Оценка бизнес-рисков, рисков проекта

да 

Да

Заиров Э.Р.


 

Глоссарий

Английский

Русский

Пояснения

Activity diagram

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

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

Actor

Актер

Действующие единицы системы

UML diagram

UML диаграмма

  

Class diagram

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

Диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Ее изображают в виде множества вершин и дуг.

Sequence diagram

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

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

Interaction diagram

Диаграмма взаимодействий

Взаимодействие между  объектами в системе представляются диаграммами взаимодействия

Extend

  

Определяет взаимосвязь  экземпляров отдельного варианта использования  с более общим вариантом, свойства которого определяются на основе способа  совместного объединения данных экземпляров

Include

Включение

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

Use-case model

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

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

 

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

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

Sklad

Система складского учета

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


 

 

Заключение

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

В ходе ее разработки были изучены  основы языка моделирования UML и построены следующие диаграммы:

  • диаграмма вариантов использования;
  • диаграмма последовательности;
  • диаграмма классов;
  • диаграмма активности;
  • диаграмма компонентов.

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

В качестве среды разработки информационной подсистемы был использован  программный продукт IBM Rational Software Architect Standard Edition.

 

 

 

 

 

 

 

 

Список использованных источников

    1. Frederick Phillips. The mythical man-month : essays on software engineering . - Anniversary ed. - 1995. - Pp. 322
    2. Wikipedia - свободная энциклопедия. Система управления складом. [Электронный ресурс]. Дата обновления: 01.11.2013. - Режим доступа: http://ru.wikipedia.org/wiki/Система_управления_складом.
    3. Эрик Брауде. Технология разработки программного обеспечения. - Спб.: Питер.//Э. Брауде //2004. - 655 с.: ил.
    4. Wikipedia - свободная энциклопедия. Инструменты UML-моделирования. [Электронный ресурс]. Дата обновления: 19.01.2011. - Режим доступа: http://ru.wikipedia.org/wiki/Инструменты UML-моделирования.
    5. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2000.- 432 с., ил.
    6. Ларман К. применение UML и шаблонов проектирования: Пер. с англ. - М.: Издательский дом «Вильямс», 2001. - 496 с., ил.