Технически университет 

Варна   
Катедра „Софтуерни и интернет технологии

Курсов проект
по
Интернет за мобилни устройства

Тема:
Разработване на информационна система,
предоставяща услуга склад
Изработил: Проверил:
Тамара Бонева доц. Христо Ненов
Факултетен №: 20651271
Специалност: Софтуерно инженерство
Задание:
Склад с наличности
Да се разработи информационна система, предоставяща услуга склад. Програмата
съхранява и обработва данни за складови помещения. Системата позволява множествен
достъп.
Системата поддържа два вида потребители администратор и оператори (складов агент)
с различни роли за достъп до функционалностите в системата.
Операции за работа с потребители:
• Създаване на складови оператори от администратор;
• Създаване на доставчици;
• Създаване на клиенти;
• Създаване на каса (Парична наличност).

Системата поддържа операции за работа със събития:

• Създаване на номенклатури;
• Работа с фактури
•Приемане на стока от доставчик на доставна цена;
• Изписване на стока на продажна цена;
• Наблюдение за наличност на стоки в склада;
• Наблюдение за наличност на пари в касата;

Системата поддържа справки по произволен период за:

• Доставки и доставчици;
• Изписване и клиенти;
• Дейност на складовите оператори;
• За наличности в склада;
• Разходи,приходи,печалба.
• Движение на наличността в касата.
Системата поддържа Известия за събития:
• Критичен минимум и липса на стока;
II. Критичен минимум и липса на парична наличност

I. Анализ на проблема
I.1. Функционални изисквания
Разработваната система трябва да предоставя следните функционални възможности:
 Системата трябва да предоставя функционалности за съхранява и обработва
данни за складови помещения;
 Системата позволява множествен достъп – различни потребители да работят
едновременно;
 Вход в системата;
 Наличие на два вида потребители- оператор(скадов) и администратор, които
имат различни роли за достъп до функционалностите в системата.
 Администраторите имат права да създават потребители – складови оператори и
други администатори;
 Администраторите имат права да създават каси, доставчици и клиенти;
 Сладовите оператори имат права за създаване на доставчици;
 Сладовите оператори имат права за създаване на клиенти;
 Системата поддържа операции за създаване на номенклатури;
 Системата поддържа операции за работа с фактури;
 Системата поддържа операции приемане на стока от доставчик на доставна
цена;
 Системата поддържа операции за изписване на стока на продажна цена;
 Системата предоставя възможност за наблюдение за наличност на стоки в
склада;
 Системата предоставя възможност за наблюдение за наличност на пари в
избрана каса;
 Системата поддържа справки по произволен период за:
o Доставки и доставчици;
o Изписване и клиенти;
o Дейност на складовите оператори;
o За наличности в склада;
o Разходи,приходи,печалба;
o Движение на наличността в касата.
 Системата поддържа Известия за събития:
o Критичен минимум и липса на стока;
o Критичен минимум и липса на парична наличност

I.2. Структура на проекта

Системата се състои от три компонента: сървърно приложение, база данни и

мобилно приложение. Информацията нужна за работа на системата се съхранява в
базата данни. Сървърното приложение предоставя REST interface, чрез който
мобилното приложение има достъп до данните на системата. За реализирането на REST
interface сървърното приложение използва Spring boot.
в сървърната част и Retrofit в клиентската част.
I.3. Дефиниция на модулите на системата
Сървърно приложение - състои се от следните компоненти:
 REST API
Състои се от три слоя:
o Уеб слой (Web Layer)
o Обслужващ слой (Service Layer)
o Слой на хранилището (Repository Layer)
База данни – Информацията нужна за работа на системата се съхранява в базата
данни.
Мобилно приложение – мобилен клиент реализиране като Android App

I.4. Проектиране на системата

 Поектиране на база данни

Избрана е MySQL система за управление на релационна база данни. Тя е с отворен код,
безплатна и достъпна за използване от всички. Подходяща е както за малки така и за
големи приложение. MySQL работи на много различни платформи. Релационните бази
от данни съдържат данни, достъпни за много потребителски приложения ( един път
съхранени, данните могат да се използват многократно в едно или няколко
приложения), представянето на данни е независимо от начина на физическото им
съхраняване, т.н. логически аспект на данните.
 Проектиране на REST API
REpresentational State Transfer (REST) е архитектурен стил, дефиниращ набор от
ограничения, които да бъдат използвани при изграждане на уеб услуги. REST е
архитектура, базирана на уеб стандарти, използваща HTTP протокола. Всеки
компонент е ресурс и всеки ресурс е достъпван посредством интерфейс чрез използване
на HTTP методи. При REST архитектурата REST сървър предоставя достъп до ресурси
и REST клиент достъпва и модифицира тези ресурси. Всеки ресурс е идентифициран
чрез URI. REST използва различни начини за представяне на ресурси като: текст, JSON,
XML. JSON е най-често употребявания формат за предоставяне на ресурси чрез REST
услуга.
REST – стилът обикновено се състои от клиенти и сървъри. Клиентите инициират
заявки към сървърите; сървърите преработват заявките и връщат подходящи отговори.
Клиентът е front-end и сървърът е back-end на услугата. Биват независими един от друг.
Най-често използваните HTTP методи при REST са:
- GET – предоставя достъп за четене до ресурс;
- POST – използван за създаване на нов ресурс;
- DELETE – използван за премахване на ресурс;
- PUT – използван за модифициране на съществуващ ресурс или за създаване на
нов ресурс.
 I.5. Реализация на проекта
 Реализация на база данни
