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

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

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

GZ>>Возьми Oberon, и реализуй на нем алгоритм. Будет не менее понятно. Или питон например.(главное не идти на поводу у Кнута )

M>А что такого у Кнута? Чем литературное программирование так плохо?
Плохо то, что алгоритмы показываются с помощью своего левого ассемблера. Больше времени угрохаешь на разбор ассемблера, чем на смысл алгоритма.

С уважением, Gleb.

GlebZ wrote:
> M>А что такого у Кнута? Чем литературное программирование так плохо?
> Плохо то, что алгоритмы показываются с помощью своего левого ассемблера.
> Больше времени угрохаешь на разбор ассемблера, чем на смысл алгоритма.

Смысл описан рядом, словами.

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

M>>Я к тому, что .NET Framework задокументирован лучше большинства проектов, изучение его не составляет большой сложности, но все обошлось без UML.

Д>но с UML было бы проще

UML у MS я видел только в документации к MMC, а это такое запутанное уёжище, пузыря для того, чтобы разобраться мало...

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

sch>Когда же будет изобретена технология, которая сможет дать вышеописанные результаты, то программирование из творчества превратится в ремесло...

Лучше уж тогда сразу в профессию

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

M>>А что такого у Кнута? Чем литературное программирование так плохо?
GZ>Плохо то, что алгоритмы показываются с помощью своего левого ассемблера. Больше времени угрохаешь на разбор ассемблера, чем на смысл алгоритма.

Сколько раз можно повторять Алгоритм у Кнута очень понятно расписан словами. На ассемблере же приведена эффективная машинная реализация. По тем временам вещь необходимая. Но если брать программы, написаные Д. Кнутом (TeX, METAFONT) то там мы видим использование методологии литературного программирования. И я бы не сказал, что это нечитабельно и непонятно.

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


C>Нет, это уже abuse Если схема (UML или блок-схема) настолько
C>детальна, что из нее можно генерировать код — то лучше было сразу писать
C>код и не заморачиваться со схемами.

Не всегда. Скажем, если схема суть некий конечный автомат (или некоторая его вариация), то код будет существенно менее нагляден и понятен и правильней будет генерить его из схемы.

_Obelisk_ wrote:

> C>Нет, это уже abuse Если схема (UML или блок-схема) настолько
> C>детальна, что из нее можно генерировать код — то лучше было сразу
> писать
> C>код и не заморачиваться со схемами.
> Не всегда. Скажем, если схема суть некий конечный автомат (или
> некоторая его вариация), то код будет существенно менее нагляден и
> понятен и правильней будет генерить его из схемы.

Ладно, согласен — иногда (но очень редко) это имеет смысл

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Ладно, согласен — иногда (но очень редко) это имеет смысл

В смысле в Вашей практике? У меня проблема реализации конечных автоматов идет красной нитью через года...

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

BKV>>Или как вам нагромождение из 3х (трех) классов чтобы записать 1 (одну) строчку в XML?

AVK>Вне контекста это ни о чем не говорит. Такое вполне может быть оправданным.

Контекст был такой. Отчёт, бланк на одну страницу, штук 50 полей. Максимум на 200 строчек кода в лоб вместе с хелперами. Результат — 77 классов. Эту херню (простите мне мой французский) программировало 4 человека, я тоже участвовал в этом бардаке. Что оно такое, как работает и зачем, я так и не понял.

AVK>Это проблемы вашего отдела кадров и начальника, не сумевшего отфильтровать некомпетентных людей.

Андрей, это уже из серии "Если вы такие умные, то почему тогда такие бедные"

BKV>>Опять же можно сказать, что это единичный случай. Могу вас уверить — нет не единчный. Имея непосредственное отношение к крупнейшему консалтингу в мире

AVK>IBM?

Не просто IBM. IBM в тесном сотрудничестве с Microsoft

AVK>К счастью в России ситуация несколько лучше.

Думаешь? Что-то я всё больше и больше начинаю сомневаться, что она вообще где-нибудь лучше. Тут дело не в России, а в проблемах в самой индустрии.

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

IT> Тут дело не в России, а в проблемах в самой индустрии.
Вот это мы тоже обсудим...

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

M>В смысле в Вашей практике? У меня проблема реализации конечных автоматов идет красной нитью через года...

кстати, да. Генерация кода для конечных автоматов напрямую из диаграмм — очень перспективное направление.
И нагляднее, и эффективнее.

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

C>Ладно, согласен — иногда (но очень редко) это имеет смысл

ПО отнюдь не исчерпывается всякими информационными и бухгалтерскими программами.

