UML, чертежи, принципиальные схемы — ненужны?

Нет, разным.

>принято говорить, что UML — это маркетинговый баззворд и ненужен

в мире принято говорить и не такую чушь, а UML - полезная штука, если не пихать его туда, где ему не место

> а про чертежи, принципиальные схемы, осциллограммы и схемы коммуникаций никто так не говорит?

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

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

Кстати слабенько троллите товарищ, тренируйтесь на кошках.

> есть чертежи по которым собирают машину.

У программы есть исходный код по которым собирают собственно программу

Доказательства по аналогии такие убедительные.

> Нет, разным.

Это почему же? И то, и другое, и третье — стандартизованная графическая нотация, которая:

а) показывает декомпозицию Системы на компоненты;
б) показывает взаимодействие и отношения между компонентами;
в) не затрагивает внутреннего устройства компонентов;
г) используется на стадии проектирования Системы;
д) используется для объяснения устройства Системы конструкторам;
е) используется в качестве документации.

Что тут не так?

> У нее есть чертежи

У программы есть исходный код

Программный код является конечным продуктом для software-систем (так как компиляция в бинарный код тривиальна). Чертёж не является конечным продуктом: конечный продукт получается в результате конструирования по чертежам. Точно так же, как программный код конструируется по UML-диаграммам.

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

а обратный процесс — генерация UML по программе, нереален — вот как ты проверишь, что объекты 2 классов действительно поддерживают отношение «1 ко многим» ?

UML — это смущение умов, иными словами, наебка. Он не проясняет и не помогает. Ему есть альтернативы, и они очень простые.

Первое. Надо разговаривать. Разговаривать, блять! Совещаться. Кто не понимает — тот молчит или выходит, а не пялится в диаграммы и дает комментарии. UML-формализация отнимает время. Диаграммы дают иллюзию понимания, и только созадется иллюзия общей точки, общего предмета обсуждения, особенно когда манагеры начинают вклиниваться в технический разговор. То есть понимания нет, но есть картинка, и поэтому появляется что обсуждать и что делать. Потому что есть картинка, образ, за который цепляются мысли, а нужно полное детальное поинмание. И его должны создавать люди, способные вникнуть в тему и создать систему. А UML этому не помогает.

Вы можете спросить: а как тогда доносить детали архитектуры до разработчиков? Неужели словесно? Да, блин, словесно! Люди должны разговаривать! Это такое откровение, правда? А тот, кто не может говорить на темы проектируемой системы — должен молчать. Или даже не слушать. Любую диаграмму, будь то диаграмма классов, последовательностей или состояний, я смогу описать словами для заинтересованных лиц. И каждый нарисует себе картинку, если он не может ее в голове удержать. Свою, блять, картинку. Но предметом обсуждения будет не картинка, а последовательность действий. И это очень принципиально. А UML подменяет предмет обсуждения.

И это только первая часть. Так вот, а вторая часть — это код. Да-да, код. Вторая часть очень хорошо описана в статье «Пиши код, блять!», поэтому не буду особо распространяться. Просто сходите по ссылке и почитайте.

Итак:
1. Разговаривать;
2. Писать код.

А UML в газенваген. Это — лже-технология.

> а обратный процесс — генерация UML по программе, нереален

Очень даже реален. Откройте для себя ИДЕ Эклипс и >9000 плагинов на эту тему (по крайней мере для явы).

Очень даже реален. Откройте для себя ИДЕ Эклипс и >9000 плагинов

реален >9000 кривыми способами

FIXED

> Скажите, почему принято говорить, что UML — это маркетинговый баззворд и ненужен

Потому что 95% разработчиков - это низовой уровень. А UML - инструмент архитекторов (т.е. уровнем выше) и нужен для координации действий большого числа программистов.

> Потому что 95% разработчиков - это низовой уровень

И из этого следует, что UML ненужен?

> FIXED

Да, глючит, но с одним из плагинов у меня удалось таки получить вменяемую картинку (не помню что за плагин).

