День добрый! Помогите пожалуйста исправить отчёт по диаграмме прецедентов в соответствии с комментариями преподавателя:

* В отчете отсутствует описание актеров.

* Сценарий должен быть по каждому прецеденту, а не один на все.

Сама диаграмма:


Отчёт по ней:

ООО «ВкуS!esть!»

Описание системы
На данный момент ресторан «ВкуS!esть!» не имеет никакой информационной системы. Потребность в ней появилась в связи с увеличением количества посетителей и ассортимента блюд. Посетитель, зайдя в ресторан, следует к кассе. Кассир узнает стоимость блюд по памяти. Оплата производится только наличными. Заказ полуфабрикатов поставщику делается в хаотичном порядке: повар несвоевременно сообщает администратору о том, что полуфабрикатов осталось мало, и администратор не может вовремя сделать полноценную заявку на поставку. В итоге, какие-то полуфабрикаты находятся в морозильнике в избытке, а каких-то вовсе нет.


Описание требований к проектируемой системе.
Задачи и их решения.
1. Кассир может забыть цену и наличие какого-либо готового блюда. Нужно сделать так, чтобы кассир располагал актуальной информацией о количестве готовых блюд, и их стоимости в реальном времени.

Задача будет решена за счет:
А) Закупки кассовых терминалов;
Б) Слежения за количеством готовых блюд;
В) Внесения информации о ценах блюд в БД.

У кассира будет кассовый терминал с монитором.
С помощью этого терминала кассир сможет следить за количеством готовых блюд и за их стоимостью.
Каждое блюдо будет иметь свой идентификационный номер.
Кассир будет набивать на экране терминала заказанные блюда, система сама сформирует чек, а так же запишет данные о продаже.

2. Оплата производится наличными, что доставляет трудности некоторым клиентам ресторана. Необходимо сделать возможным оплату безналичными платежами.

Задача будет решена за счет:
Авторизации платежа.
 
Оплата будет возможна как наличным, так и безналичным платежом.

3. Трудно отследить количество каких полуфабрикатов в морозильнике подходит к концу.

Задача будет решена за счет:
А) Слежения за количеством полуфабрикатов;
Б) Еженедельного формирования заявки поставщику.


Прецеденты:

1.   Проверка наличия полуфабрикатов в морозильнике.
2.   Заказ полуфабрикатов.
3.   Поставка полуфабрикатов.
4.   Выписка счёта-накладной.
5.   Оплата счёта-накладной.
6.   Приёмка полуфабрикатов у поставщика.
7.   Внесение прибывших полуфабрикатов в БД.
8.   Перемещение полуфабрикатов в морозильник.
9.   Доставка полуфабрикатов из морозильника на кухню.
10.    Ввод информации об использованных полуфабрикатах в БД.
11.    Доготовка полуфабрикатов.
12.    Приготовление блюд из готовых полуфабрикатов.
13.    Слежение за количеством готовых блюд.
14.    Ввод информации о готовых блюдах в БД.
15.    Ввод информации о цене блюд в БД.
16.    Считывание информации из БД.
17.    Отображение на терминале количества готовых блюд.
18.    Оформление заказа.
19.    Отображение на терминале заказанных блюд.
20.    Отображение на терминале стоимости блюд.
21.    Подсчёт итоговой стоимости.
22.    Определение формы оплаты.
23.    Оформление чека.
24.    Запись информации о продажах в БД.

Сценарии прецедентов соответственно:

