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

B>На вашем же сайте про вас вы сами все и написали
Вас не затруднит дать мне ссылочку на мой сайт? А то я не знал что он у меня есть...

B>так что на правах более опытного товарища таки рекоммендую ...
И ссылочку на опытомер, если можно.

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

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

B>> рекоммендую восполнить пробелы в ваших знаниях, а потом дискутировать ...
M>Рекомендую не рекомендовать...

Рекоммендации ни к чему не обязывают , а я плохого не посоветую. Просто хотелось поговорить о вкусе устриц ... Но факт остается фактом ... видимо вы действительно не знакомы, скажем с RUP ... хотя с MSF скорее всего знакомы ... кроме этого вы похоже неплохой РАЗРАБОТЧИК, и соответсвенно рассуждаете с т.з. разработчика. Мне показалось, что вы смотрите на вещи сквозь призму только MS (это я про DSL ...) а это таки однобокий взгляд IMHO.

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

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

AF>> Но нигде не обяснили, как он может обяснить что нужно писать значительному числу людей — особенно тем, кому потом придётся стыковаться к его коду...
M>Во-первых объяснил, а во-вторых объяснил, что не надо ничего делать большему количеству людей — нет такой проблемы.
AF>>Отцам основателям это удавалось.
M>Как совершенно верно заметил Mishka, у отцов-основателей проекты были существенно меньше чем сейчас.
То есть проект системы управления авиаперевозками в рамках целой страны вы считаете мелким проектом? Там мало людей и им ничего не нужно обяснять?

AF>>Затем, что любой язык, который применяется не для живого общения, а для документации — которую может читать специалист не знакомый с автором опуса, должен быть описан.
M>Он уже есть, и описан, называется исходный код с комментариями, причем описан однозначно.
А если к моменту передачи кода Outsourcer'ам, например, написано только 10% кода? А если потребуется сменить технологию реализации?

AF>> А теперь представьте, что вам принесли диаграмму — на которой неизвестные вам обозначения и спросить некого
M>UML от этой проблемы не избавляет, он слишком не однозначен.
Примеры?

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

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

M>>В API больше функций. Тут рулят exapmles. И русский (английский) язык. А вообще 250 функций это мало И как я разбирался с подобными вещами без UML??? Просматриваешь названия функций, отбрасываешь 95% тех, что уже не подходят, бегло читаешь то, что тебе надо...
AF>И это быстрее, чем посмотреть на одну диаграмму?

Ну... эту диаграмму тоже надо найти...

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

Ну... сколько примеров я не встречал (яркий тому пример msdn), обычно примеры выполняют роль как раз диаграмм последовательности. Вот пример, который в какой-то мере аналогичен диаграмме последовательности. В качесте альтернативы можно использовать unit-тесты.

AF>А вот когда не ясно, почему написанный по API код не работает — приходится или искать чей то работающий исходник и по нему выяснять протокол вызова, или книжки читать, или вообще методом тыка разбираться ...

Это называется отладка. UML тут помогает мало Обычно возвращаешься к рабочему примеру и начинаешь по шагам, аккуратно шаг за шагом делать все изменения. Или напрямую лезешь в исходники библиотеки, смотреть, что там делается... Вот тут больше распространены ошибки, связаные с техникой, когда ты знаешь последовательность действий, но совершаешь ошибку в одном из шагов.

AF> Это так, но смысл то не в этом. Что бы понять математическую модель, ты пользуешься её описанием, а не только самой моделью. Если описание хорошее — сама модель (конкретные выкладки, то есть реализация) — может вообще не понадобиться. А вот без описания понять, что имелось в виду — часто вообще не возможно. Свёртка например используется как в обработке сигналов, так и в экономике. Но по уравнению — для чего оно — не понять.

Я не против текстового описания. Более того, одно из лучших описаний кода, которое я видел, есть описание TeX (литературное программирование). Увы, эта методология не получила должного распространения. Но провести параллель между русским языком и UML я не могу, ввиду недостаточности UML.

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

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

AR>> Не должны архитекторы думать об особенностях языка реализации.
M> Все понятно.

AR>> Но доскональное знание ВСЕХ языков, на которых будет написан исходный код, является лишним.
M>Оно является необходимым. Не досконеальное, но не меньшее чем у рядового разработчика на этом языке.

Из этого можно сделать вполне логичный вывод. Как архитектор вы пока здорово ограничены рамками создания лишь тех систем, которые вы полностью понимаете на уровне исходного кода. Вот и всё...

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

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

B>>Если я проектировщик/архитектор, то я не рассуждаю на уровне кода ...
M>А следовало бы. Все беды как раз от аритекторов, которые забыли что такое программировать.
M>Архитектор — он как хирург, как совсем не давно кто-то очень метко заметил, без практики программирования стремительно теряет квалификацию.

