Файл: С помощью фреймовика.docx

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

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

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

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

С моделью предметной области связано большое количество различных контекстов. Простейший вариант — однопользовательское приложение, где единый граф объектов считывается из дискового файла и располагается в оперативной памяти. Такой стиль работы присущ настольным программам, но менее характерен для многоуровневых приложений, поскольку в них намного больше объектов. Размещение каждого объекта в памяти сопряжено с чрезмерными затратами ресурсов памяти и времени. Достоинство объектно-ориентированных систем баз данных заключается в том, что они создают впечатление, будто объекты пребывают в памяти постоянно.

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

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

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

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

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

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

Класс Type
Класс Member
Класс Ypakovka
Класс Rastenie
Класс Prodaza
Класс CartProduct
Класс Cart
Класс Order
Класс Customer
Класс NotificationManager
Класс Notification
I Класс mageGallary

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

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

Вариант использования – это независящее от реализации высокоуровневое представление конкретной функции разрабатываемой системы. Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое внешним объектом (действующим лицом, актером) [12]. Другими словами, такое представление предназначено для упрощения взаимодействия с будущими пользователями системы, с клиентами, и особенно пригодятся для определения необходимых характеристик системы.

Составление вариантов использования производится на основе анализа требований к интернет-магазинам. Главными актерами в контексте программного средства являются администратор и пользователь этой системы.

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

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

На рисунке 2 изображена диаграмма вариантов использования в нотации UML.

Рисунок 2 - Диаграмма вариантов использования в нотации UML

3 Структура программного обеспечения и еѐ реализации на языках программирования

Базовым шаблоном является base.html. Он содержит в себе шапку сайта, с логотипом, поисковым блогом, и навигацией. Доступ к этим элементам необходим из любой части сайта, поэтому базовый шаблон всегда будет использоваться при рендеринге страницы. Его наследуют остальные шаблоны

В проекте представлены следующие шаблоны:

– product_detail.html, страница с подробной информацией о конкретном товаре, характеристиками, рейтингом, отзывами и т.д.;

– cart.html, пользовательская корзина с возможностью изменять количество товаров, удалять или оформить покупку;

– wish.html, список желаемых товаров пользователя;

– login.html, страница авторизации пользователя;

– registration.html, страница регистрации нового пользователя;

Приняв во внимание требования, представленные в разделе проектирования, был разработан пользовательский интерфейс.

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

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

Интерфейс главной страницы представлен на рисунке 3.

Рисунок 3 – Главная страница

На главной странице представлены продаваемые товаре. В верхней части кнопки «Авторизация» и «Регистрация». Есть возможность отсортировать цену по параметрам (min, max).

Для того чтобы пользователю совершать покупки необходимо пройти регистрацию «Рисунок 4».

Рисунок 4 – Форма регистрации

Форма авторизации представлена на рисунке 5.

Рисунок 5 – Форма авторизации

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

Рисунок 6 – Галерея изображений

Также пользователь может просматривать информацию о дате изготовления, упаковки, описания и есть ли товар в наличии (Рисунок 7).

Рисунок 7 – Информации

После добавления в корзину в правом верхнем углу появляется информация о количестве добавленных товаров в корзину (Рисунок 8).

Рисунок 8 – Значок корзины

При переходе в саму корзину видим добавленные товары и общую сумму к оплате (Рисунок 9).

Рисунок 9 – Корзина

Форма заказа представлена на рисунке 10.

Рисунок 10 – Форма заказа

Можно выбрать доставку самовывозом или доставкой.

Если товар на складе закончился, около него появляется надпись «Нет в наличии» (Рисунок 11).

Рисунок 11 – Товара нет в наличии.

Админ панель представлена на рисунке 12.

Рисунок 12 – Админ панель

Рисунок 13 – Администрирование

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

ЗАКЛЮЧЕНИЕ

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

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

Благодаря фреймворку Django удалось значительно ускорить разработку за счет реализации компонентного подхода и принципу DRY. Компонентная архитектура упростила определение и поддержание единого стиля приложения и правил поведения.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Элементы интернет-магазина [Электронный ресурс]. – URL: http://www.web.starport.ru/ecommerce/pg3_0.php (дата обращения: 23.04.23).

2. Фаулер, М. UML. Основы / М. Фаулер, К. Скотт. – СПб: Символ-Плюс, 2002. – 192 с.

3. Маклаков, С.В. BPwin и ERwin: СASE-средства для разработки информационных систем / С.В. Маклаков. – М.: Диалог-МИФИ, 2019. – 238 с.

4. Лутц, М. Изучаем Python, 4-е издание / М. Лутц. – СПб: Символ-Плюс, 2010. — 1280 с.

5. Model View Controller [Электронный ресурс]. – URL: https://ru.wikipedia.org/wiki/Model-View-Controller (дата обращения: 02.04.23).

6. Фреймворк Django [Электронный ресурс]. – URL: http://djbook.ru/rel1.8/intro/overview.html (дата обращения: 03.04.23).

7. Общий обзор архитектуры Django [Электронный ресурс]. – URL: http://kutaloweb.com/jeff_forcier_glava_3/obschiy_obzor_arhitektury_django/ (дата обращения: 03.04.23).

8. Разработка сайтов с использованием HTML5 [Электронный ресурс]. – URL: https://www.prcomm-spb.ru/html-5.html (дата обращения: 12.04.23).

9. СSS3 свойства [Электронный ресурс]. – URL: https://webformyself.com/sss3-svojstva/ (дата обращения: 12.04.23).

10. Современный учебник Javascript [Электронный ресурс]. – URL: https://learn.javascript.ru/ (дата обращения: 14.04.23.