Физическая модель базы данных
Физическая модель базы данных представляет собой завершающий этап перед созданием программного приложения. Для создания базы данных было выбрана СУБД PostgreSQL. Выбор PostgreSQL в качестве СУБД обоснован поддержкой реляционной модели данных, соответствием стандарту SQL, мощными функциями, включая транзакционность, управление параллелизмом и безопасность, а также широкой экосистемой инструментов и библиотек, поддержкой расширений и возможностью масштабирования. Физическая модель БД представлена на рисунке 4:
Рисунок 4 – Физическая модель базы данных
Таблица "products" (товары):
id (bigint)
name (varchar)
description (varchar)
price (numeric(8,2))
status (varchar)
brand_id (bigint)
img_src (varchar)
Таблица "brands" (бренды):
id (bigint)
name (varchar)
country (varchar)
description (varchar)
website (varchar)
Таблица "blog_posts" (блог-посты):
id (bigint)
heading (varchar)
content (varchar)
publication_date (timestamp with time zone)
Таблица "special_offers" (специальные предложения):
id (bigint)
name (varchar)
start_date (date)
end_date (date)
description (varchar)
В этом разделе были разработаны модели базы данных, включая определение 4 сущностей, их связей и атрибутов, а также указаны первичные и внешние ключи. Этот этап является важным шагом к разработке информационной системы.
Разработка программного приложения аис магазина спортивных товаров
Для создания веб-приложения для АИС, обеспечивающего удобный интерфейс для работы с базой данных, необходимо выбрать подходящие инструменты и технологии, которые обеспечат высокую производительность, надежность и удобство разработки.
В качестве языка программирования выбран Java, так как он является популярным и мощным языком, который обладает широкой экосистемой инструментов и библиотек. Для упрощения процесса разработки веб-приложения на Java выбрана интегрированная среда разработки IntelliJ IDEA, которая предоставляет множество функций, упрощающих разработку, таких как автодополнение кода, отладка, тестирование и интеграция с системами контроля версий.
Для создания веб-приложения на основе Java выбран фреймворк Spring, который предоставляет множество модулей для упрощения разработки. В частности, для создания RESTful API и обработки HTTP-запросов используется модуль Spring Web, а для работы с базой данных используется модуль Spring Data JPA, который упрощает работу с базами данных, используя Java Persistence API (JPA). Для упрощения создания и развертывания веб-приложения на основе Spring используется фреймворк Spring Boot, который предоставляет множество готовых настроек и конфигураций, которые позволяют быстро начать разработку и снижают сложность управления зависимостями.
Для создания динамических HTML-страниц на основе Java-кода используется шаблонизатор Thymeleaf, который интегрируется с Spring и предоставляет простой и понятный синтаксис для работы с данными и логикой веб-страниц.
В качестве системы управления реляционными базами данных выбран PostgreSQL, который является мощной и надежной системой с открытым исходным кодом, обеспечивающей высокую производительность, масштабируемость и поддержку.
Отличительная особенность Spring Framework в том, что он предоставляет набор готовых реализаций паттернов проектирования, которые можно использовать для разработки приложений. Например:
Spring Framework по умолчанию использует паттерн Singleton (одиночка) для управления жизненным циклом бинов (классов, обработкой который занимается контейнер Spring). Когда вы определяете бин, Spring создает только один экземпляр этого бина и возвращает его каждый раз, когда он запрашивается;
Spring Framework предоставляет паттерн фасад в виде интерфейса JpaRepository для упрощения взаимодействия с базой данных. JpaRepository предоставляет удобный интерфейс для выполнения операций CRUD (создание, чтение, обновление, удаление) над сущностями, а также предоставляет дополнительные методы для выполнения сложных запросов;
Spring Web реализует структурный паттерн MVC (Model-View-Controller):
Model (модели) обычно представлены классами Java, которые аннотированы @Entity. Они могут быть сохранены в базе данных с помощью Spring Data JPA или использоваться для передачи данных между контроллером и представлением;
View (представление) отвечает за отображение данных пользователю. В разработанном приложении представление реализовано с использованием Thymeleaf. Контроллеры возвращают имена представлений, а рендеринг представлений выполняется автоматически конфигурируемым с помощью Spring Boot ViewResolver;
Controller (контроллер) обрабатывает запросы от пользователя, взаимодействует с моделью и выбирает подходящее представление для отображения данных. Контроллеры в Spring MVC аннотируются @Controller и содержат методы, аннотированные @RequestMapping, которые обрабатывают конкретные URL-пути и HTTP-запросы.
Рассмотрим пример: в каждом из классов контроллеров, работающих с сущностями (таблицами БД), содержится бин класса сервис-слоя, отвечающего за бизнес-логику предложения. Так, например в контроллере для товаров ProductController, внедрены два singleton-бина сервис-слоя. Часть кода представлена на листинге 1:
@Controller
@AllArgsConstructor
@RequestMapping("/sportline/products")
public class ProductController {
private static final String REDIRECT_LIST = "redirect:/sportline/products";
private static final String REDIRECT_ITEM = "redirect:/sportline/products/{id}";
private ProductService productService;
private BrandService brandService;
// реализации методов контроллера
}
Листинг 1 – Часть кода класса контроллера
Далее, каждая из реализаций бинов содержит бин репозитория для получения доступа к операциям работы с БД. Он также внедрён как singleton (одиночка), предоставляя доступ всегда к одному и тому же бину в любом из классов. Так, например в классе-сервисе для товаров ProductServiceImpl, внедрен singleton-бин класса ProductRepository. Сам класс ProductRepository реализует паттерн фасад, предоставляя доступ к CRUD-операциям, операциям фильтрации, сортировки и другим за счёт наследования от интерфейса JpaRepository, который в свою очередь реализует интерфейсы ListCrudRepository, ListPagingAndSortingRepository, QueryByExampleExecutor. Часть кода классов ProductServiceImpl и ProductRepository представлена на листинге 2:
@Service
@AllArgsConstructor
@Transactional(readOnly = true)
public class ProductServiceImpl implements ProductService {
private final ProductRepository productRepository;
// реализации методов класса-сервиса
} public interface ProductRepository extends JpaRepository<Product, Long> { }
Листинг 2 – Часть кода классов ProductServiceImpl и ProductRepository
Наконец после того, как контроллер обратился к классу сервис-слоя, а тот к классу репозитория, полученные данные отправляются соответствующей HTML-странице с использованием Thymeleaf, позволяя динамически загружать данные из БД и проводить с ними операции в пользовательском интерфейсе, что завершает структуру паттерна MVC.
Таким образом, использование паттернов одиночка, фасад, MVC в приложении позволяет эффективно осуществлять доступ к бинам, упрощает взаимодействие с базой данных, обеспечивает четкую структуру приложения и разделение ответственностей, что делает приложение более гибким, масштабируемым и поддерживаемым.
Также была разработана UML-диаграмма классов для проектирования и визуализации структуры приложения. Создание UML-диаграммы классов позволяет наглядно представить взаимосвязи между компонентами приложения, его структуру и поведение. На UML-диаграмме классов на рисунке 5 представлены основные компоненты (контроллеры, сервисы и репозитории) и их связи. На UML-диаграмме классов на рисунке 6 представлены основные сущности (товары и их статусы, бренды, специальные предложения и посты в блогах) и их связи.
Рисунок 5 – UML-диаграмма классов контроллеров, сервисов и репозиториев
Рисунок 6 – UML-диаграмма классов сущностей
Итак, в данном разделе были рассмотрены аспекты разработки продукта. Что позволяет перейти к следующему этапу тестирования программного приложения