Здравствуйте, Пономарёв Иван, Вы писали:
ПИ>1. Про общий вопрос про перспективы языков он говорит, что сейчас требуется разработать язык, в синтаксис которого был бы изящно встроен параллелизм. Причем критерием достижения этой цели он считает лёгкость обучения студентов. Т. е. это должен быть такой язык с параллелизмом в синтаксисе, которому было бы легко обучать.
ПИ>2. Я спросил его, а не нужен ли в таком случае язык, в синтаксис которого были бы изящно встроены идеи паттернов проектирования. Он сказал, что не является специалистом по паттернам проектирования, но знает, что некоторые люди принимают их, а некоторые -- не принимают. Посему он смотрит на паттерны как на новшество, которое его пока не заботит. Говоря вообще, он -- скорее за свободу для программиста, чем за какие-то предопределенные "паттерны".
Похоже, он просто не понимает, что такое "паттерн"
ПИ>3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"
Здравствуйте, Трурль, Вы писали:
Д>>Что такое UML, он тоже не понимает. Мдя. Грустно Т>Похоже, он понимает это гораздо лучше, чем многие другие.
Факт. С появлением этих "паттернов" (не самих приёмов, а их описаний) наблюдал какую-то странную шаблонизированность мышления у поклонников этих самых паттернов — среди тех, с кем сталкивался по работе. Хорошие программисты умели это всё и до появления этого суржик-лексикона.
Что до UML — я как-то не видел ни одного доводу в пользу его удобства. Уже не говоря о том, что продукты Rational сами по себе подчёркнуто неудобны. У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать начальству, чтоб оно видело, что работа кипит. И не более того.
Здравствуйте, Zdreni, Вы писали:
Z>Факт. С появлением этих "паттернов" (не самих приёмов, а их описаний) наблюдал какую-то странную шаблонизированность мышления у поклонников этих самых паттернов — среди тех, с кем сталкивался по работе. Хорошие программисты умели это всё и до появления этого суржик-лексикона.
если уж сказал "а", скажи заодно и "б".
и кто вообще сказал, что "шаблонизированность" — это плохо?
Z>Что до UML — я как-то не видел ни одного доводу в пользу его удобства.
Значит, понимание у тебя еще впереди.
Z>Уже не говоря о том, что продукты Rational сами по себе подчёркнуто неудобны.
Rational != UML
Z>У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать начальству, чтоб оно видело, что работа кипит. И не более того.
Для этой цели он тоже подходит. Хотя лично я использую его в других целях.
Здравствуйте, Трурль, Вы писали:
Т>Похоже, он понимает это гораздо лучше, чем многие другие.
Если он объединяет UML и блок-схемы по тому принципу, что и то и другое — это диаграммы, то тут он безусловно прав
надо только отметить, что по тому же принципу можно отнести в одну группу классификации его собственные труды и последнее "произведение" Марининой — потому что и то, и другое написано буквами. На основании чего сделать вывод, что и пользы от них одинаковое количество
Zdreni wrote:
> Д>>Что такое UML, он тоже не понимает. Мдя. Грустно > Т>Похоже, он понимает это гораздо лучше, чем многие другие. > Факт. С появлением этих "паттернов" (не самих приёмов, а их описаний) > наблюдал какую-то странную шаблонизированность мышления у поклонников > этих самых паттернов — среди тех, с кем сталкивался по работе. Хорошие > программисты умели это всё и до появления этого суржик-лексикона.
"Суржик-лексикон" позволяет говорить "синглтон", а не "объект,
существующий в единственном экземпляре"; "фасад", а не "объект,
проедоставляющий удобный для использования объектный интерфейс для
какой-то другой системы" и т.п.
> Что до UML — я как-то не видел ни одного доводу в пользу его удобства. > Уже не говоря о том, что продукты Rational сами по себе подчёркнуто > неудобны.
А причем здесь Rational? Или у вас UML==Rational?
> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать > начальству, чтоб оно видело, что работа кипит. И не более того.
Здравствуйте, Дарней, Вы писали:
Д>надо только отметить, что по тому же принципу можно отнести в одну группу классификации его собственные труды и последнее "произведение" Марининой — потому что и то, и другое написано буквами. На основании чего сделать вывод, что и пользы от них одинаковое количество
Судя по тому снисходительно-ироническому тону, с которым здесь в последнее время говорят про Вирта, вероятно, так оно и есть.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >> начальству, чтоб оно видело, что работа кипит. И не более того.
C>Ну и вы не понимаете что такое UML....
Здравствуйте, eao197, Вы писали:
E>Судя по тому снисходительно-ироническому тону, с которым здесь в последнее время говорят про Вирта, вероятно, так оно и есть.
Не знаю, что думают остальные.
Я не считаю нужным соглашаться с кем-то только потому, что он — авторитет. А некоторые его высказывания выглядят так, будто их сделал человек, который не видит ни на сантиметр дальше собственного носа. Более того — не хочет видеть, и не считает это нужным. Вот собственно и всё.
ironwit wrote:
>>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >>> начальству, чтоб оно видело, что работа кипит. И не более того. > C>Ну и вы не понимаете что такое UML.... > Расскажите?
Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших
систем, так как UML — это единый графический язык описания структур и их
взаимодействий.
UML — не серебряная пуля, конечно, но очень удобен так как его понимают
все. Примерно та же ситуация, что и с XML
Здравствуйте, Cyberax, Вы писали:
C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших C>систем, так как UML — это единый графический язык описания структур и их C>взаимодействий.
не только при создании. Очень удобен, чтобы быстро составить представление о структуре незнакомой системы, например. Правда, тут всё упирается в убогость существующих UML-систем. Если построить диаграммы из кода Java или C# еще можно более-менее нормально, то ситуация с С++ — это просто тихий ужас
Здравствуйте, Cyberax, Вы писали:
C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших C>систем, так как UML — это единый графический язык описания структур и их C>взаимодействий.
не только при создании. Очень удобен, чтобы быстро составить представление о структуре незнакомой системы, например. Правда, тут всё упирается в убогость существующих UML-систем. Если построить диаграммы из кода Java или C# еще можно более-менее нормально, то ситуация с С++ — это просто тихий ужас
Здравствуйте, Cyberax, Вы писали:
C>ironwit wrote:
>>>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >>>> начальству, чтоб оно видело, что работа кипит. И не более того. >> C>Ну и вы не понимаете что такое UML.... >> Расскажите?
C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших C>систем, так как UML — это единый графический язык описания структур и их C>взаимодействий.
C>UML — не серебряная пуля, конечно, но очень удобен так как его понимают C>все. Примерно та же ситуация, что и с XML
можно ли какой то маленький пример большой системы и конкретный пример ее облегчение проектирования\разработки?
Дарней wrote:
> C>Язык для создания моделей систем. ОЧЕНЬ помогает при разработке больших > C>систем, так как UML — это единый графический язык описания структур > и их > C>взаимодействий. > не только при создании. Очень удобен, чтобы быстро составить > представление о структуре незнакомой системы, например. Правда, тут > всё упирается в убогость существующих UML-систем. Если построить > диаграммы из кода Java или C# еще можно более-менее нормально, то > ситуация с С++ — это просто тихий ужас
Ага, да и сами по себе диаграммы из кода тоже не очень-то удобны (хотя
иногда полезны).
Поэтому мы используем UML для описания разделения системы на модули и их
взаимодействия. В реализациях модулей UML используется только в
документации для иллюстрации каких-нибудь сложных по структуре подсистем.
ironwit wrote:
> C>UML — не серебряная пуля, конечно, но очень удобен так как его понимают > C>все. Примерно та же ситуация, что и с XML > можно ли какой то маленький пример большой системы и конкретный пример > ее облегчение проектирования\разработки?
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Трурль, Вы писали:
Т>>Похоже, он понимает это гораздо лучше, чем многие другие.
Д>Если он объединяет UML и блок-схемы по тому принципу, что и то и другое — это диаграммы, то тут он безусловно прав
Собственно так и есть. Это вообще свойственный для него подход — обобщать и классифицировать по поверхностным признакам. Потому у него и произведения получаются столь же поверхностными — что Паскаль, что Оберон. Вроде как всё есть, а при этом какое то оно всё не как у людей. Как до практики доходит, так начинаются всякие хаки как в турбо-паскале или системных библиотеках.
Д>надо только отметить, что по тому же принципу можно отнести в одну группу классификации его собственные труды и последнее "произведение" Марининой — потому что и то, и другое написано буквами. На основании чего сделать вывод, что и пользы от них одинаковое количество
Здравствуйте, Дарней, Вы писали:
Д>Не знаю, что думают остальные. Д>Я не считаю нужным соглашаться с кем-то только потому, что он — авторитет.
Соглашаться не обязательно. Но, имхо, принимать к сведению его мнение все же стоит. Как раз на основании того, что он -- авторитет. Ведь авторитетами становятся как раз те, кто что-то замечает чуть-чуть раньше, чем все остальные. Либо вообще говорит что-то, о чем другие раньше не задумывались. Либо делает то, что другим кажется невозможным.
Может быть и сейчас такая же ситуация? Есть мейнстрим. Есть масса зашоренных этим мейнстримом людей. Когда движешься в толпе, то не видишь дальше затылков нескольких впереди идущих попутчиков. В таком движении можно даже не заметить извилистости пути, поскольку весь путь -- это непрерывная последовательность мелких шажков вперед. Только в стороне от потока можно составить более полную картину происходящего.
Вот Вирт, имхо, как раз в стороне и находится. И у него есть возможность замечать то, с чем нам придется столкнуться чуть позже. Конечно же, Вирт может сильно заблуждаться в отношении того, _как должно быть_. Но вот то, _что-то не так_ он наверняка видит лучше многих из нас. Я бы даже сказал лучше подавляющего большинства из нас. Может быть даже гораздо лучше подавляющего большинства из нас.
Д> А некоторые его высказывания выглядят так, будто их сделал человек, который не видит ни на сантиметр дальше собственного носа. Более того — не хочет видеть, и не считает это нужным.
Не уверен, что мы можем себе хотя бы вообразить тот поток информации, с которым сталкивается Вирт. Позволю себе привести цитату из Страуструпа, но думаю, что она в тему:
It is common to hear generalizations along the line “C++ is used like this”. Such statements are typically wishful thinking based on very limited experience. We are playing “blind men and the elephant” with a very large creature. There are people who have read more than a million lines of C++ code, written hundred of thousands of lines of C++, read all the articles in C-vu, C/C++ Users Journal, etc., read all the good C++ books and dozens of the bad ones, read all the academic papers relating to C++, and “lived” on the C++ newsgroups for years. There are not many such people, and even they have only scratched the surface.
(предисловие к японскому изданию книги "Дизайн и эволюция языка C++").
Имхо, аналогичные слова можно отнести и к разработанным Виртом языкам. И уж если кто-то и может себе составить более-менее объективную картину использования Pascal-производных языков, так это сам Вирт. Поскольку к нему стекается информация о проблемах языка в одних предметных областях, о достоинствах в других, о пожеланиях в третьих и т.д., и т.п. Но объем этой информации должен быть просто огромен. Поэтому я думаю, что возможностей видеть намного дальше своего носа у Вирта предостаточно.
Проблема Вирта (если вообще уместно об этом говорить), имхо, состоит в том, что тот вектор развития, который пытается указать Вирт, не совпадает с тем направлением, в котором нам бы хотелось пойти. Но важно другое -- то, что Вирт говорит, что двигаться в прежнем направлении не правильно, нужно по-другому. И лично я склонен предполагать, что так оно и есть. Только, в отличии от меня, Вирт хоть какое-то направление может предложить. Более того, это направление вполне работоспособно (давайте вспомним успешность Паскаля и то, что Оберон даже сейчас применяется в реальных и весьма важных проектах).
Вот ты говоришь:
ПИ>3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"
Что такое UML, он тоже не понимает. Мдя. Грустно
А что, если Вирт прав? Предположим, что история развивается-таки по спирали. В конце семидесятых годов применяли блок-схемы для описания программных систем. И этот подход был оправдан до тех пор, пока сама сложность систем позволяла делать такие блок-схемные описания. Сложность выросла -- блок-схемы стали историей. Прошло время. Махровым цветом расцвело ООП, которое чуть облегчено создание современного ПО. Появилась еще одна, чуть более продвинутая графическая нотация -- UML. И оказалось, что сложность разрабатываемых сейчас систем допускает их описание с помощью данной нотации. Это именно та точка, на которой мы находимся сейчас. Так вот, имхо, Вирт говорит: "Еще чуть-чуть и сложность задач возрастет настолько, что UML уже не в состоянии будет их описывать. Поэтому с UML произойдет то же самое, что с блок-схемами". Лично я не сомневаюсь, что сложность ПО будет только возрастать. И поэтому я вполне могу согласиться с предположением Вирта о будущем UML.
Я бы добавил еще немного от себя. Время от времени в разработке ПО происходят прорывы, которые становятся знаковой вехой и которые не утрачивают своей актуальности с течением времени. Ассемблер. Языки высокого уровня, процедурное программирование. Структурное и модульное программирование. Объектно-ориентированное программирование. Так вот, имхо, UML совсем не из их числа. Просто потому, что все перечисленные мной вехи способствовали повышению производительности программиста. UML, имхо, к этому никакого отношения не имеет -- это всего лишь язык записи уже сгенерированных идей. Но самому процессу генерации идей он никак не способствует. Не открывает новых горизонтов, не расширяет сознания. Это просто инструмент. А у любого инструмента есть свой срок эксплуатации. Вот и все.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>если уж сказал "а", скажи заодно и "б". Д>и кто вообще сказал, что "шаблонизированность" — это плохо?
Я видел случаи, когда это очень плохо. Человек (в должности тим лида, кстати) выдавал такие предложения из области "паттернов", что волосы дыбом вставали. "Нет, мы не будем использовать smart pointers, я в них не очень разбираюсь, мы нагромоздим тут менеджер таких обьектов и менеджер таким, и навернём десяток интерфейсов для визиторов и пр.".
Z>>Что до UML — я как-то не видел ни одного доводу в пользу его удобства. Д>Значит, понимание у тебя еще впереди.
Например, сколько не программировал, но понимания "преимущества блок-схем" так и не появилось — наоборот, появилось понимание того, что это нежизнеспособная концепция. Почему с UML должно быть по-другому?
Z>>Уже не говоря о том, что продукты Rational сами по себе подчёркнуто неудобны. Д>Rational != UML
Да, но разве не Rational его продвигает пуще всех? И разве не в Rational работает собственно изобретатель этого самого RUP?
Я думал, что Rose — это и есть первоочередной продукт для UML. Мои коллеги пользовались также Visio, но это не сильно изменило моего мнения о UML.
Z>>У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать начальству, чтоб оно видело, что работа кипит. И не более того. Д>Для этой цели он тоже подходит. Хотя лично я использую его в других целях.
Не знаю, я обычно пользуюсь plain-text описаниями ролей классов и принципов их функционирования. Этого достаточно, причём можно не расписывать каждый метод. Достаточно написать, что "такой-то класс является менеджером таких-то обьектов", и всё становится куда понятнее, чем простое перечисление методов, интерфейсов и т.д..
Здравствуйте, Cyberax, Вы писали:
C>"Суржик-лексикон" позволяет говорить "синглтон", а не "объект, C>существующий в единственном экземпляре";
Ну, положим, "синглетон" существовал ещё до появления той книги.
C>"фасад", а не "объект, C>проедоставляющий удобный для использования объектный интерфейс для C>какой-то другой системы" и т.п.
А что, трудно написать "менеджер" или "переходник" (последнее — для бриджа)?
А сколько по-сути однотипных применений для "ОО-коллбека" предоставлено в книге под видом разных шаблонов — я был немало удивлён. Interpreter, Iterator, Strategy, Visitor... И везде — читаешь книжку — прям-таки Америку открывают, хотя идеи-то простые и уже использовались до того.
Кроме того, эти шаблоны не учитывают, например, специфику С++ из разряда той, которую использовал Александреску — с шаблонными шаблонными параметрами, передачей стратегий и т.д. В результате горе-проектировщики, обчитавшиеся таких книжек, дальше интерфейсов ничего не видят и громоздят что попало. Я такое видел.
C>А причем здесь Rational? Или у вас UML==Rational?
В предыдущем сообщении ответил. Rational — основные "продвигатели" UML, AFAIK.
>> У меня закрепилось мнение, что UML — это подобие диаграмм — рисовать >> начальству, чтоб оно видело, что работа кипит. И не более того. C>Ну и вы не понимаете что такое UML....
Видите ли... текст я набираю явно быстрее, чем возюкаю мышой в любом из UML-пейнтов. И мне проще текстом обьяснить и себе, и другим, что конкретно требуется от каких классов. Это во-первых.
Кроме того, plain text отлично обрабатывается системой контроля версий — лучше, чем бинарные форматы с диаграмками. Кроме того, по plain text лучше работает поиск. Кроме того, в plain text лучше видно, как согласовывался и менялся дизайн. Единственное, для чего plain text хуже — как я и сказал, это в демонстрации начальству "кипучести работы".
Может, я чего-то действительно не понимаю — ну так обьясните.
Здравствуйте, Zdreni, Вы писали:
Z>Здравствуйте, Дарней, Вы писали:
Z>Да, но разве не Rational его продвигает пуще всех? И разве не в Rational работает собственно изобретатель этого самого RUP? Z>Я думал, что Rose — это и есть первоочередной продукт для UML. Мои коллеги пользовались также Visio, но это не сильно изменило моего мнения о UML.
UML это не Rational и не Visio. UML это некий набор идей которыми ты можешь пользоваться, видоизменять их. Я вот например ненавижу Rational, Visio а юзаю UML дабы структуризовать кашу в голове, рисую на бумажке карандашом. Z>Не знаю, я обычно пользуюсь plain-text описаниями ролей классов и принципов их функционирования. Этого достаточно, причём можно не расписывать каждый метод. Достаточно написать, что "такой-то класс является менеджером таких-то обьектов", и всё становится куда понятнее, чем простое перечисление методов, интерфейсов и т.д..
Некоторые люди визуальные -- им удобнее представить класс как квадратик
Вероятно это трудно понять и с этим трудно согласиться, но хороший дизайн должен быть настолько простым, чтобы для его описания хватило пары страниц. Иначе он банально не соответствует принципу модульности. Перефразируя известную аксиому, можно сказать, что если вы не сможете объяснить семилетнему ребенку как работает ваша программа и из каких частей она состоит, то вы сами вряд ли понимаете что в ней происходит. Поэтому не стоит переоценивать возможности UML, т.к. UML -- далеко не панацея, скорее -- плацебо.
С другой стороны, как мне кажется многие вкладывали и вкладывают в UML надежды на создание технологии, которая будет позволять получить качество программы пропорциональное времени разработки помноженному на количеству программистов, причем вне зависимости от мастерства программистов и каких-либо иных факторов. Но, к сожалению схематичность UML не оставляет и тени надежды на такой исход, ибо хорошое программирование и хорошая программа есть артефакт творчества в первую очередь. Когда же будет изобретена технология, которая сможет дать вышеописанные результаты, то программирование из творчества превратится в ремесло...
Здравствуйте, Zdreni, Вы писали:
Д>>если уж сказал "а", скажи заодно и "б". Д>>и кто вообще сказал, что "шаблонизированность" — это плохо?
Z>Я видел случаи, когда это очень плохо. Человек (в должности тим лида, кстати) выдавал такие предложения из области "паттернов", что волосы дыбом вставали. "Нет, мы не будем использовать smart pointers, я в них не очень разбираюсь, мы нагромоздим тут менеджер таких обьектов и менеджер таким, и навернём десяток интерфейсов для визиторов и пр.".
А при чем здесь паттерны? Это скорее полная неопытность человека. Видимо он в качестве тим-лида не закончил ни одного тяжелого проекта.
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Здравствуйте, Zdreni, Вы писали:
Z>А сколько по-сути однотипных применений для "ОО-коллбека" предоставлено в книге под видом разных шаблонов — я был немало удивлён. Interpreter, Iterator, Strategy, Visitor... И везде — читаешь книжку — прям-таки Америку открывают, хотя идеи-то простые и уже использовались до того.
Ты про какую книжку? Если про GoF, то там многократно говорится о том, что паттерны это попытка оформить часто применяемые решения ввиде библиотеки. Сами решения авторы не создавали.
Z>Кроме того, эти шаблоны не учитывают, например, специфику С++
И про это там (в GoF) тоже специально оговаривается. Есть отдельные книжки по паттернам, специальным как для платформы, так и для прикладной сферы.
Z> из разряда той, которую использовал Александреску — с шаблонными шаблонными параметрами, передачей стратегий и т.д. В результате горе-проектировщики, обчитавшиеся таких книжек, дальше интерфейсов ничего не видят и громоздят что попало. Я такое видел.
А если бы они эти книжки не прочли? Ты чего предлагаешь — запретить паттерны по причине того что отдельные идиоты так и не поняли что это такое?
... << RSDN@Home 1.2.0 alpha rev. 615 on Windows XP 5.1.2600.131072>>
Ну так он без сомнения прав
> Предположим, что история развивается-таки по спирали. В конце > семидесятых годов применяли блок-схемы для описания программных > систем. И этот подход был оправдан до тех пор, пока сама сложность > систем позволяла делать такие блок-схемные описания.
Да, причем блок-схемы (если их использовать по назначению) существенно
помогали понимать алгоритмы.
> Сложность выросла -- блок-схемы стали историей. Прошло время. Махровым > цветом расцвело ООП, которое чуть облегчено создание современного ПО. > Появилась еще одна, чуть более продвинутая графическая нотация -- UML. > И оказалось, что сложность разрабатываемых сейчас систем допускает их > описание с помощью данной нотации. Это именно та точка, на которой мы > находимся сейчас. Так вот, имхо, Вирт говорит: "Еще чуть-чуть и > сложность задач возрастет настолько, что UML уже не в состоянии будет > их описывать. Поэтому с UML произойдет то же самое, что с блок-схемами".
Да, и вместо UML будет какой-нибудь новый HyperModelingLanguage. Вполне
согласен.
Но при этом Вирт делает вывод, что из-за этого сейчас UML не стоит
изучать и заострять на нем внимание (ведь все равно когда-нибудь умрет).
Вот именно с этим я и не согласен.
Zdreni wrote:
> Например, сколько не программировал, но понимания "преимущества > блок-схем" так и не появилось — наоборот, появилось понимание того, > что это нежизнеспособная концепция. Почему с UML должно быть по-другому?
Блок-схемы — это вполне жизнеспособная концепция, даже сейчас они
используются для иллюстрации алгоритмов, например.
> Да, но разве не Rational его продвигает пуще всех? И разве не в > Rational работает собственно изобретатель этого самого RUP? > Я думал, что Rose — это и есть первоочередной продукт для UML. Мои > коллеги пользовались также Visio, но это не сильно изменило моего > мнения о UML.
А мы рисуем UML фломастером на доске, а потом ее фотографируем — и нам
так очень нравится работать. Что мы делаем "не так"???
> Не знаю, я обычно пользуюсь plain-text описаниями ролей классов и > принципов их функционирования. Этого достаточно, причём можно не > расписывать каждый метод. Достаточно написать, что "такой-то класс > является менеджером таких-то обьектов", и всё становится куда > понятнее, чем простое перечисление методов, интерфейсов и т.д..
Ну, в общем, понятно. Как вы собираетесь словами описать систему из 5000
классов и тысяч 50000 методов?
Z>Я видел случаи, когда это очень плохо. Человек (в должности тим лида, кстати) выдавал такие предложения из области "паттернов", что волосы дыбом вставали. "Нет, мы не будем использовать smart pointers, я в них не очень разбираюсь, мы нагромоздим тут менеджер таких обьектов и менеджер таким, и навернём десяток интерфейсов для визиторов и пр.".
Бери в голову хорошие применения технологий, и не бери плохие.
Z>Видите ли... текст я набираю явно быстрее, чем возюкаю мышой в любом из UML-пейнтов. И мне проще текстом обьяснить и себе, и другим, что конкретно требуется от каких классов. Это во-первых. Z>Кроме того, plain text отлично обрабатывается системой контроля версий — лучше, чем бинарные форматы с диаграмками. Кроме того, по plain text лучше работает поиск. Кроме того, в plain text лучше видно, как согласовывался и менялся дизайн. Единственное, для чего plain text хуже — как я и сказал, это в демонстрации начальству "кипучести работы".
С чего Вы взяли, что UML-диаграмма не может является Plain-текстом?
Здравствуйте, Cyberax, Вы писали:
C>Ну, в общем, понятно. Как вы собираетесь словами описать систему из 5000 C>классов и тысяч 50000 методов?
Хочешь сказать, что в UML описание такой системы будет простым и понятным?
Словами — очень просто, там тоже можно различные уровни абстракции использовать, равно как и в UML, только проще...
Здравствуйте, Cyberax, Вы писали:
C>Блок-схемы — это вполне жизнеспособная концепция, даже сейчас они C>используются для иллюстрации алгоритмов, например.
Возьми Oberon, и реализуй на нем алгоритм. Будет не менее понятно. Или питон например.(главное не идти на поводу у Кнута )
C>А мы рисуем UML фломастером на доске, а потом ее фотографируем — и нам C>так очень нравится работать. Что мы делаем "не так"???
Неужели UML так прост для рисования? Я лучше текстом перечислю пункты, чем рисовать sequence диаграмму
Merle wrote:
> C>Ну, в общем, понятно. Как вы собираетесь словами описать систему из > 5000 > C>классов и тысяч 50000 методов? > Хочешь сказать, что в UML описание такой системы будет простым и > понятным?
Нет, просто словесные (как и графические ) способы описания структуры
на уровне классов и методов уже становятся неприменимыми.
Уже нужно рассуждать в более высокоуровневых терминах, типа: "Система A
делится на три подсистемы: сборщик данных (A1), потоковый буффер (A2),
обработчик потока (A3)". Если записывать все ТОЛЬКО словами (я пробовал ), то получается каша. Уже становится нужным рисовать какие-то
пояснительные диаграммы и схемы. Для этого можно рисовать квадратики и
кружочки со стрелочками, а можно использовать стандартный UML.
> Словами — очень просто, там тоже можно различные уровни абстракции > использовать, равно как и в UML, только проще...
Здравствуйте, eao197, Вы писали:
E>А что, если Вирт прав? Предположим, что история развивается-таки по спирали. В конце семидесятых годов применяли блок-схемы для описания программных систем. И этот подход был оправдан до тех пор, пока сама сложность систем позволяла делать такие блок-схемные описания. Сложность выросла -- блок-схемы стали историей. Прошло время. Махровым цветом расцвело ООП, которое чуть облегчено создание современного ПО. Появилась еще одна, чуть более продвинутая графическая нотация -- UML. И оказалось, что сложность разрабатываемых сейчас систем допускает их описание с помощью данной нотации. Это именно та точка, на которой мы находимся сейчас. Так вот, имхо, Вирт говорит: "Еще чуть-чуть и сложность задач возрастет настолько, что UML уже не в состоянии будет их описывать. Поэтому с UML произойдет то же самое, что с блок-схемами". Лично я не сомневаюсь, что сложность ПО будет только возрастать. И поэтому я вполне могу согласиться с предположением Вирта о будущем UML.
IMHO Я думаю, что все значительно проще. Блок схемы как и UML позиционировались как средство моделирования и разработки ПО. В действительности, они не слишком отвечают этому требованию. Как документирование, UML как и блок-схемы рулят. Как моделирование, не очень. Расписать алгоритм на языке(особенно синтаксически понятном как рекламируемый им Oberon) ненамногим сложнее чем рисовать блок схему. А главное точнее, поскольку алгоритм можно проверить. Описать систему на русском(английском, немецком, голандском) значительно легче, чем рисованием. А если убрать моделирование, то и UML и блок-схемы мало отличаются друг от друга.
GlebZ wrote:
> C>Блок-схемы — это вполне жизнеспособная концепция, даже сейчас они > C>используются для иллюстрации алгоритмов, например. > Возьми Oberon, и реализуй на нем алгоритм. Будет не менее понятно. Или > питон например.(главное не идти на поводу у Кнута )
Схемы имеют то преимущество, что в них можно использовать псевдокод —
иногда понятнее.
> C>А мы рисуем UML фломастером на доске, а потом ее фотографируем — и нам > C>так очень нравится работать. Что мы делаем "не так"??? > Неужели UML так прост для рисования? Я лучше текстом перечислю пункты, > чем рисовать sequence диаграмму
У нас, в основном, структурные диаграммы используются. А sequence'ы в
UML вообще не очень удачная вещь.
Здравствуйте, Cyberax, Вы писали:
C>Да, причем блок-схемы (если их использовать по назначению) существенно C>помогали понимать алгоритмы.
Более того. Блок-схему можно транслировать в исполняемый код (язык промышленного программирования CFC, как пример).
UML -- всего лишь синтаксис, позволяющий представить структуру системы. Например, посмотреть двумерную картину отношений между классами. Поведенческие аспекты системы на UML в явной форме не выразишь, -- приходится писать "белый стих" на человеческом языке, для которого автоматических трансляторов пока не придумали.
Здравствуйте, sch, Вы писали:
sch>Вероятно это трудно понять и с этим трудно согласиться, но хороший дизайн должен быть настолько простым, чтобы для его описания хватило пары страниц. Иначе он банально не соответствует принципу модульности. Перефразируя известную аксиому, можно сказать, что если вы не сможете объяснить семилетнему ребенку как работает ваша программа и из каких частей она состоит, то вы сами вряд ли понимаете что в ней происходит. Поэтому не стоит переоценивать возможности UML, т.к. UML -- далеко не панацея, скорее -- плацебо.
Именно. Но в этом случае проще нарисовать два квадратика с надписями "A" и "B" чем написать:
"Класс А"
"Класс B"
ИМХО. sch>С другой стороны, как мне кажется многие вкладывали и вкладывают в UML надежды на создание технологии, которая будет позволять получить качество программы пропорциональное времени разработки помноженному на количеству программистов, причем вне зависимости от мастерства программистов и каких-либо иных факторов. Но, к сожалению схематичность UML не оставляет и тени надежды на такой исход, ибо хорошое программирование и хорошая программа есть артефакт творчества в первую очередь. Когда же будет изобретена технология, которая сможет дать вышеописанные результаты, то программирование из творчества превратится в ремесло...
Результат работы ремесленников тоже зависит от мастерства.
... << А писал я этот бред на RSDN@Home 1.1.4 stable rev. 510, под звуки тишины>>
Здравствуйте, Cyberax, Вы писали:
C>Нет, просто словесные (как и графические ) способы описания структуры C>на уровне классов и методов уже становятся неприменимыми.
А кто говорит об уровне классов и методов?
C>Уже нужно рассуждать в более высокоуровневых терминах <...>
Да байта ради, ни ктож не спорит.. В языке тоже есть эти термины, UML ни сколько не облегчает зачачу абстрагирования...
C> Если записывать все ТОЛЬКО словами (я пробовал ), то получается каша.
Попробуй словами и кодом... Обычно этого достаточно, UML только вредит — я пробовал..
C> Для этого можно рисовать квадратики и кружочки со стрелочками, а можно использовать стандартный UML.
Со стандартным UML-ем другая засада... Задача описывается словами и реализуется в коде, все, кто так или иначе принимают участие в процессе получения продукта с достаточной степенью свободы оперируют этими двумя языками, и этих двух языков более чем достаточно, чтобы описать продукт полностью на любом уровне абстракции. UML, получается, не пришей кобыле хвост. Это достаточно не тривиальная нотация, которой необходимо обучить и тестеров, и разработчиков, и архитекторов, и менеджеров, при том, что любая конструкция выраженая на этом языке устаревает через секунду после реализации... Так зачем нужен UML?
Здравствуйте, Zdreni, Вы писали:
Z>Я видел случаи, когда это очень плохо. Человек (в должности тим лида, кстати) выдавал такие предложения из области "паттернов", что волосы дыбом вставали. "Нет, мы не будем использовать smart pointers, я в них не очень разбираюсь, мы нагромоздим тут менеджер таких обьектов и менеджер таким, и навернём десяток интерфейсов для визиторов и пр.".
Этот человек просто некомпетентен, вот и всё. Что ты хочешь доказать этим примером?
Z>Например, сколько не программировал, но понимания "преимущества блок-схем" так и не появилось — наоборот, появилось понимание того, что это нежизнеспособная концепция. Почему с UML должно быть по-другому?
А ты программировал во времена повсеместного использования goto и кода-спагетти? Разобраться в таком коде для сложного алгоритма без блок-схемы практически невозможно, для чего собственно блок-схемы и предназначались. Код код-спагетти сейчас остался в прошлом, там же остались и блок-схемы — просто не все, особенно "преподаватели старой школы" это поняли. UML имеет с блок-схемами крайне мало общего.
Z>Да, но разве не Rational его продвигает пуще всех? И разве не в Rational работает собственно изобретатель этого самого RUP?
так все-таки RUP или UML? не надо путать божий дар с яичницей
Z>Я думал, что Rose — это и есть первоочередной продукт для UML. Мои коллеги пользовались также Visio
так себе продукт. Что первый, что другой.
Z>Достаточно написать, что "такой-то класс является менеджером таких-то обьектов", и всё становится куда понятнее, чем простое перечисление методов, интерфейсов и т.д..
Никто не заставляет перечислять все методы, особенно на первых этапах. Нарисуй класс и поставь ему стереотип "менджер таких-то объектов"
Здравствуйте, sch, Вы писали:
sch>Перефразируя известную аксиому, можно сказать, что если вы не сможете объяснить семилетнему ребенку как работает ваша программа и из каких частей она состоит, то вы сами вряд ли понимаете что в ней происходит.
Ты правда считаешь, что сможешь рассказать семилетнему ребенку, как работает твоя программа? Или хотя бы для чего вообще она нужна?
Здравствуйте, eao197, Вы писали:
E>Соглашаться не обязательно. Но, имхо, принимать к сведению его мнение все же стоит. Как раз на основании того, что он -- авторитет. Ведь авторитетами становятся как раз те, кто что-то замечает чуть-чуть раньше, чем все остальные. Либо вообще говорит что-то, о чем другие раньше не задумывались. Либо делает то, что другим кажется невозможным.
Принял к сведению... ничего интересного не увидел
E>Может быть и сейчас такая же ситуация? Есть мейнстрим. Есть масса зашоренных этим мейнстримом людей. Когда движешься в толпе, то не видишь дальше затылков нескольких впереди идущих попутчиков. В таком движении можно даже не заметить извилистости пути, поскольку весь путь -- это непрерывная последовательность мелких шажков вперед. Только в стороне от потока можно составить более полную картину происходящего.
Я и сам вижу, что текущее положение в области разработки программ далеко от идеала, и что временами развитие идет совсем не в том направлении, в каком надо бы. Даже пытаюсь вести разработку своего собственного проекта, который сможет решить некоторые проблемы. Боюсь только, что из-за нехватки времени из этого получится намного меньше, чем хочется
E>Не уверен, что мы можем себе хотя бы вообразить тот поток информации, с которым сталкивается Вирт. Позволю себе привести цитату из Страуструпа, но думаю, что она в тему:
Может быть, поток у него очень мощный. Только очень уж узкий. Совершенно безграмотные высказывания по поводу ФЯ тому подтверждение. (Даже моих скудных познаний в этой области хватает, чтобы сказать, что Пролог — это вообще НЕ функциональный язык).
E>Только, в отличии от меня, Вирт хоть какое-то направление может предложить.
А какое направление он предлагает на данный момент? Заменить страшные закорючки на begin/end, избавиться от этого гнуснейшего =, и выкинуть из for break и continue?
E>Предположим, что история развивается-таки по спирали.
Совершенно с этим согласен.
Но он говорит, что это шаг назад. То есть, никакой разницы между предыдущим витком и текущим он не видит вообще.
E>Я бы добавил еще немного от себя. Время от времени в разработке ПО происходят прорывы, которые становятся знаковой вехой и которые не утрачивают своей актуальности с течением времени. Ассемблер. Языки высокого уровня, процедурное программирование. Структурное и модульное программирование. Объектно-ориентированное программирование. Так вот, имхо, UML совсем не из их числа.
Оберон тоже не из их числа, это однозначно.
E>Но самому процессу генерации идей он никак не способствует. Не открывает новых горизонтов, не расширяет сознания.
Человеческому сознанию легче работать с визуальной информацией, а не словесной. Намного легче. "Расширению сознания" мешает только убогость современных средств для работы с UML.
Здравствуйте, Cyberax, Вы писали:
C>Уже нужно рассуждать в более высокоуровневых терминах, типа: "Система A C>делится на три подсистемы: сборщик данных (A1), потоковый буффер (A2), C>обработчик потока (A3)". Если записывать все ТОЛЬКО словами (я пробовал C> ), то получается каша. Уже становится нужным рисовать какие-то C>пояснительные диаграммы и схемы. Для этого можно рисовать квадратики и C>кружочки со стрелочками, а можно использовать стандартный UML.
Без слов вообще становится грустно Учебник высшей математики в картинках... Грусть. Одной, как мне кажется, большой ошибкой является тот факт, что набора UML-диаграмм достаточно для описания архитектуры, проектирования, ...
Здравствуйте, GlebZ, Вы писали:
C>>Блок-схемы — это вполне жизнеспособная концепция, даже сейчас они C>>используются для иллюстрации алгоритмов, например.
GZ>Возьми Oberon, и реализуй на нем алгоритм. Будет не менее понятно. Или питон например.(главное не идти на поводу у Кнута )
А что такого у Кнута? Чем литературное программирование так плохо?
Zdreni wrote:
> C>"Суржик-лексикон" позволяет говорить "синглтон", а не "объект, > C>существующий в единственном экземпляре"; > Ну, положим, "синглетон" существовал ещё до появления той книги.
GOF "Design Patterns" хороша тем, что в ней все паттерны собрали в кучу
и нормально описали. Такой словарик своеобразный получился.
> А что, трудно написать "менеджер" или "переходник" (последнее — для > бриджа)? > А сколько по-сути однотипных применений для "ОО-коллбека" > предоставлено в книге под видом разных шаблонов — я был немало > удивлён. Interpreter, Iterator, Strategy, Visitor...
Нда... И где Iterator и Visitor, например, похожи?
> И везде — читаешь книжку — прям-таки Америку открывают, хотя идеи-то > простые и уже использовались до того.
Ну так в том-то и смысл, чтобы выделить частоиспользуемые идеи,
классифицировать и описать их. Чтобы программисты, которые до них еще
сами не додумались не изобретали велосипед.
> C>А причем здесь Rational? Или у вас UML==Rational? > В предыдущем сообщении ответил. Rational — основные "продвигатели" > UML, AFAIK.
И что?
> Видите ли... текст я набираю явно быстрее, чем возюкаю мышой в любом > из UML-пейнтов. И мне проще текстом обьяснить и себе, и другим, что > конкретно требуется от каких классов.
Блин, UML нужен там, где описание на уровне методов и классов просто
неприменимо.
> Это во-первых. Кроме того, plain text отлично обрабатывается системой > контроля версий — лучше, чем бинарные форматы с диаграмками.
Откройте для себя XMI....
> Может, я чего-то действительно не понимаю — ну так обьясните.
A.Lokotkov wrote:
> C>Да, причем блок-схемы (если их использовать по назначению) существенно > C>помогали понимать алгоритмы. > Более того. Блок-схему можно транслировать в исполняемый код (язык > промышленного программирования CFC, как пример).
Нет, это уже abuse Если схема (UML или блок-схема) настолько
детальна, что из нее можно генерировать код — то лучше было сразу писать
код и не заморачиваться со схемами.
Здравствуйте, GlebZ, Вы писали:
GZ>А если убрать моделирование, то и UML и блок-схемы мало отличаются друг от друга.
Есть еще state-chart диаграммы, которые представляют собой достаточно полезную идею. Но они стоят, как мне кажется, как-то особняком от всех прочих видов UML-диаграмм.
Mystic wrote:
> C>Уже нужно рассуждать в более высокоуровневых терминах, типа: "Система A > C>делится на три подсистемы: сборщик данных (A1), потоковый буффер (A2), > C>обработчик потока (A3)". Если записывать все ТОЛЬКО словами (я пробовал > C> ), то получается каша. Уже становится нужным рисовать какие-то > C>пояснительные диаграммы и схемы. Для этого можно рисовать квадратики и > C>кружочки со стрелочками, а можно использовать стандартный UML. > Без слов вообще становится грустно
Кто говорит, что совсем без слов? Есть пояснительный текст, а в
самом UMLе есть текстовые комментарии.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Mystic, Вы писали:
M>>Т. е. рабобраться в .NET Framework без UML диаграмм невозможно?
Д>Возможно, конечно. Другой вопрос — сколько времени это займет. Но .NET Framework нужно изучать один раз в жизни, а новые проекты — регулярно.
Я к тому, что .NET Framework задокументирован лучше большинства проектов, изучение его не составляет большой сложности, но все обошлось без UML.
Здравствуйте, Mystic, Вы писали:
M>Я к тому, что .NET Framework задокументирован лучше большинства проектов, изучение его не составляет большой сложности, но все обошлось без UML.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Mystic, Вы писали:
M>>Я к тому, что .NET Framework задокументирован лучше большинства проектов, изучение его не составляет большой сложности, но все обошлось без UML.
Д>но с UML было бы проще
Mystic wrote:
> C>Ну, в общем, понятно. Как вы собираетесь словами описать систему из > 5000 > C>классов и тысяч 50000 методов? > Т. е. рабобраться в .NET Framework без UML диаграмм невозможно?
Некорректный пример — большая часть классов в .NET абсолютно не связана,
а просто лежит в одной "упаковке".
> Тысяч 50000, это 50 000 000 методов? По 10 000 на класс?
M>Без слов вообще становится грустно Учебник высшей математики в картинках... Грусть. Одной, как мне кажется, большой ошибкой является тот факт, что набора UML-диаграмм достаточно для описания архитектуры, проектирования, ...
Здравствуйте, AndrewVK, Вы писали:
AVK>А если бы они эти книжки не прочли? Ты чего предлагаешь — запретить паттерны по причине того что отдельные идиоты так и не поняли что это такое?
К сожалению, вы неаверное не представляете количество таких идиотичекских горе архитекторов и тим лидов. Проблемы начинаются когда такие горе архитекторы в угоду использования паттернов начинают неправильно расставлять приоритеты. К примеру, что важнее — воплощение бизнис требований или упрямое использование паттернов. Вот оказывается что для некоторых архитекторов второе, а бизнесу заевляется, что мы не можем сделать так как вы хотите, потому что это не вписывается красиво в мою модель... Он даже сам себя называл Pattern Police, и мы даже горько шутили что если он не может применить никакой другой паттерн — то будет использован Visitor. Вы не представляете куда можно засунуть его — даже GoF наверняка не предполагали такое. Или как вам нагромождение из 3х (трех) классов чтобы записать 1 (одну) строчку в XML? Вы наверное скажете — что таких надо гнать как можно быстрее — но есть обычно много факторов (политических, технических, бизнес) по которым избавится от такого человека бывает ой как не просто — в свое время заняло около пол-года чтобы понизить его до девелопера (выгнать — не получилось — очень специфический у него контракт был). Можно сказать — ну и фиг с ним что такое нагромождение паттернов — продукт то наверное выпущен. Да, после 2х лет задержки — и то "пожарниками" — т.е. консультантами. Но продукт в целом так до конца и не заработал в полную — так как в другой части проекта был такоей же горе паттерн-архитект.
Опять же можно сказать, что это единичный случай. Могу вас уверить — нет не единчный. Имея непосредственное отношение к крупнейшему консалтингу в мире, могу сказать, что таких пальцатых архитекторов и тим лидов в это консалтинге ну просто очень много (может мне конечно "везло"). Проблема во-первых в том что эти люди считают, что наличие названия компании о которой я говорю на бэджике (индетификационной карточке) добавляет минимум 100 поинтов к IQ а также автоматически делает их решения правильными, во-вторых похоже что консалтингу этой компании клиенты пофиг (клиенты как мотыльки на огонь все равно будут лететь на имя компании), ну а в-третьих даже если человек завалил проект, сделал его очень херово, не в срок и т.д. его просто переведут на следуюший (знаю мого таких случаев) — уволить в этой компании похоже очень тяжело.
Вообще, я не за запрет паттернов, но и не за повсеместное их насаждение и трезвую оценку — нужен паттерн в этом месте или нет, а то получаются factory по производству Одного Гвозя.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Mystic, Вы писали:
M>>Кто знает?! Видимо Microsoft так не считает...
Д>в MS порой придерживаются очень странных мнений. Взять хотя бы "венгерскую нотацию" или реестр, от кторого в конце концов они сами же отказались
Не ошибается тот, кто ничего не делает... Однако и описания STL, VCL и других библиотек не богаты UML-диаграммами, равно как и книги о них.
Здравствуйте, BorisKV, Вы писали:
BKV>К сожалению, вы неаверное не представляете количество таких идиотичекских горе архитекторов и тим лидов.
Какое это имеет значение в плане обсуждаемого вопроса? Ты что, считаешь что, если запретить паттерны, их станет сильно меньше? Боюсь что нет. Не будет паттернов, они найдут какой нибудь другой buzz word, вроде веб-сервисов или DSL, и история повторится.
BKV>Или как вам нагромождение из 3х (трех) классов чтобы записать 1 (одну) строчку в XML?
Вне контекста это ни о чем не говорит. Такое вполне может быть оправданным.
BKV> Вы наверное скажете — что таких надо гнать как можно быстрее — но есть обычно много факторов (политических, технических, бизнес) по которым избавится от такого человека бывает ой как не просто — в свое время заняло около пол-года чтобы понизить его до девелопера (выгнать — не получилось — очень специфический у него контракт был).
Это проблемы вашего отдела кадров и начальника, не сумевшего отфильтровать некомпетентных людей.
BKV>Опять же можно сказать, что это единичный случай. Могу вас уверить — нет не единчный. Имея непосредственное отношение к крупнейшему консалтингу в мире
IBM?
BKV>, могу сказать, что таких пальцатых архитекторов и тим лидов в это консалтинге ну просто очень много (может мне конечно "везло"). Проблема во-первых в том что эти люди считают, что наличие названия компании о которой я говорю на бэджике (индетификационной карточке) добавляет минимум 100 поинтов к IQ а также автоматически делает их решения правильными, во-вторых похоже что консалтингу этой компании клиенты пофиг (клиенты как мотыльки на огонь все равно будут лететь на имя компании), ну а в-третьих даже если человек завалил проект, сделал его очень херово, не в срок и т.д. его просто переведут на следуюший (знаю мого таких случаев) — уволить в этой компании похоже очень тяжело.
К счастью в России ситуация несколько лучше.
BKV>Вообще, я не за запрет паттернов, но и не за повсеместное их насаждение и трезвую оценку
Mystic wrote:
> C>Некорректный пример — большая часть классов в .NET абсолютно не > связана, > C>а просто лежит в одной "упаковке". > Может это хороший пример для подражания? Стиль "спагетти" без goto, но > только в классах меня удручает...
Простите, но не все производят исключительно базовые framework'и.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
C>>>Блок-схемы — это вполне жизнеспособная концепция, даже сейчас они C>>>используются для иллюстрации алгоритмов, например.
GZ>>Возьми Oberon, и реализуй на нем алгоритм. Будет не менее понятно. Или питон например.(главное не идти на поводу у Кнута )
M>А что такого у Кнута? Чем литературное программирование так плохо?
Плохо то, что алгоритмы показываются с помощью своего левого ассемблера. Больше времени угрохаешь на разбор ассемблера, чем на смысл алгоритма.
GlebZ wrote: > M>А что такого у Кнута? Чем литературное программирование так плохо? > Плохо то, что алгоритмы показываются с помощью своего левого ассемблера. > Больше времени угрохаешь на разбор ассемблера, чем на смысл алгоритма.
Здравствуйте, Дарней, Вы писали:
M>>Я к тому, что .NET Framework задокументирован лучше большинства проектов, изучение его не составляет большой сложности, но все обошлось без UML.
Д>но с UML было бы проще
UML у MS я видел только в документации к MMC, а это такое запутанное уёжище, пузыря для того, чтобы разобраться мало...
Здравствуйте, sch, Вы писали:
sch>Когда же будет изобретена технология, которая сможет дать вышеописанные результаты, то программирование из творчества превратится в ремесло...
Здравствуйте, GlebZ, Вы писали:
M>>А что такого у Кнута? Чем литературное программирование так плохо? GZ>Плохо то, что алгоритмы показываются с помощью своего левого ассемблера. Больше времени угрохаешь на разбор ассемблера, чем на смысл алгоритма.
Сколько раз можно повторять Алгоритм у Кнута очень понятно расписан словами. На ассемблере же приведена эффективная машинная реализация. По тем временам вещь необходимая. Но если брать программы, написаные Д. Кнутом (TeX, METAFONT) то там мы видим использование методологии литературного программирования. И я бы не сказал, что это нечитабельно и непонятно.
C>Нет, это уже abuse Если схема (UML или блок-схема) настолько C>детальна, что из нее можно генерировать код — то лучше было сразу писать C>код и не заморачиваться со схемами.
Не всегда. Скажем, если схема суть некий конечный автомат (или некоторая его вариация), то код будет существенно менее нагляден и понятен и правильней будет генерить его из схемы.
_Obelisk_ wrote:
> C>Нет, это уже abuse Если схема (UML или блок-схема) настолько > C>детальна, что из нее можно генерировать код — то лучше было сразу > писать > C>код и не заморачиваться со схемами. > Не всегда. Скажем, если схема суть некий конечный автомат (или > некоторая его вариация), то код будет существенно менее нагляден и > понятен и правильней будет генерить его из схемы.
Ладно, согласен — иногда (но очень редко) это имеет смысл
Здравствуйте, AndrewVK, Вы писали:
BKV>>Или как вам нагромождение из 3х (трех) классов чтобы записать 1 (одну) строчку в XML?
AVK>Вне контекста это ни о чем не говорит. Такое вполне может быть оправданным.
Контекст был такой. Отчёт, бланк на одну страницу, штук 50 полей. Максимум на 200 строчек кода в лоб вместе с хелперами. Результат — 77 классов. Эту херню (простите мне мой французский) программировало 4 человека, я тоже участвовал в этом бардаке. Что оно такое, как работает и зачем, я так и не понял.
AVK>Это проблемы вашего отдела кадров и начальника, не сумевшего отфильтровать некомпетентных людей.
Андрей, это уже из серии "Если вы такие умные, то почему тогда такие бедные"
BKV>>Опять же можно сказать, что это единичный случай. Могу вас уверить — нет не единчный. Имея непосредственное отношение к крупнейшему консалтингу в мире
AVK>IBM?
Не просто IBM. IBM в тесном сотрудничестве с Microsoft
AVK>К счастью в России ситуация несколько лучше.
Думаешь? Что-то я всё больше и больше начинаю сомневаться, что она вообще где-нибудь лучше. Тут дело не в России, а в проблемах в самой индустрии.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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 хорош, как языковонезависимый стандарт, легко рисуем и прост в понимании.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, 0rc
E>А можно ссылки на оригинальные высказывания Фаулера?
К сожалению, в электронном варианте я не искал.
А бумажный вариант:
UML.Основы. 3-е издание., СПб: Символ-Плюс,2004.- 192с., ISBN 5-93286-060-X ISBN 0-321-19368-7 (англ.)
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, 0rc, Вы писали:
0rc>>Трудности возникли с переводом C части. Пришлось исхитрятся и извращатся.
Д>Ну дык неудивительно — трудно положить ООП нотацию на не-ООП код
Д>PS А в чём он всё-таки прав то?
3. Тогда я спросил его, что он думает по поводу значения UML и его будущего. Он ответил: "Я не сторонник UML. Я считаю, что UML -- шаг назад, ибо продвигает идею блок-схем, а блок-схемы хороши только для решения совсем уж примитивных задач. Всё это -- этап, пройденный в конце 70-х"
Вот с выделенном он, по моему мнению, прав. Очень трудно отобразить в виде UML сложные задачи, в которых нет: a) ООП б)прецедентов в)сложное взаимодействие г) асинхронная активация., с нужной детализацией и с одновременным ненаграмождением абстрактных сущностей, которых в действительности нет. С этим я действительно встретился.
Ну а высказывание про блок-схемы я промолчу, в строгие блок-схемы UML я просто не верю, поскольку их трудно понять неподготовленному специалисту (иногда этим специалистом выступает заказчик).
Здравствуйте, _Obelisk_, Вы писали:
_O_>Не всегда. Скажем, если схема суть некий конечный автомат (или некоторая его вариация), то код будет существенно менее нагляден и понятен и правильней будет генерить его из схемы.
Если этот конечный автомат имеет пару десятков состояний, не думаю, что его схема покажется такой уж наглядной.
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Не всегда. Скажем, если схема суть некий конечный автомат (или некоторая его вариация), то код будет существенно менее нагляден и понятен и правильней будет генерить его из схемы.
Т>Если этот конечный автомат имеет пару десятков состояний, не думаю, что его схема покажется такой уж наглядной.
1. Схему можно разбить на несколько диаграмм
2. Можно использовать hierarchical state-ы и упрятать часть автомата в sub-state-ы.
3. Можно комбинировать автоматы с вызовом обычных функций и методов
Здравствуйте, Zdreni, Вы писали:
Z>Кроме того, plain text отлично обрабатывается системой контроля версий — лучше, чем бинарные форматы с диаграмками. Кроме того, по plain text лучше работает поиск. Кроме того, в plain text лучше видно, как согласовывался и менялся дизайн. Единственное, для чего plain text хуже — как я и сказал, это в демонстрации начальству "кипучести работы".
Z>Может, я чего-то действительно не понимаю — ну так обьясните.
Молодец, все правильно пишешь!
Добавлю от себя, в порядке обмена опытом. Есть такой замечательный plain text — называется CRC Cards. Подходит не только как лучший промежуточный формат для групповой разработки ОО модели, но и (!) как самый лучший (!!) комментарий (!!!) к классу в тексте программы, по информативности и компактности рвущий разнообразные детские рисунки как тузик грелку. Я, разумеется, говорю о больших, господа, больших проектах — от миллиона строк и выше. Чтобы снять возможное недопонимание.
Лучший способ передачи информации о дизайне (если хочется, чтобы идея дизайна хоть до кого-то дошла) — текстовый документ со связным, последовательным и аргументированным изложением, с небольшим количеством диаграмм по делу. Отличается от "UML-модели" примерно как художественная книга от телефонного справичника.
Из диаграмм реально полезно только то, что было в OMT. А именно —
1) диаграмма классов (не имеет смысла хранить и рисовать в тузлах — она элементарно восстанавливается по коду автоматически). Они не слишком информативны — обычно используются для набросков от руки поверх диаграммы при раздумьях и объяснениях. Например, удобно рисовать потоки данных поверх ассоциаций.
2) Конечные автоматы для асинхронных подсистем, например, для описания сетевых протоколов (вот натурально область, где без диаграмм тяжело — просто невозможно). В тех применениях, где такие модели реально нужны, они весьма слабо стыкуются с ООП. Из кода вытягивается очень сложно.
3) Диаграммы потоков данных нужны редко, но в ряде приложений и бизнес-анализе они совершенно незаменимы. В UML их нет, как нет вообще ни одной функциональной модели. С ООП стыкуется тоже очень смешно — практически никак. Из кода вытягивается очень сложно. Кстати, SADT/IDEF0 — очень достойная альтернатива DFD.
При этом, из перечисленных моделей тоже не надо делать культа. Понимание проблемы и умение объяснить ее на обычном человеческом языке — как обычно гораздо важнее. А все остальное — по большому счету такая бесполезная мутотень...
G>Лучший способ передачи информации о дизайне (если хочется, чтобы идея дизайна хоть до кого-то дошла) — текстовый документ со связным, последовательным и аргументированным изложением, с небольшим количеством диаграмм по делу. Отличается от "UML-модели" примерно как художественная книга от телефонного справичника.
Художественный (связный) текст — удобнее только, если надо получить общее впечатление обо всей архитектуре в целом.
Если же необходимо быстро получать информацию об обдельных аспектах работы программы, то удобнее справочник.
Здравствуйте, DarkGray, Вы писали:
G>>Лучший способ передачи информации о дизайне (если хочется, чтобы идея дизайна хоть до кого-то дошла) — текстовый документ со связным, последовательным и аргументированным изложением, с небольшим количеством диаграмм по делу. Отличается от "UML-модели" примерно как художественная книга от телефонного справичника.
DG>Художественный (связный) текст — удобнее только, если надо получить общее впечатление обо всей архитектуре в целом.
Он удобнее только, если вы хотите что-то понять. И речь идет не только об архитектуре, но и принципах дизайна отдельных подсистем. Модели UML в этом смысле совершенно не информативны и отвратительно структурированы.
DG>Если же необходимо быстро получать информацию об обдельных аспектах работы программы, то удобнее справочник.
Для этого удобнее всего исходный текст самой программы на языке высокого уровня — ничего лучше пока человечество не придумало.
Ну а что -- их швейцарский институт явно же может позволить себе решать те задачи, которые им нравятся 
Хотя лично я использую его в других целях.
"Всё что не убивает нас, делает нас сильнее..."
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
