Используете ли вы UML в своих проектах?, IBM Telelogic Rhapsody / Atollic / Иное. Опции

[Basilij]

Здравствуйте господа.

Озадачился вопросом ведения сложных проектов после прочтения ряда статей.
1) Верно ли я понял то что методики и технологии предоставляемые програмным продуктом IBM Telelogic Rhapsody являются идеалом в данном вопросе?
2) Есть ли аналоги (не просто UML редакторы), а аналоги в широком смысле этого слова?
3) Используете ли вы данное ПО или аналогичное или весь алгоритм по старинке в головах программистов и на "солфетках", а абстрактное обобщение всего проекта в текстовом виде?

Окончательным гвоздём к переосмыслению ведения проектов стала статья Татарчевского Владимира "Некоторые мысли по поводу программирования встроенных систем" в журнале "Компоненты и технологии №8'2006" где все реалии с которыми сталкивается разработчик описаны в простой доступной форме.

[Basilij]

На чем основаны такие утверждения? Есть опыт?

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

Посмотрите все таки Simulink. Там есть реально работающие модели с полной детализацией готовые к переносу на железо.
Диаграммы состояний там либо вообще не применяются либо применяются фрагментарно.

Посмотрю обязательно, спасибо.

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

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

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


В первом вашем комментарии вы писали:

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

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

[AlexandrY]

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

Там речь идет о реверсе. Он копировал немецкий дивайс. Инструкция к дивайсу не помогла.
Тогда он сделал дамп прошивки дивайса в IDA и распечатал автоматически сгенерированные в ней диаграммы.
Да, в ассемблере разобраться без диаграмм сложно. Но к UML это не имеет никакого отношения.

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

Были еще заказчики которые знали графическую нотацию определенного класса логических контроллеров. Например Logo от Simensa или Alpha от Mitsubishi. Они представляли такие графические диаграммы и утверждали что это и есть программа. Тож не UML, как понимаете.

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