Я удачно чередую, чтобы по словам Фаулера, не потерять квалификацию , ... в одних проектах делаю и требования и проектирование и код пишу сам, вместе с разработчиками, в других только проектирую или требования делаю .

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

Внятный код -- это признак внятных мыслей ... кто ясно мыслит, тот ясно излагает ... значит может и ясно в UML изложить а не только в коде ... Язык это только способ изложения мыслей. Модели на UML это essentials ... а в коде много подробностей. Есть опасность изучая только код, за деревьями не увидеть леса ... А для начала хотелось бы на лес взглянуть а потом на интересующие меня деревья .

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

M>>Нет ничего невозможного Достигается упражнениями Вообще-то мир, в котором приходится вести разработку, неидеален. Большую часть времени приходится не разрабатывать новый функционал, а исправлять ошибки. А ошибки большей частью завязаны на технические особенности, не отраженные в UML. Так что от исходников в любом случае никуда.

AF>Ну а если в коде реализована не вся необходимая функциональность?

Тут возможны варианты

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

AF>И кто определяет ложность аналогий?
Аналогии ложны все..

AF> Хорошо. Как спец по микроэлектронике — могу легко подсунуть тебе схемку на пару десятков процов и FLEX кристаллов. Разбирайся как с ней работать по этой самой схемке
Ну, про аналогии я уж еговорил...

AF> ты от всех остальных стало быть требуешь вступления в джедайский орден?
Вовсе нет, я хочу чтобы мне внятно объяснили зачем UML нужен. Два способа использования меня уже вполне устроили, но в остальном пока увы...

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

AF>Дело не в том, как написан код. Дело в том, что в коде написано не все.
В нормально написанном коде есть все.

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

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

