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

[yanvasiij]

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

[yanvasiij]

Ну положим с неделькой то я действительно загнул, но дело не в сроках. Вот представте: один из вас куратор моего проекта. Времени смотреть мой код у вас нет, разбираться в алгоритмах тоже нет. Но контролировать надо, надо обсуждать, надо мониторить мой прогресс, ориентироваться в какой стадии я сейчас нахожусь. И вот в самом начале Вы спрашиваете: "Вася, ну-как расскажи как ты будешь делать?" Я такой достаю диаграммки и наглядно показываю, что где и для чего, с чем связано и какие атрибуты и методы я намерен использовать. Вы, как более опытный куратор, видите уязвимости, излишества и прочие недостатки и говорите: "Нет, гораздо лучше будет, если ты сделаешь вот так..." Мы дискутируем, я учитываю ваши пожелания, и, чтобы продемонстрировать серьезность моих намерений вношу все это в диаграммы. Далее вы просматриваете их еще раз, возможно, что то снова вызывает сомнения, но так или иначе в конце концов одобряете. После этого вы в любой момент можете узнать, что я делаю и в какой стадии проект. Более того, вы примерно знаете структуру моей программы, можете при наличии свободного времени поучавствовать. А я же в свою очередь проработав концепцию не занимаюсь изобритательством на ходу, а действую планомерно и расчетливо.

Посмотрел город. Около-"мега" строение? Но неважно.

На задачи то красиво бьется. Мастер опроса датчиков, монитор питания и заряда, конфигуратор, связь и проч.
Делаете простыми и лаконичными задачи, складывающие/берущие/конвертирующие данные из памяти, тогда будут понятны и связи между ними.

Мой личный подход - имеется структура данных, управляющая разными процессами, с консольки имеется постоянный доступ для управления и просмотра результатов (для облегчения жизни своей и другого человека). Тогда устройство сразу становится не черным ящиком, а несколькими "белыми ящиками", которые всего-то нужно как-то связать между собой.

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

[AlexandrY]

Я такой достаю диаграммки и наглядно показываю, что где и для чего...

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

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