С какими типами UML-диаграмм вам приходится работать?

Какие диаграммы принесут на перевод, с такими и работаю. UML ни разу не приносили: обычно попадаются или автофигуры Word/PowerPont с надписями, или встроенные файлы Visio, или вставленные в документ растровые картинки с надписями.

Получается, «Не использую UML в повседневной работе».

а если принесут UML? там порог вхождения чуть выше чем во многих других диаграммах.

а если принесут UML?

Вряд ли. Я пока локализирую UI и перевожу документы, весьма далекие от программирования (вроде сельского хозяйства и полиграфии).

Да и если подумать, кому понадобится переводить UML? Если фирма работает на внутренний рынок, документация будет на русском (или украинском). Галере на аутсорсе достаточно документации на английском. Международная компания с офисом где-то на просторах? Ну, может быть, но пока с такими не работал.

там порог вхождения чуть выше чем во многих других диаграммах.

Если все-таки принесут, буду разбираться. Если найду способ скормить UML какой-нибудь CAT, переведу в CAT. Если не найду, переведу по-старинке в редакторе. Заменить текст не сложно. Главное - в предметной области разобраться.

В draw.io просто для себя делаю зарисовки разве что, прямоугольниками с надписями и всё =) Типа такого

• https://i.ibb.co/9gnq7zv/drawio.png

Считается? :D Ни на какие категории диаграммы не делю.
Всё одно и тоже, просто выглядит по разному.

От такого

• Диаграмма деятельности

Теряюсь в догадках что это такое…

С какими типами

Я опять забыл: какая из этих перечисленных в оригинале называлась use case?

Диаграмма деятельности

В оригинале — activity :)

(Автору: возможно, для некоторых вариантов ответов до подтверждения надо будет привести оригинальные названия в скобках. Нет, не для классов и компонентов, с этими всё понятно, а для таких вот.)

Диаграммы прецедентов

Первая диаграмма что-то среднее между Диаграмма состояний и последовательности, вторая похожа на Диаграмму последовательности. В твоих диаграммах нет легенды цветов стрелок, операции(преценденты) и объекты представленны одинаково - прямоугольниками, на второй диаграмме не понятно схождение стрелок --><-- между статус онлайн и игровой сервер. В случае с UML где стрелки стандартизированны читать было бы легче.

изменил пункты, некоторые диаграммы объеденил, т.к. они являются производными, добавил пункты отказа, посмотри последний, мне формулировака не нравится, может как то изменить?

Где варианты «не взаимодействую» и «что это»?

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

Стандартизованное графическое моделирование не является необходимым условием для реализации проекта

Ну по крайней мере когда делаешь один.
Но для многих проектов и в коммандной работе оно не обязательно. Оно становится нужным когда кто-то в комманде без наглядного рисунка затрудняется понять структуру

Вопрос «что это» мне кажется не уместным в данном вопросе, диаграммы, я думаю, все понимают что такое.

Первый раз вижу это название (UML). В опросах обычно объясняют о чём речь а не тупо сразу список вариантов.

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

Как писатель – диаграммы классов и когда-то давно имел дело с компонентами. Как читатель – use case.

Из других нотаций приходилось делать ER-модели в нотации Oracle. Да, строго говоря, это не альтернатива UML, это просто другая область моделирования… хотя ряд авторов настойчиво предлагает использовать для ER-моделирования UML-ные диаграммы классов (на мой взгляд, это натягивание филина на глобус, но сильно не настаиваю).

Рисую диаграммы по спекам С4 (Сосиска 4)

Куда отнести «логическую схему базы данных»

К «другой нотации», думаю.

UML был популярен во времена каскадных моделей разработки. Т.к. позволял очень детально смоделировать систему на этапе проектирования. По сути, конкретный код ввода вывода оставалось разработчикам по какому-нить RUP написать, ну и обойти ошибки в модели.

Сейчас, я вообще х3 кто хоть сколько-то регулярно использует UML по его прямому назначения.

Использование отдельных диаграм модели для «наглядности», нельзя назвать применением UML, т.к. по задумке, каждая диаграмма, это окно в единую объектную модель.

В draw.io просто для себя делаю зарисовки разве что, прямоугольниками с надписями и всё =) Типа такого

Напомнило блок-схемы для Паскаля школьных времён.

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

Про UML вообще впервые узнал.

UML был популярен во времена каскадных моделей разработки.

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

При этом детальность не обязана быть высокой, иногда её даже полезно ограничивать, и по-моему, Гради Буч с товарищами об этом писали.

Использование отдельных диаграм модели для «наглядности», нельзя назвать применением UML, т.к. по задумке, каждая диаграмма, это окно в единую объектную модель.

Ну это идеальный случай, да. Но его совсем необязательно переносить в реальную жизнь.

Только в книжке читал (у Гради Буча), но на практике не использовал никогда, т.к. ненужно (по крайней мере мне).

UML (Unified Modeling Language) …

Нарисованные кружочки со стрелочками нельзя назвать моделью - результат работы модели узреть нельзя же. Тогда выходит, что Ю-Эм-Эл это язык не моделирования, а лишь описания. Так на практике и получается, что эти описательные рисунки нужны лишь программистам, вновь входящим в проект, чтобы понять суть предстоящей работы.

