Майкл,
Ваш учитель, кажется, до смерти от UML Fever ( Ссылка на статью ): -)
Многие люди имеют "неправильное" понимание UML. (Чтоэто так, а что нет)
UML - это просто стандартные графические обозначения, строки и т. д. .Визуальное моделирование с общими обозначениями может быть очень полезным, , но вряд ли это так же важно, как знать , как проектировать и мыслить в объектах.Такие знания по проектированию - это совсем другой и более важный навык, и не овладевают изучением UML-нотации или использованием инструмента CASE или MDA. Человек, не имеющий хороших навыков в области ОО-проектирования и программирования, который рисует UML, просто рисует плохие проекты. Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и итеративную разработку, третье издание, КрейгЛарман [ 1.6.Что такое UML?] )
А также имеет «неправильное понимание» при рисовании диаграмм UML (когда рисовать диаграмму и кто ее будет рисовать)
Полезные UML зарисованы опытными OO-программистами (в идеале парами на досках) в качестве помощи для творчества мысли и коммуникации , прежде чем они сами используют свои собственные эскизы * каквдохновение * во время программирования.... Что важно, так это возможность создавать хорошие проекты и программы для объектов - искусство OOA / D. Когда резина выходит на дорогу, и код должен быть сокращен, важно то, что наша способность назначатьответственность и создать дизайн с низким сцеплением, высокой связностью, понятностью и простотой модификации. Это очень отличается от знания диаграммной нотации, такой как UML. ( Крейг Ларман, Что такое UML, а что нет Ссылка на статью )
И многие люди думают, что в UML есть только одна диаграмма: (или только одна полезная диаграмма), которая является Диаграмма классов .Это также неправильно.
Название парадигмы: Объектно-ориентированное Моделирование / Проектирование / Программирование /. Не ориентированный на класс ... Диаграммы классов просто показывают статические отношения между вашими классами. Вы не можете понять истинно объектно-ориентированную систему, а просто смотрите на ее «статическую» структуру.
Структура времени выполнения объектно-ориентированной программы часто мало похожа на ее структуру кода .Структура кода заморожена во время компиляции;он состоит из классов в фиксированных отношениях наследования. Структура времени выполнения программы состоит из быстро меняющихся сетей взаимодействующих объектов. Фактически, эти две структуры в значительной степени независимы. Пытаться понять одно из другого - все равно, что пытаться понять динамизм живых экосистем из статической таксономии растений и животных и наоборот. [Шаблоны проектирования, элементы многоразового объектно-ориентированного программного обеспеченияЭрих Гамма, Ричард Хелм, Ральф Джонсон, Джон Влиссидес [Соотношение структур времени выполнения и времени компиляции]
Таким образом, исследовать эти взаимодействия с помощью диграмм последовательности или коммуникации можнобыть также полезным.
Как правило: (очень простое, поэтому забытое правило)
Если вы рисуете диаграмму, у вас должна быть веская причина:Почему вы делаете это?Если у вас нет конкретного ответа (ответ должен показывать реальную выгоду), ничего не рисуйте.Моделирование не является документальным занятием. И ешьте собачью еду.Рисуй для себя, а не для других.