В предыдущей статье я писал с чего начинался стартап namingservice.org. В этом топике я продолжу описывать следующий этап материализации идеи. После того как документ «Видение проекта» был готов, я подумал что было бы здорово перенести на бумагу виды сайта, т. е. то как он должен выглядеть, и как я себе его представлял.
Всё началось с вида домашней страницы. Она должна была давать краткое представление о проекте, и содержать шапку страницы (логотип, слоган, навигация, кнопки логина и регистрации), плюс я решил что будет полезным отображать на главной странице непосредственно заказы с кратким описанием и ценой.
В итоге получился документ, состоящий из 15 видов, которые легли в основу дизайна сайта. Что из этого вышло, можно посмотреть непосредственно на сайте, но для того чтобы почувствовать разницу между тем, что проектировалось, и тем что получилось приведу еще несколько основных видов.
В этом документе были приведены основные требования к данным.
Для хранения личных настроек пользователей служит стандартная таблица Django User.
Счета пользователей отражают текущий баланс пользователей. Информация, сохраняемая в счетах пользователей включает в себя:
Транзакции хранят историю всех операций, произведенных по счетам пользователей. Информация, сохраняемая в транзакциях включает в себя:
Заказы содержат всю информацию о поступающих, активных и уже завершенных заказах. Информация, сохраняемая в заказах включает в себя:
Здесь содержатся все предложения поступающие от пользователей. Информация, сохраняемая в предложениях включает в себя:
* Кардинальность — тип связи (1:M — один ко многим, M:N — многие ко многим).
** Показатель участия — обязательность, необязательность наличия данной связи для каждого кортежа (строки) сущности (таблицы) (P — частичное участие в связи, T — полное участие в связи).
В итоге получилась схема, связывающая структуры БД с приложениями Django Framework
На этом собственно и завершилось проектирование проекта, после чего более не осталось сил и терпения проектировать дальше, и я принялся за написание кода в Django Framework.
Виды
Всё началось с вида домашней страницы. Она должна была давать краткое представление о проекте, и содержать шапку страницы (логотип, слоган, навигация, кнопки логина и регистрации), плюс я решил что будет полезным отображать на главной странице непосредственно заказы с кратким описанием и ценой.
В итоге получился документ, состоящий из 15 видов, которые легли в основу дизайна сайта. Что из этого вышло, можно посмотреть непосредственно на сайте, но для того чтобы почувствовать разницу между тем, что проектировалось, и тем что получилось приведу еще несколько основных видов.
Вид «Мои заказы»
Вид «Мой заказ»
Вид «Мой счёт»
Требования к данным
В этом документе были приведены основные требования к данным.
1 Профили пользователей
Для хранения личных настроек пользователей служит стандартная таблица Django User.
2 Счета пользователей
Счета пользователей отражают текущий баланс пользователей. Информация, сохраняемая в счетах пользователей включает в себя:
- Количество средств на счету
- Валюта счёта (возможно понадобится в будущем, по умолчанию USD)
3 Транзакции
Транзакции хранят историю всех операций, произведенных по счетам пользователей. Информация, сохраняемая в транзакциях включает в себя:
- Дата
- Тип
- Сумма
- Статус
- Заметка
4 Заказы
Заказы содержат всю информацию о поступающих, активных и уже завершенных заказах. Информация, сохраняемая в заказах включает в себя:
- Описание
- Ключевые слова заказа
- Ограничения
- Дополнительно
- Цена
- Статус
- Дата создания
- Дата изменения
- Язык (чтобы потом при переводе учитывать это при показе)
5 Предложения
Здесь содержатся все предложения поступающие от пользователей. Информация, сохраняемая в предложениях включает в себя:
- Предложение
- Статус
- Дата создания
- Дата изменения
6 Типы сущностей
- Профиль
- Счёт
- Транзакция
- Заказ
- Предложение
7 Типы связей
Тип сущности | Связь | Тип сущности | Кардинальность* | Показатель участия** |
---|---|---|---|---|
Профиль | Имеет | Счёт | 1:M | T:T |
Счёт | Имеет | Транзакция | 1:M | P:T |
Профиль | Имеет | Заказ | 1:M | P:T |
Профиль | Имеет | Предложение | 1:M | P:T |
Заказ | Имеет | Предложение | 1:M | P:T |
* Кардинальность — тип связи (1:M — один ко многим, M:N — многие ко многим).
** Показатель участия — обязательность, необязательность наличия данной связи для каждого кортежа (строки) сущности (таблицы) (P — частичное участие в связи, T — полное участие в связи).
В итоге получилась схема, связывающая структуры БД с приложениями Django Framework
На этом собственно и завершилось проектирование проекта, после чего более не осталось сил и терпения проектировать дальше, и я принялся за написание кода в Django Framework.