UML и птолемеевские системы

Материал этой статьи послужил основой для главы "UML и птолемеевские системы", входящей в книгу "Дефрагментация мозга. Софтостроение изнутри".

...Обе системы (Коперника и Птолемея) отражали и отражают объективные явления материального мира. Современная наука, отказавшись от птолемеевской системы, не отказалась от птолемеевского подхода для описания видимого движения планет на небесной сфере.

Итак, что же заставило ученых отказаться от системы Птолемея? Ответ с позиций современной теории познания мы видим в следующем. Система Птолемея описывала (хорошо или плохо - не столь принципиально) движение планет, видимое с Земли, т.е. описывала явление. Если же мы оказались, например, на Меркурии или Марсе, то земную птолемеевскую систему нам пришлось бы упразднить и заменить новой. Система Коперника сумела схватить сущность взаимного движения планет солнечной системы. Такое описание, говоря современным языком, уже не зависело от того, какую планету в качестве системы отсчета захочет выбрать себе наблюдатель.

С точки зрения теории познания объективной истины теологи совершали грубейшую ошибку: они сущность подменяли явлением. Наблюдаемое с Земли движение планет по небосводу они считали их действительным движением в пространстве (Текст отсюда)

Почему понадобилось столь длинное вступление? Возьмем пресловутый "анализ" прецедентов в UML, варианты использования - use case-ы. Поражает, насколько это похоже на повсеместно используемое построение модели по явлениям, а не по сущности! Каждый разработчик очередного "склада" или "магазина" создает свою "птолемеевскую систему", которая при попытке примерить ее на другой склад или магазин "вдруг" перестает работать, как не работает и настоящая птолемеевская система для наблюдателя, находящегося на Марсе. Уместно еще вспомнить притчу про слона и семь слепых мудрецов.

По ссылке - обсуждение темы "Моделирование бизнес-процессов" с воспоследовавшей критикой UML (что называется, наболело), сопосталением с IDEF, разбором недостатков на конкретном примере, формулированием требований к языку моделирования. Прошло 7 лет, а воз и ныне там.

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

Смотрим на небо. Солнце движется с востока на запад. Это явление. Сущность этого явления в том, что Земля движется вокруг Солнца, а не наоборот, как кажется из явления.

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

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

Можно возразить, что варианты использования - это описание функциональных требований к системе и все. При чем тут "сущность" и "явление"? Делай, что требуют и не бухти :) В конце концов, экстремальные методики разработки примерно на это и ориентированы.

Во-первых, функциональные требования (ФТ) это не единственные требования к системе (ТС). Не зря в UML рекомендуется использовать комментарии для отражения ТС (sic!). Во-вторых, именно эта часть требований - ФТ - наиболее изменчива со стороны заказчика.

Подход "сущность-явление" позволяет выделить в предметной области неизменные сущности, их связи, поведение, декомпозицию на уровни и т.д., которые будет затем детализироваться на стадии реализации в зависимости от ФТ. Если же у вас не выделена сущность, то вы приступаете к реализации на основе наблюдаемого являния (ФТ). Зоологам глупо было бы относить одних и тех же животных к разным типам, если они летом и зимой имеют разный окрас. Однако на уровне ФТ и аналитик и проектировщик зачастую получают именно такие наблюдения и выводы.

Образно выражаясь, отличие таково. Первый вариант (модель отражает сущность): имеем эскиз картины, который раскрашивается цветами, требуемыми заказчиком. Второй вариант: складываем картину из мозаики без представления о том, что должно сложится и без каких-либо гарантий, что у нас есть все её элементы.

Для тиражируемых продуктов второй поход, мягко говоря, плохо применим. Для заказных систем с перспективой повторных внедрений - тоже. Остаются, по сути, только уникальные проекты. Или "шабашки" под музыку наживульки.