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

http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D0%B9_%28UML%29
Что необычно, в английской есть такой же бред:
http://en.wikipedia.org/wiki/State_diagram_%28UML%29
Правда, имеется нормальная статья:
http://en.wikipedia.org/wiki/UML_state_machine, но отчего-то для перевода в русскую википедию выбрали не её.

Виктор, добрый день. С Новым годом.

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

Если серьезно, думаю тут все относительно просто. Первая статья небольшая, перевести ее большого труда не составило. Таким образом некто Пес-призраг сохранил себя в истории.

Причем английская страница ведет на несколько иную страницу на русском http://ru.wikipedia.org/wiki/Диаграмма_состояний_(теория_автоматов), которая по созданию СТАРШЕЕ других англоязычных аналогов

Однако вот подобные статьи - удар по репутации.

Виктор, что не так с диаграммой?

1. [start] - определено как сторожевое условие, но это неправильно. Start - не условие, а триггер
2. и т.д.

n-1. retrivial - незнакомое слово, имелось в виду видимо Retrival - считывание.
n. использование do/wait просто глупо
n+1. вообще не сказано, что за объект. Это не есть гуд

а в этой статье по-вашему правильно изображена диаграмма деятельности http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%B4%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8
?

Есть ошибки. Некоторые стрелки не показаны. Возможно есть семантическая путаница. Ситаксически практически верно. Прагматику понять тоже можно - попытка описать алгоритм проведения мозгового штурма, вполне к месту

а в этой статье по-вашему правильно изображена диаграмма деятельности?

Абстрагируясь от смысла, плохими являются следующие фрагменты:
1) Есть три узла действия, в которые входят по два потока управления. По UML 2.0 узел осуществляет синхронизацию таких потоков. Согласно диаграмме возникнет блокировка в этих узлах.
2) Присутствуют "склеенные" потоки (т. е. две стрелки выходят из разных узлов, сливаются и втыкаются в один). Следовало явно указать merge-узлы.
3) Не ошибка, но рекомендуется не объединять decision и merge узлы в один. Т. е. в ромбике либо один вход и несколько выходов, либо несколько входов и один выход.

Виктор, добрый день. С Новым годом.

Эдуард, благодарю за поздравления! Поздравляю с Рождеством! Благополучия и проветания!

Виктор, что не так с диаграммой?

Эдуард указал, что перепутаны сторожевые условия и триггеры. Из-за этого триггером всех переходов будет событие завершения. Для состояния Running, в котором нет ни действий, ни деятельности, это полная бессмыслица. Из каждого состояния  по событию завершения может быть запущен один из двух исходящих переходов. Независимо от того, что имелось в виду под условиями на переходах, возможен недетерминизм, если оба условия выполнены, который вряд ли тут хотели проиллюстрировать. А если по завершении не выполнилось ни одно из условий, происходит блокировка автомата, так как событие завершения больше не наступит.
Деятельность wait в состоянии Paused -- то, от чего пытаюсь отучить студентов в течение семестра. Автор диаграммы полагает, что чтобы ничего не делать, надо делать "ничего".

Можно полюбоваться на диаграмму композитной структуры:
http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%B7%D0%B8%D1%82%D0%BD%D0%BE%D0%B9_%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D1%8B
Логика видимо такая, если вокруг фрагмента диаграммы классов нарисовать овал, сразу получается композитная структура.

Логика видимо такая, если вокруг фрагмента диаграммы классов нарисовать овал, сразу получается композитная структура.

Есть предложение показать ошибки или правильную диаграмму

Есть предложение показать ошибки или правильную диаграмму

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

Абстрагируясь от смысла, плохими являются следующие фрагменты:
1) Есть три узла действия, в которые входят по два потока управления. По UML 2.0 узел осуществляет синхронизацию таких потоков. Согласно диаграмме возникнет блокировка в этих узлах.
2) Присутствуют "склеенные" потоки (т. е. две стрелки выходят из разных узлов, сливаются и втыкаются в один). Следовало явно указать merge-узлы.
3) Не ошибка, но рекомендуется не объединять decision и merge узлы в один. Т. е. в ромбике либо один вход и несколько выходов, либо несколько входов и один выход.

вот это я и хотел услышать, чтоб убедиться - не мне одному так кажется

Эдуард указал, что перепутаны сторожевые условия и триггеры. Из-за этого триггером всех переходов будет событие завершения. Для состояния Running, в котором нет ни действий, ни деятельности, это полная бессмыслица. Из каждого состояния  по событию завершения может быть запущен один из двух исходящих переходов. Независимо от того, что имелось в виду под условиями на переходах, возможен недетерминизм, если оба условия выполнены, который вряд ли тут хотели проиллюстрировать. А если по завершении не выполнилось ни одно из условий, происходит блокировка автомата, так как событие завершения больше не наступит.
Деятельность wait в состоянии Paused -- то, от чего пытаюсь отучить студентов в течение семестра. Автор диаграммы полагает, что чтобы ничего не делать, надо делать "ничего".

В статье там представлена диаграмма состояния неизвестного объекта с неизвестными бизнес-правилами в неизвестной версии нотации.
Причём из названия «пример диаграммы состояний» не следует, что это эталонная диаграмма. Это просто КАКАЯ-то диаграмма, возможно, с ошибками и в содержании и нотации модели.

На мой взгляд, всё это говорит плохо о UML в той же степени, что и о wikipedia.

Если то, что кружки/квадратики обозначают состояния чего-то, а стрелки — возможные направления перехода, понятно большинству людей из их опыта столкновения с инфографикой, начиная с детского возраста, то вот обозначения сторожевых условий / условий перехода — это уже похоже какая-то книжная муть, типа include/extend у use case diagram.

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

Студенту нашли, что ответить?

то вот обозначения сторожевых условий / условий перехода — это уже похоже какая-то книжная муть, типа include/extend у use case diagram.

сторожевое условие - это не муть и далеко не типа include/extend у use case diagram.

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

диаграммы состояний (или автоматов) появились задолго до UML, так же как и теория автоматов, которая, конечно, порой недоступна каждому. Отличное использование ее можно найти в пакете Matlab - Stateflow

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

диаграмма в UML теряет свою строгость, приобретая описательную силу и универсальность