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

Спасибо! Как раз то, о чем я спрашивал!


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

То есть Вы сами себе ответили?

По моему, тут другого ответа и нет. Если диаграммы нужны для обучения мастером ученика, то используются те техники, которыми в совершенстве владеет мастер. Если диаграммы для большой команды разработчиков, то наверное это выбор этой команды (чтобы по возможности всем было удобно).

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

Но если посмотреть ту же книгу "Practical UML Statecharts" можете ли вы там понять любую попавшуюся случайно UML диаграмму?
Гарантирую что нет. Все диаграммы там абсолютно зависят от контекста, как математические формулы.
Пока не прочитаете всю статью ниже с описаниями всех символьных переменных в диаграмме, что делает диаграмма вообще не поймете.
Чем это отличается от чтения чистых исходников?

Автор книги напирает как здорово все делать на базе автоматов состояний, которые он изображает диаграммами.

Проект FreeMODBUS как раз сделан на этой концепции.
Не далее как весной разбирался с портированием FreeMODBUS.
Надо было сделать мост между сетью MODBUS устройств на шине RS485 и сетью Ethernet.

Так вот, исходники автоматов состояний не имея перед глазами их диаграмму расшифровывать очень трудно.
FreeMODBUS достаточно простой проект. Там объем реальных исходников не больше 100 кБ. Но возиться с ним пришлось наверно около недели.
Ребята умудрялись передаваться события в пределах одного автомата используя внешние сервисы. Это, как понимаю, называют декомпозицией на слои.
Т.е. все равно как если бы в пределах одной процедуры чтобы передать данные дальше вы вызываете процедуру прерывания с аргументом, а та передает аргумент в вашу же функцию записью в статическую переменную.
Да, красиво, эффектно, масштабируемо Но по сути дурь.

Автоматы состояний - зло.
Применение RTOS позволяет отказаться от автоматов состояний.
В результате я написал полностью свой MODBUS мост немного основываясь на исходниках от Micrium без всяких диаграмм в линейном стиле только на вложенных if else.
Такой стиль абсолютно прозрачен, понимается в лёт, не нужно никаких дополнительных диаграмм. Через сто лет понадобится минимум времени чтобы понять что там написано.

Советую перепрыгнуть этап рисования диаграмм, а сразу начинать изучать исходники авторитетных проектов.
Например uC/OS от Micrium и весь их промежуточный софт или MQX от Freescale.

Я спрашивал, как применяют UML в embeded.



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

Сообщение отредактировал yanvasiij - Nov 15 2013, 07:55

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

Книжка хорошая, фреймворк хороший. Сам фреймворк QP не использую, т.к. работодатель его не купил. Использую самописные автоматы по аналогии - без иерархических автоматов и без активных объектов. Сначала рисую UML state charts (на сайте есть stencils для Visio), потом кодирую. В шаблонах нет графического представления для if внутри else - посмотрите как это сделано у них в QM.


И, да - графическое представление помогает.


Да наоборот, с опытом быстрее их рисовать будет.

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

А может есть смысл подумать о MATLAB/Simulink - и особенно о StateFlow? Там как раз концепцию очень легко можно проработать и отладить. Даже если потом из этого не будет генериться код - все-равно будет полезно поизучать, как оно будет работать.

бред эти все диаграммы и UML.
гораздо проще записать просто списком по пунктам.

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

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

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

"Как планировать, как разбивать? Как прорабатывать концепцию?" - главное чтобы было написано ТЗ, не для кого то а для себя. Каждый пункт в ТЗ это и есть твоя разбивка. А концепция построения программы такая, что если начальник скажит все вывернуть наизнанку - то ты бы смог это выполнить. Т.е универсальность и гибкость. А по поводу "Как планировать" так c утра и до вечера, а читать нужно не книжки, а форум с какими проблемами сталкивались люди при реализации подобного набора ваших датчиков и оконечных устройств (MODBUS, GSM, спутниковый канал, и ethernet)

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

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

Спасибо, за советы и высказанные мнения!

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

И как мы раньше обходились без UML:)

Обратите внимание на методологию SADT (IDEF0), которая как раз для этого и придумана. Хотя мне для программ порядка 10000 строк кода хватает 30-40 тетрадных листов и обычных блок-схем.
А методологий и языков помимо UML куча...


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