Тут в одной ветке мы уже немного обсуждаем, что в UML 2.5.1 несколько иначе трактуется use case, чем это обсуждалось в той самой ветке.
 
Может поговорим, почему object diagram более не поддерживается стандартом?

Мне представляется, что когда-то местом для описания диаграмм сделали UML Reference Manual и т. п. руководства. Стандарт не так уж много внимания уделял диаграммам в прошлом. В этом плане последняя версия в приложениях сравнительно много говорит о диаграммах. Появился кусок метамодели UML, посвящённый диаграммам. На UmlObjectDiagram даже одно ограничение навесили.

Мне представляется, что когда-то местом для описания диаграмм сделали UML Reference Manual и т. п. руководства. Стандарт не так уж много внимания уделял диаграммам в прошлом. В этом плане последняя версия в приложениях сравнительно много говорит о диаграммах. Появился кусок метамодели UML, посвящённый диаграммам. На UmlObjectDiagram даже одно ограничение навесили.

Ага, вот оно в чем дело. Спасибо.

Написанное мною, не соответствует стандарту UML 1.4. В первом UML описание стандарта языка строилось вокруг диаграмм, т. е. вокруг ранее независимых нотаций, брошенных в плавильный котёл UML. Поэтому в стандарте UML 1.4 есть определение диаграммы объектов. С переходом ко второй версии точка зрения авторов стандарта сместилась. Софтина, работающая с UML-моделью -- трансформатор, кодогенератор, анализатор -- не интересуется диаграммами, видит общую кучу элементов модели и связей между ними, вычленяя то, что её интересует по типам элементов и связей, а не по факту принадлежности элементов одной и той же диаграмме или разным. В подобном виде переписан стандарт UML. В стандарте UML 2.4.1 нет определения не только для диаграммы объектов, но и для диаграммы классов. Также в стандарте UML 2.4.1  приводится иллюстрация, являющаяся смешением диаграммы деятельности с диаграммой классов. Видимо, авторов стандарта увлекала идея сплавления подъязыков UML в единое целое. В последней версии стандарта постулируется зыбкость границ между разными типами диаграмм (контрастирующая с привычным ходом составления самих диаграмм в какой-либо UML-среде).

Написанное мною, не соответствует стандарту UML 1.4. В первом UML описание стандарта языка строилось вокруг диаграмм, т. е. вокруг ранее независимых нотаций, брошенных в плавильный котёл UML. Поэтому в стандарте UML 1.4 есть определение диаграммы объектов. С переходом ко второй версии точка зрения авторов стандарта сместилась. Софтина, работающая с UML-моделью -- трансформатор, кодогенератор, анализатор -- не интересуется диаграммами, видит общую кучу элементов модели и связей между ними, вычленяя то, что её интересует по типам элементов и связей, а не по факту принадлежности элементов одной и той же диаграмме или разным. В подобном виде переписан стандарт UML. В стандарте UML 2.4.1 нет определения не только для диаграммы объектов, но и для диаграммы классов. Также в стандарте UML 2.4.1  приводится иллюстрация, являющаяся смешением диаграммы деятельности с диаграммой классов. Видимо, авторов стандарта увлекала идея сплавления подъязыков UML в единое целое. В последней версии стандарта постулируется зыбкость границ между разными типами диаграмм (контрастирующая с привычным ходом составления самих диаграмм в какой-либо UML-среде).

А куда это может нас привести, как Вы полагаете? Сплавление одни диаграмм в целом кажется разумным, но других выглядит почти безумием. Но возможно гениальным
К

Не знаю и не берусь предсказать. Если будет технология и инструменты, соответствующие этим (пока чрезмерным, на мой взгляд) выразительным возможностям UML 2.5.1, то прогресс пойдёт.