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

Для диаграмм состояний нашел вот такую книжку.

Уважаемые модераторы, администраторы, возможно я поспешно разместил тему в разделе Управление проектами. Может имеет смысл перенести тему в раздел Вопросы системного уровня проектирования ?

Так книжку нашли или ее рекламу?
Все никак не могу ее где нибудь скачать.

Я бы перенес тему, но раздел не мой.

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

Еще один интересный подход на мой взгляд изложен в этой книге. Это совсем не UML, но по мне тоже весьма оригинально и имеет право на жизнь.

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

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

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

Это 2-я глава, что ли? Где про блочные диаграммы, иерархию управления, интерфейс драйверов и схему модель-представление-контроллер (Model-View-Controller)?

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

Интерфейсы драйверов в стиле open-close-read-write_IOcontrol на дух не переношу. Они маскируют физику. А физику в real-time системах не замаскируешь.
Она даст о себе знать, а унифицированный интерфейс только увеличит вероятность ошибок.

Вещь под название Model-View-Controller представляет собой какой-то чистый поток разума, высшую абстракцию. Никакой практической нагрузки. Просто чтобы занять объем книги.

Ну вот, например, сейчас нужно реализовать телеметрию: передавать данные с датчиков по GSM либо по спутниковому каналу (должен уметь работать и так и так) по протоколу МЭК-104 на скаду. Датчики выполнены в виде отдельных модулей с протоколом MODBUS. Устройство автономное, на аккумуляторе, поэтому алгоритм должен быть энергоэффективным (измерил, заснул и много не кушаешь). В добавок в перспективе должны быть подключено дополнительные модули через ethernet по UDP, данные тоже должны отправляться по запросу. Конфигурирование устройства должно осуществляться по telnetу. Ну вот для начала. По отдельности пустяк, а в комплексе можно набыдлокодить за недельку, а потом никто кроме тебя поддержать это не сможет. Вот и хочется, что все было продуманно, лаконично. А как это сделать? Как планировать, как разбивать? Как прорабатывать концепцию?



Ну, что же. Положим Вы меня убедили в неэффективности всего этого творчества. Тогда, что же Вы используете?

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

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

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

За недельку...? Эт вам нужны тогда нейростимуляторы, а не диаграммы

Мне недели хватает чтобы написать килобайт 50 исходников не больше.
Так это капля в море для приложения такого рода.

Лучше перестать волноваться и начать жить. Диаграммы можно представлять и не рисовать. Все само собой уложится.
Только вот не надо рассчитывать на недельку и даже на месяц.

А по-моему, надо не в диаграммы упираться а в средства, ограничивающие свободу выбора. Т.е. взяли постановку задачи в такой форме как сказали - и вперед. Есть "давление обстоятельств" . IEC-104? кескесе какгриццо - отдельным модулем. Модбас - точно так же.
ЖСМ - прекрасно, но зависит от AT-command set.
AT-command set - замечательно, но если в системе жсм-модемы разные - надо предусмотреть каким образом подмножество нужных Вам действий отображается на множетвах AT-команд.
Собрали до кучи всё? Нифига! нужно спроектировать взаимодействие между модулями.

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



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

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

UML - это язык записи. и ничего больше. Он помогает людям записывать-читать-делится полётом мысли.
как составлять диаграммы... кхм. вот этот вопрос самый интересный. потому, как чертит жирный крест на понимание чего же это за зверь. для начала надо понимать, что первично? (Тут и далее пойдёт всё старое от старика Буча. Лучше почитать его на этот предмет. я может буду обращать внимание на сильные стороны всей этой кухни или выражаться применимо "к земле". Итак...)Первично ООА (Объектно-Ориентированный Анализ) - это такая вещь, которую надо думать и в результате мы должны загрузится бизнес областью, терминами, собрать как можно больше кучи инфы. Потом идёт ООП (Объектно-Ориентированное Проектирование! ВНИМАНИЕ! Многие, проспали теорию на парах или поленились вникнуть в суть читая популярную литературу, посему часто перефразируют в программирование. Так вот ООП это ещё не код!!! и отношение к программирование вообще имеет слабое!!!) на этой фазе Вы выделяете сущности из собранной инфы и взаимодействие их между собой. Это приводит к возможности описать объекты(читай проекцию в логику программирования, бизнес логики из жизни) с их глаголами, свойствами, взаимодействием и т.д.. Очень ВАЖНО в этой фазе следовать БУКВЕ ОО методики. Т.е. сущности ДОЛЖНЫ идти от ЖИЗНИ!!! НИКАКОЙ отсебятины не должно быть!!! Это ЗАКОН!!! И второй не маловажный закон - НЕЛЬЗЯ программировать на БУДУЩЕЕ, если этого нет в ЖИЗНИ!!! НО!!! Нельзя усекать модель, в угоду простоте, за счёт невозможности полноценной поддержки сущностей. Пример: если из жизни не пришла инфа, что вертолёт может ездить на колёсах - то это не значит что он ТОЛЬКО летает!!!

