Здравствуйте, 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.
"Всё что не убивает нас, делает нас сильнее..."
Мы уже победили, просто это еще не так заметно...
