Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Даниил

Страницы: « 1 2 3 4 5 6 »
16
1) Код пользователя изменил, спасибо за бдительность.
2) В физической модели будет указано как связана таблица Элемент заказа с товаром и заказом, это будет ключ, который и первичный и внешний. Я видимо не правильно решил, что в этой модели нет необходимости указывать вторичные ключи?
Иначе во всех таблицах нужно будет указать их.
3) Красненькое это первичный ключ я обозначил так (помимо PK) чтобы выделялся )) А в таблице Элемент заказа, уже выше написал что не указал, потому как он еще и вторичный.
4) А там где я делал эту модель, только куриные лапки, мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.

17
Категорию оставляю, так как это одновременно ткань из которой делается товар.
Стоимость в заказ добавляю.

Ну, спустя страниц, думаю эту тему можно закрыть =))

Спасибо всем за помощь большое.

18
Как-то так получается.
Я в модель еще сущность "категория" добавил, вот по нему у меня правда есть сомнения что это бизнес-объект.
Еще вопросы:
1) правильно ли я связи указываю? Потому что начитался про связи и уже запутался, каких только не бывает.
2) Для сущности Вид доставки, мне теперь как и с продуктом нужно добавить сущность ведь так? Иначе опять с ценой косяк будет.

19
Безусловно. Элементы заказа обычно называют  OrderLines или OrderDetails. Ну и производителя лучше выделить в отдельную сущность. И если предусмотрена возможность добавления новых видов упаковки, тоже в отдельную сущность.

И если захочется хранить историю цен (не только текущую цену, но и ту , которая была на товар 3,5 или 10 дней назад) то и ее тоже
Таблицы упаковка, производитель и размеры у меня в БД есть отдельно. Я думал в концептуальной модели они не важны.
Получается все таблицы надо сюда из БД.

20
Что у пианиста радует, так это наличие некоторой системы в разработке.  Но никак не могу понять, почему концептуальная модель появилась на финальной стадии ?

Ведь все что нужно для ее разработки - это понятия. Провести интервью, почитать литературу. Не требуется ни фиксация бизнес-процессов, ни разработанные варианты использования. Даже не нужны уточненные требования к системе - построение КМ это практически лингвистическое упражнение.

Причем пропуск разработки КМ это скорее норма, чем исключение.
Почему пианист ? ) И с кем проводить интервью?

Объясняю почему сначала сайт, а потом диаграммы.
Потому что за время моего обучения в институте, мы раза 2 делали эти диаграммы, и оба раза нам толком не объясняли и на зачет или экзамен принимали кривые диаграммы (непонятно что).
Ни кто толком не объяснил зачем, для чего и почему сначала диаграмму, а потом проект. Что так логичней, что так проще потом будет сам проект делать.
В итоге у меня и всех моих одногруппников сложилось мнение, что главное сделать программу (или сайт), а уж диаграммы то нарисуем как-нибудь.
Но тут выпускная квалификационная работа. Как обычно делаю сначала сайт, а потом остальное. И тут на тебе, оказывается, что на защите мой сайт даже смотреть ни кто не будет, даже не проверит работает ли он. Главное это презентация, в которой будут диаграммы и пара скринов с сайта.
А в пояснительной записке главное не содержание (за исключением диаграмм конечно), главное чтобы по ГОСТу все было, чтобы таблицы правильно названы были, чтобы интервал полуторный и т.д. и т.п.
Вот так у нас выпускают программистов с высшим образованием.

21
Я ближе к цели ? =)

22
Я топикстартера уже четвертую страницу к этому подталкиваю :) Но похоже только чувство голода заставляет присматриваться к предметной области настоящих програмистов :) Менее активные раздражители не способны заставить их поступиться уже написанным кодом:)
Да, при построении моделей я исхожу из уже существующей БД и кода.
Ели я в концептуальной модели выделю отдельный класс, мне же придется и дальше менять саму бд правильно ведь?

23
Типичная ошибка студентов.
Вы строите концептуальную модель. КМ - это понятия предметной области и отношения  между ними. Отношения - это ограничения, зависимости, связанности одного понятия к другому.

