Здравствуйте, Сомов Александр, Вы писали:
СА>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Сомов Александр, Вы писали:
AF>>>>И что в 10% кода содержится описание того, что должно быть в остальных 90%? 
AF>>>>Вселенная, конечно, фрактал, но не до такой же степени...
СА>>>Вселенная — нет. А грамотно спроектированный код — да. Вот те 90% "мешающегося" при понимании архитектуры кода очень легко спрятать. Этот давно известный приём ООП называется "инкапсуляция".
AF>>То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать?
СА>Не так, 10% кода должны отражать логику работу, а 90% — нюансы.
Про должны — это теория. А если не отражают? А если, как это часто бывает, зказчик хочет, что бы сначала заработала часть функционала, а потом делалось всё остальное — и именно этот кусок + обвязка которая ему нужна и реализованы?
СА>Насчёт доводить — функциональные требования нужны всегда, а с ними — да, возьмусь. В этой области UML один из инструментов описания и даже не самый удобный.
То есть тезис о том, что кода достаточно вы только что сами же и отвергли...
СА>Опять же, из функциональных требований, которые сами по себе не требуют UML.
Да, как уже многократно говорилось, обойтись можно. И в зависимости от ситуации это будет разумно использовать UML или не использовать.
СА>А из грамотно написанного, работающего кода я могу извлечь описание функциональности. Разумеется, то, что в коде не содержится, не будет отражено.
То есть нужна документация описывющая модель.
СА>Но в этом случае, если была бы документация, то она просто не соответствовала системе. А когда она полностью соответствует, то она становится ненужной (при условии, что код написан хорошо). Причём ненужной, как документация, — необходимость остаётся при разборе дефектов. Но тут опять же архитектурный UML никаким боком не вылазит, достаточно словесных описаний.
Система может быть написана плохо и действительно не отражать модель. Но ценность часто имеет именно модель, а не сам код — особенно в крупных проектах.
