Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Santey от 04 Апреля 2014, 10:08:21
-
Доброго времени суток. Решил я написать сайт для магазина моего дяди и всё это представить, как курсовой проект в университете. Преподаватель посоветовал начать с UML диаграммы. Вот что у меня получилось. Прошу указать на мои недочеты и чего еще не хватает.
P.S: Раньше ни когда не строил UML диаграммы.
(http://s6.hostingkartinok.com/uploads/thumbs/2014/04/f52674355a87133de6dfe04e25a7c666.png) (http://hostingkartinok.com/show-image.php?id=f52674355a87133de6dfe04e25a7c666)
-
Добрый день!
А с какой именно UML диаграммы посоветовал начать преподаватель? Их ведь больше одной.
Что касается данной ДВИ, то для начала сделайте вот что:
1. Перенесите всех акторов влево и перерисуйте их иерархию.
2. Удалите ВИ которые не несут пользы акторам (например, вход в систему)
3. Добавьте ВИ которые вы забыли (например, регистрация для гостя)
В ДВИ самое главное - набор полезных действий для акторов. Именно каждый полезный вариант использования определяет функционал. Пихать туда все подряд - не надо. А вот подумать что должен полезного давать сделать сайт - обязательно.
-
А как Вам такой вариант?
(http://i33.fastpic.ru/thumb/2014/0404/86/491f8cc241cfff3a218fec10226fa686.jpeg) (http://fastpic.ru/view/33/2014/0404/491f8cc241cfff3a218fec10226fa686.jpg.html)
-
Еще я бы хотел нарисовать ДК, но я не знаю с чего начать...
-
Другой вариант...
(http://i59.fastpic.ru/big/2014/0404/65/9cd19cb09f5b98fc9e1bfaea0f7ddd65.jpg)
-
Второй вариант еще хуже:)
Во первых про "акторов влево, ВИ вправо" я не шутил. Если уж используете UML, надо соответствовать нотации.
Во вторых, ВИ это конкретное полезное действие, которое может сделать актор, а не абстрактное определение. Т.е. не "Новости управление", а "Управление новостями", не "комментарии модерирование", а "модерация комментариев" и т.д.
В третьих по прежнему надо удалить бесполезные ВИ типа "Авторизация".
В четвертых "Статические страницы" вообще не имеют отношения к ВИ.
Так какую диаграмму посоветовал сделать преподаватель? Точно ДВИ?
И что за ДК вы планируете сделать?
-
Доброго времени суток. Решил я написать сайт для магазина моего дяди и всё это представить, как курсовой проект в университете. Преподаватель посоветовал начать с UML диаграммы. Вот что у меня получилось. Прошу указать на мои недочеты и чего еще не хватает.
Есть хорошее правило: начинать названия вариантов использования с глаголов. Это сразу меняет подход от абстрактной возможности к конкретной цели, которой хочет достичь пользователь.
То есть не "Просмотр страниц", а "Просматривать страницы", не "Пользователи управление", а "Управлять пользователями".
Ещё одно хорошее правило: представьте, что разрабатываемая система содержит только кнопки, нажимая на которые пользователь достигает своей цели. "Найти товар", "Заказать товар", "Оплатить товар".
И тогда возникают вопросы вроде такого: а вы бы стали нажимать на кнопку "Просматривать страницы"? Есть ли у вас, как у посетителя интернет-магазина, такая цель?
-
Преподаватель посоветовал начать с UML диаграммы.
Зря вы его послушали...
Подход "Построение диаграммы ВИ" не предполагает методов контроля полноты. Как следствие, во всех вариантах вы пропустили огромное количество ВИ. Если мы рассматриваем интернет магазин полностью, т.е фронтент + бэкофис, то должно получиться несколько сотен ВИ. Если рассматриваем только со стороны покупателя, то все равно их несколько десятков (ориентируйтесь на полсотни).
Согласен с davvol почти по всем пунктам.
> В четвертых "Статические страницы" вообще не имеют отношения к ВИ.
Здесь не хватает действия. Должно быть:
CRUDL статических страниц (пять вариантов использования).
Причем RL для всех, включая покупателя, а CUD только для группы подготовки контента. Ну и в сложных случаях еще будет что то типа "Опубликовать/ вернуть на доработку страницу" для роли "Выпускающий редактор".
И да, название Ви имеет структуру: <Действие> <Объект действия> <Дополнения>.
При этом ошибкой будет указание в названии субъекта, производящего действие.
PS. Иногда на тренинге по юзкейсам я разбираю вопросы, заданные на этом форуме. Посетители тренинга, как правило, находят гораздо больше больше ВИ, чем рисуют на диаграмме. В разы. Это следствие того, что я рассказываю множество методов верификации. Этот пример немного великоват, но его я пожалуй тоже утащу. Тут, чтобы сделать реестр ВИ со стороны только покупателя с 70%-й полнотой нужно полчаса - час.
-
И тогда возникают вопросы вроде такого: а вы бы стали нажимать на кнопку "Просматривать страницы"? Есть ли у вас, как у посетителя интернет-магазина, такая цель?
Точно есть. Для обычного любителя роликов ABIC 3-5 является оптимумом. 6-9 будет катиться хуже. Поэтому есть цель: "Ознакомиться с советами эксперта по подбору роликовых коньков".
-
Следую Вашим советам, вот что у меня получилось
(http://i33.fastpic.ru/big/2014/0404/87/cc98797e91117c62cd4befb7b94d2c87.jpg)
-
Извините меня за мою орфографию, просто я на работе в данный момент и я вынужден делать два дела одновременно, поэтому плохо получается сконцентрироваться... :-\
-
Ещё одно хорошее правило: представьте, что разрабатываемая система содержит только кнопки, нажимая на которые пользователь достигает своей цели. "Найти товар", "Заказать товар", "Оплатить товар".
И тогда возникают вопросы вроде такого: а вы бы стали нажимать на кнопку "Просматривать страницы"? Есть ли у вас, как у посетителя интернет-магазина, такая цель?
Круть! Утяну для рекомендаций для студентов:) +1
-
Точно есть. Для обычного любителя роликов ABIC 3-5 является оптимумом. 6-9 будет катиться хуже. Поэтому есть цель: "Ознакомиться с советами эксперта по подбору роликовых коньков".
Но это не "Просматривать страницы", это уже близко к кнопке "Получить совет эксперта". Т.е. ты полностью согласен с Гришей.
-
Следую Вашим советам, вот что у меня получилось
Почему все овальчиками, а регистрация прямоугольником?
1. Почему Просматривать каталог товаров и Осуществлять поиск товаров - разобщены
2. Лучше придерживаться одного стиля или активного Искать Заказать Управлять, или пассивного Поиск Заказ Управление
3. Администратор - это не зарегистрированный пользователь?
4. Зарегистрированный пользователь - я бы назвал Покупатель или Заказчик или Клиент - больше смысла понятна роль
5. Должен ли пользователь как-то управлять (следить) за своим заказом? Может ли он его отменить, удалить, повторить, отредактировать (изменить), проследить и т.п.?
-
Но это не "Просматривать страницы", это уже близко к кнопке "Получить совет эксперта". Т.е. ты полностью согласен с Гришей.
Для обеспечения полноты проще думать в терминах CRUDL. "Read page", но согласен, что на стадии выявления целей пользователя лучше думать в терминах целей.
Только вот какая петрушка получается, если думать в терминах целей, то цель одна "определиться, какими характеристиками должен обладать товар, чтобы он подошел мне". А вот ВИ будет много. ~20 штук я вижу навскидку, вероятно можно накопать еще.
-
Ещё одно хорошее правило: представьте, что разрабатываемая система содержит только кнопки, нажимая на которые пользователь достигает своей цели.
Отличная идея!
-
Прошу указать на мои недочеты
"Укажу" по части функционала.
Если в этом магазине не предполагается навороченной системы лояльности с баллами, мини-играми и девушками службы поддержки клиента, то вам совершенно не нужно заставлять посетителя сайта регистрироваться на нем. Плюсы:
- Потенциальный покупатель не будет отделен от покупок неприятной процедурой.
- Не надо разрабатывать соответствующие экранные формы и механизмы бэкэнда.
Вам не авторизовать посетителя надо, а всего лишь идентифицировать (все равно без предварительного созвона уже никто никуда ничего не везет). Идентифицировать достаточно легко: например, по номеру контактного телефона. "Клиентскую карточку" в БД оформите автоматически из данных, которые покупатель введет для доставки в первый раз.
Любить клиента нужно нежно.
-
"Укажу" по части функционала.
Если в этом магазине не предполагается навороченной системы лояльности с баллами, мини-играми и девушками службы поддержки клиента, то вам совершенно не нужно заставлять посетителя сайта регистрироваться на нем. Плюсы:
- Потенциальный покупатель не будет отделен от покупок неприятной процедурой.
- Не надо разрабатывать соответствующие экранные формы и механизмы бэкэнда.
Вам не авторизовать посетителя надо, а всего лишь идентифицировать (все равно без предварительного созвона уже никто никуда ничего не везет). Идентифицировать достаточно легко: например, по номеру контактного телефона. "Клиентскую карточку" в БД оформите автоматически из данных, которые покупатель введет для доставки в первый раз.
Любить клиента нужно нежно.
+1
Регистрация действительно сильно снижает конверсию. Поэтому она нужна:
* Для накопительной системы баллов
* Отслеживания статусов заказов на сайте (иногда это удобно)
* Защиты от ботов, накручивающих/скручивающих отзывы и оценки
* и т.д.
А для покупателя удобнее всего "купить в один клик". Вот идеальный функционал с моей точки зрения для книжного магазина:
* На форуме uml2.ru увидел линк на книгу по анализу, нажал
* Попал на описание товара
* начал "купить"
* ввел номер телефона и подтвердил желание купить
* закрыл броузер
Все, моя работа с сайтом закончилась.
Через 1 минуту мне перезвонили, мы договорились, каким почтоматом я воспользуюсь (это стоит всего 50 руб, в отличии от курьерки http://www.ozon.ru/context/detail/id/20171026/), вечером, возвращаясь с работы сунул в терминал наличку и забрал заказ.
От заказа до получения - 2 часа.
При повторном заказе оператор спросит: "Вам в тот же почтомат?"
Тот, кто сделает это первым в своем секторе рынка, получит преимущество перед конкурентами.
-
Сергей, а оплата — при получении в почтомате?
А, вижу. Мне удобней оплатить сразу, без налички )
-
Сергей, а оплата — при получении в почтомате?
А, вижу. Мне удобней оплатить сразу, без налички)
Правильно. Мы с тобой разные, нам удобно по разному.
Поэтому естественно нужно поддержать множество вариантов оплаты: оплата с счета в банке, при помощи карты и Pidion1300 принесенный курьером, вебмани, пайпал, банковский счет (говорить карта в корне неверно), со своего счета на сайте (заработок при помощи партнерки) и т. д.
Но это лучше не в ВИ. это другая категория требований.
PS. Кстати, популярную некогда партнерку забыли. А это еще куча ВИ.
-
Всем спасибо за советы! Особенно по "регистрации", буду реализовывать. Пока ДВИ отодвинулась на второй план, но когда я продолжу её корректировку, обязательно обращусь к Вам за советом.
-
Вам очень поможет введение понятия "Уровень ВИ".
* "авторизация" - уровень ниже уровня моря. И действительно, часто его лучше не включать. Это уровень программиста. Но. Авторизация может оказаться сильно не тривиальной и ее реализация может потребовать более 2 недель. В этом случае имеет смысл внести ее в реестр, как единицу планирования, а потом отдельно расписать.
* "добавить товар в корзину" - уровень моря, основная единица планирования (как правило).
* "Управление товаром в корзине" - обобщающий сценарий. Включает от 5 сценариев уровня моря
Предложение 1. На ДВИ лучше выносить ВИ одного уровня.
Предложение 2. Есть метод "Зачем <-> как". Один из вариантов - описываете бизнес идею сначала как результат, потом как набор действий, затем декомпозируете.
Например.
Книги по IT тематике стоят в США очень дорого. О, идея! В Индии полно дешевых репринтов. Наш интернет магазин будет позволять американцам дешево купить индийский репринт. Теперь нужно написать самый верхнеуровневый сценарий. Пишите.
Идея скорее всего не сработает, т.к. ЕМНИП ввоз в США книг очень сильно ограничен. Но для курсовой, сойдет.
Идея пересылать дешевые репринты в РФ (переводчики такие переводчики) тоже скорее всего не сработает, т.к. наши инженеры, "в булочную на такси не ездят книг по специальности не читают".
-
Некрокоммент: Местная озабоченность надуманным принципом "одна ДВИ -- один уровень всех ВИ на ней" позволила не заметить основные дефекты диаграммы: просматривать каталог гость и зарегистрированный пользователь обязаны, взявшись за руки; искать (?найти?) товары можно только в том случае, если этим займётся пара админ + зареганный пользователь. А всё почему, потому что в вузах плохо учат UMLю, якобы.
-
Некрокоммент: Местная озабоченность надуманным принципом "одна ДВИ -- один уровень всех ВИ на ней" позволила не заметить основные дефекты диаграммы: просматривать каталог гость и зарегистрированный пользователь обязаны, взявшись за руки; искать (?найти?) товары можно только в том случае, если этим займётся пара админ + зареганный пользователь. А всё почему, потому что в вузах плохо учат UMLю, якобы.
Тут есть один момент. Научить нельзя, научиться можно. В ВУЗах может и правильному учат, только вот студенты не научаются, а потом на производстве им говорят, да какая разница, правильно или неправильно нарисовано, главное же тебя поняли :)
-
а потом на производстве им говорят, да какая разница, правильно или неправильно нарисовано, главное же тебя поняли :)
Даже не знаю, как на такое ответить. Может быть, авторы профстандартов недоглядели, не оборонили землянскую софтверную индустрию от такого непрофессионального подхода.
-
Даже не знаю, как на такое ответить. Может быть, авторы профстандартов недоглядели, не оборонили землянскую софтверную индустрию от такого непрофессионального подхода.
по-моему в землянском стандарте нет явных требований по знанию UML, и вообще еще в далеком 2011 году один землянский философ (известный правда в своих особых кругах), сказал, что поезд UML стоит в тупике, где ему и следует быть :)
В архитектурном канале регулярно вижу как те или иные диаграммы UML обругиваются. Не так давно ругали диаграмму классов, а вот диаграмму последовательности хвалят.
-
Кажись, UML гостировали. А нафига, если профи его не нужно знать, если профи позволительно рисовать и понимать какой-то псевдоUML под видом настоящего? [Марсианская риторика, если что.]
-
Кажись, UML гостировали.
А есть какие-то признаки? Это ведь должен быть докУмент какой-то?
А нафига, если профи его не нужно знать, если профи позволительно рисовать и понимать какой-то псевдоUML под видом настоящего? [Марсианская риторика, если что.]
А вот не знаю. Слушал выступление Александра Лучкова. Он определенно заявил, что тот не архитектор, если он не знает UML и не только его, и не может его использовать правильно.
Но даже на Linkendin интерес к теме UML как-то сильно угас.
-
А есть какие-то признаки? Это ведь должен быть докУмент какой-то?
Нету, ни признаков, ни докУментов. Приврало, по марсианскому обычаю. ;D
Как курьёз, есть геоинформационный ГОСТ Р 57668 -- калька с ISO 19115 и там содержится кусочек UMLя. Т. к. переводили геоспецы, то их ксенолингвист породил принцип Анти-Лизковы, согласно которому подклассы заменяются суперклассами. Теперь так, по ГОСТу.
-
Нету, ни признаков, ни докУментов. Приврало, по марсианскому обычаю. ;D
Как курьёз, есть геоинформационный ГОСТ Р 57668 -- калька с ISO 19115 и там содержится кусочек UMLя. Т. к. переводили геоспецы, то их ксенолингвист породил принцип Анти-Лизковы, согласно которому подклассы заменяются суперклассами. Теперь так, по ГОСТу.
Хахаха