> с одним из плагинов

у меня

удалось таки

не помню что за плагин

Факт реальности сего у меня зафиксирован в памяти, так что мимо. Если у вас не получается, значит не очень-то и хотелось...

Кажись (99%) вот с этим у меня получилось:

http://green.sourceforge.net/help3.0.0/green_index_frameset.html

> Факт реальности сего неподтверждаем в принципе

FIXED

>> Факт реальности сего неподтверждаем в принципе

FIXED

Руки из жопы вынь.

> Кажись (99%) вот с этим у меня получилось

У тебя получилось поделие, едва дотягиваяющее до 1% Rational Rose.

> У тебя получилось поделие, едва дотягиваяющее до 1% Rational Rose.

Пф, я с этим и не спорил. Но зато бесплатно.

Ну, а смысл? Забесплатно получить 1% совершенного, оттестированного, зрелого корпоративного продукта?

Ты идиот, причём клинический

По существу есть что ответить?

По видимому, грамотно спаянная плата это плата 200х200 на 20 элементов, с 20мм разносом элементов, чтобы визуально можно было понять её работу, да?

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

> По видимому, грамотно спаянная плата это плата 200х200 на 20 элементов, с 20мм разносом элементов, чтобы визуально можно было понять её работу, да?

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

Нет.

Неправильные аналогии. Разница с инженерией гигантская. Здания и мосты должны всего лишь не развалиться при допустимых нагрузках, и прослужить сколько-то лет (хотя в начале каждой из технологий был сплошное хакерство: вспомним с каким запасом толщин стен строились первые большие здания - тогда когда не могли рассчитывать прочность стен). И главное - там стандартный набор материалов, т.е. всё устаканено давным давно. А других материалов пока нет, и новые приходят раз в десятилетие, т.е. редко. А радио-схемы сначала рассчитываются, потом тестируются на макетах и уже работающую прог^Wсхему печатают. Для последнего аналог в программировании - код (т.е. точное описание - как повторить уже работающее и собранное - во втором экземпляре, один в один).

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

Для написания хорошей программы (предвидеть будущие изменения бизнес-логики, будущую нагрузку, возможные изменения в данных, возможные ошибки итд) - это уже искусство, а не инженерия. А в _искусстве_ - не любят схем от менагеров. Пример искусства - книга или картина. Попробуйте написать план хорошему художнику в ваших терминах, стрелках, диаграммах! Настоящий художник этого неприемлет. Он отвечает за результат, а деление на функции, классы, какие буфера использовать - это разбиение зависит слишком от многих переменных - чтобы это мог диктовать какой-то менагер. Либо это будет послушный быдлокодер, работающий за еду, «произведение» которого (не его, а всего коллектива) - выкинут через несколько лет в лучшем случае, если оно вообще будет работающим. Или попробуйте спланировать будущие открытия и дайте план по будущим статьям в Академии. А программирование на высоком уровне - это почти Академия. Мало что известно наперёд, технологии - bleeding edge, т.е. мало кто это делал, и тем более нет под руками пилотов, и рассчётов нагрузок. Итд.

(Сейчас набегут бездель^Wархитекторы и начнут оправдывать свою полезность. Знаем, плавали. И где те аркитекты после многих лет? Уже в других конторах. А программеры которые могут делать ручками, всё от начала до конца - работают всё в тех же конторах, без них - никуда)

> Сейчас набегут бездель^Wархитекторы и начнут оправдывать свою полезность. Знаем, плавали.

Попробуй построй многоэтажное здание без чертежа, ага.

Тред объявляется ГСМ-ным и подлежит сносу

Один фиг использование UML статистику успешных проектов не улучшает.

> Один фиг использование UML статистику успешных проектов не улучшает.

Использование кульмана тоже не улучшает статистику успешных запусков орбитальных ракет. И что?

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

> Принципиальные схемы, осциллограммы и схемы коммуникаций относятся уже к внутреннему устройству компонентов.

Нет, это ошибка.

А доказать сможешь?

