Дошёл до такого уровня, когда программа пишется не за день-два и все необходимое держишь в голове, а когда проект большой и сложный на несколько месяцев. Мне нужно средство, которое позволило бы грамотно проработать концепцию программы, спланировать работу, разбить ее на куски и т.д. То есть здесь не обойтись просто алгоритмами, нужно нечто более глобальное такое как 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у. Ну вот для начала. По отдельности пустяк, а в комплексе можно набыдлокодить за недельку, а потом никто кроме тебя поддержать это не сможет. Вот и хочется, что все было продуманно, лаконично. А как это сделать? Как планировать, как разбивать? Как прорабатывать концепцию?



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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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


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

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

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