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

[yanvasiij]

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

[yanvasiij]

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

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

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

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

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

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