среда, 18 сентября 2013 г.

Об UML и чертежах

Сегодня в голову пришла "крамольная" мысль. Даже жену спросил об этом.

Вот скажем как "всякие" сантехники или водопроводчики. Или токари чертежи читают.

Как?

Где их этому учат? В ПТУ вестимо.

И ничего. Читают и делают своё дело.

С разрезами, проекциями, фасками и прочими допусками.

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

И ничего.

Помните, как Лев Кассиль писал про "магию людей своими руками создающими вещи"? Там правда не очень оптимистичная кульминация сюжета была. Но это - не важно....

Так как же так получается, что люди с ВЫСШИМ образованием, в основной своей массе - НЕ ГОТОВЫ читать диаграммы UML. Ведь они не СЛОЖНЕЕ, чем чертежи. Которым кстати в школе учили. Азам. А уж в ВУЗах - и подавно. По себе знаю. У меня было много подобных дисциплин. И ничего. Никто не умер.

Сколько должно времени пройти, чтобы научились? Лет 50-т?

Начинать надо со школы? ВУЗов?

Ведь UML - явно - НЕ СЛОЖНЕЕ, чем чертежи.

Или "сантехники" умнее, чем "креативный класс"?

И ведь главное - ведь УМНЫЕ люди говорят - "не хотим читать ваш UML, мы в нём ничего не понимаем".

Проблема в UML? Или в "молодости технологии"? Или в менталитете?

Не понимаю.

У меня у жены кстати заказчики - читают UML. Откуда они "такие умные" взялись - не понимаю. Много вопросов по этому поводу задавал. Ответов - пока не получил.

Или я что-то не так трактую?

P.S. Меня тут "на просторах интернета" дружно "тыкали носом". Мол "прочитайте книжки про UML". Прочитал. И перечитал. Много всяких разных. Умных и не очень. "Отбашлял" денег авторам.

Того же Лармана перечитал. И много других. В количестве 6-ти штук.

Ну что могу сказать. Да ничего.

