Товарищи, доброго времени дня

Так сложилось, что я стал ассистентом преподавателя по направлению "Бизнес-информатика". Сейчас мы готовим учебный курс, часть из которого включает построение диаграмм UML. Рассматривается учебный кейс про компанию, занимающуюся доставкой отправлений

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

P.S. я больше специализируюсь на архитектуре предприятия, UML пошел туго. Но честно-честно пытался понять и осознать UML

Коммуникационная диаграмма перепутана с диаграммой последовательности.
На диаграмме классов есть Заказ, но из диаграммы вариантов использования не следует, что какие-либо действия с заказом совершаются.
Сигнатуры атрибутов ещё куда ни шло (действительно ли нужно указывать типы латиницей?), но у операций -- нет слов. В дополнение к этому замечанию укажу, что ни одно сообщение с диаграмм взаимодействия нельзя связать ни с одной операцией. Поясняю, если объект-сотрудник посылает сообщение "наклеивает номера" объекту-отправлению, это значит, что у отправления есть операция "наклеивает номера" и это оно -- отправление -- их наклеивает.
Диаграмма состояний бессмысленна. Entry и exit -- это действия по входу и выходу, а не события, вызывающие смену состояний. Таковые события следует указывать на переходах.

Подсказать в такой ситуации можно следующее: на русском языке есть достаточное количество учебников (обычно, переводных) с учебными примерами по UML. Там бывают ошибки, но более мелкие, чем те, что указаны выше. Используйте примеры из проверенных источников.

Сигнатуры атрибутов ещё куда ни шло (действительно ли нужно указывать типы латиницей?), но у операций -- нет слов.

Огромное спасибо за ответ!

А не подскажете, с операциями совсем беда? Вроде звучит более-менее адекватно...

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

Что Вы показываете на диаграмме, зависит от того, с какой целью Вы её рисовали. Вы не привели никаких описаний, поэтому диаграммы можно оценивать лишь как есть -- т. е. по соответствию/несоответствию правилам UML. Операции представляют в модели ответственности объектов класса, они же являются обработчиками принятых объектами сообщений. Но в модели, которую Вы представили, это не так.

Путем изучения разных книг (включая "Освой UML за 24 часа" Шмуллера) провел работу над ошибками

Исправил диаграмму прецедентов, диаграмму классов, диаграмму последовательности и диаграмму коммуникации. Так ведь стало лучше, или тоже ерунда?

Что делать с состояниями - ума не приложу. Пытаюсь найти нормальный пример, но пока никак

Товарищи, доброго времени дня

Так сложилось, что я стал ассистентом преподавателя по направлению "Бизнес-информатика". Сейчас мы готовим учебный курс, часть из которого включает построение диаграмм UML.

...

P.S. я больше специализируюсь на архитектуре предприятия, UML пошел туго. Но честно-честно пытался понять и осознать UML

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

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

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

Так ведь стало лучше, или тоже ерунда?

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

На диаграмме классов ассоциацию между Отправлением и Типом отправления замените на зависимость Отправления от Типа.
На диаграмме последовательности было бы логичнее сначала добавлять заказ созданному клиенту, а затем добавлять отправления в заказ. Отправление, являющееся частью заказа, т. о. подчинённое ему, ведёт себя с заказом "не по рангу". Кроме того, на диаграмме антипаттерн "телепатия": как Отправление может догадаться, что создан заказ и пора посылать ему сообщение "добавь меня"? Никак. Откуда у отправления может возникнуть ссылка на только что созданный заказ?

Диаграмма состояний могла бы обрести смысл, если бы фиксировала переходы между разными состояниями (способами поведения) объектов. Как пример, при составлении заказа в него можно добавлять отправления, но в созданный и отправленный заказ добавлять что-либо поздно.