1.   Администратор с помощью терминала следит за остатками полуфабрикатов в морозильнике.
2.   Администратор заказывает необходимое количество полуфабрикатов, исходя из данных по остаткам, полученных из терминала.
3.   Поставщик поставляет необходимые полуфабрикаты в соответствии с заказом Администратора.
4.   Поставщик выписывает счёт-накладную для оплаты поставленной им продукции для ресторана.
5.   Администратор оплачивает счёт-накладную поставщика в соответствии с указанной в ней суммой.
6.   Администратор осуществляет приём полуфабрикатов у поставщика.
7.   Администратор вносит поступившие от поставщика полуфабрикаты в БД.
8.   Администратор перемещает полуфабрикаты в морозильник.
9.   Повар осуществляет доставку полуфабрикатов из морозильника на кухню.
10.    Повар вводит информацию об использованных полуфабрикатах в БД.
11.    Повар осуществляет доготовку полуфабрикатов.
12.    Повар приготавливает блюда из готовых полуфабрикатов.
13.    Повар следит за количеством готовых блюд.
14.    Повар вводит информацию о готовых блюдах в БД.
15.    Администратор вводит информацию о ценах на готовые блюда в БД.
16.    Компьютерно-кассовая система (ККС) считывает информацию из БД.
17.    ККС отображает на терминале кассира количество готовых блюд.
18.    Кассир оформляет заказ в соответствии с потребностями клиента.
19.    ККС отображает на терминале кассира заказанные клиентом блюда.
20.    ККС отображает на терминале стоимость заказанных клиентом блюд.
21.    ККС подсчитывает итоговую стоимость блюд, заказанных клиентом, и выводит её на терминал кассиру.
22.    Кассир определяет форму оплаты заказа в соответствии с видом платежа клиента.
23.    ККС оформляет чек, печатает его.
24.    ККС делает запись о проданных блюдах в БД.

Не понятно в чем заключается ваша проблема:
Разработать правильную диаграмму прецедентов и представить её описание или только в подготовить описание по существующей диаграмме?

Если ответ 1.
Правильно ли я понял что перед вами стоит только 3 задачи?
1. Кассир может забыть цену и наличие какого-либо готового блюда. Нужно сделать так, чтобы кассир располагал актуальной информацией о количестве готовых блюд, и их стоимости в реальном времени.
2. Оплата производится наличными, что доставляет трудности некоторым клиентам ресторана. Необходимо сделать возможным оплату безналичными платежами.
3. Трудно отследить количество каких полуфабрикатов в морозильнике подходит к концу.

Если это так то необходимо ВЫБРОСИТЬ все прецеденты не имеющие отношения к данным задачам.
Кандидаты на выбрасываение - большая часть прецедентов:
- в которых нет ключевого слова БД или терминал
- не связанны с функционированием проектируемой системы.

После того как выкините не целевые прецеденты можно продолжить обсуждение.

Если ответ 2. То собственно в чем вопрос?
2.1. Приведите описание актеров.
2.2. По каждому прецеденту на диаграмме представьте сценарий. Под сценарием подразумевается описание типичного порядка действий актера для достижения цели прецедента и какие могут быть исключительные ситуации и ограничения.

Как отмечено выше такая диаграмма прецедентов не является нормальной поскольку содержит прецеденты не являющиеся часть системы. Смысла написания сценариев для таких прецедентов - нет. Имеет смысл сосредоточиться на сценариях именно взаимодействия актеров с системой.

Проблема заключается только в отчёте, т.к. саму диаграмму преподаватель принял без нареканий.
Можете поподробнее рассказать про описание актёров?
Например описание прецедента "Заказывает необходимое количество полуфабрикатов":


    1.     Администратор заказывает необходимое количество полуфабрикатов, исходя из данных по остаткам, полученных из терминала.

 Это ведь сценарий прецедента и одновременно описание деятельности администратора (актёра). какое именно описание будет правильным? Внешности?)) joke

Проблема заключается только в отчёте, т.к. саму диаграмму преподаватель принял без нареканий.
Можете поподробнее рассказать про описание актёров?
Например описание прецедента "Заказывает необходимое количество полуфабрикатов":


    1.     Администратор заказывает необходимое количество полуфабрикатов, исходя из данных по остаткам, полученных из терминала.

 Это ведь сценарий прецедента и одновременно описание деятельности администратора (актёра). какое именно описание будет правильным? Внешности?)) joke

