Может ли использование UML показать все, что может сделать актер (функциональность) или все, что хочет сделать актер (цели)?

Question

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

1. Register (создать учетную запись)
2. Обзор пунктов
3. Добавить элементы в корзину
4. заказ и оплатить
5. Просмотр учетной записи информация
информация
6. Редактировать счет т.д.

Вместе с тем, было бы функции, которые пользователь может инициировать, но не будет их основная цель использования системы:

1. Войти
2. Выйти
3. отдел Выберите «электроника»
4. Выбрать «транспортные средства "отдел
5. Введите детали доставки т.д.

Я считаю, что такие вещи, как Logi n и logout не должны быть в диаграмме использования UML. Причина в том, что пользователь не захочет войти в онлайн-магазин только для входа в систему; у них всегда была бы другая цель, которая заключалась бы в том, чтобы просматривать/редактировать информацию об учетной записи или просматривать и покупать вещи.

Аналогично, два отбираемых «утверждения» являются частью используемого случая для просмотра объектов. Я бы не использовал обобщение, потому что может быть много отделов.

И, наконец, данные о доставке являются частью варианта использования «checkout» или «edit account information». Я, как правило, собираю это с использованием варианта использования учетной записи «редактировать учетную запись», иначе вы можете иметь варианты использования для «редактировать имя», «редактировать электронную почту» и т. Д.

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

Итак, мой вопрос заключается в следующем. Я считаю, что это правильно? Лучше ли только моделировать «реальные» цели в диаграммах использования или все, что могут инициировать актеры?

Answer 1

Имеет ли использование UML может показать все, что актер может сделать (функциональность) или все, актер хочет сделать (цели)?

Это может быть либо - спецификация UML не является предписывающей на этом фронте. Алистер Кокберн создал categorisation for Use Cases, который указывает, на каком уровне они сосредоточены.

Сказав, что:

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

Это очень реальный риск. Лично я считаю, что получаю большую часть от UC, сосредоточившись на пользователях и их целях. Какую ценность они хотят получить от системы?

Сохранение этого уровня предотвращает ситуацию «не видно дерева для деревьев», а также останавливает UC, становясь полным функциональным дизайном разложения.

hth.

Answer 2

Неправильно исключать некоторые варианты использования с вашей диаграммы, и действительно, это может быть хорошей идеей. Например, если вы собираетесь показать свою диаграмму в бизнес-отделе, вы можете нарисовать модель UML, описывающую оперативные варианты использования. Если вы собираетесь передать свою диаграмму программистам, вы хотели бы дать им полное описание того, что им нужно реализовать. Это всего лишь модели вашей системы.

Когда вы рисуете диаграмму использования, как правило, также записывается поведение каждого варианта использования (в виде текстового описания, псевдокода или с использованием диаграмм взаимодействия).

В языке UML спецификация говорит, что:

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

Войти и Выход наблюдаются для пользователя. Хотя пользователь не будет посещать ваш сайт с единственной целью входа в систему, у такого прецедента есть определенный поток выполнения, который вы также хотите описать. Если вы не разрешаете пользователям самостоятельно вводить логин, будут использоваться случаи, когда включает функциональность login. Пользователь может также заинтересоваться при выходе из системы, прежде чем покинуть сайт, чтобы данные сеанса не сохранялись на его компьютере.

отдел Выберите «Электроника», Выбрать «автомобили» универмаги ... Почему не просто Выбрать отдел (я полагаю, что они не слишком отличаются).

Я бы нарисовал этот и другие прецеденты, если они имеют отношение к модели.