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

×


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

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


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

Страницы: « 1 2 3 4 5 6 »
61
Правильно ли я понимаю, что в данной модели нет необходимости указывать какие-либо справочники? важны основные классы?

62
Спасибо за ответы и советы.
Однако если модель преподавателя более-менее верная, то чем она отличается в итоге от логической и физической модели БД. По сути только поля обозначены русским языком и все.

63
Добрый день.
Прошу помочь сделать концептуальную модель предметной области или по-крайней мере объяснить как она делается.
Разобраться не могу толком так как у меня есть пример преподавателя и есть пример из интернета, и они скажем так отличаются очень. В итоге как правильно делать я так и не понял. А в Visio вообще не нашел шаблона концептуальной модели предметной области.
Делаю я интернет магазин по продаже постельного белья. Соответственно покупатель заходит ищет нужный товар, далее происходит оформление товара, а администратор магазина может просматривать заказы и проставлять статусы (новый заказ, в обработке и т.д.)
Ниже примеры от преподавателя и из интернета.

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

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

Что будет по завершению UC3, проблемах в UC5, может быть UC5 исполнен отдельно?

Я начал делать с диаграммы вариантов использования. К базовым ВИ напиал спецификации. И по ВИ "Оформление заказа" теперь делаю диаграмму деятельностей.
Я в начале темы написал, что делаю по спецификации данную диаграмму, а не просто из головы.
Единственное, что сюда не выложил ее.

65
На диаграмме есть лишний поток управления от "удалить товар" к "оформлению заказа".
Пока клиент не зарегался / не авторизовался, не ясно как определить были ли у него раньше покупки или нет. Разумно предложить клиенту авторизоваться либо зарегаться и после его выбора выводить нужную форму.
Не вижу смысла сначала вводить адрес доставки, а затем выбирать её способ. Например, если способ = самовывоз, может не понадобится вводить адрес. Вероятно, следует поменять местами, либо объединить.
У диаграммы лишь одни финальный узел, т. е. у ВИ лишь один возможный исход -- успешное оформление заказа. Заказ нельзя отменить, авторизация всегда успешна, регистрация всегда успешна. Разумно показать на диаграмме неуспешные завершения и альтернативные потоки, ведущие к ним.
Нигде нет сторожа, проверяющего, что заказ оформляется по непустой (после удалений товаров) корзине. Аналогично, нет сторожа для удалений из пустой корзины.
1. Лишний поток убрал, не заметил сразу, спасибо.
2. Клиент сам определяет были у него покупки или нет. На форме "оформление заказ" будет такой выбор. Далее клиент один из вариантов выбирает и т.д.
3. Доставка. Сначала ввод адреса, потому что исходя из адреса будет выдаваться способ доставки. Например если по такому-то адресу нет курьерской доставки, на форме она и не появится. Если наоборот сделать, то после того как клиент ввел адрес, а на него нет курьерской доставки, выдавать ошибку и возвращать к выбору доставки.
Если смотреть, как я сделал, сначала адрес, а потом способ доставки, то даже при самовывозе, адрес моно просто не учитывать потом, а внести его в базу как и контактные данные, вдруг клиент потом решит еще раз заказать и не самовывозом, а тут раз и все автоматом заносится.
4. Альтернативные потоки я сделаю чуть позже, я про них помню )) Сейчас пока преподаватель принял как есть (не думаю что он вообще проверял что-то). А вот когда буду пояснительную записку писать, обязательно учту альтернативные потоки.
Кстати вопрос по альтернативным потокам: отказаться от оформления заказа можно в любой точке в момент его оформления, получается будет много много стрелок к возврату в корзину...

66
вертикально и с двумя левыми и правыми ветками.

Что значит по факту? по какому факту, вы требования описывает или то как сейчас работает система? если как сейчас - это одно, если придумываем, то это может быть навязыванием решения. кмк
мм..это выпускная работа, поэтому получается, что я заранее знаю как будет система работать.

67
1. Зачем вообще понадобилась дорожка "Клиент"?
Активности типа "Ввод данных для регистрации" и "Отображение формы регистрации" я бы объединил во что-то типа "Ввод регистрационных данных в форму регистрации".
Насколько я вижу, все активности на диаграмме сейчас образуют такие пары. Т.е. никакого дополнительного смысла от такого разделения не проявляется. Диаграмма упростилась бы.

