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

[yanvasiij]

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

[kolobok0]

... нужно нечто более глобальное такое как UML. Но как применить UML к embedded на простом Си. Как составлять диаграммы классов, если у тебя их в явном виде нет как таковых, какие диаграммы из стандарта мне вообще нужны и в каком порядке мне их применять? Посоветуйте...

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

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

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

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

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


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