Есть понятие - Клиент. Он делает Заказы Товаров. Заказ обрабатывается определенным Администратором, хотя странное понятие для такой предметной области, скорее уже Оператор заказа, Менеджер заказа, Исполнитель заказа.

Заказ сам по себе себя не определяет, он определяется через свою связь с Клиентом. Именно Клиент идентифицирует (определяет) Заказ.

Товар - тут посложнее. Товар - это абстрактное понятие. У вас по сути Товар - это экземпляр товар. Конкретная продаваемая единица. Это нормально работает со штучным товаром, хотя из каталога Вы выбираете не конкретный товар - а обобщенное описание этого товара.

При это Вы не первый, кто моделирует подобные предметные области, и даже не второй, ну может быть какой-нибудь 10миллионный.

http://www.databaseanswers.org/data_models/
У меня же есть связь клиента с заказом. Один ко многим.
По поводу того что у меня Администратор обрабатывает заказ это да, необычно, и естественно в реальном интернет магазине такого не будет. Но в моем случае пуст будет один администратор он же менджер, который и товары добавляет и за заказами следит.

24
Согласно Вашей диаграмме ВИ (прежней её версии) авторизация обязательно происходила при оформлении заказа (связь включения между ВИ). Вместо 3-х тем, каждая из которых про отдельный тип диаграмм, удобнее было бы иметь одну тему по всей Вашей модели. Диаграммы и описания (части модели) должны подходить друг к другу, иначе целостной модели не получится. Отвечать, Вам отслеживая изменения в одной модели, разбросанные по трём темам, затруднительно.
Извиняюсь, я думал наоборот надо разделить, так как разные диаграммы.
и плюс они были начаты в разное время, просто потом перерыв был и сейчас я продолжил.

25
Для всех / Re: UCD для интернет-магазина
« : 20 Июня 2016, 21:23:40 »
И снова я изменил диаграмму.
ВИ регистрация как цель никому не нужен, поэтому и ассоциацию с акторами я убрал опять.
Сделал ВИ регистарция, расширением к ВИ Оформление заказа.
ВИ оформление заказа может прекрасно работать и без ВИ регистрация (когда пользователь авторизирован),
но при определенных условиях, а именно пользователь не авторизирован, срабатывает ВИ регистрация.

Надеюсь что верно.

26
Медом не медом, а жизнь себе хотят упростить созданием сущностей типа "всякая хрень, о которой мне лениво думать,  пока проблема себя не обозначила". Всякие там "универсальные справочники", "универсальные классификаторы" - топикстартер норовит в эту помойку аж поставщиков засунуть.

А когда начинаются проблемы с ссылочной целостностью, интерпретационными свойствами,  производительностью поиска оказываются почему -то виноваты аналитики
У меня нет универсального справочника типа поставщиков...для поставщика, а точнее производителя у меня отдельный справочник brand, в котором есть только поля id и name.
Проблема у меня с полем products в таблице заказов, в нем сразу id товара и количество. Да, сейчас я понимаю, что это криво и возможно следовало бы сделать отдельную таблицу заказанных товаров, в которой указать товар, количество и стоимость.
Однако делал интернет-магазин по видео-урокам, и там был именно такой способ. Времени изменять что-либо к сожалению не осталось.
К слову я немного изменил концептуальную модель, правда думаю что все равно не верно...
Я разделил сущность пользователь, на две сущности: клиент и администратор.

27
Вы же сами предлагаете использовать отдельный ВИ авторизации - т.е. лучше написать Клиент выполняет ВИ Авторизация в системе.
Тогда все исключения, связанные с авторизацией, будут записаны отдельно, и нет нужды перегружать этот.
Клиент может и не авторизироваться для оформления заказа.
пункт 7.2 подразумевает не ввод данных для авторизации, а ввод контактных данных (им, телефон, почта) для оформления заказа и последующей регистрации.

