UML как инструмент для проектирования архитектуры софта

Хочу до запуска IDE иметь окончательно продуманную структуру программы.

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

А UML устарел лет так 15 назад, как минимум. Был когда-то такой buzz word для hr. Еще кое-где отголоски встречаются, но все реже.

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

Частые подходы к станку в моём случае приводят к постоянному рефакторингу и созданию огромного количества функций, которые занимаются лишь преобразованием типов. Это очень мутный и неприятный код.
Чистый каскадный подход для меня невозможен: я могу продумать логику изначально, поскольку у меня есть голова на плечах и я вполне владею плюсами, но, например, UI я буду реализовывать на Qt, с которым знаком настолько поверхностно, что без «подходов к станку» в принципе не смогу продумать всё правильно и полностью.
Но главное-то — логика. И эту часть хотелось бы спроектировать до собственно запуска станка.
Да я и не строго про UML. Возможно есть какие-то другие методики. Просто UML был на слуху и отложился в голове.

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

у меня обычно это стрелочки в квадратик с подписью «жопа» ))

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

Не структуру программы, а архитектуру системы ... /скорее макро архитектуру .../.
Впрочем возможны и другие мнения.

Проект будет на Си++.

проектирования архитектуры софта

ага, увидимся через 100 лет

хочется всё сделать «по уму»
Си++
UML

Поделил так поделил.

Не слушайте ни кого!
Реализуйте задуманное.

Ну а мы, злоязычные в свое время будем посрамлены.

С Богом!

Используй Qt (с дизайнером, естественно) и Python, как напишешь и отладишь прототип, - начинай переписывать на С++ снизу-вверх, когда все перепишешь - будет тебе счастье, а если не перепишешь - будет просто рабочий софт.

Iron_Bug, как тебе планчик?

Проектирование для слабаков. Продумывая всё заранее, ты лишаешь себя удовольствия от переписывания кода.

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

ну и пистон ненужен. это, я думаю, уже не надо повторять.

редакторы UML

Dia вполне прикольная штука. К Си++ имеет весьма косвенное отношение, но понятие классов ей не чуждо. Но хотелось бы что-то более... узконаправленное.
Хотя местные вообще почему-то против UML как понятия.

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

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

Кстати, чтобы не тыкать мышкой есть plantuml, хоть я его и не пробовал. Но может оно не так задалбывает.

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

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

Кстати, чтобы не тыкать мышкой есть plantuml, хоть я его и не пробовал. Но может оно не так задалбывает.

так уж проще тогда сразу хэдеры писать. чтобы два раза работу не делать :)

Был такой редактор bouml. Потом автор его закрыл и стал стричь бабосы. Но может ещё где можно открытую версию достать. Так вот он «сам на себе» написан и свою структуру классов к качестве примера содержит. Посмотри хоть, что такое серьёзный проект в uml.

Опа! Полез сам поискать: а он оказывается опять открытый! Во дела. В общем рекомендую.

https://www.bouml.fr/download.html

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

Проектирование нужно начинать не с UML, а с потоков данных и разбивки на модули. Описываешь взаимодействие между модулями и зоны их ответственности, как черные ящики. После уже пишешь сами модули и отдельно их тестируешь. Хочешь UML юзать для проектирования модуля - пожалуйста. Модули можно сначала сделать заглушками, а потом реализовывать, рефакторить и переписывать с нуля если надо.

Данным способом можно управлять сложностью (после десятка другого классов никакая диаграмма не поможет уже - в голове перестанет умещаться). К каждому модулю прописывай функциональные требования которые можно проверить (а лучше сразу прописывай API). Это проектирование сверху вниз. Оно помогает избежать проблем переписывания всей системы при выявлении проблем в каком-либо модуле, тк проблемы только внутри модуля будут (если ты продумал взаимодействие модулей хорошо). А проектировать нужно в том виде в котором тебе будет удобно и быстро превращать свои мысли в документацию.

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

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

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

годы на проектировку и годы на реализацию

если ты «один-человек-проект» то г-но кодь на С++ своем лижбы работало, займет времени раз в 5 меньше чем с изначальной проектировкой

не возможно за человеческую жизнь сделать UML в крупному проекту и реализовать этот проект на С++, в одиночку все

это нереально

а потом реализовывать, рефакторить и переписывать с нуля если надо.

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

чем больше проект тем больше переписываний по мере реализации

