Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Системный анализ, проектирование и UML > Прецеденты


Автор: SLeN 13.2.2008, 19:53
Меня мучают сомнения правильно ли я составляю развернутое описание прецедента, не слишком ли это подробно (на алгоритм уже тянет) ? или так и надо - чем подробнее тем лучше в развернутом описании...
Цитата


...

Основной Сценарий 

1. Клиент приходит в офис компании и приносит с собой технику
2. Мастер открывает новый заказ
...

Альтернативный сценарий

2а.   Клиент предъявляет мастеру купон на скидку
   1.  Мастер вводит номер купона
   2. Система проверяет бизнес правила ( можно ли добавить купон к заказу )
      2.а Бизнес правила Запрещают добавление номера купона к заказу
          1. Мастер Приносит свои соболезнования клиенту
      2.б Система не может проверить бизнес правила
          1. Система сообщает о ошибке и спрашивает разрешения повторить проверку бизнес правил 
             1.а Ответ положительный
                1.Система повторяет проверку бизнес правил
             1.б Ответ отрицательный
                1. Система не записывает в заказ номер купона
                2. Мастер предлагает добавить купон к заказу после  устранения неисправности.
   3. Система проверяет номер купона  
            3.а Система не находит номер купона, находит номер купона( но он уже использовался) или купон просрочен 
               1. Система сообщает о ошибке
               2. Мастер интересуется нет ли клиента еще купона
                   2.а  Клиент предъявляет мастеру другой купон на скидку
                       1. Мастер вводит номер другого купона
                   2.б  Клиент сообщает мастеру о том что у него нету другого купона
                      1. Мастер продолжает оформление заказа без номера купона
            3.б  Система не может произвести поиск
                1. Система сообщает о ошибке.
                2. Мастер предлагает ввести номер купона позже.

   4. Система добавляет к заказу номер купона
   5. Мастер сообщает клиенту о успешном добавлении купона к заказу
         5.а Клиент сообщает что у него еще есть купоны на скидку
           1. Мастер производит попытку добавить номер еще 1го купона
...


Автор: Exception 17.2.2008, 02:17
Мне кажется, что ты пытаешься рассмотреть все возможные случаи, в то время, как пользы это никакой не принесёт.

Цитата(SLeN @  13.2.2008,  20:53 Найти цитируемый пост)
      2.б Система не может проверить бизнес правила
          1. Система сообщает о ошибке и спрашивает разрешения повторить проверку бизнес правил 
             1.а Ответ положительный
                1.Система повторяет проверку бизнес правил
             1.б Ответ отрицательный
                1. Система не записывает в заказ номер купона
                2. Мастер предлагает добавить купон к заказу после  устранения неисправности.


А как же вариант «Система зависла» smile ? Шучу. Я думаю, что всё это можно запросто опустить или в случае крайней необходимости просто объединить в один пункт.


Цитата(SLeN @  13.2.2008,  20:53 Найти цитируемый пост)
Мастер производит попытку добавить номер еще 1го купона


Это хреновый текст. Нет, правда. Ты когда-нибудь видел, чтобы люди производили попытки добавления номеров купонов? Мне кажется, что сценарии гораздо полезнее подобных детализованных описаний юз-кейсов. Напиши литературным языком два-три сценария, о том, как Мэт сидит и пьёт кофе со сливками, когда к нему в офис вламывается клиент с просроченным купоном. Или про Пегги, которую опять бросил парень, и про то, как она, рассерженная, пытается вбить в систему размер скидки клиента. И тому подобное. Эти сухие описания ужасны.

Автор: Aazmandius 17.2.2008, 02:35
+1

сценарии-рассказы намного легче воспринимать

Автор: SLeN 17.2.2008, 12:56
Надеюсь что понял  smile 

К примеру если я буду испоьзовать метод  система как "Черный ящик" и описывать лиш взаимодействие актер - система, ситема - актер то прецеденты будут лучше ?

Продолжая тему купонов

Цитата

...
Основной Сценарий 

1. Клиент приходит в офис компании и приносит с собой технику
2. Мастер открывает новый заказ
3. ...
...

Альтернативный сценарий

2.а Клиент предъявляет мастеру купон на скидку
    1. Мастер вводит номер купона
        1.а Купон недействителен, бизнес правила запрещают добавление купона
            1.Система сообщает о ошибке
    2. Система уведомляет о успешном добавлении и размере скидки, перещитывает стоимость заказа
3а ...
...




Очень хочется увидеть Прецеденты с Мэтом и Пегги  smile  

Автор: SLeN 17.2.2008, 15:56
В общем получилась такая тема:

Цитата


Заинтересованные лица и их требования

Клиент — Заинтересован в услугах компании, получении сохранной расписки на технику и стоимости заказа.
Мастер — Заинтересован в быстром и правильном составлении заказа.
Компания — Заинтересованна в исполнении пожеланий клиента, ведении статистических данных, составлении плана работ для мастера.
Менеджер — Хочет знать какие заказы требуют его вмешательства

Предусловия 

Мастер Аутентифицирован и Авторизован

Пост условия

Данные о заказе сохранены, распечатана сохранная расписка, план работ для мастера, сохранены данные о новом клиенте, новой технике, складские данные обновлены


Основной Сценарий 

