Дефрагментация мозга. Софтостроение изнутри
Шрифт:
Пишу я об этом вовсе не потому, что IDEF-стандарты такие крутые, несмотря на то, что системные аналитики ими часто пользуются. Просто небольшой сравнительный пример из закромов собственной практики.
Наконец, главное слово, «язык». Графические образы – это, конечно, аналог слов, но не всякий набор слов является языком. Поэтому UML до языка ещё далеко. Язык, даже естественный, можно автоматически проверить на формальную правильность. Входящий в UML OCL хоть и является языком, но выполняет лишь малую часть работы по проверке, и не собственно модели, а её элементов. А о способностях проверить модель написано выше.
Всё сказанное не должно вас смущать и поражать новизной. Ведь и XML тоже не язык, несмотря на соответствующую букву в аббревиатуре, а
Итак, UML:
• не универсальный, а унифицированный, объединяющий отдельные практики;
• не язык, а набор нотаций (графических);
• не моделирования, а в основном рисования иллюстраций, поясняющих текст многочисленных комментариев.
Поэтому использование UML имеет две основные альтернативы, напрямую зависящие от целей:
• Цель – использовать «как есть». Не заниматься вопросами целостности, ограничившись рисованием частей системы в разных ракурсах. Если повезёт, то часть кода можно будет генерировать из схем.
• Цель – использовать для моделирования и генерации кода. Придётся создать свои формализмы, соответствующие моделируемой области. В самом минимальном варианте – использовать в принудительном порядке стереотипы и написанные руками скрипты и ограничения для проверки непротиворечивости такого использования. Чтобы, например, стереотип «Водитель» в рамках ассоциаций «Управление машинами» был связан только с классом, реализующим интерфейс «Транспортное средство».Во втором случае формализация модели является, по сути, созданием предметно-ориентированного языка, то есть серьёзной исследовательской работой вплоть до уровня научной диссертации. Далеко не каждая софтостроительная фирма может позволить себе вести такие работы без ясных перспектив тиражирования своих продуктов.
Поэтому в большинстве ситуаций программисты находятся в «случае номер один», да и то не всегда. Потому что вместо «порисовали картинки и пиши код» все может ограничиться «пиши код и не отвлекайся на теории яйцеголовых».
С картинками в UML сложилась некоторая неразбериха вкупе с излишествами. Например, диаграммы деятельности ( activity diagram ), состояний ( state machine diagram ) и последовательностей ( sequence diagram ), а также их многочисленные подвиды по большому счёту описывают одно и то же – поток управления в программе.
У Киплинга есть замечательный рассказ «Как было написано первое письмо». Про неудачный опыт использования графической нотации первобытными людьми. Но если в рассказе все закончилось хорошо, то в современном проекте была ситуация, когда двум проектировщикам по отдельности поручили делать диаграммы переходов для одного и того же набора классов. Получилось очень «унифицированно»: найти хотя бы одну пару общих элементов в двух диаграммах было затруднительно. Если методология проектирования действительно существует, то работа двух людей даёт сопоставимый результат.
С другой стороны, для фиксации знаний программиста о предметной области основой являются прецеденты, варианты использования ( use case diagram ) из эллипсов, «палка, палка, огуречик» – человечков и комментариев. В UML рекомендуется использовать комментарии для отражения требований к системе, а сами прецеденты неформальны. При отсутствии проработанной системы стереотипов приходится, например, отделять приходные документы от расходных с помощью раскраски. Процитирую фрагмент из главы 8 адаптированного перевода «Введения в RUP» [22].. .Диаграмма прецедентов показывает деловые субъекты, деловые прецеденты, пакеты деловых прецедентов и связи между ними. Никаких строгих правил относительно того, что нужно показывать в диаграммах прецедентов, не существует. Вы показываете те связи в модели, которые считаете интересными. .
Столь длинное вступление к главе напрямую связано с так называемым анализом прецедентов в UML. Это идеальный инструмент для создания птолемеевых систем. Только если модель Птолемея является геоцентрической, то прецеденты использования – модель заказчико-центрическая.
Прецеденты, как и геоцентрическая модель, могут удовлетворительно описывать явление, не касаясь его сущности. Всякий раз разработчики очередного корпоративного приложения создают свою «птолемеевскую систему», которая при попытке примерить ее на другую фигуру внезапно оказывается неподходящей и нуждается в серьёзной перекройке. Так и земная птолемеевская система не работает для наблюдателя, находящегося на Марсе. Если же прецеденты рисуются коллективом, то будет уместно также вспомнить притчу про слона и семь слепых мудрецов, так и не пришедших к единогласию о том, что же они на самом деле ощупывают.
Явление зависит от условий наблюдения. Сущность от этих условий не зависит.
Применительно к разработке программных систем. Вы описываете какой-то отдельный прецедент в том виде, в котором наблюдаете. Или, скорее всего, со слов участников. Например, «оплата в кассу». Пока расчёты наличные, вы наблюдаете перемещение монет и купюр из кошелька покупателя в кассу продавца. И считаете, что движение денег – это физическое перемещение монет. В один прекрасный день возникнет необходимость принимать к оплате безналичные средства, например карты. Возникают проблемы с прежней постановкой: ничего физически не перемещается. Имеем уже два прецедента: «оплата в кассу наличными» и «оплата в кассу безналичными». Послезавтра возникнет новый способ оплаты – в кредит, но операцию покупки проводят все в той же кассе. Потом с учётом скидок. Потом с учётом истории покупок по «клубной» карте и так далее.
Подобно уточняющим геоцентрическую модель эпициклам, на диаграмму накручиваются всё новые прецеденты. Видимо, поэтому в RUP рекомендуют не увлекаться наворачиванием прецедентов друг на друга ( avoiding functional design ). Исходя из этого совета можно легко перейти в иную крайность, увидев «альтернативу» в том, чтобы побольше писать кода для заказчика и поменьше строить моделей. Хотя сущность явления достаточно проста: независимо от вида расчёта, скидок, кредитов и прочего во всех прецедентах имеет место движение денежных средств, суть взаимных обязательств, выраженных в общепринятом количественном (денежном) виде. В большинстве случаев оптимальным средством для моделирования этого процесса является регистрация количественного выражения обязательств в системе счетов предприятия.
Альтернатив, к сожалению, немного. Об основной – создании собственных предметно-ориентированных языков, мета-языков – уже сказано, и не раз, в том числе в рамках описаний конкретных систем. Далеко не факт, что для этого будет нужен UML хоть в каком-то виде.
Отрасль же в очередной раз оказалась в интересном положении, когда «лучше такой UML, чем никакой». Слишком часто формулировка «лучше плохой, чем никакой» стала широко применяться, что настораживает. Но прогресс, развивающийся по законам бизнеса, неотвратим, даже если слово «прогресс», при наличии на то оснований, заключать в кавычки.
Из положительных моментов UML и поддерживающих его сред необходимо отметить, что в ситуации, когда задача складывается, как мозаика, из обрывочных сведений представителей заказчика, прецеденты помогут хоть как-то формализовать и зафиксировать неиссякаемый поток противоречивых требований. Неважно, что мозаика может, скорее всего, не сложиться в стройную картинку, но при отсутствии экспертизы в предметной области риски недопонимания и недооценки снижаются. Наиболее проработанная часть UML – диаграмма классов – при определённых усилиях и дисциплине программистов, конечно, поможет вам автоматизировать генерацию части рутинного кода приложения.