но этоже С++ о да

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

На рефакторинг уходит слишком много времени, не представляю как писать продумать всё заранее на абстрактном уровне, гораздо проще решать задачи в терминах произвольного ЯП.

Давно «просто смотрел» MagicDraw и Borland Together (сейчас его перекупил ктото)
Просто посмотри на них и на dia ты более не взглянешь без слез )
Сам не использую UML, но надо бы еще раз попробовать.

Ты писал, что не знаешь Qt, а вот если бы знал, то мог бы использовать не голый c++, а готовые классы Qt не только для GUI, например сеть и/или сигналы слоты нужны ведь будут ?

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

UML - не средство проектирования, а просто нотация для записи результатов проектирования.

Просто в голос, один ублuд0к («директор» на шестью макаками) так не проектировал, дак я его долго в лесу обучал ночами, днём переписывая проект (тот самый, на 1кк+ строк) с уже другими людьми. Веселое было время, лол.

Не знаю где он устарел. Во все поля используется. Как ты ещё архитектуру опишешь?

Plantuml

Uml не только иерархию классов описывает. Сиквенс диаграммы где писать?:)

И потом plantuml хоть визуализируется.

сиквенс-диаграммы (как и всякие там меандры) отлично пишутся в тетрадке в клеточку. опыт хардварной разработки :)

И потом где эта тетрадка в клеточке хранится? В шкафу или как подставка для кофе? Как показать эти диаграммы коллегам из другой фирмы которая должна твое апи использовать? Тетрадки в клеточку копировать? И по почте в другую страну высылать? :)

Есть ли у кого какие советы? Может есть более подходящий вариант.

Отказаться от C++ и упрощать архитектуру, до тех пор, пока желание нарисовать этого монстра не пропадет вместе с самой монструозностью.

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

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

Plantuml успешно заменяет бумажку :)

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

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

Мы из uml интерфейсы генерим. Franca idl & yamaica (genivi). А из fidl бойлерплейт код.

ну, если вас устраивают его ограничения, то это ваше дело. но так для плюсов он слишком убог. ну просто неудобно. а для сишки он тащемта бесполезен.

Как практика показывает, что сведение кода и диаграммы - будет то ещё приключение.
Попробуй http://www.draw.io. Написанное на электроне, можно попробовать прямо на сайте.
Но обозреть сложный проект на мониторе будет проблемно. Охватить целиком картину будет сложно, если наизусть не выучил, а если выучил, то оно тебе не пригодится (чертоги разума удобнее пока).
По своему опыту скажу, что легче начинать, если формулировать задачи в математических терминах. Множества, подмножества, их логика и проч. ерунда, которая будет тянуть тебя в ад.
Когда общая схема утряслась, переходим к психиатрии.
Определяем профиль психопатов, их препочтения.(структуры данных, классов).
О чем это я? На самом деле сначала тебе надо абстрагироваться от ЯП и описать работу без учёта особенностей, а как будет выглядеть в результат этого UI ты потом поймешь.
Может придумаешь так, что будет одна кнопка «сделайте мне красиво» и сам восхитишься своей гениальностью.

сначала тебе надо абстрагироваться от ЯП и описать работу без учёта особенностей

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

Но всё же мне хотелось бы некоторые нюансы моего языка: вменяемая типизация например. Это самое важное. Код это мелочи. Самое хитрое всегда была аритектура. Взаимосвязь объектов. Код это просто.

UML
2018 год

Чувак, потыкай себя палочкой, ты походу мёртвый.

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

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

Мне на практике хватало двух вещей:

1. Майндмапы, чтобы мысли в порядок привести. Сейчас юзаю https://coggle.it
2. Диаграммы Data Flow, чтобы правильно на модули напилить. Остановился на https://www.draw.io

Дальше обычно уже понятно что и как кодить. Можно конечно и целиком прорисовывать, просто обычно смысла нет.

draw.io (есть десктоп версии) адекватных альтернаив нет, быстро, удобно, маштабируемо, невырвиглазно! Удобно делать визуализацию огроооомных проектов, на нём же можно прототипы интерфейсов делать и всё что угодно иное, рекомендую короче. Идея у тебя хорошая, качай запускай, врубай музыку и включай полёт фантазии.

Это визуализация идеи

ИМХНО нынешние языки, технологии разработки программ, ... /пра,
пра, пра, ... внуки их создателей/ остаются такими же.

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