Кроме "рекламных лозунгов" типа "UML это круто" и "UML позволяет упрощать общение с заказчиками". А также обсуждений типа "какая стрелочка кошернее" - ничего не почерпнул оттуда. :-(

Может быть я такой дурак и не понимаю "гениальности замысла"?

И не умею "читать между строк"?

Я ИСКАЛ - МОТИВАЦИЮ. Что? Почему? Зачем?

ПОЧЕМУ - UML это - ЗДОРОВО. Не нашёл... :-(

Ни в одной из книжек.

Плохо искал?

P.P.S. У меня кстати родилась ещё одна "крамольная" мысль, что и RUP и XP и Agile -направлены на "сантехников" и "кодеров". Потому что предполагают "открытый формат", "незамороченность" и "нестатусность".

Может быть "у них там на Западе" - по-другому всё устроено?

P.P.P.S. Да! Никого не хочу "поругать" или задеть. Просто "со стороны наблюдаю". И не только на СВОЁМ опыте. Было бы это ТОЛЬКО на МОЁМ опыте. "В рамках отдельно взятого предприятия" - я бы и писать бы об этом не стал бы.

11 комментариев:

  1. С трудом себе представляю выпускника профильного ВУЗа, который имея доступ в Интернет не разберётся с UML-диаграммой.
    Другое дело, что рисовать означенные диаграммы он по своей воле не станет, поскольку чаще всего имеет дело с задачами, для решения которых они не необходимы.
    С другой стороны, проектировщики и архитекоторы в небольших компания (да и в больших тоже) со скепсисом относятся к применению UML, поскольку:
    1. Довести детали технического решения до исполнителя они чаще всего могут с использованием более простых средств.
    2. Большие UML-диаграммы воспринимаются чуть ли не хуже, чем текст на русском, а затраты на их производство/сопровождение несопоставимы.
    3. Как правило, детализация до классов не нужна, поскольку для проектировщиков и архитекоторов это не операционный язык. Они работают с более высоким уровнем - компонент, в то время как за классы отвечают конкретные исполнители, для которых уровень архитекторов тоже не операционный, они на нём редко работают.

    Таким образом получается, что применение UML ограничивается пояснительными картинками к техническим заданиям и постановкам.

    ОтветитьУдалить
  2. Пртиворечие, Ваше честь!

    >>который имея доступ в Интернет не разберётся с UML-диаграммой.

    >>Большие UML-диаграммы воспринимаются чуть ли не хуже

    ... и еще, позволю себе некий трюк, взяв за основу текст комментария

    Как правило, детализация до чертежей, поскольку для проектировщиков и архитекоторов это не операционный язык. Они работают с более высоким уровнем - детали, в то время как за сборку отвечают конкретные слесаря-сборщики, для которых уровень архитекторов тоже не операционный, они на нём редко работают.

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

    ОтветитьУдалить
  3. «Пртиворечие, Ваше честь!
    >> который имея доступ в Интернет не разберётся с UML-диаграммой.
    >> Большие UML-диаграммы воспринимаются чуть ли не хуже»
    -- В чём же Вы видите противоречие? ;-)
    Ну и разобраться - это одно, а использовать UML в роли такого же инструмента, как программный код - совсем другое.

    «... и еще, позволю себе некий трюк, взяв за основу текст комментария»
    -- 1. Для проектировщиков и архитекторов, о которых Вы говорите, чертежи как раз операционный язык. Более того, часто единственными артефактами их деятельности и являются означенные чертежи, в соответствии с которыми далее точат, куют и строят. В программировании же и артефакты другие и методы. Не удивительно, что на UML смотрят со скепсисом, поскольку вполне успешно обходятся без него.
    2. Далее, чертежи в Вашем случае являются формализованным языком, на котором инструкции передаются от проектировщика конкретному исполнителю. В программировании же UML на эту роль претендовать не может, поскольку формализовать позволяет далеко не всё и не с той степенью подробности, что в означенном Вами примере.
    3. В программировании совершенно иначе построено разделение труда. Кто по-Вашему должен рисовать диаграммы? Аналитик? - У него часто просто недостаточно квалификации для этого. Архитектор? - У него своих проблем полно. Программист? - Для него эти диаграммы - не более, чем пояснительные картинки. Ввести специалиста по созданию UML-диаграмм? - А зачем, если система успешно работает и без этого специалиста?

    ОтветитьУдалить
  4. >>Кто по-Вашему должен рисовать диаграммы?
    Все.

    Чертежи должны читать все. Рисовать - да, не все. А читать - да.

    >>А зачем, если система успешно работает и без этого специалиста?

    Бригада шабашников, строящих забор, тоже обходятся без чертежей.

    ОтветитьУдалить
  5. «Кто по-Вашему должен рисовать диаграммы?
    Все.

    Чертежи должны читать все. Рисовать - да, не все. А читать - да.»
    -- Читать все и могут. Тут не виду вообще никакой проблемы.

    «А зачем, если система успешно работает и без этого специалиста?

    Бригада шабашников, строящих забор, тоже обходятся без чертежей.»
    -- Врачи, учителя и учёные также зачастую без них обходятся.
    Не нужно спекулировать Всеволод, поднимая UML для программистов до уровня чертежей для токарей и строителей. Программисты не детали вытачивают и не бетон месят. Более тонкая работа требует более тонких инструментов.

    ОтветитьУдалить
    Ответы
    1. Простите.. Но у меня иногда создаётся ощущение, что ВСЕ МЫ (программисты) зорко охраняем свой "ореол таинственности".. Что мол "программирование - это творчество"... И вообще - закрытая сфера...

      По-моему - НЕТ ничего там ни "таинственного", ни "творческого" (я писал уже об этом).. По-моему - программирование на 80% состоит из "умения выполнять те или иные УСТОЯВШИЕСЯ правила"... не более того.. ну и 10% на творчество... ну и 10 - на всё остальное...

      Удалить
    2. "умения выполнять те или иные УСТОЯВШИЕСЯ правила"

      -- шаблоны проектирования, UML, RUP, стандартные алгоритмы, Agile, "best-practice".. далее - "добавить - по-вкусу"...

      Удалить
    3. "*поднимая* UML для программистов до уровня чертежей для токарей и строителей"
      "и не бетон месят. Более тонкая работа требует более тонких инструментов"

      -- по-моему - тут явное противоречие.. могу ошибаться...

      Удалить
    4. «Простите.. Но у меня иногда создаётся ощущение, что ВСЕ МЫ (программисты) зорко охраняем свой "ореол таинственности".. Что мол "программирование - это творчество"... И вообще - закрытая сфера...»
      -- Не знаю. Не замечал. Не понимаю, о каком "ореоле" идёт речь. Я такового не наблюдаю.
      И рассуждаю, по-моему, достаточно прозрачно. Есть понятие описательного языка (Pascal или UML, или вообще - русский). Есть предметы, с описанием которых он справляется хорошо, есть предметы, с описанием которых - плохо. Универсальных языков, одинаково хорошо годящихся для любых целей, пока, насколько мне известно, не создано. Не стоит ждать такой универсальности и от UML и от графической нотации вообще.

      «По-моему - программирование на 80% состоит из "умения выполнять те или иные УСТОЯВШИЕСЯ правила"... не более того.. ну и 10% на творчество... ну и 10 - на всё остальное...»
      -- Не знаю. Думаю, у каждого своё деление, зависящее от отношения к делу.

      «"умения выполнять те или иные УСТОЯВШИЕСЯ правила"

      -- шаблоны проектирования, UML, RUP, стандартные алгоритмы, Agile, "best-practice".. далее - "добавить - по-вкусу"...»
      -- Это всё - разновидности языков. Где-то они хороши, где-то - неадекватны.

      «"*поднимая* UML для программистов до уровня чертежей для токарей и строителей"
      "и не бетон месят. Более тонкая работа требует более тонких инструментов"

      -- по-моему - тут явное противоречие.. могу ошибаться...»
      -- Я не вижу противоречия. Я говорил ранее, что не виду причин, по которым UML должен быть универсальным языком для программистов. Это один из языков, у которого есть своя ниша. Она пересекается с программированием, но не может выступать в качестве полноценной замены специализированным языкам.
      Что же до "бетона" и его "замеса" - мне казалось очевидно. Есть низкоквалифицированная работа, есть высококвалифицированная. Чем сложнее область, тем выше порог входа и требования к навыкам. Восприятие программирования как ремесла имеет право на жизнь, если удаётся свести какую-то область к ремеслу, там можно широко распространить более простые подходы. Это вполне в духе мэйнстрима, но для такого мэйнстрима UML оказывается слишком сложным.
      С другой стороны, иные походы требуют более тонких инструментов, чем UML. Для таких подходов UML является громоздким, недостаточно гибким и детализированным. Мой первый пост в данной теме был посвящён этому.
      Что смущает и где Вы видите противоречие?

      Удалить
    5. "Не стоит ждать такой универсальности и от UML и от графической нотации вообще"

      -- я не говорю про "UML сейчас", я пытаюсь говорить про "чертежи в программировании в будущем".

      Удалить
    6. "Что смущает и где Вы видите противоречие?"
      -- "поднимать до уровня" и "месить бетон" - я тут вижу противоречие. Возможно - я как-то не так мыслю.

      Удалить