Отчет. Информационная система "Склад". - newmumba/storage-1 GitHub Wiki

В информационной системе предусмотрены следующие роли:

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

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

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

Функциональные требования.

  1. Для заказчика:

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

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

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

Обобщенная диаграмма прецедентов.

![Заказчик] (https://github.com/newmumba/storage-1/blob/master/UML/%D0%97%D0%B0%D0%BA%D0%B0%D0%B7%D1%87%D0%B8%D0%BA.png)

Начальник склада

Начальник транспортного цеха

Текстовое описание с альтернативами.

1. Заказчик

1.1. Просмотр товаров

  1. Заказчик заходит в информационную систему.
  2. Система предоставляет информацию о товарах.

1.2. Оформление заказа

  1. Заказчик просматривает каталог товаров и выбирает товары для заказа.
  2. Заказчик вводит контактную информацию.
  3. Заказчик указывает район доставки.
  4. Система предоставляет полную информацию о заявке.
  5. Заказчик оценивает правильность указанных данных и выбранных товаров.
  6. Заказчик отправляет заявку.

1.3. Просмотр состояния заявки

  1. Заказчик заходит в информационную систему.
  2. Заказчик выбирает заявку.
  3. Система предоставляет информацию о заявке.

2. Начальник склада

2.1. Просмотр заявки

  1. Начальник склада заходит в информационную систему.
  2. Система предоставляет информацию о заявках.

2.2. Оформление заявки

  1. Начальник склада просматривает список заявок и выбирает заявку для оформления.
  2. Начальник склада определяет объем товара в заявке.
  3. Система предоставляет полную информацию по заявке.
  4. Начальник склада подтверждает правильность оформления заявки.
  5. Система выбирает корзину для заявки в зависимости от района заказчика.
  6. Система предоставляет информацию о выборе корзины.
  7. Начальник подтверждает отправку транспортной накладной в корзину.
  8. Система изменяет статус заявки на ''Принято''.

2.4. Формирование транспортной накладной

  1. Система оценивает время с момента первой заявки.
  2. Система оценивает объем всех заявок в системе при приходе новой заявки.
  3. Система формирует транспортную накладную корзины при превышении лимита времени или достижении минимального объема товаров.
  4. Система отправляет транспортную накладную начальнику транспортного цеха.

**Альтернатива:**Лимит времени не превышен и не достигнут минимум объема товаров.

Система переходит к пункту 2.4.1.

3. Начальник транспортного цеха

3.1. Просмотр транспортной накладной

  1. Начальник транспортного цеха заходит в информационную систему.
  2. Система предоставляет информацию о транспортных накладных.

3.3. Назначение авто

  1. Начальник транспортно цеха выбирает накладную для оформления отправки товаров по накладной.
  2. Начальник транспортного цеха осуществляет выбор подходящего авто для отправки товаров по накладной.
  3. Начальник транспортного цеха подтверждает отправку товаров по накладной.
  4. Система изменяет статус заказа на "Отправленный".

Альтернатива: Нет подходящего авто.

Переходим к следующей заявки в очереди.

Альтернатива: Нет авто.

Ждем прибытия авто в цех.

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

![Class Diagram] (https://github.com/newmumba/storage-1/blob/master/UML/Class%20Diagram.png)

объектной модели предметной области.

![Sequence Diagram] (https://github.com/newmumba/storage-1/blob/master/UML/Sequence%20Diagram.png)

##Проектирование слоя бизнес-логики

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

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

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

Реализация слоя бизнес-логики

В качестве среды разработки выла выбрана NetBeans IDE 8.0.2. В ней был создан стандартный проект Java. Проект был назван storege.

Бизнес-логика расположена в папке src/logic

Проектирование слоя источников данных

Выбор слоя доступа к данных уже оговаривался при выборе подхода реализации бизнес-логики. Решение было принято в пользу Активной записи (Active Record). Данный подход хорошо сочетается с моделью предметной области, является достаточно простым и понятным в реализации.

В качестве источника данных была выбрана база данных JavaDB.

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

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

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

Также в отдельный класс CreatingConnection.java были вынесены методы, работающие непосредственно с БД. Это такие методы как установление соединения с БД, разрыв соединения с БД; добавление, изменение и получение записи. Тут же стоит сказать, что соединение с БД устанавливается единожды при загрузке приложения. Во время работы приложения соединение остается неразрывным и закрывается только при закрытии приложения или в случае технических неполадок.

Класс CreatingConnection.java расположен в директории /src/util/

Все настройки базы данных производились в среде NetBeans IDE 8.0.2 в разделе службы. База данных была названа как и приложение storege.

Адрес БД: jdbc:derby://localhost:1527/storage

Для создания таблиц был написан скрипт. Текст скрипта расположен в файле CreateDb.txt.

Проектирование сервисного слоя и слоя представления

Представление реализовано в формах JFrame, при помощи технологии java swing.

Представление реализовано для трех типов пользователей:

  • Заказчик (клиент);
  • Начальник склада;
  • Начальник транспортного цеха.

Файлы представления расположены в директории /src/gui/.

Комплексное тестирование

По окончанию проектирования информационной системы было произведено комплексное тестирование. Оно представляло из себя ручное тестирование на основе диаграмм использования. А также использование JUnit тестов. Результат покрытия JUnit тестами представлен ниже.

![Тест] (https://github.com/newmumba/storage-1/blob/master/test.PNG)

##Выводы

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

Для Разработав и подробно описав варианты использования, разработав как статическую, так и динамическую объектные модели предметной области, можно переходит к проектированию слоя предметной области. И первая задача, это выбрать решение для организации бизнес-логики разрабатываемого приложения. Было решено использовать одно из типовых решений, а именно модель предметной области (Domain Model). При выборе слоя доступа к данным было решено использовать Активную запись (Active Record).

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