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

Добрый день!

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

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

нет, всё верно, я на этой диаграмме хотел показать кто задействован и их функции при реализации готовой продукции хлебопекарни

преподаватель сделал вот такое замечание: "Нет связей между функциями. Функции не конкретны."
Что значит функции не конкретны? И как их связать друг с другом?

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

нет, всё верно, я на этой диаграмме хотел показать кто задействован и их функции при реализации готовой продукции хлебопекарни

Значит вам нужна другая нотация.
Диаграмма вариантов использования из UML для этого совсем не подходит, т.к. описывает полезные функции некоей автоматизированной системы и сущностей с ней взаимодействующих.
А вам нужно отобразить бизнес-процесс реализации готовой продукции. Используйте BPMN.

Нотация не виновата. Метод H. E. Eriksson'а and M. Penker'а позволяет использовать нотацию и [конкретно] диаграмму вариантов использования для бизнес-моделирования.

Нотация не виновата. Метод H. E. Eriksson'а and M. Penker'а позволяет использовать нотацию и [конкретно] диаграмму вариантов использования для бизнес-моделирования.

А не могли бы привести примеры или указать на ссылку?

"Rational Edge" 11.2002

"Rational Edge" 11.2002

Спасибо, но разве это метод H. E. Eriksson'а and M. Penker'а У них нотация обозначения вроде бы совершенно иная?

"Rational Edge" 11.2002

Спасибо, очень занимательное руководство.
Но во первых там целый комплекс диаграмм, а не только ДВИ
А во вторых, при всём уважении к парням из Rational, похоже на инструкцию "Как правильно забивать гвозди нашим микроскопом"

Спасибо, но разве это метод H. E. Eriksson'а and M. Penker'а У них нотация обозначения вроде бы совершенно иная?

Я не сразу поняло, о чём Вы. Признаю за собой заблуждение относительно E&P-метода, полистав ссылку. Полагало, то рейшеналовские "мужики с гвоздями в голове и треснутые яйца" являются развитием идей E&P. Добавлю, что и за E&P признаю заблуждение. Полагать, что их Process-диаграмма является размеченной стереотипами диаграммой деятельности, сейчас не осталось никакой возможности. А представить её юз-кейс-диаграммой можно вполне.

Спасибо, очень занимательное руководство.
Но во первых там целый комплекс диаграмм, а не только ДВИ
А во вторых, при всём уважении к парням из Rational, похоже на инструкцию "Как правильно забивать гвозди нашим микроскопом"

А в-третьих, ю-к-диаграмму можно таки использовать как перечень бизнес-процессов предприятия. О чём изначально и шла речь.
А в-четвёртых, известно, что в IBM/Rational -- все малахольные, но возможности использования нотации из-за этого не сужаются.
А в-пятых, основные проблемы автора топика не связаны с выбором нотации. Выбора у него, собственно и нет.

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

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

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

Суть ДВИ - не более чем отражение связей акторов и сценариев между собой.

Если брать Вашу ДВИ я бы сделал следущие изменения:

1) Использовал бы Boundary для группировки UC . Например Фирма, или Автоматизированная система для того чтобы отделить UC которые происходят внутри них или за их границами
2) Развел бы акторов по разным сторонам диаграммы. Работники фирмы налево, клиенты и  прочие внешние сущности направо
3) Ввел бы актора Сотрудник, остальных акторов , кроме клиента наследовал бы от него. А может быть вообще ввел актора Лица.