1. Клиент приходит в офис компании и приносит с собой технику
2. Мастер открывает новый заказ
3. Мастер вводит номер телефона клиента
4. Система находит имя и фамилию по телефону клиента и подставляет их в заказ 
5. Мастер заносит в заказ информацию о технике ( из вариантов предоставленных системой), которую принес клиент и ее количество
  Пункт 5 повторяется для всей техники принесенной клиентом
6. Мастер выбирает нужную  услугу и добавляет ее в заказ
  Пункт 6 повторяется для каждой услуги
7. Система вычисляет стоимость заказа
8. Мастер сообщает стоимость заказа клиенту,  клиент дает согласие на проведение требуемых услуг
9. Система сохраняет заказ, данные о новом клиенте, информацию о технике которую мастер ввел в ручную, обновляет складские данные
10. Система печатает сохранную расписку в которой указанна стоимость услуг и перечень оговоренных услуг, так же печатает  штрих код заказа и план работ для мастера
11. Мастер разделяет сохранную расписку на несколько частей, клиент берет свою часть, оставляет технику в компании  и уходит  


Альтернативный сценарий

2.а Клиент предъявляет мастеру купон на скидку
    1. Мастер вводит номер купона
        1.а Купон недействителен, бизнес правила запрещают добавление купона
            1.Система сообщает о ошибке
    2. Система уведомляет о успешном добавлении и размере скидки, перещитывает стоимость заказа

4.а Имя и Фамилия клиента не найдены
    1. Мастер в ручную вводит имя и фамилию клиента

5.а В системе нет данных о технике которую принес клиент
    1. Мастер вводит информацию в ручную

2 — 8 ( включительно ) а. Клиент отменяет заказ
    1. Мастер отменяет заказ
    2. Клиент забирает свою технику и уходит

9 — 11 ( включительно ) а. Клиент отменяет заказ
    1. Мастер не выдает клиенту сохранную записку
    2. Клиент забирает свою технику и уходит
    3. Мастер помечает заказ на удаление, чтоб позже менеджер удалил заказ


P.S.:

Попробовал составлять веселые сценарии-рассказы...
По мне так они больше годятся для «Функционального» программирования, чем для последующего анализа, или я опять что то недопонял  smile 

Автор: Aazmandius 18.2.2008, 19:01
Ну Мэт и Пегги в данном случае представляют экземпляры каких-либо классов, Мастер, Клиент, Клерк и т.д (выделяем объектную модель). То есть при достаточно детализированном описании их деятельности можно определить, что является их сферой деятельности - то бишь выделить методы классов, которые будут нужны в проектируемой системе. Аналогично в рассказе наверняка промелькнет взаимодействие наших героев с другими участниками бизнес-процесса, Начальником например. А те бумажки, которые Пегги будет заполнять по ходу рассказа - документооборот внутри компании, то бишь потоки данных. Их также можно и нужно анализировать. Ну и т.д. Непринужденный стиль - это не самоцель, он служит именно для облегчения восприятия, потому что когда читаешь сухие казенные фразы, то заснуть хочется на второй строчке. У Акоффа (который Рассел) подобные изложения в казенном стиле (например постановка задачи, которую он когда-то решал) как правило дальше расписаны в доступном изложении и он сам называет это "В переводе на человеческий язык". Оставим казенные фразы бюрократам smile 

Автор: SLeN 18.2.2008, 20:22
 smile 

Автор: ida 25.3.2008, 17:09
SLeN, внимательно не читала - в целом описание хорошее (степень детализации оптимальная, ни мало ни много), но над ним еще предстоит поработать.

В-частности:

1. "Система не записывает в заказ номер купона" - таких формулировок быть не должно. Нас интересует, что система ДЕЛАЕТ, а не чего она не делает. Если она чего-то не делает - просто не пишите ничего.

2. Система проверяет бизнес правила ( можно ли добавить купон к заказу )
      2.а Бизнес правила Запрещают добавление номера купона к заказу
          1. Мастер Приносит свои соболезнования клиенту
      2.б Система не может проверить бизнес правила
Где вариант: "Бизнес-правила разрешают добавление номера купона к заказу"?... Вы должны описать ВСЕ возможные ветви алгоритма, иначе возникнет исключительная ситуация, которую непонятно как обрабатывать.

3. 1. Мастер производит попытку добавить номер еще 1го купона
Такие формулировки также лучше не использовать: лучше "Мастер добавляет номер еще одного купона" (проверка того, можно ли это сделать, должна осуществляться ПЕРЕД действием).

Бегло вроде все.

Потом может посмотрю внимательнее, еще что-то напишу.

Автор: SLeN 31.3.2008, 09:57
ida,  Спасибо!

Буду ждать вниматеьного просмотра =)

Автор: ida 4.4.2008, 12:20
Нашла у себя книгу "Современные методы описания функциональных требований к системам" (в оригинале "Writing effective use cases"), автор Алистер Коберн.

Она вышла каким-то невероятно маленьким тиражом, но можно поискать в Интернете.
Это как раз про варианты использования.

Автор: ida 26.4.2008, 17:32
SLeN, вот что еще пишет А.Коберн в своей книге, возможно, это будет вам интересно.

Большинство хорошо написанных вариантов использования имеют от 2 до 8 шагов (неясно, имеются ли в виду и альтернативные сценарии - скорее всего нет).

Если в варианте использования более 10 шагов, то скорее всего туда включены действия более низкого уровня абстракции. Т.е. его надо пересмотреть.

Можно еще пользоваться правилом "7+-2" - емкость краткосрочной памяти человека.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)