Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Даниил от 11 Мая 2016, 16:05:49
-
Добрый день.
Прошу помочь составить диаграмму вариантов использования.
Набросок есть во вложении.
О работе ИМ:
1) есть пользователь. он может просмотреть каталог товаров и искать товары по каким-либо критериям. Выбрав подходящие товары в корзину, он может в нее войти и оформить заказ. При оформлении заказа необходимо внести данные о клиенте, адрес доставки, способ доставки.
На сайте есть регистрация для клиента, однако ее производить при входе на сайт не обязательно, можно сделать это во время оформления заказа (при вводе всех данных, соответственно происходит и регистрация одновременно).
2) есть контент-менеджер или администратор сайта. Он соответственно занимается изменением, удалением и добавлением товара на сайт. Для того, чтобы войти в админку он должен пройти авторизацию, однако регистрацию он не производит. Ему пароль, так сказать, выдается.
На ДВИ есть ВИ "аутентификация". У этого ВИ ассоциация с обоими актерами (клиент и администратор). Я не могу придумать как сделать ВИ регистрация. Хотел сделать его инклюдом к аутентификации, но тогда это будет означать, что и администратор, перед аутентификацией должен регистрацию пройти, а этого у меня нет (как указано было выше, администратору пароль выдается).
Ну и в целом в диаграмме у меня сомнения.
-
Вам нужно нарисовать ДВИ для реального проекта, или это учебное задание?
-
Это выпускная работа, которая я надеюсь будет реальным проектом
-
Если реальный, то рекомендую пройтись по чек-листу:
https://habrahabr.ru/company/sibirix/blog/224627/
На вашей схеме, как минимум, непонятно, кто оформляет заказ - этот кейс повис в воздухе.
-
Если пока опустить само оформление заказа, подскажите пожалуйста правильно ли я сделал включения, а то мне подсказывают что стрелки в другую сторону должны быть ( Но я думаю что так как у меня..
-
1. Стрелочка от "Добавление товара" к "Управление каталогом" идёт в неправильном направлении (как и остальные стрелочки к "Управлению каталогом").
2. Это, конечно, дискуссионный вопрос, но "Аутентификацию" я бы поставил как расширение или включение к "Оформлению заказа" или "Управлению каталогом", как самостоятельный юзкейс она режет глаз. У клиента, обычно, нет самостоятельной цели аутентифицироваться, у него есть цель оформить заказ или поискать товар.
-
1. Стрелочка от "Добавление товара" к "Управление каталогом" идёт в неправильном направлении (как и остальные стрелочки к "Управлению каталогом").
2. Это, конечно, дискуссионный вопрос, но "Аутентификацию" я бы поставил как расширение или включение к "Оформлению заказа" или "Управлению каталогом", как самостоятельный юзкейс она режет глаз. У клиента, обычно, нет самостоятельной цели аутентифицироваться, у него есть цель оформить заказ или поискать товар.
1. Не понимаю почему стрелки неправильно (( ведь чтобы добавить товар, нужно обязательно зайти в управление каталогом.
2. Полностью согласен, что у клиента нет цели аутентифицироваться. Я как раз выше и написал что не знаю как это сделать толком. А вот у админа есть цель аутентифицироваться, ведь без этого он не войдет в админку. А как сделать по-человечески не знаю.
-
Вот так переделал.
Не знаю почему надо менять в управлении каталогом стрелки, но раз уж все говорят что так верно.
Аутентификацию тоже переделал, думаю так должно быт правильно. Только регистрацию ведь для пользователя надо добавить туда как-то, или это можно опустить?
-
Не понимаю почему стрелки неправильно (( ведь чтобы добавить товар, нужно обязательно зайти в управление каталогом.
Последовательность действий клиента вообще никак не отображается в UCD.
Направление стрелки это просто синтаксис. Грубо говоря, направление стрелки показывает какой юз-кейс на какой ссылается (упоминает). Включаемые юзкейсы упоминаются в во включающем.
Думаю, забыта связь между клиентом и поиском товара. Клиент же может искать товар, не делая заказ?
-
Инклюд же означает что базовый ВИ выполнится только после включаемого ВИ, разве нет?
Да, связь с поиском товара я не поставил целенаправленно. Ведь подразумевается, что основная цель клиента купить товар, а если он зашел поглазел и вышел, это можно поставить как альтернативу оформлению, когда спецификации писать буду.
Переделал по-другому все. Правда у меня получается при оформлении заказа аутентификация а не регистрация...регистрацию куда засунуть не знаю..
-
Инклюд же означает что базовый ВИ выполнится только после включаемого ВИ, разве нет?
Нет это не так. Понятий "до" и "после" в UCD не может быть. Овал UC на UCD, с одной стороны это цель Актора относительно Системы, а с другой стороны, простое текстовое описание того как Актор добивается этой цели (его на UCD нет, оно лежит в документе UC Specification). Куски описаний, которые используются повторно во многих UC иногда выносят в отдельный UC. Чтобы обозначить на UCD что текст UC1 использует\ссылается на текст UC2 используется стрелочка "включает" от UC1 к UC2. Т.е. вся UCD и все эти стрелочки просто наглядно изображают какие есть куски текста (в UC Specification) и связь между этими кусками текста.
Да, связь с поиском товара я не поставил целенаправленно. Ведь подразумевается, что основная цель клиента купить товар, а если он зашел поглазел и вышел, это можно поставить как альтернативу оформлению, когда спецификации писать буду.
Ну это ваш магазин, хозяин барин :) Я под поиском товара имел в виду, то что делает клиент придя в незнакомый магазин - смотрит какие товары есть, какие у них характеристики, какие цены. В т.ч. ищет нужные ему товары. Это совершенно другой клиентский опыт, чем оформление заказа.
Переделал по-другому все. Правда у меня получается при оформлении заказа аутентификация а не регистрация...регистрацию куда засунуть не знаю..
Можно совместить с аутентификацией для простоты. Т.е. будет юзкейс "Аутентификация или регистрация". Можно и отдельным юз-кейсом.
-
Если реальный, то рекомендую пройтись по чек-листу:
https://habrahabr.ru/company/sibirix/blog/224627/
На вашей схеме, как минимум, непонятно, кто оформляет заказ - этот кейс повис в воздухе.
А если только на выпускную работу? можно обойтись без продавца? Боюсь не осилю за месяц все это. Это ведь нужна отдельная панель и для контент-менеджера/администратора и для продавца.
P.S. спасибо за ссылку, почитал, каши в голове стало поменьше.
-
1. Последняя версия диаграммы стала несколько захламлённой. Это из-за того, что в ней смешаны UC совершенно разного уровня детальности\абстракции.
Осталось только добавить UC "Закрыть окно браузера" и поставить стрелочки "включает" к нему от остальных UC на диаграмме (это сарказм :) ).
Я бы для уменьшения "захламлённости" объединил бы UC "Добавление" "Изменение" и "Удаление" товара, а может и вообще бы их убрал с диаграммы. Повторно они никем не используются. В чём был смысл их выделять?
2. Стрелочками "расширить" вы пользуетесь неправильно. Они пока не нужны на вашей диаграмме. Как вы себе представляете текст UC "Удалить товар" расширяющий UC "управление каталогом"?
-
Я теперь запутался весь =(
Выделил Удаление Изменение и Редактирование, потому что администратор заходит в управление каталогом и может выбрать одно из этих действий, а может и не выбрать вообще.
Я уже еще обновил диаграмму и она стала еще более захламленной.
В оформление у меня входит аутентификация, но клиент не процедуру аутентификации проходит при оформлении, а процедуру регистрации, при условии что ранее не был зарегистрирован. Я сделал включение Регистрацию, а к ней расширение...наверное не правильно опять.
-
1. Последняя версия диаграммы стала несколько захламлённой. Это из-за того, что в ней смешаны UC совершенно разного уровня детальности\абстракции.
Осталось только добавить UC "Закрыть окно браузера" и поставить стрелочки "включает" к нему от остальных UC на диаграмме (это сарказм :) ).
Я бы для уменьшения "захламлённости" объединил бы UC "Добавление" "Изменение" и "Удаление" товара, а может и вообще бы их убрал с диаграммы. Повторно они никем не используются. В чём был смысл их выделять?
2. Стрелочками "расширить" вы пользуетесь неправильно. Они пока не нужны на вашей диаграмме. Как вы себе представляете текст UC "Удалить товар" расширяющий UC "управление каталогом"?
Правильно ли я понимаю, что отношение "расширения" используется тогда, когда один ВИ уже где-то используется, и в то же время при определенных условиях может использоваться еще в одном ВИ ?
-
Начните с главного. Какие есть Акторы и какие у них цели относительно системы? Клиент, Администратор, Контент-менеджер?
Чего хочет клиент от системы? "Посмотреть товары в магазине" и "Оформить заказ"?. Чего хочет Администратор - "Управлять каталогом". Чего хочет контент-менеджер? Предположим "Редактировать описание товара".
Нарисуйте эти UC. В принципе, диаграмма готова. С ней всё нормально. Можно писать сами тексты UC.
Если хотите дать понять преподавателю, что освоили связь "включает", то
можно добавить Аутентификацию\Регистрацию как включённый UC для "Оформления заказа", "Управления каталогом", "Редактировать описание товара". "Редактировать описание" можно считать включённым кейсом для "Управление каталогом", а можно не считать - зависит от вашей бизнес-логики.
С этой диаграммой тоже всё ОК.
Вся путаница - от смешения UC разных уровней детальности в одной диаграмме.
Начните писать тексты UC и всё станет на свои места.
-
Правильно ли я понимаю, что отношение "расширения" используется тогда, когда один ВИ уже где-то используется, и в то же время при определенных условиях может использоваться еще в одном ВИ ?
Не совсем так.
Расширение, это другая взаимосвязь между кусками текста. Это когда в тексте UC1 даже не упоминается UC2. А UC2 знает\ссылается на UC1 и активизируется при определённых условиях в UC1. Классический пример UC1 "Редактирование текста", UC2 "Проверка правописания". UC1 даже не упоминает UC2. В UC2 написано что-то вроде "активизируется в случае если в UC1 возникла синтаксическая ошибка " и далее в нём описывается в как проверка правописания должна выглядеть для пользователя.
Расширение это не про повторное использование кусков текста. Это скорее про опциональные возможности или про то как описать новую функциональность системы, не пересогласовывая старую спеку.
С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".
-
Как-то так тогда получается (просто брал удаление, изменение и добавление). Правда у меня теперь "поиск" включается в "управление каталогом" однако, например, для добавления товара в каталог, поиск совершенно не нужен. Криво значит (
Администратор и контент-менеджер у меня одно лицо. Предполагаю, что еще будет продавец, который будет следить за заказами (просмотр статуса, изменение и т.п.)
Надеюсь, не страшно то, что я объединил таки регистрацию и аутентификацию...
-
Не совсем так.
Расширение, это другая взаимосвязь между кусками текста. Это когда в тексте UC1 даже не упоминается UC2. А UC2 знает\ссылается на UC1 и активизируется при определённых условиях в UC1. Классический пример UC1 "Редактирование текста", UC2 "Проверка правописания". UC1 даже не упоминает UC2. В UC2 написано что-то вроде "активизируется в случае если в UC1 возникла синтаксическая ошибка " и далее в нём описывается в как проверка правописания должна выглядеть для пользователя.
Расширение это не про повторное использование кусков текста. Это скорее про опциональные возможности или про то как описать новую функциональность системы, не пересогласовывая старую спеку.
С отношением расширения, вам пока лучше не связываться. Кажется Коберн, говорил что один раз только в жизни им пользовался на реальном проекте. Оно не сложнее включения, просто ваша задача решается и без него. Если есть очень большое желание - Авторизацию\Регистрацию можно описать как расширение для кейса "Оформить заказ".
Я надеюсь, что не обязательно ставить расширение на диаграмме "проверка ввода данных при регистрации", а то точно будет много мусора.
-
Как-то так тогда получается (просто брал удаление, изменение и добавление). Правда у меня теперь "поиск" включается в "управление каталогом" однако, например, для добавления товара в каталог, поиск совершенно не нужен. Криво значит (
Администратор и контент-менеджер у меня одно лицо. Предполагаю, что еще будет продавец, который будет следить за заказами (просмотр статуса, изменение и т.п.)
Надеюсь, не страшно то, что я объединил таки регистрацию и аутентификацию...
Диаграмма -ОК. Если бы был преподом - меня бы устроило.
В "Управлении каталогом" у вас спрятано и "добавление" и "удаление" и "правка". Т.к. удалению и правке поиск нужен, то стрелочка к поиску - ОК.
Надеюсь в вашу курсовую входит разработка самих текстов юзкейсов. Когда вы их напишите, то диаграмма для вас прояснится окончательно.
-
Конечно входит, еще ночь впереди, буду писать теперь и их тоже)) А потом и другими диаграммами займусь.
Спасибо большое за помощь, многое разъяснили.
-
Я надеюсь, что не обязательно ставить расширение на диаграмме "проверка ввода данных при регистрации", а то точно будет много мусора.
Чтобы корректно дойти до такого уровня детальности ваша диаграмма должна разрастить в объёме раз в 10. В неё тогда придётся включить и другие низкоуровневые подробности клиентского опыта. Не думаю, что это правильно для учебного проекта.
Не мусором такая стрелка была бы если бы весь ваш проект заключался в добавлении "проверки данных при регистрации" к уже существующей системе. Тогда это было бы очень к месту, чтобы показать место новой функциональности относительно существующей.
-
Диаграмма -ОК. Если бы был преподом - меня бы устроило.
А меня как реального препода эта диаграмма не устраивает по очень многим параметрам.
Тут есть некое заблуждение, что диаграмма первична. Она может быть первична и полезна, но только как визуальный инструмент набрасывания содержания проекта, отображения набора ВИ и тех, кто эти ВИ инициирует.
Далее должно следовать специфицирование ВИ и их анализ из которого, если будет так необходимо можно будь получить диаграмму, которую Даниил представил.
В диаграмме Даниила на мой взгляд есть неопределенности, вот они:
- то что представлено на диаграмме - это варианты использования цели пользователя, т.е. пользователь обращается к системе, чтобы решить какую-то важную для него задачу, например по управлению каталогом это означает добавить элемент, изменить имеющийся, удалить элемент
- отношение включение говорит мне (а я читаю схему, которая выполнена в определенной нотации и согласно определенному стандарту), что ВИ управления каталогом обязательно включает ВИ авторизации / регистрации, т.е. ВИ УК не будет полон без включения в него и исполнения шагов ВИ А/Р
- т.е. каждый раз когда мне требуется добавить/изменить/удалить какой-то элемент каталога, я должен авторизовать или регистрироваться вновь и вновь - ситуация возможная, но весьма странная
- ровно эти же рассуждения приведут меня и по ВИ оформление заказа, при этом если включение ВИ поиск заказа выглядит разумным, то ВИ А/Р явно нет.
- объединения Авторизации и регистрации вместе тоже довольно странное решение, так как постусловия сценария авторизации и регистрации различны. В одном случае открывается доступ согласно введенным данным авторизации, в другом создается новый объект - учетная запись
-
Эдуард, спасибо за участие в топике.
А меня как реального препода эта диаграмма не устраивает по очень многим параметрам.
...
то что представлено на диаграмме - это варианты использования цели пользователя, т.е. пользователь обращается к системе, чтобы решить какую-то важную для него задачу, например по управлению каталогом это означает добавить элемент, изменить имеющийся, удалить элемент
Если я правильно вас понял- то вы за то чтобы вернуть на диаграмму UC "Добавить товар", "Изменить товар", "Удалить товар".
Здесь, мне кажется, ситуация из разряда "на вкус и цвет". Думаю, в контексте учебного проекта, эти UC отлично упаковываются в большой UC "Управление каталогом".
Впрочем, если описание задачи из начального поста топика - это и именно та формулировка, которую дал Даниилу преподаватель, то этот преподаватель, возможно, в итоге ожидает увидеть картинку по принципу "по одному UC на каждый глагол из описания". Тогда надо добавлять ещё и другие UC типа "выбрать товар в корзину", "просмотреть каталог товаров" может даже "войти в корзину". И тогда стоит вернуть "Добавить", "Удалить", "Изменить".
Но это только гипотеза и начал я бы всё-таки с самого минимума UC. Мельчить - плохо (насколько я помню Коберна, он примерно то же самое говорил).
- отношение включение говорит мне (а я читаю схему, которая выполнена в определенной нотации и согласно определенному стандарту), что ВИ управления каталогом обязательно включает ВИ авторизации / регистрации, т.е. ВИ УК не будет полон без включения в него и исполнения шагов ВИ А/Р
- т.е. каждый раз когда мне требуется добавить/изменить/удалить какой-то элемент каталога, я должен авторизовать или регистрироваться вновь и вновь - ситуация возможная, но весьма странная
- ровно эти же рассуждения приведут меня и по ВИ оформление заказа, при этом если включение ВИ поиск заказа выглядит разумным, то ВИ А/Р явно нет.
Если я правильно понял, то вы клоните к тому, что <<include>> надо менять на <<extend>>, т.к. включённые UC выполняются всегда, а ту же авторизацию надо выполнять не всегда.
Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).
Даже погуглил на эту тему: http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html (http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html).
- объединения Авторизации и регистрации вместе тоже довольно странное решение, так как постусловия сценария авторизации и регистрации различны. В одном случае открывается доступ согласно введенным данным авторизации, в другом создается новый объект - учетная запись
Соглашусь. Текст объединённого UC для Авторизации и Регистрации будет уродливым. Это была плохая идея с моей стороны.
-
Если я правильно вас понял- то вы за то чтобы вернуть на диаграмму UC "Добавить товар", "Изменить товар", "Удалить товар".
Здесь, мне кажется, ситуация из разряда "на вкус и цвет". Думаю, в контексте учебного проекта, эти UC отлично упаковываются в большой UC "Управление каталогом".
Нет, нет. Вы меня не правильно поняли. Я вовсе за это не ратую. Использования шаблона CRUDL вполне себе оправдано для подобных UC, связанных общими предусловиями и постусловиями.
Более того, я читал только конечную диаграмму и все посты (ниже/выше - зависит от настрое отображения ленты) ее.
-
Если я правильно понял, то вы клоните к тому, что <<include>> надо менять на <<extend>>, т.к. включённые UC выполняются всегда, а ту же авторизацию надо выполнять не всегда.
Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).
Даже погуглил на эту тему: http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html (http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html).
Нет я даже не обсуждаю, нужно ли использовать include или extend. Я подвергаю сомнению вообще использование этих отношений на данном этапе. Они могут появится впоследствии и могут быть вполне уместны. Но только из анализа текстовых спецификаций. Когда будет понятно, что можно и целесообразно вычленить в некий общий абстрактный UC с повторяющейся последовательностью для нескольких UCs или подключаемых при особых условиях (расширениях). А краткие кусочки текста, которые записываются в овальчики, слишком малы и неопределенны для взвешенного принятия решения.
Здесь я с вами не соглашусь. UC - это не один сценарий, а взаимосвязанная группа сценариев. Да включённые UC всегда выполняются, но только для тех сценариев из группы, в которые они включены. Например: при управлении каталогом текст UC можно сформулировать так, что авторизация будет входить не в базовый сценарий, а в альтернативный (и следовательно не будет выполняться при каждой активизации UC).
Видите сколько неопределенности и интерпретации не поддержанной какими-либо спецфикациями или описаниями таких сценариев
-
Даниил, а вы уже перечитали топики
http://www.uml2.ru/forum/index.php?topic=286
http://www.uml2.ru/forum/index.php?topic=1112
http://www.uml2.ru/forum/index.php?topic=1277
http://www.uml2.ru/forum/index.php?topic=5955
http://www.uml2.ru/forum/index.php?topic=6159
?
-
За ссылку спасибо.
-
Мои извинения за долгое отсутствие, и спасибо за помощь.
Ранее сдал преподавателю предыдущую диаграмму на преддипломную практику, по-моему он даже не смотрел ее...
Теперь продолжаю ту же тему на диплом, на защите думаю смотреть все же будут мои диаграммы.
Помимо тех ВИ, что были, у меня добавился ВИ "управление заказами".
- отношение включение говорит мне (а я читаю схему, которая выполнена в определенной нотации и согласно определенному стандарту), что ВИ управления каталогом обязательно включает ВИ авторизации / регистрации, т.е. ВИ УК не будет полон без включения в него и исполнения шагов ВИ А/Р
- т.е. каждый раз когда мне требуется добавить/изменить/удалить какой-то элемент каталога, я должен авторизовать или регистрироваться вновь и вновь - ситуация возможная, но весьма странная
- ровно эти же рассуждения приведут меня и по ВИ оформление заказа, при этом если включение ВИ поиск заказа выглядит разумным, то ВИ А/Р явно нет.
- объединения Авторизации и регистрации вместе тоже довольно странное решение, так как постусловия сценария авторизации и регистрации различны. В одном случае открывается доступ согласно введенным данным авторизации, в другом создается новый объект - учетная запись
1) Как мне кажется, что "включение" верно, потому что для того чтобы управлять каталогом авторизироваться нужно обязательно.
Конечно не для каждого удаления или добавления товара нужно делать это заново, но все же перед этими действиями обязательно нужно пройти авторизацию.
2) В случае оформления заказа, у меня будет такая ситуация. Клиент либо при входе на сайт авторизируется/регистрируется (что вряд ли если честно, все таки не это его цель), либо сразу выбирает товары в корзину и оформляет заказ, при этом при нажатии кнопки "Оформить заказ" происходит автоматическая регистрация пользователя, если ранее он не был зарегистрирован.
3) Пожалуй да, надо бы разделить. Не уверен, что правильно разделяю, но все же.
-
Так выглядит спецификация.
Правда пока только на 3 ВИ.
ID: 1.
ВИ: Поиск товара.
Краткое описание: Система выполняет поиск в каталоге товаров по заданным администратором или клиентом критериям.
Основные действующие лица: Клиент, Администратор
Второстепенные действующие лица: Нет.
Предусловия: Нет.
Постусловия: Система нашла товары по заданным критериям и вывела результаты на экран.
Основной поток:
1. ВИ начинается, когда клиент/администратор переходит в каталог товаров.
2. Система выводит на экран общий список товаров и список критериев поиска.
3. клиент/администратор вводит необходимые для поиска товара критерии.
4. Система выполняет поиск товаров, соответствующих заданным критериям.
5. Для каждого найденного товара система выводит изображение, наименование и стоимость товара.
6. Если клиент/администратор запрашивает полную информацию о выбранном товаре.
6.1. Система выводи на экран все характеристики соответствующего товара.
Альтернативные потоки:
4.1. Системе не удалось найти товары.
4.2. Система сообщает пользователю, что товары с заданными характеристиками найти не удалось.
ID: 2.
ВИ: Оформление заказа.
Краткое описание: Оформление заказа на покупку товара в интернет-магазине.
Основное действующее лицо: Клиент.
Второстепенные действующие лица: Система автоматизации торговли.
Предусловия:
В корзине клиента присутствуют товары.
Постусловия:
1. Система автоматизации торговли получила заказ.
2. Клиент зарегистрирован в системе.
3. Система отправила клиенту письмо с информацией о его заказе.
Основной поток:
1. ВИ начинается, когда клиент входит в виртуальную корзину.
2. Система отображает содержимое виртуальной корзины клиента.
3. Система отображает стоимость заказа.
4. Если клиент выбирает опцию «Удалить товар».
5.1. Система удаляет отмеченные товары из корзины.
5.2. Система пересчитывает стоимость содержимого корзины.
5. Клиент выбирает опцию «Оформить заказ»
6. Система отображает форму оформления заказа.
7. Если клиент ранее совершал покупки и зарегистрирован в ситеме.
7.1. Система предлагает клиенту ввести его адрес электронной почты и пароль.
7.2. Клиент вводит свой адрес электронной почты и пароль.
8. Если клиент не совершал покупок в магазине и не зарегистрирован.
8.1. Система предлагает клиенту ввести контактные данные.
8.2. Клиент осуществляет ввод необходимых контактных данных.
9. Система предлагает клиенту ввести адрес доставки.
10. Клиент вводит адрес доставки.
11. Система предлагает клиенту выбрать вариант доставки.
12. Клиент выбирает вариант доставки.
13. Система производит пересчет стоимости заказа с учетом стоимости доставки.
14. Система запрашивает у клиента подтверждение оформления заказа.
15. Клиент подтверждает оформление заказа.
16. Система отправляет заказ на исполнение.
Альтернативные потоки:
7.2.1. Клиент ввел неверный адрес или пароль.
7.2.2. Система сообщает пользователю, что введенный адрес или пароль неверный.
7.2.3. Происходит возврат к пункту 7.1.
8.2.1. Клиент ввел некорректные данные.
8.2.2. Система сообщает пользователю, что введенные данные не корректны.
8.2.3. Возврат к пункту 8.1.
15.1 Клиент отменяет заказ.
15.2. Происходит возврат в виртуальную корзину клиента.
ID: 3.
ВИ: Управление каталогом.
Краткое описание: Администратор осуществляет управление каталогом товаров (добавление, изменение, удаление товаров).
Основное действующее лицо: Администратор сайта.
Второстепенные действующие лица: Система управления каталогом товаров.
Предусловия:
Администратор прошел авторизацию в системе управления каталогом товаров. Для изменения или удаления товар найден.
Постусловия:
Система внесла изменения, добавила или удалила товар.
Основной поток:
1. Если Администратор выбрал опцию «Добавить товар».
1.1. Система отображает на экране форму для ввода характеристик нового товара и добавления изображения.
1.2. Администратор вводит характеристики товара.
1.3. Администратор подтверждает добавление нового товара.
2. Если Администратор выбрал опцию «Изменить товар».
2.1. Система отображает на экране форму с характеристиками товара.
2.2. Администратор вносит изменения в характеристики товара.
2.3. Администратор подтверждает внесение изменений в характеристики товара.
3. Если Администратор выбрал опцию «Удалить товар».
3.1. Система запрашивает подтверждение удаления товара.
3.2. Администратор подтверждает удаление товара.
Альтернативные потоки:
1.3.1. Администратор отменил добавление товара.
1.3.2. Система осуществила переход к основному списку товаров.
2.3.1. Администратор отменил внесение изменений в характеристики товара.
2.3.2. Система осуществила переход к основному списку товаров.
3.2.1. Администратор отменил удаление товара.
3.2.2. Система осуществила переход к основному списку товаров.
-
Скорее всего поздно об этом писать, но всё же. Сравните свою диаграмму с таким решением:
(https://upload.wikimedia.org/wikipedia/commons/0/07/Online_Shopping_System_Use_Case_Model.jpg)
Где проходит граница Вашей системы?
Теперь по описаниям.
1) В описаниях Вы упоминаете действующие лица, которые отсутствуют на диаграмме ВИ. При этом в сценариях нет шагов этих действующих лиц. Зачем так сделано?
2) По диаграмме ВИ "Оформить заказ" включает 3 других ВИ. Следовательно, в сценарии оформления заказа ожидаемо видеть три шага вида: запускается сценарий включённого ВИ такого-то (по одному для каждого ВИ). Очевидно несоответствие между диаграммой и описаниями.
3) Пропущены некоторые шаги системы. Например, пользователь вводит контактные данные, но ответных действий системы нет (подтвердить корректность данных, сохранить их или др.)
4) Постусловия записаны только для успешного завершения ВИ. Для неуспешного завершения постусловия не указаны.
-
По поводу сравнения диаграмм:
У меня всего 2 актора, и более не предполагается на текущий момент.
Описания:
1. Не совсем понял какие я упоминаю действующие лица, которых нет на диаграмме. У меня есть Администратор и Клиент. или вы говорите про второстепенные "Система автоматизации торговли" и "Система управления каталогом" ? Я решил, что это сама система и ее нет смысла как актора указывать. Думаю просто не стоит указывать данные лица в описаниях, правильно?
2. Верно ли будет если я укажу эти три ВИ как предусловия к выполнению ВИ "Оформление заказа" ? Тут сложность только в том, что Аутентификация не обязательно должна быть перед оформлением, она возможна во время оформления.
3. Спецификация по ВИ "Оформелния заказа" не корректна, следующим постом измененную сделаю.
4. Не успешное завершение не является альтернативным потоком? Разве может ВИ завершиться, если оно не успешно? Это я бы назвал прерыванием скорее.
-
В целом адекватно ли у меня составлена сама диаграмма?
-
Немного изменил диаграмму. У меня администратор не может искать товары по категориям, в админке все товары выводятся одним списком. Понимаю, что это не удобно, но опять же сроки.
Ниже спецификация на ВИ "Оформление заказа".
Помимо того, что там наверняка ошибки есть, у меня сразу вопросы:
1. Система отображает форму оформления заказа. На этой форме сразу все поля. Однако я в спецификации последовательно указал ввод контактных данных, ввод адреса доставки и выбор варианта доставки. Так как контактные данные могут быть введены, если клиент не авторизирован, а если авторизирован то они автоматом подтягиваются.
Верно ли такое решение?
2. Отменить заказ клиент может в любую секунду, писать альтернативный поток к каждому пункту основного потока?
ID: 2.
ВИ: Оформление заказа.
Краткое описание: Оформление заказа на покупку товара в интернет-магазине.
Основное действующее лицо: Клиент.
Второстепенные действующие лица: нет.
Предусловия:
В корзине клиента присутствуют товары.
Постусловия:
1. Система автоматизации торговли получила заказ.
2. Клиент зарегистрирован в системе.
3. Система отправила клиенту письмо с информацией о его заказе.
Основной поток:
1. ВИ начинается, когда клиент входит в виртуальную корзину.
2. Система отображает содержимое виртуальной корзины клиента.
3. Система отображает стоимость заказа.
4. Если клиент выбирает опцию «Удалить товар».
4.1. Система удаляет отмеченные товары из корзины.
4.2. Система пересчитывает стоимость содержимого корзины.
5. Клиент выбирает опцию «Оформить заказ»
6. Система отображает форму оформления заказа.
7. Если клиент авторизирован в системе.
7.1. Система заполняет поля с контактными данными клиента из БД.
8. Если клиент не авторизирован.
8.1. Система предлагает клиенту ввести контактные данные.
8.2. Клиент осуществляет ввод необходимых контактных данных.
9. Система предлагает клиенту ввести адрес доставки.
10. Клиент вводит адрес доставки.
11. Система предлагает клиенту выбрать вариант доставки.
12. Клиент выбирает вариант доставки.
13. Система запрашивает у клиента подтверждение оформления заказа.
14. Клиент подтверждает оформление заказа.
15. Система отправляет заказ на исполнение.
Альтернативные потоки:
15.1. Клиент ввел имя короче 2-х символов.
15.1.1. Система сообщает пользователю, что необходимо ввести имя не короче 2-х символов.
15.2. Клиент ввел не корректный e-mail.
15.2.1. Система сообщает пользователю, что адрес электронной почты должен содержать символ “@”.
15.3. Клиент ввел уже зарегистрированный e-mail.
15.3.1. Система сообщает клиенту, что пользователь с таким e-mail уже зарегистрирован в системе, и предлагает пройти процедуру авторизации.
15.4. Клиент ввел не корректный номер телефона.
15.4.1. Система сообщает пользователю, что необходимо ввести номер телефона по маске ввода.
15.5. Возврат к пункту 6.
15.6 Клиент отменяет заказ.
15.6.1. Происходит переход на страницу, выбранную клиентом.
-
1) Как мне кажется, что "включение" верно, потому что для того чтобы управлять каталогом авторизироваться нужно обязательно.
Конечно не для каждого удаления или добавления товара нужно делать это заново, но все же перед этими действиями обязательно нужно пройти авторизацию.
К сожалению Вы так и не поняли, что я Вам написал. Попытаюсь еще:
улавливаете ли Вы разницу между
- для выполнения работы с каталогом, пользователь должен быть авторизован (возможно иметь соответствующие права)
и
- для выполнения действия с каталогом, пользователь должен выполнить авторизацию (подтвердить полномочия)
2) В случае оформления заказа, у меня будет такая ситуация. Клиент либо при входе на сайт авторизируется/регистрируется (что вряд ли если честно, все таки не это его цель), либо сразу выбирает товары в корзину и оформляет заказ, при этом при нажатии кнопки "Оформить заказ" происходит автоматическая регистрация пользователя, если ранее он не был зарегистрирован.
А тут ключевым словом является ЕСЛИ - это уже не обязательное, а условное включение(расширение). Для оформление заказа, вовсе не нужно регистрировать пользователя( тем более требовать с него авторизации). Но если вы это делаете, то есть конкретный ВИ "Зарегистрироваться на сайте" или "Войти в систему", которые могут активироваться из ВИ Оформление заказа при определенных условиях.
-
3) Пожалуй да, надо бы разделить. Не уверен, что правильно разделяю, но все же.
Аутентификация - это не авторизация. Правильно ли я понимаю, что пользователь не может авторизоваться на сайте без обращения к каталогу или оформления заказа.
-
К сожалению Вы так и не поняли, что я Вам написал. Попытаюсь еще:
улавливаете ли Вы разницу между
- для выполнения работы с каталогом, пользователь должен быть авторизован (возможно иметь соответствующие права)
и
- для выполнения действия с каталогом, пользователь должен выполнить авторизацию (подтвердить полномочия)
честно говоря я не совсем понимаю разницу между "работой с каталогом" и "действиями с каталогом".
-
А тут ключевым словом является ЕСЛИ - это уже не обязательное, а условное включение(расширение). Для оформление заказа, вовсе не нужно регистрировать пользователя( тем более требовать с него авторизации). Но если вы это делаете, то есть конкретный ВИ "Зарегистрироваться на сайте" или "Войти в систему", которые могут активироваться из ВИ Оформление заказа при определенных условиях.
Я регистрирую пользователя автоматом, для того чтобы он потом мог просматривать историю покупок, правда этого пока не предвидится, позже будет реализовано.
По сути так и получается, что при оформлении заказа активизируется ВИ "Регистрация на сайте".
В таком случае ведь регистрация происходит в любом случае, а значит как я думаю это включение. Ведь расширение может быть а может и не быть.
-
Аутентификация - это не авторизация. Правильно ли я понимаю, что пользователь не может авторизоваться на сайте без обращения к каталогу или оформления заказа.
хм...я всегда считал это синонимом...
Нет, пользователь может сразу при входе на сайт авторизироваться.
-
честно говоря я не совсем понимаю разницу между "работой с каталогом" и "действиями с каталогом".
Я не написал действиями, я написал действия. В одном случае говорится о работе с каталогом (который будет включать весь спектр возможных действий с ним), а в другом о действии с каталогом.
Т.е. чтобы работать с каталогом пользователь, уже должен быть авторизован и иметь определенный набор прав
-
Я регистрирую пользователя автоматом, для того чтобы он потом мог просматривать историю покупок, правда этого пока не предвидится, позже будет реализовано.
По сути так и получается, что при оформлении заказа активизируется ВИ "Регистрация на сайте".
В таком случае ведь регистрация происходит в любом случае, а значит как я думаю это включение. Ведь расширение может быть а может и не быть.
Что значит автоматом? Как вы идентифицируете пользователя?
-
Я не написал действиями, я написал действия. В одном случае говорится о работе с каталогом (который будет включать весь спектр возможных действий с ним), а в другом о действии с каталогом.
Т.е. чтобы работать с каталогом пользователь, уже должен быть авторизован и иметь определенный набор прав
Поиск и просмотр товаров в каталоге - это же тоже работа с каталогом. Но для этого пользователю не обязательно авторизизроваться.
-
Что значит автоматом? Как вы идентифицируете пользователя?
по id
-
по id
Как создается Id? Вы написали, пользователя регистрирую автоматом при оформлении заказа. Как?
-
Как создается Id? Вы написали, пользователя регистрирую автоматом при оформлении заказа. Как?
Когда пользователь вводит контактные данные выбирает вариант доставки и т.д., далее он нажимает кнопку "оформить заказ". После чего проверяется авторизирован ли он, если нет то далее проверяется есть ли в БД пользователь с таким же e-mail, если нет, то происходит регистрация пользователя.
-
Когда пользователь вводит контактные данные выбирает вариант доставки и т.д., далее он нажимает кнопку "оформить заказ". После чего проверяется авторизирован ли он, если нет то далее проверяется есть ли в БД пользователь с таким же e-mail, если нет, то происходит регистрация пользователя.
Т.е. чтобы потом авторизоваться, пользователю достаточно ввести свой e-mail?
А как происходит регистрация, если пользователь регистрируется явно?
-
Т.е. чтобы потом авторизоваться, пользователю достаточно ввести свой e-mail?
А как происходит регистрация, если пользователь регистрируется явно?
Не совсем так.
Ему пароль присваивается - это его имя. Т.е. при авторизации он вводит логин - почта и пароль - имя. После чего в профиле может поменять на другой пароль.
При явной регистрации вводится имя, почта, телефон, пароль.
-
Немного изменил диаграмму.
Аутентификацию заменил на авторизацию (почитал в чем разница =) )
Авторизация теперь является расширением оформления заказа. Ведь клиент может и пройти авторизацию и не проходить ее для оформления заказа. Для управления каталогом и заказами она так и осталась включением, потому как не пройдя авторизацию не зайти в админку.
А вот как быть с регистрацией я не знаю, на диаграмме однозначно не верно. По уму она должна включаться в оформление заказа из-за того что при оформлении у меня происходит и регистрация (если пользователь не авторизирован). И отсюда следует, что и включение не совсем верно, ведь оно означает, что данный ВИ будет обязательно выполнен, но это не так, ведь если клиент ранее прошел авторизацию, то регистрации не произойдет
-
И снова я изменил диаграмму.
ВИ регистрация как цель никому не нужен, поэтому и ассоциацию с акторами я убрал опять.
Сделал ВИ регистарция, расширением к ВИ Оформление заказа.
ВИ оформление заказа может прекрасно работать и без ВИ регистрация (когда пользователь авторизирован),
но при определенных условиях, а именно пользователь не авторизирован, срабатывает ВИ регистрация.
Надеюсь что верно.
-
И снова я изменил диаграмму.
Можно ещё раз указать на то, что связи между ВИ на диаграмме ВИ влияют на описание ВИ. Из диаграммы следует, что в описании ВИ Оформление заказа должны быть:
1) одна (или более) точка расширения (для регистрации, авторизации);
2) шаги, на которых вызываются сценарии включаемых ВИ (поиск, выбор).
Ещё одно несоответствие между диаграммой и описанием ВИ Оформление заказа можно видеть в том, что при оформлении заказа нет возможности добавлять товары в заказ (только удалять). Вероятно, пропущен ВИ, в рамках которого это можно делать -- Составление заказа или вроде того. Либо надо менять описание и диаграмму деятельности из параллельной темы.
P. S. Ассоциация между действующим лицом и вариантом использования толкуется не только в том ключе, кому нужен ВИ как цель.
-
Можно ещё раз указать на то, что связи между ВИ на диаграмме ВИ влияют на описание ВИ. Из диаграммы следует, что в описании ВИ Оформление заказа должны быть:
1) одна (или более) точка расширения (для регистрации, авторизации);
2) шаги, на которых вызываются сценарии включаемых ВИ (поиск, выбор).
Ещё одно несоответствие между диаграммой и описанием ВИ Оформление заказа можно видеть в том, что при оформлении заказа нет возможности добавлять товары в заказ (только удалять). Вероятно, пропущен ВИ, в рамках которого это можно делать -- Составление заказа или вроде того. Либо надо менять описание и диаграмму деятельности из параллельной темы.
P. S. Ассоциация между действующим лицом и вариантом использования толкуется не только в том ключе, кому нужен ВИ как цель.
Честно говоря не представляю как осуществить описание расширения авторизация и регистрация.
Поиск у меня так сказать пропущен ,но в предуслови к ВИ Оформлении заказа, указано, что в корзине есть товары, т.е. поиск уже осуществлен.
Действие выбора на диаграмме деятельности указано.
А я решил составление заказа и его оформление в один ВИ Оформление заказа засунуть, наверное из-за этого у меня диаграмма и вышла такая нагроможденная. Чтобы добавить товар в заказ придется выйти из оформления заказа в каталог, добавить в корзину и заново начать ВИ Оформление заказа.
Стоит разделить на 2 ВИ "Составление заказа" или "Работа с корзиной", и "Оформление заказа" ?
-
Изменения.
Согласен с Вами, Добавление товара в корзину у меня повисло в воздухе.
Добавил это отдельным ВИ. Теперь для диаграммы деятельностей ВИ Оформление заказа и предусловие получается правльно написано: "в корзине есть товары".
А то раньше было что будто я их нашел и они чудесным образом сами добавились в корзину.
Также добавил ассоциации к ВИ Регистарция и Авторизация от Клиента и к ВИ Авторизация от Администратора.
Потому как прочитал, что без них получается то, что, например, клиент не может активировать ВИ Авторизация пока не начнет оформление заказа. А может он просто так решил авторизироваться или свои контакты поменять.
Правда стало как-то слишком нагромождено все...
Правильно ли я понял значение связи "Ассоциация" ?
-
Изменения.
Моё замечание про ассоциации не касалось якобы нехватки их на Вашей диаграмме.
Основной акцент делался на связи включения и расширения. Вы их используете на диаграмме (по легенде: преподаватель их хочет), но не используете в описаниях ВИ. Как включение/расширение влияет на описания подробно написано на русском у Коберна в "Современных методах описания функциональных требований к системам".
Я не буду пытаться пересказать. Дам краткое пояснение. ВИ с включениями пишутся специальным образом. ВИ с расширениями пишутся специальным образом. Если Вы не знаете, как их писать, то либо нужно узнать, либо не нужно использовать включение и расширение на диаграмме, а описывать ВИ как обычно.