Всяка таблица в MySQL базата данни е създадена с оглед изискванията на системата с
необходимите полета, типове данни, първични и външно ключове. Основните таблици,
които изграждат релационната база данни са показани на фиг. 1. Чрез използването на
UML диаграма ясно се представя структурата на базата данни, таблиците от които е
изградена, техните атрибути и типовете от стойности, които атрибутите могат да
приемат.
За създаване на базата данни в файл application.properties задаваме пътя към базата
данни, името на базата, настройки за потребителско име и парола, и на кой порт ще
работи сървъра.
Фиг.1 UML клас диаграма документната база данни
Базата данни се състои от 7 таблици:
- users – тук се съхранват данните да потребителителите
- customers – тук се съхраняват данните за клиенти и доставчици
- nom – номенклатури на стоките в склада
- CashRegister – информация за всяка каса
- CashRegisterTransaction – съхранява информация за всяка направена транзакция на
каса
- Invoice – съхранява информация за всички фактур
- InvoicePosition – в таблицата се записват данни за всяка позиция във фактурата
За създаването на всяка една от таблиците се създава отделен клас (Entity Model), в
който се описват полетата. За всяка от таблиците, които са ни необходими са създадени
един клас и един интерфейс.

За таблица - Customer:

@Entity: Тази анотация позволява на нашия клас да бъде сериализиран и

десериализиран във и от JSON. Той също така ни позволява да създадем таблица в
базата данни
@Table(name = “customers”): Тази анотация казва на програмата да извика таблицата
„customers“.
-дкларират се полетата от таблицата, както и get() и set() методите – те се използват за
задаване и връщане на различни променливи в нашия клас.
@ManyToOne – добавяме връзки на обекти между класовете

Създадени са класовете:
- User
- Customer
- CashRegister
- CashRegisterTransaction
- Invoice
- InvoicePosition
- Nom
Те са необходими за осъществяването на бизнес логиката на системата.

Създадените интефейси- ..Repository ще ни

позволят да взаимодействаме с нашата база
данни. Те разширяват JpaRepository за CRUD
методите и персонализираните методи за
намиране.
@Repository: Това казва на Spring, че това е интерфейсът, който да използваме за
нашите функции за управление на база данни.
JpaRepository: Това свързва интерфейса с таблицата на нашата база данни. Казваме му
да погледне нашата таблица с клиенти - customers и му казваме, че стойността на
нашето поле за идентификатор е Long.

Enum Status ще се изполва като начин да се даде

обратна връзка на потребителя дали текущото им
действие е било успешно или неуспешно.
За връзка между сървърната част и графичния интерфейс на приложението са
използвани контролери. Това е бизнес логиката на нашата програма. Тук се обработват
HTTP заявките изпратени към приложението.
За всяка една от таблиците е създаден контролер с
изключение на таблицата Invoice_positions, защото
позициите няма смисъл поотделно

UserController

@RestController: казва на Spring, че това ще се използва за контрол на

функционалността на нашия API и всички заявки, изпратени до нашата
програма.
@PostMapping: Това казва на Spring, че всеки път, когато нашата
програма получи заявка за публикуване към /users/register, функцията
registerUser трябва да бъде извикана и след това предава получените данни
към функцията registerUser.
Функцията registerUser(@Valid @RequestBody User newUser): изисква
валиден json обект, подобен на нашия клас User, по този начин ще сме
сигурни, че обектът, който получаваме, е използваем в нашата програма.
Функцията започва със създаване на списък с потребители в нашата база
данни, наречени потребители.
От“repo.findAll()” прави заявка към нашата база данни и връща всички
потребители, които сме запазили в момента. След това функцията обикаля
всички потребители в нашата база данни и я сравнява с потребителя, който
току-що получихме, така се гарантира, че потребителят вече не е част от
нашата база данни. Ако установи, че потребителят вече е в нашата база
данни, той връща Status. USER_ALREADY_EXITS. В противен случай той
ще добави новия потребител в нашата база данни и ще върне статус
SUCCESS.

Тук изполваме метода GET(), за да получим списък на всички клиенти

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

Метода PUT() е изпозлван за заменя адресирания член на таблицата или

ако не съществува го създава.
Методът PUT HTTP е използван за модифициране на ресурс, където
клиентът изпраща данни, които актуализират целия ресурс.
Използва се за пълно задаване на информация за обект. PUT е подобен на
POST по това, че може да създава ресурси, но го прави, когато има
дефиниран URI. PUT презаписва целия обект, ако той вече съществува, и
създава нов ресурс, ако не съществува.
 Реализация на гарфичен дизайн
Реализирана е чрез Retrofit – HTTP клиент за Android и Java. Предоставя удобен
начин за предаване на JSON структурирани данни към REST базирана уеб услуга.
Извършва автоматично конвертиране на JSON обекти към Java обекти и обратно.
Създаден е интерфейс API, за да обработва заявките и отговорите. Обектът на API
се създава от Retrofit. Проверяваме дали вече има създаден такъв клиент.

Графичният интерфейс се състои от 3 активитита:

o MainActivity – тук е показан бутона – login с който ни препраща към активити за
влизане.
o LoginActivity - Потребителят попълва данни за вход, потренителско име и
потребителските данни ще бъдат изпратени до Spring Backend. След тива
се проверяват в Backend и връща информормация дали успешно ли в
влизането в системата. Активността на таблото за управление се показва
и приветства потребителя.