Реализация программного обеспечения

Разработка каркаса Web-приложения

 

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

Этот компонент в разрабатываемой программе и есть приложение core. У него есть URL конфигурация:

1. / домашняя страница - страница (приветствием и алгоритм работы).

2. / анализ - страница с графиками анализа.

3. / прогноз - страница с графиками прогнозов.

Это отражено в файле urls.py. Содержание рассмотрено в листинге 2.

Листинг 2. Конфигурация URL приложения ядра.

из.импорт просмотров *

из пути импорта django.urls, включите

из django.contrib.auth импортировать представления как auth_views

 

urlpatterns = [

путь ('', HomeView.as_view (), name = 'home'),

путь ('analysis /', AnalysisView.as_view (), name = 'analysis'),

путь («прогноз /», ForecastView.as_view (), имя = «прогноз»),

]

# Добавить URL для аккаунтов

urlpatterns + = [

путь («account /», include («django.contrib.auth.urls»)),

]

изcore.request_handlers import *

# Добавить URL для rest-api

urlpatterns + = [

путь («клиенты /», список клиентов, имя = «клиенты»),

путь ('products /', product_list, name = 'products'),

путь («категории /», список категорий, имя = «категории»),

путь ('products /', product_list, name = 'products'),

путь ('payment_methods /', payment_method_list, name = 'payment_methods'),

путь('trend_list', trend_list, имя = 'trend_list')

]

Внешний вид этих страниц анализа и прогноза представлен на рис.3.1 и 3.2

Рисунок 3.1 - Страница / анализ

 

Рисунок 3.2 - Страница / прогноз

    Coreпредставляет собой кейс для этих компонентов, но отдельно от сore они работать не смогут.

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

Система авторизации используется стандартная. Она поставлена разработчиками Django.

 

Разработка моделей

 

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

    Все классы моделей в Django являются наследниками Model. Python-код, который обрабатывает фреймворком и отображает на основе базы данных. Механизм миграции поддерживает синхронность описания моделей и таблиц в базе данных. Сохранить данные в базе данных settings.py.

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

3. Полное содержание файла models.py, доступные объявления о моделях, показаны в приложении B.

Листинг 3. Объявления модели.

Класс продукта (модели.Модель):

sale_price = models.FloatField (null = False, blank = False) #Цена, которая используется клиентами

name = models.CharField (max_length = CHAR_FIELD_MAX_LENGTH, null = False, пробел = False)

cost_price = models.FloatField (null = False, пусто = False)

category = models.ForeignKey ('Category', on_delete = models.CASCADE)

def __str __ (self):

вернуть self.name

defget_revenue (self, count):

вернутьself.sale_price * count

defis_category (self, category):

вернутьself.category == категорию

defget_total_for_day (self, dt):

завтра = utils.get_t Saturday ()

вчера = utils.get_yesterday ()

pos = ProductsOrders.objects.filter (order__date__gt = вчера, order__date__lt = завтра). \

фильтр (продукт = Я). aggregate (Sum(‘общий'))

returnpos ['total__sum']

Таблица Product будет иметь политипа FLOAT для цены себестоимости, текстовое поле размеромCHAR_FIELD_MAX_LENGTH, и внешний ключ к таблице Категория. Полеid, являющееся первичным ключом. Как и любой Python-класс, модель может содержать методы для реализации бизнес-логики. Get_revenue, который возвращает стоимость count объектов этого типа; функция is_category, возвращающая значение True, если продукт относится к категории категорий,get_total_for_day, возвращающий общий доход за день.

Каждый подкласс Django database modelполучает доступ к базе данных с использованием методов менеджера. По умолчанию имя менеджера объектов, то есть для обращения к объектам из таблицы.

Все методы менеджера возвращают объекты класса QuerySet, позволяющий использовать последовательность методов. Основные методы менеджера:

1. all () - возвращает все объекты из базы данных;

2. first () - возвращает первый объект из QuerySet;

3. filter () - получает аргументы, которые ограничивают выдачу объектов.

4. значения () – ограничиваетполявыдачи;

5. annotate () - обнаружен в выданом поле;

6. aggregate () - возвращает одно значение после применения агрегирующей функции:

a. Sum – суммирует значения поля;

b. Avg - возвращает среднее арифметическое значение поля

c. Count– возвращает число значений поля

Пример использования методов менеджера показывает в листинге функции get_total_for_day:

pos = ProductsOrders.objects.filter

(Order__date__gt = вчера,

order__date__lt = завтра). filter (продукт = Я). \

Совокупный (Sum('общий'))

Этот запрос обозначает следующее: из объектов: заказы, данные, которые больше, чем вчера, но меньше, чем завтра (вчера и завтра - дата и время), то есть выбор из них, которые описывают продукт self (тот экземпляр класса Product, который вызвал этот метод), потом возвратить сумму его полей всего.