Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: Galogen от 07 Марта 2011, 00:01:03
-
Предлагаю ответить всем, кто хочет высказаться по этом поводу. Ваш ответ очень ценен для меня.
Желательно указать возрастную категорию: до 20, 21-30, 31-40, 41-50 и т.д.
-
Возрастная категория: 31-40
Я активно использую UML, так как он является фундаментальной вещью (не хочу употреблять слово "язык"), на которой можно построить:
1) процесс разработки ПО
2) способ мышления
Поясню.
Для большинства, UML - это некий язык с графической нотацией, который может как-то применяться при разработке ПО.
Я думаю тут все гораздо глубже.
UML на самом деле предлагает целый процесс разработки. Просто форма описания выбрана не стандартная. Нет деления на роли, к которым мы привыкли (при описании RUP попытались этот недостаток убрать).
Процесс разработки, который описыват UML, рассматривается с точки зрения того ЧТО надо разработать, а не с точки зрения того КТО разрабатывает. И это описание содержит все что ДОСТАТОЧНО сделать, чтобы полностью описать (построить) программную систему, т.е. такой минимальный джентельменский набор.
Конечно речь идет о разработке объектно-ориентированных программных систем.
Кроме этого, UML предлагает и некоторый новый способ мышления. По сути алгоритм, который позволяет связывать воедино термины разных уровней абстракции.
Поясню на примере.
Любой язык программирования работает на одном уровне абстракции (кстати очень низком). Когда программист пишет программу он оперирует переменными, классами, операциями и пр. На уровне языка это все безлико. Чтобы делать программу более понятной, программист дает названиям переменных, классов, операций осмысленные имена, поднимая тем самым уровень абстракции. Но он не может поднимать уровень описания выше некоторой границы. Например, до уровня понимания заказчика он дойти не может.
А UML это может.
-
Использую, но сейчас редко, т.к. ПМ более ориентирован на ARIS и текст. Пытался несколько раз переубеждать в ходе проекта - пока безуспешно.
С удовольствием бы прошёл какой-нибудь обучающий курс с целью продвижения идей Дениса Иванова.
Категория: 21-30.
-
Использую неформально (нотации не следую, типы стрелочек сознательно игнорирую). Мои любимые диаграммы: диаграмма юзкейсов, диаграмма последовательности, диаграмма состояний.
Возрастная категория: пока ещё 31-40.
-
Начала использовать 5 лет назад, пока работала аналитиком - в каждом проекте, сейчас использую реже, ибо задач на анализ меньше.
Почему да:
1. удобно представлять проблему, когда объектов больше, чем можно одновременно удержать в памяти
2. хорошее средство диагностики ("дыры" в требованиях или реализации)
Почему нет:
1. без владения методами анализа бесполезен, ибо только инструмент
2. слишком гибкий для ситуаций, когда требуется однозначная интерпретация
-
ЗЫ. 31 :)
-
21-30. Практически не использую, руководство не поощряет и времени на них не дает - в основном пишу сценарии использования по Коберну к сложной функциональности системы (для своего понимания, activity diagram рисовал всего 1-2 раза), для своего понимания рисую неформалтизованные блок-схемы с алгоритмами (мне их быстрее всего рисовать).
Мне кажется, что вопрос использования зачастую зависит от руководителя (по-крайне мере в больших компниях... если кто считает, что надо идти и доказывать пользу от внедрения практики использования UML, то я только испытательный прошел).
-
41-50
преподаватель
руководитель сектора тестирования
руководитель отдела сопровождения КИС
Как преподаватель широко использую UML. UML на мой взгляд синтетическая вещь, которая сложилась из массы подходов и диаграмм, которые использовались до этого десятилетиями и доказали свою эффективность. UML фундаментален, и в этом его прелесть в академическом образовании. Но сложен - ибо проще написать программу на коленке. Увы!
Как руководитель сектора тестирования - я бы хотел использовать UML. И я использую для наших внутренних целей, но недостаточно и слабосвязано с тестируемым проектом.
Как руководитель отдела сопровождения КИС я использую UML для фиксации идей, пожеланий пользователей, обсуждения прототипов решений с пользователями. К сожалению с программистами контакта через UML нет. Пару раз пытался, но не получилось. Видимо от меня ожидали использование реальных классов проекта, а не некоего прототипа решения. Хотя мне кажется они не правы.
Резюме: в учебных целях все нормально - ну куда деваться студенту :), в практической деятельности - попытка демонстрировать прекрасное знание английского языка неанглоязычной аудитории, да еще и не пытающейся тебя понять
-
21-30
UML не использую. Я занимаюсь бизнес-процессами, а в этой части у нас используется ARIS. В других видах деятельности на работе я просто не знаю как мне UML может помочь.
-
Друзья, прошу вас высказываться активнее в ту или иную сторону
-
Возрастная категория: 21-30
Начинал с работы системным аналитиком и сейчас работаю бизнес-аналитиком.
UML нигде, кроме как на собеседованиях при трудоустройстве не использовал за 6+ лет работы, а изучал только в рамках саморазвития.
По поводу использования UML у меня есть такое мнение, что в моей работе могли бы пригодиться только диаграммы USE CASE, последовательности, состояний. На практике же все эти диаграммы легко перекрываются диаграммами work/dataflow, блок-схемами, в части бизнес-процессов использую BPMN, можно использовать диаграммы ARIS, но на практике не прижилось.
Минусы у UML стандартные, помогает, только если им все заинтересованные лица им владеют. В практике моей работы настоящей потребности в этом языке, никогда не возникало, задачи успешно решаются и без него.
Мое личное мнение, если можно не использовать, то не используйте, лучше всего себя зарекомендовали инструменты, которые просты и понятны всем, от программистов до бизнес-пользователей.
-
Мое личное мнение, если можно не использовать, то не используйте, лучше всего себя зарекомендовали инструменты, которые просты и понятны всем, от программистов до бизнес-пользователей.
Спасибо за Ваше мнение, но а что это за инструменты, которые просты и понятны всем?
-
Возрастная категория: 41-50
Работала аналитиком и на стороне заказчика и на стороне исполнителя. Нигде не использовали UML. Только диаграммы последовательности для описания бизнес процессов. Считаю, что знать надо и пытаться использовать по возможности. Ибо процесс внедрения нового - это долгий процесс.
-
Предлагаю ответить всем, кто хочет высказаться по этом поводу. Ваш ответ очень ценен для меня.
Желательно указать возрастную категорию: до 20, 21-30, 31-40, 41-50 и т.д.
На предыдущей работе использовал эпизодически в основном для описания Use Cases и диаграмм деятельности верхнего уровня описывающего процесс работы пользователя в системе в рамках конкретного бизнес процесса.
На новой работе (3 месяца) использую более плотно в проекте 1С 8.
Диаграммы анализа для выделения ролей - boundary, документов - control, справочников - entity.
Диаграммы классов для описания объектов конфигурации и связи между ними (как прикладных так и базовых).
Диаграммы вариантов использования для описания функциональности в рамках роли.
Диаграммы деятельности для описания алгоритмов работы обработок (с углублением в основные процедуры и функции реализующих значимые алгоритмы).
В рамках этой деятельности и обучения в АНХ (www.itmane.ru) выбрал тему выпускной работы "Разработка методики моделирования приложений 1С для платформы 8.2 с использованием нотаций UML".
Защита в конце марта. Тезисы к работе доступны здесь http://www.ильяфедоров.рф (http://www.ильяфедоров.рф).
Возраст: 31-40.
-
Категория 21-30
В работе, точнее для работы (в отчетных документах) использую редко.
Почему в работе не используется?
Потому что нужны только картинки , и в Visio.
Описания, требования и т.п. - текстом.
Для объяснения и понимания - среди "понимающих" диаграммы - да (обычно юзкейсы, диаграммы последовательности и состояний).
Суммируем : Используем - 20% ; Не используем - 80%
-
Спасибо за Ваше мнение, но а что это за инструменты, которые просты и понятны всем?
Ничего понятнее, чем детализированное словесное описание еще не изобрели, а для иллюстрации, если уж необходимо, подойдет несколько схемочек из Visio, причем с сохранением постулатов SADT.
-
Ничего понятнее, чем детализированное словесное описание еще не изобрели, а для иллюстрации, если уж необходимо, подойдет несколько схемочек из Visio, причем с сохранением постулатов SADT.
Правильно ли я Вас понимаю, что Вы воспринимаете UML как средство иллюстрации, визуализации?
Да, а что это за постулаты SADT вы упомянули? Может это тоже, что я и думаю, но возможно что-то иное. Не мог ли бы вы их изложить коротенечко?
-
Довольно много посетителей высказалось, но недостаточно для более или менее объективных выводов.
Прошу посетителей форума активнее высказываться. Как постоянных, так и появляющихся здесь время от времени. Нужна репрезентативная выборка :) Большое спасибо заранее
-
Правильно ли я Вас понимаю, что Вы воспринимаете UML как средство иллюстрации, визуализации?
Да, а что это за постулаты SADT вы упомянули? Может это тоже, что я и думаю, но возможно что-то иное. Не мог ли бы вы их изложить коротенечко?
Воспринимаю, как язык моделирования, который представляет модель в визуальной форме.
Коротенечко, принципы SADT строились в свое время на масштабных исследованиях, в том числе, определялось оптимальное количество воспринимаемых объектов на визуальных моделях и диаграммах, так вот исследования тогда показали, что хорошо воспринимаются от 5 до 7 объектов, при необходимости использовать декомпозицию, собственно из этих предпосылок и исследований далее и развивались нотации IDEF0/3, DFD. Моделирование на языке UML либо не позволяет следовать таким рекомендациям, либо сильно ограничивают специалиста, так как на практике необходимы гораздо более сложные модели, где количество объектов на моделе легко может выходить за 10, что делает модели еще более сложными для восприятия другими заинтересованными лицами, а это уже ведет к ряду других проблем.
По-хорошему, стоит написать отдельную статью на эту тему, что-нибудь в стиле "Почему UML не работает?" но думаю сподоблюсь еще не скоро, надо вспомнить свои блоггерские навыки и открыть тематический блог.
-
Использую постоянно Д классов (бизнес-сущностей), активности и последовательности. Как для себя, так и чтобы донести мысль до Бизнеса и Разработчиков.
Для БП в последнее время использую BPMN.
По ситуации Д СВИ и Развертывания
Возрастная категория: пока еще 21-30
-
Саша, спасибо. Насколько ты считаешь это полезным. Не является ли это искусственным? Как твои подвиги воспринимаются другими?
-
Если объяснить зачем нужны это Д, как их читать и проговаривать их вместе с Бизнесом или Разработчиками, то очень помогают и хорошо воспринимаются.
Если просто послать Д по почте, то в ответ будешь также послан.
-
41-50. Активно использую UML при создании постановок. Вообще UML используется в нашей компании с где-то с 2002 года, и я был одним из инициаторов.
Активно используются диаграммы классов и диаграммы состояний (для документооборота). Когда уместно - диаграммы деятельности, диаграммы последовательностей и другие. Для рисования используется visio с шаблонами от http://www.softwarestencils.com/. Мы воспринимаем UML как удобный и разнообразный набор диаграмм со стандартной нотацией. А сами диаграммы - рассматриваем как необходимую часть постановок. В общем, по Фаулеру (UML distilled).
При этом диаграммы читают все - они согласуются с заказчиком (в том числе - не с ИТ), по ним идет реализация разработчиками и так далее. Поэтому избегаем излишней нагруженности и подробностей, например, не показываем фискальные атрибуты, а также сознательно ограничиваем сложность используемой нотации.
-
Довольно много посетителей высказалось, но недостаточно для более или менее объективных выводов.
Эдуард, а где вы хотите использовать этим выводы?
Может, есть более короткий и простой способ достижения цели? :)
-
Возрастная категория 21-30
Использую, скорее, для себя и не во всех ситациях, в качестве стандарта UML в компании не прижился по разным причинам (среди нас есть сторонники BPWin и всего, что ему сопутствует; еще дело в том, на мой взгляд, что и заказчики, и разработчики, и другие наши сотрудники предпочитают текст и картинки а-ля прототипы интерфейса)...
Для меня диаграммы UML играют роль шаблона, помогающего структурировать информацию о предметной области и анализируемых процессах / объектах, причем, дальше уже становится не важно: будет нарисована сама диаграмма или все то же самое будет написано текстом - главное, что вся необходимая информация, таким образом, будет зафиксирована, и ничего не будет забыто. Наиболее полезными для себя считаю диаграммы деятельности, вариантов использования, состояний, последовательности, классов + может, еще иногда развертывания.
Еще одна из причин не использования UML в качестве стандарта, на мой взгляд, заключается в том, что просто нет физической возможности перевести все описание системы на язык диаграмм, из чего вытекает формат использования UML лишь от случая к случаю по необходимости, определяемой аналитиком... А когда что-то становится опциональным, то и применяется оно при наличии знаний, умений, навыков, желания, привычки... (нужное подчеркнуть). :)
P.S. Студентов, тем не менее, учу, что UML необходим и полезен :)
-
Друзья, спасибо за ответы. Я еще подожду, прежде чем предлагать результаты на обсуждение.
Может, есть более короткий и простой способ достижения цели? :)
Марина, догадываюсь у Вас есть на этот Ваш ответ. Может поделитесь своими мыслями на этот счет?
-
darco
По-хорошему, стоит написать отдельную статью на эту тему, что-нибудь в стиле "Почему UML не работает?" но думаю сподоблюсь еще не скоро, надо вспомнить свои блоггерские навыки и открыть тематический блог.
Да такая статья не помешает.
Или чем UML (точнее диаграммы на нем) лучше простых квадратиков и ромбиков.
bas
Если объяснить зачем нужны это Д, как их читать и проговаривать их вместе с Бизнесом или Разработчиками...
Согласен. В этом часто и есть основная проблема - непонимание с другой стороны.
-
Преподаватель, 31-40. Читаю курс, веду практикум к курсу, темы дипломных и курсовых даю, связанные с UML. Так что, можно сказать, что использую.
UML отличается от квадратиков тем, что он читаем не только людьми, но и программами. Значит, модель является не подпоркой, а ключевым звеном.
-
21-30. Пока ещё только изучаю. Но стараюсь применять не только в своих личных проектах, но и на работе, например при проектировании приложений на языке C. в этом случае диаграмма классов отсутствует, поэтому я точно не уверен, допустимо ли в этом случае использовать UML, но модель вырисовывается. На текстовые требования никогда не хватает времени, поэтому всё очень кратко. Генерация кода из диаграммы классов, оказывается очень полезной, когда не ясно как выглядит диаграмма на языке программирования и когда нужно писать код по одной модели на разных языках.
-
Опрос по схожей теме на хабре (http://habrahabr.ru/post/153353/).
-
Ну вполне закономерные результаты (про хабр) - зачем сантехнику математика? (на фига программистам UML? ))
Я сейчас использую EA в сочетании с плагином собственной разработки моей компании для сурового информационного моделирования, предметная область - банковская деятельность.
Довольно интересно получается. Фактически, здесь придуман свой собственный формальный язык на базе средств UML.
Параллельно пробую сделать модель для другой сферы своих интересов, впечатляет то, насколько точным и полным получается конечный результат.
-
Отдельные диаграммы из uml использую - восновном sequence и state-chart.
С моей точки зрения, uml сел между всех стульев:
- Для бизнеса - он слишком технический. Есть гораздо более простые способы донести свою мысль.
- Для разработчиков - он вроде бы и язык программирования, только очень громоздкий и неудобный.
- Для архитекторов - он слишком детализированный что-ли. Архитектор размышляющий на уровне uml - какой-то уж совсем наноархитектор получается. Да и архитектурные вопросы, по моему, в ООП парадигму не укладываются совсем.
Практическое применение uml для меня - быстро проиллюстрировать разработчикам какую-нибудь мысль. Т.е. фактически, всё формальное великолепие uml сводится к набору несвязанных между собой типов диаграммок, которые все, кто имеет отношение к разработке, худо-бедно понимают.
-
Я уважаю ваше мнение, но не могу согласиться.
С моей точки зрения, uml сел между всех стульев:
- Для бизнеса - он слишком технический. Есть гораздо более простые способы донести свою мысль.
UML никогда не позиционировался как система для моделирования бизнеса. Вы пытаетесь усадить UML на чужой стул.
- Для разработчиков - он вроде бы и язык программирования, только очень громоздкий и неудобный.
UML никогда не был языком программирования и не должен стать, иначе естественно он будет громоздким и неудобным. Однако UML - это язык МОДЕЛИРОВАНИЯ, разница ощущается?
- Для архитекторов - он слишком детализированный что-ли. Архитектор размышляющий на уровне uml - какой-то уж совсем наноархитектор получается. Да и архитектурные вопросы, по моему, в ООП парадигму не укладываются совсем.
Забавное у вас представление об архитектуре и архитекторах. Будто бы Главнй Конструктор (ну тот что вселенные создает походя, чего ему тут UML как зубочистка)
Практическое применение uml для меня - быстро проиллюстрировать разработчикам какую-нибудь мысль. Т.е. фактически, всё формальное великолепие uml сводится к набору несвязанных между собой типов диаграммок, которые все, кто имеет отношение к разработке, худо-бедно понимают.
Просто мало кто реально знает, понимает как использовать этот язык. Кто потратился на это, понимают преимущества. Однако ведь задачи задачам рознь. Это как единоборства, у кого-то получается, у кого-то нет. Но без тренировок само по себе ничего не происходит
-
С моей точки зрения, uml сел между всех стульев:
- Для бизнеса - он слишком технический. Есть гораздо более простые способы донести свою мысль.
- Для разработчиков - он вроде бы и язык программирования, только очень громоздкий и неудобный.
- Для архитекторов - он слишком детализированный что-ли. Архитектор размышляющий на уровне uml - какой-то уж совсем наноархитектор получается. Да и архитектурные вопросы, по моему, в ООП парадигму не укладываются совсем.
Кривыми руками можно и из кастрюли сделать орудие убийства.
Как верно замечено - у большинства людей в ИТ области на исполнительских должностях мышление конкретное, а UML требует развитого абстрактного.
Так вот людям, у которых оно конкретное, действительно не нужно им пользоваться - только чистый текст! Ясный, линейный, одномерный (только не спрашивайте, что вам делать, если в команде никто не умеет писАть - см. про кастрюлю).
-
Я уважаю ваше мнение, но не могу согласиться.UML никогда не позиционировался как система для моделирования бизнеса. Вы пытаетесь усадить UML на чужой стул.
UML никогда не был языком программирования и не должен стать, иначе естественно он будет громоздким и неудобным. Однако UML - это язык МОДЕЛИРОВАНИЯ, разница ощущается?
Забавное у вас представление об архитектуре и архитекторах. Будто бы Главнй Конструктор (ну тот что вселенные создает походя, чего ему тут UML как зубочистка)
Просто мало кто реально знает, понимает как использовать этот язык. Кто потратился на это, понимают преимущества. Однако ведь задачи задачам рознь. Это как единоборства, у кого-то получается, у кого-то нет. Но без тренировок само по себе ничего не происходит
Про моделирование бизнеса. Даже на этом сайте были статьи типа "Использование UML для моделирования БП". И в книжках есть на эту тему немало. Рад, что не я один считаю, что uml для этой цели не совсем подходит.
Про разработчиков. Если разработчику нужно что-то смоделировать, вряд ли ему нужно строить полную и корректную uml модель из нескольких связанных диаграмм в правильном инструменте. Отдельных диаграмм от руки на доске вполне хватает. Ну может быть вы знаете каких-то других разработчиков. Я за свой опыт только говорю.
Про то что это не язык программирования. Помнится, когда вышел uml2 было много информации на тему, что теперь uml наконец-то стал (ну или почти стал) пригоден для однозначного определения кода программы. И всех нас неминуемо ждёт MDA. Так что, не вижу криминала в том чтобы смотреть на Uml, как на язык программирования.
Про архитекторов. Когда я говорил про архитекторов, у меня в голове был Отдел Архитектуры в нашей компании. Они такой мелочью как потроха какой-то АСки не занимаются. Забыл про роль архитектора на отдельной АС. Возможно uml подойдет таким людям. Присутствовал при паре неуспешных попыток его использовать для этих целей. Наверное у кого-то всё получилось.
-
Про моделирование бизнеса. Даже на этом сайте были статьи типа "Использование UML для моделирования БП". И в книжках есть на эту тему немало. Рад, что не я один считаю, что uml для этой цели не совсем подходит.
Да речь не о том, что можно или нельзя использовать UML для моделирования бизнеса. А о том, что Вы подвергаете критики то, что якобы приписывают UML и что он это якобы узурпировал.
Можно использовать UML для описания бизнес систем, почему нет? Кстати так и делается. Все зависит о того, где кому и для чего. Это же язык.
Про разработчиков. Если разработчику нужно что-то смоделировать, вряд ли ему нужно строить полную и корректную uml модель из нескольких связанных диаграмм в правильном инструменте. Отдельных диаграмм от руки на доске вполне хватает. Ну может быть вы знаете каких-то других разработчиков. Я за свой опыт только говорю.
1. никто это не оспаривает KISS принцип работает. Но хорошая модель UML играет не только роль донесения смысла и идеи решения, но она и документирует решение, сохраняет его и может быть использовано в дальнейшем.
2. Никто ведь не утверждает, что без формализованных требований, формализованного процесса, формализованных артефактов проектирования и т.п. нельзя получить решение. Тут вопрос качества, воспроизведения качества и т.п. UML может быть частью этого качества, но это не просто.
Про то что это не язык программирования. Помнится, когда вышел uml2 было много информации на тему, что теперь uml наконец-то стал (ну или почти стал) пригоден для однозначного определения кода программы. И всех нас неминуемо ждёт MDA. Так что, не вижу криминала в том чтобы смотреть на Uml, как на язык программирования.
Исполняемый UML не является языком в полной мере, но все-таки попытка стать языком программирования и приводит к тому, о чем вы пишете. Естественно проще писать на нормальном языке, чем продираться через тонкости исполняемого UML. Чем больше UML становится языком "программирования", тем больше он перестает быть UML.
Про архитекторов. Когда я говорил про архитекторов, у меня в голове был Отдел Архитектуры в нашей компании. Они такой мелочью как потроха какой-то АСки не занимаются. Забыл про роль архитектора на отдельной АС. Возможно uml подойдет таким людям. Присутствовал при паре неуспешных попыток его использовать для этих целей. Наверное у кого-то всё получилось.
У меня тоже нет примеров успешного использования UML в тех или иных более или менее серьезных компаниях. Но есть примеры очень успешного применения UML отдельными людьми и небольшими группами.
Но вот зарубежом ситуация совсем другая. Правда, нет примеров с моим личным участием, потому не могу их обсуждать.
Правда, я не пытаюсь переубедить вас в вашем мнение. Просто в своем утверждении (с которого началась дискуссия) вы сделали некорректные выводы, наделив UML тем, чем он не является.
-
В докторской диссертации Д. В. Кознова есть статистика по использованию UML в Питере (правда, собранная в 2008 году).
См. https://disser.spbu.ru/disser2/706/disser/Dissertation_Koznov.pdf стр. 31 и далее.
41 из 76 используют UML. 32 из 41 -- как рисуночки. 23 из 41 рисуют не карандашом на бумаге, а в программах. 31 из 41 сами захотели UML, не из-под палки. Топ 3 нужных UML-диаграмм: диаграммы классов, диаграммы ВИ, диаграммы последовательности.
-
В докторской диссертации Д. В. Кознова есть статистика по использованию UML в Питере (правда, собранная в 2008 году).
См. https://disser.spbu.ru/disser2/706/disser/Dissertation_Koznov.pdf стр. 31 и далее.
Интересно бы повторить исследование
-
Есть статья британского учёного (тм) с исследованием 2013 года: https://goo.gl/lrDYpw
Если сравнивать, то питерцы из 2008-го очень продвинуты в использовании UML.)
Другая публикация той же свежести посвящена исследованию проиндексированных гуглем EA-проектов. На 121й модели из открытых источников сосчитали частоту использования диаграмм, элементов языка, стереотипов и т. д.: http://subs.emis.de/LNI/Proceedings/Proceedings225/289.pdf
Хороший источник развлекательных вставок в слайды.)
-
Есть статья британского учёного (тм) с исследованием 2013 года: https://goo.gl/lrDYpw
Если сравнивать, то питерцы из 2008-го очень продвинуты в использовании UML.)
Другая публикация той же свежести посвящена исследованию проиндексированных гуглем EA-проектов. На 121й модели из открытых источников сосчитали частоту использования диаграмм, элементов языка, стереотипов и т. д.: http://subs.emis.de/LNI/Proceedings/Proceedings225/289.pdf
Хороший источник развлекательных вставок в слайды.)
Да, интересно :)
-
Интересно бы повторить исследование
Вот уж да уж.
А то такое чувство, что кругом одни имбецилы и дегенераты, а мне просто сказочно повезло, или же я живу на другой планете. В 2005-2007 годах прекрасно наши бизнес-пользователи понимали диаграммы в нотации UML (мы их вставляли в ТЗ). Причем, что характерно, не владея самой нотацией - просто для них такой способ визуализации оказался вполне естественным. Если это имеет какое-то значение, заказчики были из финансовой сферы, с высшим образованием, география - Москва, Питер, Минск. Использовали диаграммы последовательностей, состояний, деятельности, классов, кооперации.