Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.97.9.168] |
|
Страницы: (4) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Буэнос диас, амигос!
Хочется похоливарить на тему сабжа А, если честно, очень хочется услышать true history как жысть резко наладилась, когда началось скучное и повседневное использование UML при проектировании и документировании, |
Сообщ.
#2
,
|
|
|
Ответил "не пользуюсь", хотя до ссылки на вики даже не знал, что это такое. Теперь хоть почитаю... Почитал. Очередное "программирование мышкой"? Не, нафиг.
|
Сообщ.
#3
,
|
|
|
Цитата Dushevny @ Почитал. Очередное "программирование мышкой"? Не, нафиг. Это просто ты с большими проектами, видимо, еще не сталкивался. Очень незаменимая вещь, для понимания как что взаимосвязано и как работает. Эта штука нужна в основном архитекторам, для написания блок схем программы, чтобы наглядно показать как и что взаимосвязано в системе. Программисту эта штука так же может понадобиться для того, чтоб посмотреть как взаимосвязаны сущности между собой. Уверен практически любой программист рисовал UML диаграммы в тетрадке, ну если сталкивался хотя б с 10+ взаимосвязанных классов. Так что это не очередное "программирование мышкой", а очень востребованный продукт. Добавлено Его даже в универе преподают. Я не знаю как сейчас. Когда я учился в универе, у меня был курс работа с UML диаграммами, там объясняли где че означает, какими стрелками соединяются разные сущности. В общем довольно странная тема и ответы в ней. Для написания пятка классов или тулзы аля хеловорлд - этот UML нафиг не упал. А как только ты начинаешь теряться в количестве классов, связей между ними, в количестве модулей и связей между ними - эта штука становится незаменимым инструментом. Ну это как знаешь когда соцопросы делают или там озвучивают данные по короновирусу - вообще нихрена не понятно, ну цифры и цифры, много это или мало хз. А как только график тебе покажут - так сразу понятно что все эти числа означают. Вот так и тут. Цифры - программный код, а UML - своего рода график, по которому можно понять как и что с чем взаимосвязано, и куда можно всандалить еще один какой нибудь прокси-адаптер, или еще что то чтоб было норм. Добавлено У нас на работе UML диаграммы активно используются, в разработке в документах всегда они присутствуют, чтоб понимать что куда добавили/планируется добавить, как что было спроектировано. Когда тебе рисуют блок, за которым скрывается тысяча классов, и показывают от какой тысячи классов этот блок имеет зависимость - это воспринимать проще, чем просто на словах и тем более это не очевидно в коде. Добавлено Ну и к слову еще: Для объяснения тех же патернов проектирования активно используются UML-диаграммы. https://ru.wikipedia.org/wiki/%D0%9F%D1%80%...BD%D0%B8%D1%8F) https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%...BD%D0%B8%D1%8F) Глядя на UML-диаграмму сразу становится понятен принцип работы патерна. Попробуй сразу же так понять принцип работы глядя на код. А если он еще и не просто голвый, а со всякими наворотами и неявными связями? |
Сообщ.
#4
,
|
|
|
Wound, я почему поднял эту нему - тупо начал "плавать" в сигналах-слотах своей проги (Qt5/C++). Ладно было бы связать стопицот созданных объектов, и существующих до конца выполнения проги ... Так около 20% объектов получились динамическими (создание-выполнение-разрушение). Началось разрушение моего мозга. И вот вспомнил то, что когда-то надежно забыл.
|
Сообщ.
#5
,
|
|
|
Да особо нечего расписывать. Взаимодействие между частями крупной системы так или иначе нужно описывать, т.к. у тебя в коде нет одного места, где бы ты мог крупномасштабно увидеть, что у тебя происходит. UML это будет или просто текстовый документ - не сильно, в общем-то важно. Лично мне uml как-то не зашёл, но это субъективщина. |
Сообщ.
#6
,
|
|
|
Цитата OpenGL @ UML это будет или просто текстовый документ Не не не !!! В спецификации - куча видов диаграмм, отвечающих за разные аспекты проектирования. Там может быть много чего - и взаимодействие, и иерархия, и таймлайн ... много чего. Каждый вид диаграммы описывает свое свойство (а если вернее - "предназначение"). Как бы я не сопротивлялся "дополнительному" - сска, чувствую учить и использовать надо. Особенно когда проектируемая система выходит за "10 классов" © Киля. А может и раньше надо. |
Сообщ.
#7
,
|
|
|
Цитата JoeUser @ Как бы я не сопротивлялся "дополнительному" - сска, чувствую учить и использовать надо. Ну а почему нет? Это просто инструмент, а уж как ты его будешь использовать - дело твоё |
Сообщ.
#8
,
|
|
|
Цитата OpenGL @ UML это будет или просто текстовый документ - не сильно, в общем-то важно. Лично мне uml как-то не зашёл, но это субъективщина. Ну UML это просто как бы стандрат. Для себя можно рисовать хоть в блокноте, хоть в паинте. А если показывать кому то - то нужно юзать UML, чтоб тот, другой понял. Иначе тебе придется отдельно расписывать где какой блок что означает, где какая стрелка что означает. Как наследование отличить от агрегирования, где нарисован класс, а где компонент и т.д. В студии есть встроенные средства для генерирования связей, что то типа UML диаграммы, но не по стандарту UML. Но там в динамике все. Можно мышкой навести и глянуть где что обозначает. |
Сообщ.
#9
,
|
|
|
Цитата OpenGL @ Ну а почему нет? Ну я на бессознательном - всегда пользую Бритву Оккамы. Поэтому каждые "дополнительные новшества" у меня проходят строгую проверку на предмет измены родине |
Сообщ.
#10
,
|
|
|
Использую иногда диаграммы классов, реже диаграммы последовательности. Остальное почти не использую.
На правах вброса: чем хуже система спроектирована, тем больше необходимы диаграммы |
Сообщ.
#11
,
|
|
|
Цитата D_KEY @ На правах вброса: чем хуже система спроектирована, тем больше необходимы диаграммы Ну да. Это как с постройкой дома. Если есть полный план строительства - значит плохо спроектировали(иначе нахрена нам план?). Если нет, значит хорошо спроектирован Я бы наверное даже твою фразу перефразировал. Если сначало написали систему, а UML диаграм еще нет - значит никто ничего не проектировал, просто написали по велению левой пятки, и скорее всего оно плохо спроектировано(вернее оно даже не спроектировано, а просто тупо написано абы как). А если UML диаграмма появилась до написания системы. Значит систему сидели и проектировали, а уж потом начали писать по предварительно разработанному плану/архитектуре. Вообще где не работал(ну достаточно большие конторы), везде использовались UML диаграммы. Есть спецификации, UML диаграммы классов, компонентов, все это как правило входит в техническую литературу системы. Если этих диаграм нет, значит систему проектировали на коленке, и как правило в ней куча косяков, подводных камней и неучтенных концептуальных ошибок. Добавлено Да и вообще - как понять что и как делает система хотя бы приблизительно, как бы круто она ни была спроектированна без UML диаграмм ? Вот устроился я на новую работу, они там разрабатывают программу, в которую входит целая куча компонентов, 100500 файлов, кода, библиотек, включая сторонних. Мне говорят, вот у нас есть вся эта лабуда, надо короче в внести изменения в систему, чтоб она умела работать в режиме NLB кластера. Иииии? Что ты будешь делать без диаграмм с офигенно спроектированной системой? Вангую что ты будешь сидеть неделю, и рисовать эти UML диаграммы анализируя код, чтоб понять как оно вообще работает, какие модули будут затронуты, и т.д. |
Сообщ.
#12
,
|
|
|
Цитата Wound @ Ну UML это просто как бы стандрат. Да неважно. Я именно о предпочитаемом представлении данных говорю. Показать иерархию классов ещё куда ни шло, но, например, показывать, как у меня идут данные между сервисами - ну нахрен, я лучше ту же информацию прочитаю текстом, и текстом же опишу это в ТЗ. |
Сообщ.
#13
,
|
|
|
Цитата Wound @ Ну да. Это как с постройкой дома. Во-первых, аналогия - не аргумент. Во-вторых, постройка дома имеет крайне мало общего с созданием софта, это очень плохая аналогия и очень жаль, что она так прижилась. Добавлено Вот когда железо проектируешь, то да, аналогия со строительством подходит. Для софта - нет. Добавлено Если попытаться улучшить аналогию, то создание софта является скорее созданием проекта дома, а не самого дома. Сам дом ты получаешь, когда build делаешь |
Сообщ.
#14
,
|
|
|
Цитата OpenGL @ Да неважно. Я именно о предпочитаемом представлении данных говорю. Показать иерархию классов ещё куда ни шло, но, например, показывать, как у меня идут данные между сервисами - ну нахрен, я лучше ту же информацию прочитаю текстом, и текстом же опишу это в ТЗ. Нет, ну упарываться конечно не стоит. Есть же всякие стандарты/сервисы/протоколы(XML/json/SOAP/REST) это все можно просто абстрактно записывать. Типа есть компонент А, есть компонент B, B зависит от A, на стрелке пишешь REST/json, или там SOAP/xml, сразу становится понятно что данные передаются посредством такого то протокола в таком то формате. Да и плюс есть же разные схемы приближения. Допустим одна диаграмма может описывать как взаимодействуют между сосбой компоненты, вторая как классы, третья, еще там что то. Но просто ты когда себе что пишешь - ты то понимаешь, а допустим если тебе это нужно отдать следующим разрабам, то как им понять где что? Проще нафигачить UML диаграмму. Но опять же - в основном этим занимаются архитекторы, ибо это им приходится выдавать документацию по системе, и показывать как что там спроектировано или как нужно делать. Просто когда ты пишешь для себя - можно конечно как тебе нравится писать схемы, а если для кого то, то твои схемы могут просто не понять, придется лишний раз объяснять. А UML диаграмму поймут, ну либо будет куда отправить почитать. Добавлено Цитата D_KEY @ Во-первых, аналогия - не аргумент. Во-вторых, постройка дома имеет крайне мало общего с созданием софта, это очень плохая аналогия и очень жаль, что она так прижилась. На абстрактном уровне как раз у них много общего. Цитата D_KEY @ Вот когда железо проектируешь, то да, аналогия со строительством подходит. Для софта - нет. Интересно в каком месте когда железо проектируешь, подходит аналогия со строительством? Как раз для софта и подходит. Цитата D_KEY @ Если попытаться улучшить аналогию, то создание софта является скорее созданием проекта дома, а не самого дома. Сам дом ты получаешь, когда build делаешь Ты спустился на какой то ассемблерный уровень и от туда рассуждаешь об абстрактных UML диаграммах. Добавлено D_KEY, Расскажи как без UML Диаграмм понять что делает система и ее компоненты? Как они взаимосвязаны и как общаются между собой? Может я чего не знаю? Я просто не представляю как по коду все это анализировать? Расскажи. Добавлено Даже примитивным паттернам проектирования рисуют диаграммы, чтоб быстрее пришло понимание основного принципа работы. Потому что на диаграмму посмотрел - и сразу все стало понятно. А по коду надо сидеть неделю разбираться и рисовать все те же диаграммы, пусть и не в UML стандарте. |
Сообщ.
#15
,
|
|
|
Цитата Wound @ Я бы наверное даже твою фразу перефразировал. Если сначало написали систему, а UML диаграм еще нет - значит никто ничего не проектировал, просто написали по велению левой пятки, и скорее всего оно плохо спроектировано(вернее оно даже не спроектировано, а просто тупо написано абы как). Я тоже когда-то так думал, но это ошибочная точка зрения. Ты можешь проектировать сразу в код. Прототипируя, командно обсуждая интерфейсы(прямо через PR в коде, а не в схемах), используя такие практики, как "стрельба трассирующими" и т.д. и т.п. А есть еще XP. А есть еще TDD, BDD. И даже design by coding. Эти вещи нацелены на постепенное создание продукта с короткими цепями обратной связи, что позволяет и продукт делать нужный и архитектуру иметь заточенную под реальность, а не под фантазии архитектора. |