Как проектируют программы: от UML до автоматного подхода

[mayorovp]

Почему автоматное описание противопоставляется UML? Есть же UML state machine / UML statechart...

[greendimka]

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

Не верите? Проверьте по гуглу: aggregation vs composition — десятки, сотни разных трактовок.

Лично моё отношение к UML: отличная идея с ужаснейшей реализацией.

[lash05]

«Документация на программу» — это понятие надо уточнить. Ведь если программа — это уже описание некоторых действий на некотором языке программирования, то нужно ли делать описание описания? (на языке УМЛ или тп).
Может, тогда есть смысл в сами языки программирования добавлять обязательные требования «прозрачности» кода? Да, это увеличит трудоемкость собственно разработки, но решит массу проблем.

[rumkin]

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

[lash05]

Вопрос в том, стоит ли два раза писать одну программу? Причем независимо — то есть нет гарантии, что описания совпадут.
Может быть, лучше поставить требования прозрачности (или инструменты визуализации) к первому языку?

[BalinTomsk]

Кто-нибудь имеет представление как в Амазоне/Фейсбуке/etc осуществляется Business Process Management (BPM)?

A то сейчас приходится знакомиться с JBoss BPM Suite (жаба монстр от редхата) — я эти песни про автоматическое транслирование диаграмм бизнес-процессов в работающие бизнес-процессы уже лет 20 слышу.

Tакая шняга вообще взлетает? — программирование на уровне UML диаграм нифига не взлетело.

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

Mоя команда — в 1997 году пытались построить весь девелопмент начиная с рисования uml диаграмм и затем
генерации джава кода из них. Но Rational Rose еще не был ИБМ-овским.

Не-взле-те-ло!

Настолько геморройное оказалось занятие, с таким ОГРОМНЫМ количеством ручного «допиливания» кода, что мы выдержали примерно год, и забили на это дело.

[mayorovp]

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

"Программирование на диаграммах UML" в этом плане является просто разновидностью визуального программирования и может использоваться как точка композиции для написанного кода.

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

[samizdam]

>>текстовая версия технического задания, в котором заказчик прописывает подробную работу желаемого решения

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

[heleo]

Сам сталкиваюсь с тем, что UML очень мощный инструмент проектирования, но при этом он не «стого формализован», как уже писали выше

aggregation vs composition — десятки, сотни разных трактовок

И порой приходится вводить свои правила, чтобы понимать как-то или иное решение в диаграмме будет отражено в реальном коде, на конкретном языке. Судя по всему это всё следствие буквы «U» из названия и широких возможностей языка.
Бесспорно, UML идеально подходит для общения, хотя надо признать, что при этом в ход идут и многие другие диаграммы: DFD, ER, и т.д.