28
Продолжение...
Я изменил диаграмму.
1) Как адекватно прописать альтернативные потоки на ввод корректных данных? В спецификации у меня на ввод имени, телефона и почты отдельные альтернативные потоки. На диаграмме их также отдельно указывать или можно просто написать проверка ввода данных?
2)
В языке есть средства, чтобы обойтись одной стрелкой.
Я так понял что пунктиром обводятся все действия, к которым есть общий альтернативный поток и отдельно этот альтернативный поток для них прописывается. Только я в visio не нашел таких объектов ((
Поэтому пока нет на диаграмме альтернативного потока "отмена заказа".
3) Может ли быть на диаграмме два окончания? Сейчас у меня одно окончание - это оформление заказа. А второе может быть как раз "отмена заказа", так как пользователь отменяет заказ путем перехода на любую страницу сайта (в корзину, в каталог, на главную и т.д.) При этом товары в корзине конечно останутся и пользователь зайдя в корзину может начать заново оформление заказа, но это уже совсем другая история =)
4) Во вложении диаграмма и ниже спецификация.

ID: 2.
ВИ: Оформление заказа.
Краткое описание: Оформление заказа на покупку товара в интернет-магазине.
Основное действующее лицо: Клиент.
Второстепенные действующие лица: нет.
Предусловия:
В корзине клиента присутствуют товары.
Постусловия:
1.   Система автоматизации торговли получила заказ.
2.   Клиент зарегистрирован в системе.
3.   Система отправила клиенту письмо с информацией о его заказе.
Основной поток:
1.   ВИ начинается, когда клиент входит в виртуальную корзину.
2.   Система отображает содержимое виртуальной корзины клиента и стоимость.
3.   Если клиент выбирает опцию «Удалить товар».
3.1. Система удаляет отмеченные товары из корзины.
3.2. Система пересчитывает стоимость содержимого корзины.
4.   Клиент выбирает опцию «Оформить заказ»
5.   Система отображает форму оформления заказа.
6.   Если клиент авторизирован в системе.
6.1. Система заполняет поля с контактными данными клиента из БД.
7.   Если клиент не авторизирован.
7.2. Клиент осуществляет ввод необходимых контактных данных.
8.   Клиент вводит адрес доставки и выбирает способ доставки.
9.   Клиент подтверждает оформление заказа.
10.   Система отправляет заказ на исполнение.

Альтернативные потоки:
10.1. Клиент ввел имя короче 2-х символов.
10.1.1. Система сообщает пользователю, что необходимо ввести имя не короче 2-х символов.
10.2. Клиент ввел не корректный e-mail.
10.2.1. Система сообщает пользователю, что адрес электронной почты должен содержать символ “@”.
10.3. Клиент ввел уже зарегистрированный e-mail.
10.3.1. Система сообщает клиенту, что пользователь с таким e-mail уже зарегистрирован в системе, и предлагает пройти процедуру авторизации.
10.4. Клиент ввел не корректный номер телефона.
10.4.1. Система сообщает пользователю, что необходимо ввести номер телефона по маске ввода.
10.5. Возврат к пункту 6.
10.6 Клиент отменяет заказ.
10.6.1. Происходит переход на страницу, выбранную клиентом.
 

29
Для всех / Re: UCD для интернет-магазина
« : 20 Июня 2016, 09:47:36 »
Немного изменил диаграмму.
Аутентификацию заменил на авторизацию (почитал в чем разница =) )
Авторизация теперь является расширением оформления заказа. Ведь клиент может и пройти авторизацию и не проходить ее для оформления заказа. Для управления каталогом и заказами она так и осталась включением, потому как не пройдя авторизацию не зайти в админку.
А вот как быть с регистрацией я не знаю, на диаграмме однозначно не верно. По уму она должна включаться в оформление заказа из-за того что при оформлении у меня происходит и регистрация (если пользователь не авторизирован). И отсюда следует, что и включение не совсем верно, ведь оно означает, что данный ВИ будет обязательно выполнен, но это не так, ведь если клиент ранее прошел авторизацию, то регистрации не произойдет

30
Возьмите исходную постановку и все ваши другие диаграммы и проверьте , достаточно или нет. И разберитесь с хранением количества и цены в заказе

В ER нет такого понятия - справочник. Есть сущности и отношения между ними.

На этом я самоустраняюсь. Информации Вам предоставлено более чем достаточно

Большое Вам спасибо за разъяснения и потраченное на меня время.

Страницы: « 1 2 3 4 5 6 »