Преподаватель предложил разделить описание актеров и прецедентов.
Также как и с прецедентами необходимо дать описание каждого актера.
В вашем случае у вас один внешний по отношению к компании Актер, 4 внутренних, причем один из внутренних это ККС.
При описании актера необходимо описать его цели, роль в данном процессе и обязанности по отношению к проектируемой системе.
Например:
Администратор - это сотрудник компании который отвечает за:
- контроль запасов полуфабриктов
- своевременный заказ у поставщика,
- организацию приемки полуфабрикатов
- оплату поставок
- контроль ценообразования
и т.п.

На самом деле не понятно почему "проектируемая в рамках задачи ККС" является актером, поскольку становится не понятным контекст и назначение данной диаграммы прецедентов.
Описание сценария у вас поверхностное, предлагаю поискать в сети пример оформления сценарий по варианту использования. Например здесь: http://www.intuit.ru/department/pl/umlbasics/4/2.html
 
Отступление.

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

Комментарии по поводу познаний вашего преподавателя в UML и назначение диаграммы вариантов использования оставляю за кадром.
Для понимания её назначения специально для вас и поиска разницы даю ссылку: http://www.intuit.ru/department/pl/umlbasics/3/

Поговорил с преподавателем, обсудили с ним диаграмму и отчёт, он сделал много замечаний... На основании его рекомендаций, диаграмму и отчёт немного переделал. Подскажите пожалуйста, что подправить?
Диаграмму прецедентов вложил в сообщение.
Отчёт по ней:
Описание требований к проектируемой системе.
Задачи и их решения.
1. Кассир может забыть цену и наличие какого-либо готового блюда. Нужно сделать так, чтобы кассир располагал актуальной информацией о количестве готовых блюд, и их стоимости в реальном времени.

Задача будет решена за счет:
А) Слежения за количеством готовых блюд;
Б) Внесения информации о ценах блюд в БД.

У кассира будет кассовый терминал с монитором.
С помощью этого терминала кассир сможет следить за количеством готовых блюд и за их стоимостью.
Каждое блюдо будет иметь свой идентификационный номер.
Кассир будет набивать на экране терминала заказанные блюда, система сама сформирует чек, а так же запишет данные о продаже.

2. Оплата производится наличными, что доставляет трудности некоторым клиентам ресторана. Необходимо сделать возможным оплату безналичными платежами.

Задача будет решена за счет:
Авторизации платежа.
 
Оплата будет возможна как наличным, так и безналичным платежом.

3. Трудно отследить количество каких полуфабрикатов в морозильнике подходит к концу.
Задача будет решена за счет:
А) Слежения за количеством полуфабрикатов;
Б) Своевременного формирования заявки поставщику.

Описание актёров:
1.   Кассир. Работник ресторана, в задачи которого входит обслуживание посетителей за кассой: принятие заказа и его оплата.
2.   Банк. Задача банка – авторизировать платёж по кредитной карте посетителя.
3.   Администратор. Администратор осуществляет приём полуфабрикатов у поставщика, вводит информацию о ценах на готовые блюда в БД, следит за перебойной работой ресторана в целом, формирует заявки на необходимые полуфабрикаты поставщику.
4.   Поставщик. Поставщик привозит необходимые полуфабрикаты, заносит информацию о количестве полуфабрикатов в БД.



Сценарии прецедентов:
1.   Фиксация полученных полуфабрикатов. Поставщик заносит данные о количестве привезённых им полуфабрикатов в БД ККС. ККС фиксирует в БД наличие полуфабрикатов в морозильнике, исходя из данных о продажах. Если полуфабрикатов осталось мало, ККС выводит сообщение «ALERT».
2.   Формирование заявки поставщику. ККС считывает информацию с БД о продажах. Если количество полуфабрикатов подходит к нулю, система посылает заявку поставщику.
3.   Оформление заказа. Кассир принимает заказ в соответствии с потребностями клиента.
4.   Оплата. Система подсчитывает сумму заказа, кассир производит оплату либо наличными, либо банковской картой. Во втором случае ККС посылает запрос банку на авторизацию платежа.
5.   Авторизация заказа. ККС проверяет наличие готовых блюд, считывает из БД информацию о них и выводит кассиру на экран, записывает информацию о проданных блюдах в БД.