В мире пишется ОЧЕНЬ много софта, базирующегося на идеи конечного автомата. Это и телекоммуникационный софт, и части систем навигации, и части систем управления самолетов и туева куча всего остального. Я пять лет уже занимаюсь разработкой CASE средств для этого сегмента рынка, поэтому я достаточно хорошо представляю частоту применения автоматов в реальности.
И всякие графические языки (UML и разнообразные специализированные языки) очень активно в этом процессе участвуют.

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

ПИ>>3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"

Считаю, что Вирт прав, но частично...
Начну с теории, а потом плавно перейду к практике.

Что такое UML?

Унифицированный язык моделирования (UML) — это семейство графический нотаций, в основе которого лежит единая метамодель.
Он помогает в описании и проектировании программных систем, построенных с использованием ОО-технологий. Это определение в чем-то упрощенное.

M. Fowler

История возникновения

UML появился в результате процесса унификации множества ОО-языков графического моделирования, процветавших в конце 80-х и в начале 90-х годов. Появившись в 1997, он отправил эту Вавилонскую башню в вечность.
По сути событием инициировавшим появление UML, стал уход Рамбо из GE и его встреча с Бучем в Rational. С самого начала было ясно, что этот союз может создать критическую массу этого бизнеса. Они провозгласили, что "война методов завершена — мы победили", по существу заявляя, что они собираются достигнуть стандартизации, пойдя по "пути Microsoft". Некоторые методологи проектирования предложили создать анти-Бучевскую коалицию.

M. Fowler

Далее к ним присоединилась OMG группа, и после этого появился UML, который позволил CASE-средствам свободно обмениватся моделями.

UML, как язык программирования

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

M. Fowler

Практика
Вобщем-то сам Мартин сознается, что главным образом UML хорош для рисования на "белых досках" (это приоритетная роль UML, как мне кажется, отчетливо видно при введнии стандарта UML2). Например, введение леденцовой (шаро-гнездовой) нотации, циклов в диаграммах последовательностей — теперь не нужно пользоватся мочалками, для стирания пунктирной линий на периоде активности., и тд.
Сам я использую UML только как чертежный вариант, иногда как не стандартизированый так как порой не хватает иного... Например, сейчас я разрабатываю документацию по архитектуре ПП согласно требований CMM. По историческим причинам, половина модулей в этих проектах было написано на C, другая — на C++. Та часть, что была написана на C++, на UML перевелась легко. Трудности возникли с переводом C части. Пришлось исхитрятся и извращатся.

Впечатление от UML двойственное — с одной строны, мне кажется, затачивался он исключительно под Java и Smalltalk. Это видно по изменениям в спецификациях от ранних версий до поздних. С другой стороны — UML хорош, как языковонезависимый стандарт, легко рисуем и прост в понимании.

Здравствуйте, 0rc

А можно ссылки на оригинальные высказывания Фаулера?

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

E>Здравствуйте, 0rc

E>А можно ссылки на оригинальные высказывания Фаулера?

К сожалению, в электронном варианте я не искал.
А бумажный вариант:

UML.Основы. 3-е издание., СПб: Символ-Плюс,2004.- 192с.,
ISBN 5-93286-060-X
ISBN 0-321-19368-7 (англ.)

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

0rc>Трудности возникли с переводом C части. Пришлось исхитрятся и извращатся.

Ну дык неудивительно — трудно положить ООП нотацию на не-ООП код

PS А в чём он всё-таки прав то?

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

Д>Здравствуйте, 0rc, Вы писали:

0rc>>Трудности возникли с переводом C части. Пришлось исхитрятся и извращатся.

Д>Ну дык неудивительно — трудно положить ООП нотацию на не-ООП код

Д>PS А в чём он всё-таки прав то?

3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"

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

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

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

_O_>Не всегда. Скажем, если схема суть некий конечный автомат (или некоторая его вариация), то код будет существенно менее нагляден и понятен и правильней будет генерить его из схемы.

Если этот конечный автомат имеет пару десятков состояний, не думаю, что его схема покажется такой уж наглядной.

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

Т>Если этот конечный автомат имеет пару десятков состояний, не думаю, что его схема покажется такой уж наглядной.

Менее наглядной, чем код на C++?

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

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

_O_>>Не всегда. Скажем, если схема суть некий конечный автомат (или некоторая его вариация), то код будет существенно менее нагляден и понятен и правильней будет генерить его из схемы.

Т>Если этот конечный автомат имеет пару десятков состояний, не думаю, что его схема покажется такой уж наглядной.

1. Схему можно разбить на несколько диаграмм
2. Можно использовать hierarchical state-ы и упрятать часть автомата в sub-state-ы.
3. Можно комбинировать автоматы с вызовом обычных функций и методов