Если уж и делать дорожки, то по формам это было бы понятнее. Т.е. будет дорожка "Магазин", "Корзина", "Оформление заказа", "Авторизация", "Регистрация".

2. "Заказ отправлен на исполнение" звучит как состояние, а не как активность. Нужно по другому назвать.

3. В алгоритме пропущено много веток. Что например будет, если клиент не успешно авторизовался?
1. На дорожки разделил, чтобы было видно работу клиента и системы. Как сделать одной дорожкой, не могу представить себе, если честно (
2. Назову "Отправка заказа на исполнение".
3. Да, ветки пропущены, это альтернативные потоки...если каждый учесть то места не хватит...нужно тогда как-то диаграмму разделить.

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

69
Попробовал со слиянием.
Прошу еще раз посмотреть, оценить правильность.

70
Вот исправленный вариант.

71
Даниил,

1. первая точка принятия решения ведет к одному и тому же действию, какой смысл в разделение веток?
2. в "отображение  содержимого корзины и стоимости" входит 3 стрелки, это не очень верно, поскольку, чтобы решить сливаются ли три разных параллельных потока или это просто передача управления из разных мест можно понять, только просмотрев всю диаграмму. Т.е. было бы полезно разместить тут merge - пр и этом алгоритмически там цикл, пока происходит редактирование корзины (удаление товаров из корзины) - пересчитывать отображеие содержимого корзины и стоимости.
3. около начального псевдосостояния я бы поместил текст предусловия
4. около конечный псведостостояний я бы разместил текст постусловий
5. Отмена выполнения заказа может возникнуть сразу как только вы начали оформлять заказ

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

1. Случайно не в то действие стрелку выбора направил. Исправил теперь. Спасибо за внимательность.
2. Merge это я так понимаю слияние ? Оно в MS Visio выглядит так же как и "выбор решения". Единственное, что у него наверное будет один выход а входов несколько, обратное действие то есть "решению". Только вот в нем только 4 точки куда можно сделать вход/выход, а что если у меня больше входов будет?
3,4. Сделал комментарии.
5. Да, отмена заказа по сути в любое время может быть. Я решил на диаграмме ее изобразить только один раз в самом конце, иначе целая куча еще будет стрелок и "решений".

72
Если говорить содержательно, то у вас, во-первых, ошибка по условию "клиент выбирает опцию оформить заказ".
Непонятно, как вы определите, совершал ли ранее клиент покупки, если он ещё не авторизован.
Ну и деление каждой операции на две части "отобразить форму" - "заполнить форму" обычно не нужно. Хотя, конечно, всё зависит от того, как и кто эту диаграмму будет потом использовать.
1. Перенес условие после опции "оформить заказ" к клиенту. Думаю так верно. На форме отображается выбор, например "Я уже совершал покупки" и "Это моя первая покупка". Соответственно исходя из выборка клиента будет отображена определенная форма.
2. На две части все поделено потому как отображается запрос клиента и ответ системы и наоборот. Не знаю честно говоря как объединить это в одно действие, а было бы не плохо, а то диаграмма уж очень большая становится.

73
Доброго времени суток  :) 
Сделал диаграмму деятельности для Варианта использования "Оформление заказа" в интернет-магазине.
Делал я ее по спецификации диаграммы вариантов использования.
Подскажите, пожалуйста, нормальная ли она, а то по смыслу она мне кажется похожей на диаграмму последовательностей уже.
И если все же верно, то нужно ли из спецификации брать в эту диаграмму альтернативные потоки?

74
Конечно входит, еще ночь впереди, буду писать теперь и их тоже)) А потом и другими диаграммами займусь.
Спасибо большое за помощь, многое разъяснили.

75
Не совсем так.

Расширение, это другая взаимосвязь между кусками текста. Это когда в тексте UC1 даже не упоминается UC2. А UC2 знает\ссылается на UC1 и активизируется при определённых условиях в UC1. Классический пример UC1 "Редактирование текста", UC2 "Проверка правописания". UC1 даже не упоминает UC2. В UC2 написано что-то вроде "активизируется в случае если в UC1 возникла синтаксическая ошибка " и далее в нём описывается в как проверка правописания должна выглядеть для пользователя.
Расширение это не про повторное использование кусков текста. Это скорее про опциональные возможности или про то как описать новую функциональность системы, не пересогласовывая старую спеку.

С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".
Я надеюсь, что не обязательно ставить расширение на диаграмме "проверка ввода данных при регистрации", а то точно будет много мусора.

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