И вот только после этих двух фаз!!! Вы можете выбрать ЯЗЫК реализации и СПОСОБ ЗАПИСИ в нём!!! Т.е. никто Вам не запрещает использовать ASM!!! Заметьте - сущности придут из ООА и ООП, и ОСТАНУТСЯ на всём протяжении жизни ПРОЕКТА, как бы долгим он не был(Это одно из ЗАМЕЧАТЕЛЬНЫХ свойств данного подхода - СТАТИЧНОСТЬ модели!!! Т.е. кодить надо меньше, и код в дальнейшем НЕ МЕНЯЕТСЯ!!!)

Теперь о том, как подхожу к решению сам...
У Вас есть МК. Есть железка на которую он напаян. Есть бизнес задача которую надо выполнять согласно алгоритмам и условиям...
То, что у вас идёт от железа - это элементарные сущности. Зачастую в осях принято обзывать это драйверами - т.е. попытка натянуть некую абстракцию на железо. Тут прозвучало что ослинные уши всё равно вылазят от железа, и соответственно имеем не полную инкапсуляцию в чёрный ящичек... при этом ничего изменить не можем. И получаем какую-то фигню. Частично я с этим согласен. Что лепить универсальность на любую периферию - мягко говоря глупо. С другой стороны - делать более верхний слой на все случаи жизни - другая крайность. Я думаю существует золотая середина. Т.е. можно выделить однотипную переферию, которая будет одинакова для определённой серии железа. Т.е. находим сущности которые по нашему мнению будут прослеживаться на большом промежутке времени данного железа. Например: Есть несколько каналов USART. Некоторые из них подключены к приёмо-передатчикам RS485. По всем каналам предпологается MODBUS. Значит наклёвывается следующая декомпозиция: есть сущность отвечающая за работу USARTов. Есть сущность юзающая сущность юсарт и знающая о привязки номера порта=приёмо передатчик RS485. Есть сущность модбас, которую можно связать с сущностью RS485. Если например, в будущем, необходимо будет выключить/включить модбас в других комбинациях - это легко будет сделать программно - перебросив использование сущностей. И т.д..

Выше идёт бизнес слой. Который знает об агрегатах(читай "драйверах") подключаемых к плате. Найденные сущности идут из бизнес логики. Т.е. если к примеру пусканалдчики говорят, что вот при температуре в 10 градусов Вы должны включить компрессор - то напрашиваются сущности компрессора, переключателя реверса его, термодатчиков... Все эти железки управляются посредством протоколов и портов МК, которые мы "прикрыли драйверами". Например: Компрессор рулится инвертором через модбас. Значит нижний слой имеет сущность компрессор, который знает о сущности модбаса. в бизнес слое Вы работаете именно теми терминами и сущностями которые используют пусконаладчики. Т.е. компрессор вкл/выкл, состояние, степ ап, степ даун, переключить на нагрев, переключить на охлаждение, статистика, токи, напряжения и т.д.. Сущность компрессор в свою очередь отслеживает термодатчики с бошки, с контура, аварии, текущие значения, параметры. Отрабатывает перегревы, утечки фреона, переизбыток давления в контуре, правильно стартует, останавливает, и т.д. и т.п. При этом он общаеся через канал модбас, ичего не зная куда тот выходит - изернет или юсарт или ышо куда...


ну как-то такая картинка маслом

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

Что касается темы топика, полностью согласен с kolobok0 (увы, своим лбом и шишками, а уже потом пришел к необходимости изучать теорию ):

Не буду оригинальным и предложу всем кто понимает озвученную мысль к прочтению книгу (если ещё не читали данный нетленный труд)ЛЕО БРОУДИ
СПОСОБ МЫШЛЕНИЯ - Ф О Р Т ЯЗЫК И ФИЛОСОФИЯ ДЛЯ РЕШЕНИЯ ЗАДАЧ (книге уже лет 30 примерно отроду)
Эти все моменты там обдуманы автором книги!!! Форт язык, в книге, как самый простой способ обсуждения проблематики затронутых вопросов.
А дальше можно увязать информацию из книги со своим опытом и знаниями

P.S. Программистов на Форт, конечно, найти практически невозможно. Вымирающий вид, но свой вклад в понимание и развитие IT области всё ещё вносят.