Дефрагментация мозга. Софтостроение изнутри

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

...

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

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

Подобно уточняющим геоцентрическую модель эпициклам, на диаграмму накручиваются всё новые прецеденты. Видимо, поэтому в RUP рекомендуют не увлекаться наворачиванием прецедентов друг на друга ( avoiding functional design ). Исходя из этого совета можно легко перейти в иную крайность, увидев «альтернативу» в том, чтобы побольше писать кода для заказчика и поменьше строить моделей. Хотя сущность явления достаточно проста: независимо от вида расчёта, скидок, кредитов и прочего во всех прецедентах имеет место движение денежных средств, суть взаимных обязательств, выраженных в общепринятом количественном (денежном) виде. В большинстве случаев оптимальным средством для моделирования этого процесса является регистрация количественного выражения обязательств в системе счетов предприятия.

Альтернатив, к сожалению, немного. Об основной – создании собственных предметно-ориентированных языков, мета-языков – уже сказано, и не раз, в том числе в рамках описаний конкретных систем. Далеко не факт, что для этого будет нужен UML хоть в каком-то виде.

Отрасль же в очередной раз оказалась в интересном положении, когда «лучше такой UML, чем никакой». Слишком часто формулировка «лучше плохой, чем никакой» стала широко применяться, что настораживает. Но прогресс, развивающийся по законам бизнеса, неотвратим, даже если слово «прогресс», при наличии на то оснований, заключать в кавычки.

Из положительных моментов UML и поддерживающих его сред необходимо отметить, что в ситуации, когда задача складывается, как мозаика, из обрывочных сведений представителей заказчика, прецеденты помогут хоть как-то формализовать и зафиксировать неиссякаемый поток противоречивых требований. Неважно, что мозаика может, скорее всего, не сложиться в стройную картинку, но при отсутствии экспертизы в предметной области риски недопонимания и недооценки снижаются. Наиболее проработанная часть UML – диаграмма классов – при определённых усилиях и дисциплине программистов, конечно, поможет вам автоматизировать генерацию части рутинного кода приложения.

Большой интерес представляют так называемые «двусторонние» инструменты ( two-way tools ), тесно интегрированные со средами программирования и позволяющие непосредственно во время разработки оперировать диаграммами с одновременным отражением изменений в коде и, наоборот, импортировать меняющийся руками код в модель. Таковы, например, ModelMaker или Together. Но если для повышения продуктивности отдельного программиста такой подход даёт хорошие результаты, то необходимость синхронизации моделей при коллективной работе над общим кодом может свести преимущества к минимуму.

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

Когда старая школа молода