B>Андрей, посмотри что этот господин про себя пишет на своем же сайте сайте ... не стоит с ним спорить (см. http://mystic2000.newmail.ru/)

Да я и не хочу спорить. Если сам не хочешь расширять своё восприятие и обмениваться опытом, то заставить сложно.
Они ведь оба не понимают, что позиция "UML бесполезен" априори проигрывает позиции, "UML можно применить так то и так то с такими то результатами". Первая сужает доступные возможности — вторая расширяет

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

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

B>>Контор в России, которые могут потребовать UML (повторюсь, не софтверных!) я насчитал максимум 10, и сможет оценить его качество .
M>Может я по русски разьяснять разучился, но смысл моих постингов заключался в том, что качество UML-я никого не интересуют, интересуют лишь три буквы.

Так уж и никого ... ... newer say never ...

B>>ОК, сколько в этой компании сертифицированных спецов именно по UML, и чьи сертификаты?
M>Слава байту ни одного, ибо нафиг не нужен.

Каждому свое ...

B>>С каких это пор в русском языке связка "как ..., так и .." эквивалентна логическому "И"???
M>С очень давних.

Вы знаете, тут у нас в комнате сидит филолог по-образованию ... так он с вами не согласен ... хотите с ним поспорить?

B>> я просто опрвергаю утверждение, что он бесполезен и непрактичен .
M>Пока не удается..

А мне показалось я убедителен .

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

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

B>>На вашем же сайте про вас вы сами все и написали
M>Вас не затруднит дать мне ссылочку на мой сайт? А то я не знал что он у меня есть...

B>>так что на правах более опытного товарища таки рекоммендую ...
M>И ссылочку на опытомер, если можно.

См. мой постинг выше ... это не вам адресовано было ... ошибочка вышла .

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

B>Я удачно чередую, чтобы по словам Фаулера, не потерять квалификацию ,
Вы-то может быть, но речь-то идет о гипотетическом средневзятом архитекторе, который, по Вашим словам, в терминах кода мыслить не должен, а это не верно.

B>Внятный код -- это признак внятных мыслей ... кто ясно мыслит, тот ясно излагает ... значит может и ясно в UML изложить а не только в коде ... Язык это только способ изложения мыслей.
Все верно, но зачем для изложения мысле вводить еще один язык?

B> Модели на UML это essentials ... а в коде много подробностей. Есть опасность изучая только код, за деревьями не увидеть леса ... А для начала хотелось бы на лес взглянуть а потом на интересующие меня деревья .
Опять-таки все замечательно, но вводить дополнительную сущность, для другого уровня абстракции на мой взгляд не верный подход. Лучше потратить эти усилия на то что бы в коде видеть и лес и деревья.

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

AF> Из этого можно сделать вполне логичный вывод. Как архитектор вы пока здорово ограничены рамками создания лишь тех систем, которые вы полностью понимаете на уровне исходного кода. Вот и всё...
Упаси байт связаться с архитектором, который не понимает то чего на проектировал на уровне исходного кода.

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

M>Ну... эту диаграмму тоже надо найти...
При логичной организации документации — это просто.

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

M>Ну... сколько примеров я не встречал (яркий тому пример msdn), обычно примеры выполняют роль как раз диаграмм последовательности. Вот пример, который в какой-то мере аналогичен диаграмме последовательности. В качесте альтернативы можно использовать unit-тесты.
И сколько тут лишнего, по сравнению с диаграммой?
И потом сам пример не корректен. Он расчитан на то, что бы показать то, как писать код, вместо того, что бы показать — для чего его писать.

AF>>А вот когда не ясно, почему написанный по API код не работает — приходится или искать чей то работающий исходник и по нему выяснять протокол вызова, или книжки читать, или вообще методом тыка разбираться ...

M>Это называется отладка. UML тут помогает мало Обычно возвращаешься к рабочему примеру и начинаешь по шагам, аккуратно шаг за шагом делать все изменения. Или напрямую лезешь в исходники библиотеки, смотреть, что там делается... Вот тут больше распространены ошибки, связаные с техникой, когда ты знаешь последовательность действий, но совершаешь ошибку в одном из шагов.
Если причина в ошибке в коде — UML конечно не поможет, да и что угодно другое, кроме правки кода — тоже. А если ошибка — результат неверного понимания модели или отсутствия информации?

AF>> Это так, но смысл то не в этом. Что бы понять математическую модель, ты пользуешься её описанием, а не только самой моделью. Если описание хорошее — сама модель (конкретные выкладки, то есть реализация) — может вообще не понадобиться. А вот без описания понять, что имелось в виду — часто вообще не возможно. Свёртка например используется как в обработке сигналов, так и в экономике. Но по уравнению — для чего оно — не понять.

M>Я не против текстового описания. Более того, одно из лучших описаний кода, которое я видел, есть описание TeX (литературное программирование). Увы, эта методология не получила должного распространения. Но провести параллель между русским языком и UML я не могу, ввиду недостаточности UML.
А кто говорит о голых диаграммах? Предполагается использование этих диаграмм вместе с текстом, а не вместо текста.

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

AF>Они ведь оба не понимают, что позиция "UML бесполезен" априори проигрывает позиции, "UML можно применить так то и так то с такими то результатами". Первая сужает доступные возможности — вторая расширяет
Они прекрасно понимают, что позиция "UML бесполезен" априори проигрывает позиции, "UML можно применить так то и так то с такими то результатами и нулевыми затратами ресурсов".
А вот почему вы не понимаете, что затраты ресурсов на внедрение UML-я и работу с ним вовсе не нулевые, и в подавляющем большинстве случаев себя не окупают, для меня не совсем ясно. Тем более, что именно Вы, по Вашему же признанию, реально с UML не работали, но тем не менее почему-то пытаетесь доказать, что связываться с ним имеет смысл...

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

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

M>>>Нет ничего невозможного Достигается упражнениями Вообще-то мир, в котором приходится вести разработку, неидеален. Большую часть времени приходится не разрабатывать новый функционал, а исправлять ошибки. А ошибки большей частью завязаны на технические особенности, не отраженные в UML. Так что от исходников в любом случае никуда.

AF>>Ну а если в коде реализована не вся необходимая функциональность?

M>Тут возможны варианты

Какие? Мистически домыслить что имелось в виду?
Очевидно, что без описания модели или иного источника информации о том, что нужно делать — вариантов никаких.

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

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

AF>>Дело не в том, как написан код. Дело в том, что в коде написано не все.
M>В нормально написанном коде есть все.

И что в 10% кода содержится описание того, что должно быть в остальных 90%?
Вселенная, конечно, фрактал, но не до такой же степени...

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

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

AF>> Из этого можно сделать вполне логичный вывод. Как архитектор вы пока здорово ограничены рамками создания лишь тех систем, которые вы полностью понимаете на уровне исходного кода. Вот и всё...
M>Упаси байт связаться с архитектором, который не понимает то чего на проектировал на уровне исходного кода.
Упаси гейтс поручать крупный гетерогенный проект архитектору, которому всё нужно понимать на уровне исходного кода...

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

AF>И сколько тут лишнего, по сравнению с диаграммой?

Кое-что не лишнее, а полезное По примеры можно избежать чтения детальной помощи по некоторым функциям.

M>>Я не против текстового описания. Более того, одно из лучших описаний кода, которое я видел, есть описание TeX (литературное программирование). Увы, эта методология не получила должного распространения. Но провести параллель между русским языком и UML я не могу, ввиду недостаточности UML.
AF>А кто говорит о голых диаграммах? Предполагается использование этих диаграмм вместе с текстом, а не вместо текста.

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