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

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

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

M>>>Здравствуйте, Alexey Rovdo, Вы писали:

AR>>>> Но глупо отрицать его полезность как средства документирования сложных проектов и систем.
M>>>Глупо было бы считать что он полезен для документирования сложных проектов и схем.
AF>>Глупо было бы считать что он бесполезен для документирования сложных проектов и схем.
AF>> Аргументируй — что есть более полезное? Код? Карандаши бумага? (Только помни, что авторы кода тебе уже не доступны)

M>Возбмем аналогичную ситуацию. Я выбираю некоторую библиотеку для дальнейшего использования в проекте. Будем считать, что моя скромность не позволит мне напрямую обращаться к ее разработчикам. Ситуация аналогична тому, что эту библиотеку разрабатывали сотрудники нашей фирмы, но все попали под грузовики. По каким критериям я буду выбирать библиотеку (что бы я хотел видеть)?

M>1. Тестовое описание принципов системы
M>2. Помощь по системе (в формате свойство, описание)
M>3. Примеры использования
M>4. Исходный текст
M>5. Всякие документы вроде How to... FAQ...

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

Никто и не говорит, что ты должен пользоваться UML диаграммами. Более того, всё зависит от библиотеки. Если это библиотека обёрток над простыми типами — от UML тут толку ноль. А если это API к сложной телекоммуникационной системе? Ты уверен, что тебе проше будет вычитывать описания каждой из 250 функций, для того, что бы выяснить, что запрос определённых данных делается с помощью десятка из них, причём в определённой последовательности? Или всё-таки проще посмотреть на диаграмму последовательностей, что бы всё это увидеть на одном экране за 5-10 секунд?

AR>>>> Даже опытный разработчик, непосредственно участвовавший в проекте, возращаясь к своим "бумажкам и слюням" через пол года — год уже может запутаться в этом зоопарке.
M>>>Опытному разработчику достаточно кода, а не опытному тем более.
AF>> Угу. Вот посмотрим на тебя, когда тебе вместо книги с простыми и ясными обяснениями предметной области вывалят тону кода. Ты интересно и математику и физику только по исходным кодам учил?

M>Символический язык, используемый в математике и физике, гораздо ближе к языкам программирования, нежели к UML. А вот картинки... но в серьезных книгах их не так уж и много...
Но ты же книги берёшь, а не исходный код! Ты же в книге читаешь тескст с формулами, а не просто голые формулы! А если речь идёт о пространственных интегралах или графиках смотришь на картинки и разбираешься — что там нарисовано.