Разработка концепции программы для микроконтроллера Опции

[yanvasiij]

Дошёл до такого уровня, когда программа пишется не за день-два и все необходимое держишь в голове, а когда проект большой и сложный на несколько месяцев. Мне нужно средство, которое позволило бы грамотно проработать концепцию программы, спланировать работу, разбить ее на куски и т.д. То есть здесь не обойтись просто алгоритмами, нужно нечто более глобальное такое как UML. Но как применить UML к embedded на простом Си. Как составлять диаграммы классов, если у тебя их в явном виде нет как таковых, какие диаграммы из стандарта мне вообще нужны и в каком порядке мне их применять? Посоветуйте, что знаете и что сами применяете. Вообщем поделитесь опытом, буду признателен.

[yanvasiij]

как то всё в кучу. у Вас.
постараюсь выдать свой "поток разума" или по другому: сначала термины и песочница, потом как это применяю...

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

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

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

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

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

[AlexandrY]

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

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

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

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

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

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

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

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