Здравствуйте, AndreyFedotov, Вы писали:

AF>Здравствуйте, Сомов Александр, Вы писали:

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

AF>То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать?
Не так, 10% кода должны отражать логику работу, а 90% — нюансы.

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

AF>Прежде чем читать лекции и бросаться умными словами вычитаными в книжках — подумайте исходя из обычного здравого смысла — если вы не знаете что делать и узнать неоткуда — как вы можете сделать именно то, что надо и не что-то случайное?
Прежде чем читать лекции, о том что я попосту читаю лекции, лучше понять, что я не читаю лекции, а высказываю свою точку зрения.

Опять же, из функциональных требований, которые сами по себе не требуют UML.

А из грамотно написанного, работающего кода я могу извлечь описание функциональности. Разумеется, то, что в коде не содержится, не будет отражено. Но в этом случае, если была бы документация, то она просто не соответствовала системе. А когда она полностью соответствует, то она становится ненужной (при условии, что код написан хорошо). Причём ненужной, как документация, — необходимость остаётся при разборе дефектов. Но тут опять же архитектурный UML никаким боком не вылазит, достаточно словесных описаний.