Дефрагментация мозга

• не моделирования, а в основном рисования иллюстраций, поясняющих текст многочисленных комментариев.

Поэтому использование UML имеет две основные альтернативы, напрямую зависящие от целей:

• Цель – использовать «как есть». Не заниматься вопросами целостности, ограничившись рисованием частей системы в разных ракурсах. Если повезёт, то часть кода можно будет генерировать из схем.

• Цель – использовать для моделирования и генерации кода. Придётся создать свои формализмы, соответствующие моделируемой области. В самом минимальном варианте – использовать в принудительном порядке стереотипы и написанные руками скрипты и ограничения для проверки непротиворечивости такого использования. Чтобы, например, стереотип «Водитель» в рамках ассоциаций «Управление машинами» был связан только с классом, реализующим интерфейс «Транспортное средство».

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

Поэтому в большинстве ситуаций программисты находятся в «случае номер один», да и то не всегда. Потому что вместо «порисовали картинки и пиши код» все может ограничиться «пиши код и не отвлекайся на теории яйцеголовых».

С картинками в UML сложилась некоторая неразбериха вкупе с излишествами. Например, диаграммы деятельности (activity diagram), состояний (state machine diagram) и последовательностей (sequence diagram), а также их многочисленные подвиды по большому счёту описывают одно и то же – поток управления в программе.

У Киплинга есть замечательный рассказ «Как было написано первое письмо». Про неудачный опыт использования графической нотации первобытными людьми. Но если в рассказе все закончилось хорошо, то в современном проекте была ситуация, когда двум проектировщикам по отдельности поручили делать диаграммы переходов для одного и того же набора классов. Получилось очень «унифицированно»: найти хотя бы одну пару общих элементов в двух диаграммах было затруднительно. Если методология проектирования действительно существует, то работа двух людей даёт сопоставимый результат.

С другой стороны, для фиксации знаний программиста о предметной области основой являются прецеденты, варианты использования (use case diagram) из эллипсов, «палка, палка, огуречик» – человечков и комментариев. В UML рекомендуется использовать комментарии для отражения требований к системе, а сами прецеденты неформальны. При отсутствии проработанной системы стереотипов приходится, например, отделять приходные документы от расходных с помощью раскраски. Процитирую фрагмент из главы 8 адаптированного перевода «Введения в RUP» [22].

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

Столь длинное вступление к главе напрямую связано с так называемым анализом прецедентов в UML. Это идеальный инструмент для создания птолемеевых систем. Только если модель Птолемея является геоцентрической, то прецеденты использования – модель заказчико-центрическая.

Прецеденты, как и геоцентрическая модель, могут удовлетворительно описывать явление, не касаясь его сущности. Всякий раз разработчики очередного корпоративного приложения создают свою «птолемеевскую систему», которая при попытке примерить ее на другую фигуру внезапно оказывается неподходящей и нуждается в серьёзной перекройке. Так и земная птолемеевская система не работает для наблюдателя, находящегося на Марсе. Если же прецеденты рисуются коллективом, то будет уместно также вспомнить притчу про слона и семь слепых мудрецов, так и не пришедших к единогласию о том, что же они на самом деле ощупывают.

Явление зависит от условий наблюдения. Сущность от этих условий не зависит.