
- •1 Постановка задачи
- •1.1 Требования к разрабатываемому по
- •1.1.1 Требования пользователя
- •1.1.2 Требования к по
- •Интерфейс системы должен быть реализован на английском языке.
- •2 Анализ требований
- •2.1 Описание концептуальной модели
- •2.2 Словарь предметной области
- •2.3 Основные прецеденты использования по
- •4 Архитектурное и детальное проектирование по.
- •4.1 Архитектурное проектирование
- •Пользовательский интерфейс
- •4.4.2 Проектирование серверной части по
- •5 Проверка работоспособности по
- •Литература
- •Приложения Приложение а. Листинг исходного кода sql-спринтов для создания базы данных
- •Приложение б. Листинги исходных кодов классов клиентской части по Классы-сущности
- •Слой доступа к данным
- •Классы пользовательского интерфейса
Пользовательский интерфейс
Третьей частью клиентского приложения является собственно интерфейс пользователя. Он обеспечивает визуальное представление данных в удобной для пользователя форме, а также обработку его команд.
В данном случае логика работы клиентского приложения довольно проста, она заключается в получении из БД и отображении набора данных, без необходимости какой-либо её обработки. Это позволяет отказаться от создания классов бизнес-логики. Всю необходимую работу будут выполнять классы обработки пользовательского интерфейса.
4.4.2 Проектирование серверной части по
Рисунок 4.5 – Логическая модель БД
База данных будет содержать следующие сущности.
Таблица «Сотрудник»
Таблица «Сотрудник» содержит базовую информацию о работнике склада.
Таблица 4.1 - Сотрудник
Id |
Integer |
Идентификатор пользователя |
Name |
Varchar |
Имя пользователя |
Таблица «Товар»
Таблица «Товар» содержит основную информацию о товаре, зарегистрированного на складе.
Таблица 4.1 - Товар
Id |
Integer |
Идентификатор товара |
Name |
Varchar |
Название товара |
Manufacturer |
Varchar |
Название производителя товара |
QuantityInStock |
Integer |
Количество единиц товара на складе |
Таблица «Поставка»
Таблица «Поставка» содержит список поставок товаров на склад/со склада.
Таблица 4.3 - Поставка
Id |
Integer |
Идентификатор поставки |
ProductId |
Integer |
Идентификатор товара |
Quantity |
Integer |
Количество единиц товара в поставке |
ResponsiblePersonId |
Integer |
Идентификатор ответственного сотрудника |
Таблицы Товар и Поставка связаны отношением «один ко многим», т.к. один товар может участвовать во многих поставках, но каждая поставка содержит лишь один товар.
Таблицы Сотрудник и Поставка связаны отношением «один ко многим», т.к. один сотрудник может быть ответственным за многие поставки, но за одну поставку несет ответственность лишь один сотрудник.
5 Проверка работоспособности по
На рисунке 5.1 представлен экран текущего состояния склада
Рисунок 5.1 – Текущее состояние склада
На рисунке 5.2 представлено окно регистрации нового товара
Рисунок 5.2 – Диалог добавления нового товара
На рисунке 5.3 представлен экран состояния склада после регистрации нового товара.
Рисунок 5.3 – Экран состояния склада после регистрации нового товара.
На рисунке 5.4 представлен экран журнала поставок.
Рисунок 5.4 – Экран журнала поставок.
На рисунке 5.5 представлен экран регистрации входящей поставки.
Рисунок 5.5 – Экран регистрации входящей поставки.
На рисунке 5.6 представлен экран журнала поставок после регистрации новой поставки
Рисунок 5.6 – Экран журнала поставок после регистрации новой поставки.
На рисунке 5.7 представлен экран журнала поставок, отфильтрованного по товару MultiTabs.
Рисунок 5.7 – Экран журнала поставок, отфильтрованного по товару MultiTabs.
На рисунке 5.8 представлен экран журнала поставок, отфильтрованного по сотруднику Gregory House.
Рисунок 5.8 – Экран журнала поставок, отфильтрованного по сотруднику Gregory House.
Выводы
В ходе выполнения работы была разработана распределенная информационно-справочная система для учета медицинских препаратов на складе.
Для успешной работы приложения вначале была разработана логическая, физическая модель БД. Была разработана диаграмма классов, а также разработан проект архитектуры системы.
В данной работе была использована классическая двухслойная архитектура «клиент - сервер». Выбор архитектуры обоснован следующими преимуществами: простота создания, быстрота работы, отсутствие высоких нагрузок на систему.
При разработке использовалась следа NetBeans 6.7.1 и СУБД JavaDB.
Для реализации подключения к БД использовался драйвер org.apache.derby.jdbc.ClientDriver и библиотека hibernate.
В ходе проверки корректности работы системы ошибок выявлено не было.