Лучше людей ценить и удерживать, чтобы не уходили из проекта, а не пытаться заменять людей рисуночками да писаниной. Умный программист, разобравшись в работе, также уйдет, а глупому программисту рисуночки не помогут развивать дело - мышление не то, что нужно.

Если бы кто-то осилил пристегнуть к идее моделирования нормальную кодогенерацию, то мы жили бы в чудесном мире.

А так, по-моему, даже жабу не смогли нормально примотать, не говоря об остальных.

Я как-то из любопытства написал пару хеллоуворлдов в eclipse papyrus, так синхронизация крестового говнокода с диаграммами заняла у меня в несколько раз больше времени, чем если бы я тупо колбасил код в любимом блокнотике. Это был забавный и поучительный эксперимент.

Рисую как умею в том, что есть под рукой, но это явно не UML. Получается, что не использую.

Я общался с одним мужиком, который код из IBM Rhapsody генерировал. Говорил, всё чудесно.

Использую SADT, DFD, ER, IDEF0. UML по сравнению с ними - отстой.

Использую CADT

Я скромное земное существо, из моего погреба туда не дотянуться. В свое время сильно этим заинтересовался, но перещупал опенсорцные поделия и приуныл, да так и живу приунывши.

А у меня на половом органе в ряд могут сидеть тридцать два воробушка.

Пишу всё в PlantUML, а если надо много чего, пишу в ASCIIdoc с инкапсулированным PlantUML.

Почему классы и объекты в одном пункте? Раньше ж это были две разных диаграммы.

Использую диаграмму классов, отдельно диаграмму объектов.

Часто нужна диаграмма последовательности.

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

Для структурных схем системы использую не-UML нотацию.

Было бы хорошо пройтись опросом по средствам построения UML. Использует ли кто кодогенерацию и реверсит ли код в UML?

Когда то тыкал палочкой в RationalRose.

Диаграммы классов генерит doxygen, наглядно но меня вымораживает что стрелочки не в ту сторона развернуты. Т.е. это мне понятней когда они в другую сторону смотрят, не как в UML.

В сложных случаях иногда сам в dot рисую разбивку на компоненты (утилиты? модули? ХЗ как правильно назвать), данные в квадратиках, операция над данными в овалах, между ними стрелочки.

При этом детальность не обязана быть высокой, иногда её даже полезно ограничивать, и по-моему, Гради Буч с товарищами об этом писали.

Для этого можно и более простые нотации использовать, имхо. В смысле что, конечно можно, но это будет не применение инструмента по назначению и «из пушки по воробьям».

Второй момент, если брать экстремальное программирование, которое сейчас чуть ли не везде, то тут за одну итерацию редко прям архитектура меняется.

я думаю, все понимают что такое.

[x] Что такое UML? 62 (42%)

:)

Описываю всё текстом.

Тоже иногда делаю диаграммы с помощью обычного рисования (обычно на бумаге), смыслы геометрических фигур и стрелок придумываю на ходу такие чтоб было удобно для конкретного текущего случая. Но вроде UML это какой-то конкретный язык а не просто диаграммы.

Когда вам надо UML потому что без него не разобраться (в том числе входящими в проект программистами), вы уже капитально так обосрались с архитектурой и ваш проект пора переписывать. Условного doxygen-а за глаза должно быть для вникающих и вообще хорошо если и комментарии под него писать, как и комментарии к каждому классу нафига он нужен и в начале каждого файла что это за файл такой. Вот это сильно упрощает вникание и понимание происходящего. А если ещё в гите коммиты осмысленно писать и договориться о том как именно их формировать (я нынче пишу feat: added some new feature, fix: fixed memory leak while reading file (bug тут номер бага если он есть в багтрекере) и т.д.).

ЗЫ

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

sequence (часто); use case (сейчас - относительно редко); BPMN

когда-то, очень давно, использовали для проектирования БД тулзу от Sybase, она была проприетарная, но имела человеческий интерфейс. для проектирования БД она была удобна.

с тех пор я тыкала палочкой разные опенсорцные UML-ные поделия. но всё было грустно, выглядело страшненько и геморроя было больше, чем пользы. базу проще SQL-ным скриптом написать, чем в этих тулзах натягивать сову на глобус.

а вообще, для проектирования ничего лучше бумажки (возможно, доски для рисования) пока не придумали. пыталась также использовать рисовалки схем, майнд-мапы на компе, чтобы экономить бумагу, но возникла та же проблема: геморроя много, а эффективность почти нулевая. когда думаешь, думаешь быстро, а рисовать быстро в какой-то оболочке не получается. в итоге, быстро забиваешь на эти красивые схемки. бумажка пока является оптимальным средством разработки. просто покупаю большую тетрадь формата А4 - и вперёд.

Возможно граф.планшет будет более подходящим решением.

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

С uml сталкивался, не понимал зачем на это тратить время, текст программы понятнее, ну может глянуть сгенерированную диаграмму базы данных.
Из всех диаграмм, часто использую диаграммы ганта (планирование последовательности работ и их сроков), но это не разу не uml.

Сколько ни пытаюсь начать использовать UML, всё никак не получается. Оно наглядно (если умеешь составлять, с чем у меня не всё хорошо), но на создание тратится неприлично много времени