Я не обязан ничего доказывать быдлу.

Ты слишком толст и не вызываешь бугурта, тренеруйся дальше ТС

> Попробуй построй многоэтажное здание без чертежа, ага.

Выше многократно сказано, что аналог чертежа - это программа, код.

До написания программы, её верификации, тестирования - нельзя сказать о её ценности. Но после этого всего - можно сгенерить UML для документации, для объяснения другим - если есть время. Но не наоборот. Я пользовался UML с 98 года, и в основном после проектов, когда совсем доставали менагеры. Ползы - ноль. Исключение юз-кейсы, как минимальная строгая нотация, чтобы хоть как-то заставить мыслить упорядоченно бизнес-аналитиков. Остальные диаграммы - очень надуманны и высосаны из пальца (состояний - притащена из автоматов, клиент-сервер - и так использовалась и до UMLей, так что Бучам не надо бы просваивать интуитивные нотации с осью по времени себе, классовая - просто вредна, а модули - это просто модули из курса по Аде, который у меня был в 95м, за долго до UMLей, не понимаю зачем это сюда притянули). Короче, всё притянули, чтобы оправдывать просиживание штанов за казённые средства. Но UML ещё какая-то упорядоченность. Вот был я на менагерских курсах, вот там гуманитарщина разит из всех дыр заполнением времени бессмыслицей и банальными истинами. Так что да, UML не самая большая глупость, изобретённая бездельниками. (ах да, есть ещё комитеты по стандартизациям мёртвых стандартов!)

> Выше многократно сказано, что аналог чертежа - это программа, код.

(бред поскипан)

Выше многократно доказано, что вы просто не осилили UML.

> Выше многократно доказано, что вы просто не осилили UML

Гы, я его осилил в 98м, делая диаграммы, когда их ещё мало кто делал, на первой бетовой розочке. Хотя нет, раньше, когда сдавал Аду, в 95м. Знаю все основные типы диаграмм очень хорошо, по софтваре инджинирингу и теории автоматов у меня пятёрки. А в 2000м я последний раз его (UML) воспринимал серьёзно. Когда понял его бесполезность, и когда им занялись исключительно архитекты-менагеры, кто не хотел кодить.

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

Сколько пафоса. Пррограммирование точно такой же инженеринг. Искусство оно минимум для архитекторов всех мастей, хотя и здесь не всегда.

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

В прочей инженерии невозможно исправить ошибку после реализации, любой отход от изначального плана приводит к непрогнозируемым результатам и ставит крест на затраченном времени (т.е. ~ просрал бабки). И часто всё это имеет свои статьи в УК.

Грамотно спаянная плата на лиспе документирует себя лучше всяких схем.

//fixed

А UML подменяет предмет обсуждения.

UML - хорошее средство документирования, а тот кто им подменяет обсуждение - просто «буратина», но ещё больший «буратина» - это тот, кто обсуждением подменяет документирование

> Гы...

И что из вышесказанного доказывает, что ты действительно осилил UML?

> А разница между обычной инженерией и разработкой другая: программирование оно резиновое, можно сколько угодно отходить от плана реализации, ошибаться и потом легко исправлять ошибки. Это всё относительно дёшево.

Интересно, назвал бы тебя tailgunner кодером локалхоста или нет? Наверное все-таки да, и был бы прав.

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

В прочей инженерии невозможно исправить ошибку после реализации, (2) любой отход от изначального плана приводит к непрогнозируемым результатам и ставит крест на затраченном времени (т.е. ~ просрал бабки).

пг'остите что вмешиваюсь, но (1) с большой вероятностью приводит к (2), проверено электрониками (с)

Градация буратин на ЛОРе? Давно пора карму ввести.

Интересно, назвал бы тебя tailgunner кодером локалхоста или нет? Наверное все-таки да, и был бы прав.

тебе интересно, а мне нет. Опять, чувствую, у вас задёргало ЧСВ профессии, такое бывает когда больше дёргаться нечему.

деградация буратин на ЛОРе

//починил