Здравствуйте, AndreyFedotov, Вы писали:
AF> Без анализа какие компании применяют UML, в каких проектах и для чего — кроме беспредметного религиозного спора ничего не выйдет.
Ну не я же этот спор начал.. Собственно цель моего замечания была показать, что факт использования или не использования UML различными компаниями не может служить доказательством его нужности/не нужности при разработке софта. Так что тут совершенно нечего возразить.
AF> Если вы потратите время, что бы честно и спокойно ответить на эти вопросы — спорить станет не о чём.
Если на это тратить время, то оно окажется потрачено в пустую..
AF> Совсем другая картина в компаниях, которые занимаются автоматизацией — внутренней или внешней. В таких проектах предсказуемость сроков и качества работ выходят на первое место (клиенту то специфику IT обяснять никому не охота или собственному начальсту).
Стоп-стоп, а каким образом UML влияет на предсказуемость сроков? Что-то ничего, кроме как гарантировать что N-ое количество времени уйдет на рисование схем, в голову не приходит..
AF> Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков.
Не пойдет, за отмазку не канает... Проблема в том, что UML сам по себе достаточно сложен, и чтобы его адекватно применять разработчик и так должен быть хорошей квалификации. Соответственно разработчик низкой квалификации UML не понимает, а как только он начинает его понимать то его квалификация уже достаточно хороша, чтобы UML ему был не нужен.
Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.
Здравствуйте, OpenMinded, Вы писали:
OM>Здравствуйте, nixite, Вы писали:
OM> Мой личный опыт показывает, что UML полезен, но зачастую крайне не удобен, особенно, когда используется не для общения с разработчиками, а для общения с заказчиком.
А можно подробнее? Какие типы диаграмм вы показываете заказчику? В какой момент времени это происходит?
<skipped>
Очень противоречивое послание!
Со одной стороны вы говорите о порочности идеи, с другой стороны оговорите о той идеи, которая заложена в UML.
Про стандартизацию диаграмм и их множество, так и в русском языке тоже есть стандартизованные начертание 33-х букв, но ведь это не мешает использовать великий и могучий.
UML — это язык со своими "буквами", а то как вы его будете использовать, зависит только от вас.
Господа, идея с графами не нова. Увы, а может и нет.... http://www.mindmap.ru/
Есть книга на русском языке про "Карты Ума" http://www.books.ru/shop/books/137550
Например, у нас в проекте аналитик использует прогу "Mind Map" для "сбора требований".
Здравствуйте, Merle, Вы писали:
AF>> Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков. M>Не пойдет, за отмазку не канает... Проблема в том, что UML сам по себе достаточно сложен, и чтобы его адекватно применять разработчик и так должен быть хорошей квалификации. Соответственно разработчик низкой квалификации UML не понимает, а как только он начинает его понимать то его квалификация уже достаточно хороша, чтобы UML ему был не нужен. M>Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.
Например, в telecom-секторе UML становится заменителем SDL, вобрав в себя все фичи последнего.
Поэтому использование UML для тех задач, которые хорошо сводятся с statemachine-ам и синхронному/асинхронному обмену сообщениями, дает существенное преимущество перед ручным кодированием этих самых statemachine. Реализация ручками hierarchical statemachine с поддержкой save-ов и guard conditions черезвычайно муторное дело на любом языке программирования.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Например, в telecom-секторе UML становится заменителем SDL, вобрав в себя все фичи последнего.
Интересно, но тут я склонен думать, что скорее пошли от обратного. Сначала наворотили очень богатый инструментарий, а потом нашли как его применять. И опять-таки не сколько на финальном этапе, как предполагал Alexey Rovdo, сколько на начальном, для создания основного кода.
Здравствуйте, Merle, Вы писали:
AF>> Совсем другая картина в компаниях, которые занимаются автоматизацией — внутренней или внешней. В таких проектах предсказуемость сроков и качества работ выходят на первое место (клиенту то специфику IT обяснять никому не охота или собственному начальсту). M>Стоп-стоп, а каким образом UML влияет на предсказуемость сроков? Что-то ничего, кроме как гарантировать что N-ое количество времени уйдет на рисование схем, в голову не приходит..
Ответ содержался в следующей строке того же абзаца. А именнно — компании не применяют UML, как они не применяют C++ или Basic (хотя и могут писать на нём кучу софта). Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML.
AF>> Требуется процесс разработки, который позволяет вести проекты при, в среднем, довольно средней квалификации программистов. Причём делать это прогнозируемым образом. А такой процесс неизбежно требует средств описания тех же моделей — в первую очередь для самих разработчиков. M>Не пойдет, за отмазку не канает... Проблема в том, что UML сам по себе достаточно сложен, и чтобы его адекватно применять разработчик и так должен быть хорошей квалификации. Соответственно разработчик низкой квалификации UML не понимает, а как только он начинает его понимать то его квалификация уже достаточно хороша, чтобы UML ему был не нужен.
Это софистика. На практике покажи начинающему разработчику программу и попытайся обяснить на словах, как она работает (без рисования диаграмм или набросков) — крайне редко тебя поймут. А потом нарисуй диаграммы классов, последовательностей или состояний (смотря что полезнее в данном случае) — поймут гораздо быстрее. Проверял многократно.
Ну а по-поводу сложности — на любом языке можно писать (рисовать) так, что тебя нельзя будет понять. Только зачем? Тем более, что мастерство часто и состоит в том, что бы тебя поняли.
M>Таким образом делаем вывод, что UML хорош в качестве buzz word, чтобы красиво разогнуть пальцы перед заказчиком, мол "... наши разработки ведуться по RUP с применением UML... " и подсунуть клиенту красивые диаграмки, чтобы тот покивал с умным видом и ощутил свою причасность. Вот для этого UML и используется.. хм... дефакто.
Выводы каждый делает сам... Тем более, что заказчику чаще всего до фени, что вы там делаете или не делаете — ему нужен софт — хороший, надёжный и точно в срок.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML.
Вопрос не в этом, а в том, является ли UML неотъемлимой частью этого процесса и проиграет ли процесс вообще, если из него изъять UML или, наоборот, выиграет. И я все больше склоняюсь к тому, что скорее выиграет.
AF> Это софистика.
Ну ясен хвост.
AF> На практике покажи начинающему разработчику программу и попытайся обяснить на словах, как она работает (без рисования диаграмм или набросков) — крайне редко тебя поймут.
Хм.. Меня почему-то понимают.
AF>А потом нарисуй диаграммы классов, последовательностей или состояний (смотря что полезнее в данном случае) — поймут гораздо быстрее.
Да меня вообще не поймут, если не будут обладать достаточной для этого квалификацией, проходили уже, UML далеко не тривиален. А разработчиков с квалификацией сейчас не найти, а если найти, то они и без UML-я все поймут.
AF>Тем более, что мастерство часто и состоит в том, что бы тебя поняли.
Правильно, только UML здесь далеко не помощник.
Здравствуйте, Merle, Вы писали:
AF>> Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML. M>Вопрос не в этом, а в том, является ли UML неотъемлимой частью этого процесса и проиграет ли процесс вообще, если из него изъять UML или, наоборот, выиграет. И я все больше склоняюсь к тому, что скорее выиграет.
Вряд ли можно изъять UML из процессов, которые априори основаны именно на использовании этого языка. Другое дело, что можно применять другие процессы разработки, в которых роль UML-диаграм будут выполнять другие инструменты. Такие процессы могут быть похожи на существующие, однако это все-таки будут другие процессы. К примеру, представьте себе какое влияние на RUP могла бы оказать такая возможность как параллельная работа над структурой классов, реализация этих классов и тестирование уже готового кода. Я не хочу сказать, что запараллеливание данных работ будет полезным всегда. Но сегодня мы практически не имеем технической возможности реализовывать код и дорабатывать структуру приложения одновременно (разве только действовать с помощью инструментария, описанного _Obelisk_ ).
AndreyFedotov wrote:
> Это софистика. На практике покажи начинающему разработчику программу и > попытайся обяснить на словах, как она работает (без рисования диаграмм > или набросков) — крайне редко тебя поймут. А потом нарисуй диаграммы > классов, последовательностей или состояний (смотря что полезнее в > данном случае) — поймут гораздо быстрее. Проверял многократно.
Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а
простые наброски в виде квадратиков и стрелочек с надписями То есть
формальный синтаксис UML скорее мешает, чем помогает — проще
использовать нечто UML-подобное.
Здравствуйте, Cyberax, Вы писали:
C>Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а C>простые наброски в виде квадратиков и стрелочек с надписями То есть C>формальный синтаксис UML скорее мешает, чем помогает — проще C>использовать нечто UML-подобное.
Абсолютно согласен. Сам обычно так и делаю. Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Они применяют процесс разработки, основанный в том числе и на использовании UML. Эффект даёт именно процесс в целом, а не только и не столько UML. M>Вопрос не в этом, а в том, является ли UML неотъемлимой частью этого процесса и проиграет ли процесс вообще, если из него изъять UML или, наоборот, выиграет. И я все больше склоняюсь к тому, что скорее выиграет.
При условии лучшей или адекватной замены. А её пока нет.
AF>> На практике покажи начинающему разработчику программу и попытайся обяснить на словах, как она работает (без рисования диаграмм или набросков) — крайне редко тебя поймут. M>Хм.. Меня почему-то понимают.
Всегда? И сколько времени на это требуется?
AF>>А потом нарисуй диаграммы классов, последовательностей или состояний (смотря что полезнее в данном случае) — поймут гораздо быстрее. M>Да меня вообще не поймут, если не будут обладать достаточной для этого квалификацией, проходили уже, UML далеко не тривиален. А разработчиков с квалификацией сейчас не найти, а если найти, то они и без UML-я все поймут.
Странно, а у меня почему-то понимают...
AF>>Тем более, что мастерство часто и состоит в том, что бы тебя поняли. M>Правильно, только UML здесь далеко не помощник.
Это как применять.
Здравствуйте, AndreyFedotov, Вы писали:
AF> При условии лучшей или адекватной замены. А её пока нет.
Ну здрасьте, караднаш, бумага, слюни — замена вполне адекватная.
AF>Всегда? И сколько времени на это требуется?
Всегда. Мало. Намного меньше чем я потратил бы только на рисование, не считая объяснений.
AF>Странно, а у меня почему-то понимают...
Действительно странно.
AF> Это как применять.
А как не применяй.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.
А что, действительно есть проекты где более 100 человек делают одно и тоже и всем надо одно и то же объяснять? Это что, соревнование кто быстрее решит одну и ту же задачу?
AndreyFedotov wrote:
> C>Обычно гораздо эффективнее помогают не диаграммы в РациональнойРозе, а > C>простые наброски в виде квадратиков и стрелочек с надписями То есть > C>формальный синтаксис UML скорее мешает, чем помогает — проще > C>использовать нечто UML-подобное. > Абсолютно согласен. Сам обычно так и делаю. Только вы вспомните, что > UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 > человек, он создавался на случаи, когда над одним и тем же проектом > работает параллельно более 100 человек. Вот тогда наброски на бумаге > вообще перестают работать — просто не возможно рисовать и рассказывать > каждому одно и тоже.
Тогда эти наброски сканируем и рассылаем вместе с объяснениями.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>> При условии лучшей или адекватной замены. А её пока нет. M>Ну здрасьте, караднаш, бумага, слюни — замена вполне адекватная.
Берём проект человек на 300-400. Ты уверен что у тебя на всех карандашей, слюней и здоровья хватит?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже. M>А что, действительно есть проекты где более 100 человек делают одно и тоже и всем надо одно и то же объяснять? Это что, соревнование кто быстрее решит одну и ту же задачу?
Есть, но не одно и тоже, но работают над общей и достаточно крупной задачей. Тот же MS — не к столу будь сказано... В таких проектах часто на первое место выходит не скорость разработки, а управляемость процесса. Без документации при такой толпе народа её не достичь. UML в данном случае вовсе не лучший и не обязательный вариант, но система обозначений должна быть единой. Карандаш и слюни этого не обеспечивают
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Например, в telecom-секторе UML становится заменителем SDL, вобрав в себя все фичи последнего. M>Интересно, но тут я склонен думать, что скорее пошли от обратного. Сначала наворотили очень богатый инструментарий, а потом нашли как его применять. И опять-таки не сколько на финальном этапе, как предполагал Alexey Rovdo, сколько на начальном, для создания основного кода.
Не совсем так. Просто на стандарт UML 2.0 очень сильное влияние оказал стандарт SDL2000, а на SDL2000 в свое время оказал влияние набирающий обороты UML. Внедрения UML в нишу SDL-я есть ответ на потребности производства. Народ захотел UML-я, вот софтверные компании и прореагировали.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Только вы вспомните, что UML и RUP разрабатывался не для маленьких групп в 3-5-10 и даже в 20 человек, он создавался на случаи, когда над одним и тем же проектом работает параллельно более 100 человек. Вот тогда наброски на бумаге вообще перестают работать — просто не возможно рисовать и рассказывать каждому одно и тоже.
M>А что, действительно есть проекты где более 100 человек делают одно и тоже и всем надо одно и то же объяснять? Это что, соревнование кто быстрее решит одну и ту же задачу?
Я видел UML модель, над которой работает порядка 200 человек. Делают они, конечно, не одно и тоже, но работают с одной и той же моделью.
Число типов в данной модели превышает 100 000.
Мы уже победили, просто это еще не так заметно...
