61
Для всех / Re: Концептуальная модель предметной области
« : 18 Июня 2016, 21:38:38 »
Правильно ли я понимаю, что в данной модели нет необходимости указывать какие-либо справочники? важны основные классы?
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Декомпозиция на отдельные сценарии - это очень правильный подход. Просто автор темы начал сразу с ДД, а следовало бы с описания. Описание естественно соединяется в конечную ДД, но обрабатывать и описывать ее лучше такими сценариями, что вы предложили.
Тут только нужно очень аккуратно работать с предусловиями и постусловиями. Т.е. например вы завершаете основной сценарий переходом к UC5, но по идее к чему приводит UC3?
Что будет по завершению UC3, проблемах в UC5, может быть UC5 исполнен отдельно?
На диаграмме есть лишний поток управления от "удалить товар" к "оформлению заказа".1. Лишний поток убрал, не заметил сразу, спасибо.
Пока клиент не зарегался / не авторизовался, не ясно как определить были ли у него раньше покупки или нет. Разумно предложить клиенту авторизоваться либо зарегаться и после его выбора выводить нужную форму.
Не вижу смысла сначала вводить адрес доставки, а затем выбирать её способ. Например, если способ = самовывоз, может не понадобится вводить адрес. Вероятно, следует поменять местами, либо объединить.
У диаграммы лишь одни финальный узел, т. е. у ВИ лишь один возможный исход -- успешное оформление заказа. Заказ нельзя отменить, авторизация всегда успешна, регистрация всегда успешна. Разумно показать на диаграмме неуспешные завершения и альтернативные потоки, ведущие к ним.
Нигде нет сторожа, проверяющего, что заказ оформляется по непустой (после удалений товаров) корзине. Аналогично, нет сторожа для удалений из пустой корзины.
вертикально и с двумя левыми и правыми ветками.мм..это выпускная работа, поэтому получается, что я заранее знаю как будет система работать.
Что значит по факту? по какому факту, вы требования описывает или то как сейчас работает система? если как сейчас - это одно, если придумываем, то это может быть навязыванием решения. кмк
1. Зачем вообще понадобилась дорожка "Клиент"?1. На дорожки разделил, чтобы было видно работу клиента и системы. Как сделать одной дорожкой, не могу представить себе, если честно (
Активности типа "Ввод данных для регистрации" и "Отображение формы регистрации" я бы объединил во что-то типа "Ввод регистрационных данных в форму регистрации".
Насколько я вижу, все активности на диаграмме сейчас образуют такие пары. Т.е. никакого дополнительного смысла от такого разделения не проявляется. Диаграмма упростилась бы.
Если уж и делать дорожки, то по формам это было бы понятнее. Т.е. будет дорожка "Магазин", "Корзина", "Оформление заказа", "Авторизация", "Регистрация".
2. "Заказ отправлен на исполнение" звучит как состояние, а не как активность. Нужно по другому назвать.
3. В алгоритме пропущено много веток. Что например будет, если клиент не успешно авторизовался?
В отображение формы заказа входят две стрелки, я бы тоже тут обыграл с помощью мердж и структурно бы более явно выделил условный выбор.Что значит более явно выделить условный выбор?
И я бы не стал при отказе оформления заказа возвращать клиента в виртуальную корзину - проще завершить ВИ заказа.
Даниил,
1. первая точка принятия решения ведет к одному и тому же действию, какой смысл в разделение веток?
2. в "отображение содержимого корзины и стоимости" входит 3 стрелки, это не очень верно, поскольку, чтобы решить сливаются ли три разных параллельных потока или это просто передача управления из разных мест можно понять, только просмотрев всю диаграмму. Т.е. было бы полезно разместить тут merge - пр и этом алгоритмически там цикл, пока происходит редактирование корзины (удаление товаров из корзины) - пересчитывать отображеие содержимого корзины и стоимости.
3. около начального псевдосостояния я бы поместил текст предусловия
4. около конечный псведостостояний я бы разместил текст постусловий
5. Отмена выполнения заказа может возникнуть сразу как только вы начали оформлять заказ
Все исключения и альтернативные потоки можно изображать на этой диаграмме, хотя частично у вас это и делается.
Если говорить содержательно, то у вас, во-первых, ошибка по условию "клиент выбирает опцию оформить заказ".1. Перенес условие после опции "оформить заказ" к клиенту. Думаю так верно. На форме отображается выбор, например "Я уже совершал покупки" и "Это моя первая покупка". Соответственно исходя из выборка клиента будет отображена определенная форма.
Непонятно, как вы определите, совершал ли ранее клиент покупки, если он ещё не авторизован.
Ну и деление каждой операции на две части "отобразить форму" - "заполнить форму" обычно не нужно. Хотя, конечно, всё зависит от того, как и кто эту диаграмму будет потом использовать.
Не совсем так.Я надеюсь, что не обязательно ставить расширение на диаграмме "проверка ввода данных при регистрации", а то точно будет много мусора.
Расширение, это другая взаимосвязь между кусками текста. Это когда в тексте UC1 даже не упоминается UC2. А UC2 знает\ссылается на UC1 и активизируется при определённых условиях в UC1. Классический пример UC1 "Редактирование текста", UC2 "Проверка правописания". UC1 даже не упоминает UC2. В UC2 написано что-то вроде "активизируется в случае если в UC1 возникла синтаксическая ошибка " и далее в нём описывается в как проверка правописания должна выглядеть для пользователя.
Расширение это не про повторное использование кусков текста. Это скорее про опциональные возможности или про то как описать новую функциональность системы, не пересогласовывая старую спеку.
С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".