Форум Сообщества Аналитиков

×


Подскажите начинающему ассистенту преподавателя(Прочитано 9338 раз)
Товарищи, доброго времени дня

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

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

P.S. я больше специализируюсь на архитектуре предприятия, UML пошел туго. Но честно-честно пытался понять и осознать UML
« Последнее редактирование: 06 Сентября 2016, 01:36:59 от xedaler »



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

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



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

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



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



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



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

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

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



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

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

...

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

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

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

Почему бы не взять за основу курса архитектуру предприятия, рассказать о принципах ее формирования/выбора, о специфике функционирования тех или иных моделей? Это более чем информатика.
« Последнее редактирование: 07 Сентября 2016, 14:21:48 от Леонид »



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

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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19