Как описывать архитектуру девайса Опции

[Hexel]

Добрый день!

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

Если конкретно, вот полная структурная схема девайса, нарисованная в визио. Компоненты в синем ящике - периферия проца, пакаджи - софтовые модули. Компоненты на свободном поле - участки схемы, в белых ящичках - коннекторы и соответствующие им входные цепи. Входа компонентов обозначены как интерфейсы (кружками), я старался размещать их слева. Например, модуль OutExt имеет процедуру SetOut, которая вызывается из модулей UserIF и Evt, и выдает наружу сигналы через выводы Ch1 и Ch2 и через периферию SPI. Местами путаница, но это промежуточный вариант, т. к. визио показался мне не самым удобным инструментом для даной задачи. Вот я и хочу спросить, кто в каком редакторе составляет такие диаграммы? Может быть, хотя бы для чисто софтовых проектов?
На мой взгляд это должен быть UML, пока что только для структуры. За описание процессов я может потом спрошу

Прикрепленные файлы

 P171207__________.pdf ( 21.75 килобайт ) Кол-во скачиваний: 105

 

[p_v]

Теперь по инструментам. Лично у меня очень экстремальные требования по доступности. Такие далеко не у всех, но опыт может оказаться полезным на перспективу - кто знает как жизнь обернется, будете иметь в виду направления, куда можно копать.

Проекты опенсорсные:

• Надо максимально быстро и просто донести информацию до другого человека. На любой платформе. У человека может просто под настроение возникнуть желание помочь. Если начать его грузить пургой про правильное проектирование - он просто плюнет и пойдет дальше, в какой нибудь другой проект. В итоге вы будете офигенно круты и правы, но в гордом одиночестве . Идеальный вариант - когда человек может прямо в браузере посмотреть что нужно. Картинки и pdf неплохо прокатывают, но у них неудобство с ручной актуализацией после каждого изменения. Поэтому стараюсь выбирать именно вебовские тулзы, если это возможно. В перспективе плюсов больше (если вам не надо раздавать другим людям - плюсов меньше ).
• Абстрактно, локальные тулзы обычно более навороченные. Но у них проблемы с шарингом результатов. Если общаемся с разработчиками один на один, то часто каждый делает в том что удобнее, а потом финальный результат переколачиваем во что-то типа draw.io - его в нашем случае проще раздавать и поддерживать. То есть, если у вас уже есть инструмент, который вы хорошо знаете - конечно начинать лучше с него, а дальше разберетесь. Лично я со временем навострился сразу в draw.io рисовать, но у меня весьма богатая практика, как обходиться без лишних телодвижений. Не уверен что прям с нуля draw.io будет идеальным вариантом. Но штука по-своему прикольная. В любом случае, владение методологией (многобукф из предыдущих постов) важнее, IMHO. Я не могу выделить какую-то конкретную рисовалку, которая чудесным образом решает все проблемы. Могу только обратить внимание на майндмапы и диаграммы данных, и что конкретно для них есть вебовские решения. Будут ли они оптимальны для вас - решайте сами. Диаграммы классов я не рисую - за десять лет активной разработки софта как-то не понадобилось. По той же причине агитировать за UML не вижу смысла.
• Другой пример комбинированного подхода (про веб, но не совсем про диаграммы) - доносить до людей поделки через EasyEDA очень удобно. Потому что какой-нибудь слессарь (конечный юзер) может в два клика заказать и платы и детали. Шарить по ссылке схемы для обсуждения тоже очень клево. Но разводка плат там "трохи специфичная", и симуляция простовата. Решали дешево и сердито - знакомый делал предварительную расстановку и 3D-модель в кикаде, а когда правки заканчивали, я уже делал окончательный вариант в EasyEDA. Честно сказать, пока в любом приличном трассировщике двигать дорожки удобнее, особенно с переходными отверстиями. Но в плане "донести опенсорсный продукт до конечного юзера" EasyEDA рулит и педалит. В масштабах "проекта" напряги могут потом отбиться многократно. Это на примере моих поделок, у кого-то другого может быть иначе, настаивать не буду.

Конкретные тулзы, которые удобнее для моих случаев, уже называл - coggle.it и draw.io. Но то что удобно для меня - не обязательно удобно для всех или для вас лично. Рассматривайте просто как информацию для расширения кругозора. Я объясняю только некоторые принципы и подходы, а не раздаю "валшэбные рицепты".