Добрый день!

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

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

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

А рисовать в Altium-е.

Я для себя стал сводить проекты в Excel-е: делаю табличку: сверху вниз тип узла, по горизонтали девайсы, в табличке количество: Spi 2 Adc 3, и тд.
Так описывается семейство устройств.

На строчку ниже удобно в похожем виде описать каждое устройство: сверху вниз тип узла (одинаково с 1), по горизонтали функция каждого конкретного канала.
Так в таблице получается как сводная информация по семейству устройств, так и расшифровка узлов каждого.

Есть проблема с иерархией: вход может быть adc с разными функциями (усилитель, делитель, сух.конт...) но пока у меня это укладывается в плоскую схему: все они подкласс In: InAdcAmp, InDiscrDiv....

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

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

Набор узлов, их функции, и алгоритм их работы ИМХО на схеме совмещать бессмысленно: они хоть и связаны, но суть и производные, соотв. складывать их вместе теплое с мягким.

Я описал алгоритм для устройств одноранговых, простых. Как правильно заметил AlexandrY в случае сложных устройств требуется иерархия. К сожалению в связи со спецификой ПП, при переходе к трассировке все иерархии складываются в один уровень.

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

Я имею в виду, что нормальные иерархические блоки: схема+плата я не видел ни в альтиуме ни в менторе, а кэденс мы увы не разумеем(

Кстати да, хороший вариант.
Сделать универсальный процессорный модуль и сделать в нем базовый программный фреймворк с RTOS, GUI, FS, RF, CAN и проч.
Тогда и диаграммы станут очень компактными и софт будет просто небольшой надстройкой над фреймворком
А новые платы типа такой можно будет шлепать каждые две недели.
Нажмите для просмотра прикрепленного файла

Ексель - хороший вариант, но на данный момент я составляю в нем спецификацию модулей - перечень стеков, процедур, т. п. и так называемую карту переходов - по вертикали состояния устройства (вкл, работает, ошибка), а по горизонтали приходящие сигналы. На пересечении получается состояние, в которое переходит девайс (узел) в ответ на сигнал. Еще отдельно колонкой условия перехода. Потом таблица соответствий состояний узлов к состояниям верхнего уровня.
Что касается полной картины, чтоб заранее увидеть грабли, которые обычно вылазят уже на стадии кодирования/капчи (схемы)/трассировки/использования =) , то я не смог такую диаграмму придумать в екселе. Как говорится, картинка стоит тысячи слов. Мешанина теплого и мягкого вытекает из того, что девайс и есть суть такой мешанины, и в голове она как раз не помещается. Диаграмма дает возможность анализа косяков, как например, в очередной раз взглянув на представленную мной картинку, заметил кольцевание между модулями, и теперь думаю дальше, как его избежать.
Наподобие таблицы периферии я такое тоже сооружал, по ходу разработки эта таблица перерабатывается, и важно поддерживать ее актуальность.

Если Вам нужна предельно сжатая структура для облегчения восприятия, то имхо ничего лучше иерархии в природе на эту тему нет.
Желательно иметь динамическую иерархию со сворачиваемыми ветвями - например, notepad++ для кода такое делает прекрасно. И непонятно, что мешает все - и структуру и алгоритм описать текстом.

Также project libre умеет подузлы сворачивать разворачивать.

ActiveHdl ещё в своих блочных диаграммах такое умеет вроде - там и иерархию и алгоритм в картинки впихнуть можно, и они динамические - по ним ходить можно. Ну и да - альтиум.

Вместо MBI5039 и регистра клавиатуры я бы предложил AS1115-BSST
Все что можно перевести на локальные шины типа I2C и SPI. Подумать о сопроцессоре и расширяемости.

Общий принцип - модуляризация. Выделить и изолировать отдельные функции дивайса.
Скажем GUI я бы не рисовал на общей диаграмме.
У GUI логичнее рисовать дерево окон и меню, а не какими сигналами оно связано с другими задачами.
GUI не риалтаймная часть системы, зачем его так акцентировать.

Стейт машины рисовать в Excel тоже как-то странновато.
Их рисуют в Matlab StateFlow или на худой конец в IAR Visual State. Там хотя бы из них сразу код генерится и симулировать работу можно.
И даже так мне не удавалось долго сохранять эквивалентность этих моделей и их реализации в дивайсах.
Поскольку потом софт в дивайсе сверху донизу наполняется отладочными хуками, логами, ответвлениями, адаптерами к нижнему API и проч. оснасткой которая никак не лезет в чистые модели.

Это не обязательно относится к процессорному мезонину. Мне это пригодилось в управляющих платах. Да и вообще, концепция мезонина, такая прекрасная на первый взгляд, имеет недостатки: цена, габарит, теплоотвод, разьемная ёмкость, надёжность итд.

Кстати посмотрел ещё раз схему ТС - она очень даже неплоха, сильно ее не сократить.

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

Вам никогда не приходит в голову, что ваши детсадовские походы уже много раз пройдены ?

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

Идите в школу.

Консультировать нужно в чем хорошо разбираетесь - по крутилкам, шевелилкам и ble. А про ваши достоинства как разработчика тяжелых плат EvilWreker уже всё написал.

900 пинов эт когда вы DDR хотите сделать на одной плате, а процессор на другой, т.е. полный дурдом.
Когда дело идет к разрастанию сигналов, то делают мультипроцессорные решения.
И опять модули здесь сильно помогают.

Человек так устроен, что ему надо все редуцировать, чтобы он мог себе позволить о чем-то забывать.
Вот вы, например, забыли показать свои разработки прежде чем огрызаться.

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

Сервера, персональные компьютеры, ноутбуки...

P.S. Топикстартеру: попробуйте yed. Прекрасен тем, что порог входа практически нулевой. Можно отдавать части работ разным специалистам в предметных областях, которые могут и не знать ничего про альтиумы и т.п. Поддерживает иерархию. В отличие от убогих визиоподобных програм имеет неограниченное рабочее поле, но при этом не требует 32 ядра и 256 гигов оперативы, чтобы программа не тормозила.

Думаю тем кто пользуется Visio этот yed покажеться сломаными костылями.
В это трудно поверить, но в yed нельзя даже запастить картинку из буфера обмена.

Плис, коммутаторы, ацп, цап... И такие вещи тоже делают люди. И даже в России)

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

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

a123-flex
А что есть динамический список? Это когда в екселе нажимаешь Группировать и потом можно свернуть часть ячеек? Да, таким я пользуюсь, многоуровневым. Нет, задачу это не решает)

да, я имел в виду это.


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

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

Давайте начнем с нуля. Для начала, вы должны четко представлять, какой осязаемый профит вы хотите (можете) получить от рисования картинок. Иначе это будет рисование ради рисование. То есть:

• Что вы потом станете с этими картинками делать
• Где рисование картинок будет эффективнее других подходов

Например:

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

Короче, рисовать надо (полезно) DATA FLOW. То есть, протекание данных и их трансформацию. Данные - это стрелочки с подписями, блоки - куски девайса которые данные трансформируют. Что это нам дает:

• Можно быстро добиться, чтобы соединения между блоками были максимально простые
• Проверка целостности - выходы должны генериться на основе входов, а не магически
• Фиксирование API - для каждой "стрелочки" станет понятно, какие данные внутри.
• Документация, если требуется донести суть до кого-то другого

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

Например, у нас есть АЦП, с которого 100 раз в секунду снимаются данные.

• Рисовать "таймер" - очевидная идея. Но глупая . Потому что таймер генерирует события, а нам надо рисовать диаграмму данных.
• "Правильно" будет просто нарисовать стрелочку, на которой подписать что это данные от АЦП (подробности - по обстоятельствам)

Еще один пример - https://github.com/nodeca/relimit/tree/master/docs#data-flow. Кучерявый распределенный rate limiter, где надо гарантировать отсутствие коллизий. Обратите внимание, на диаграмме нет алгоритмов. Там именно протекание данных. Но по такой диаграмме потом криво закодить невозможно . Тот случай, когда задача может взорвать мозг, но если проектировать грамотно, то получается очень просто. Обратите внимание - это кажущаяся простота, результат грамотного подхода, а не того что задача плевая.

Инструменты:

• Для диаграмм использую draw.io, потому что все работы совместные и надо быстро шарить. Кстати, дополнительный стимул, рисовать кратко и только суть . IMHO редакторы UML для data flow скорее вредны чем полезны, т.к. забивают мозг псевдополезными вещами.
• Если задача слишком сложная и в голове совсем вакуум - тогда сначала в mind maps разложить что вообще хочется. Вот это https://coggle.it/ - очень приятная рисовалка, с возможностью делиться ссылками.

Скажем честно - все эти инструменты просто попытки приблизиться к Visio.
Каждый из них решает часть работ которые все может сделать один Visio.
Но как видно TC не ставит задачу удешевить тулсы, а хочет красивую многофункциональную презентацию.
А поскольку он работает в Excel, то ему удобнее Visio ничего нет, поскольку Excel напрямую может строить диаграммы в Visio на основе своих таблиц.

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

Если вы плохо знаете Visio, то действительно разумно дальше не холиварить.
Не забываем, что автор демонстрирует свою работу именно в Visio и не просит чтобы ему дали что-то более примитивное.

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

Не даром тут UML всплыл.
Я, кстати, не нашел как применить UML, от слова совсем.

1. Кто вам дал право определять, что есть честно?
2. Нет, большинство "этих програм" даже открыто заявляют, что не собираются быть монструозным комбайном, который призван решить все задачи, но при этом решать каждую из них плохо.

"Шарик, ты балбес" (с) Матроскин.

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

Ну так для того и обсуждаем.
Или будем обсуждать обсуждение?
Вы тоже имеете право применять риторику.

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

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

Я пытаюсь объяснить довольно непростые вещи по методологии. Упрощать их до выбора редактора и тем более сталкивать в УГ лозунгами про визио не очень конструктивно. Если что-то вызывает трудности - ну переспросите, постараюсь детализировать. Это будет новая информация, от которой толку намного больше, чем от развлечений с "доказыванием правоты".

Просто я здесь не согласен категорически.

Редактор решает все!
То насколько удобно он позволяет делать то или другое определяет то, что вы в нем будете или не будете рисовать.

Это как язык программирования. Я его выбираю не из-за каких-то синтаксических возможностей, а из-за библиотек, фреймворков и IDE под него.

Показанный там вами по ссылке автомат состояний только доказывает это.
Он примитивен, он не симулируется, не параметризуется, он не обложен тестами, он не интегрирован в большую систему, никто его не прочитает, он не презентабелен и т.д.
Это по сути снипет, а не проект.
Только не надо сейчас вываливать уязвленное самолюбие, я верю что где-то там в вашей тусовке и на вас самого это производит впечатление, но попробуйте хотя бы сравнить с Simulink-ом.

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

==============================================

Кто знает про майндмапы и активно использует - можно смело пропускать. Кто не уверен - можно глянуть примеры и прикинуть насколько это имеет смысл лично для вас.

<tl;dr>

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

Далее пара примеров.

• WiFi-конфигурилка (конкретно мне - для приводов), когда не хочется возиться с менюшками в прошивке и т.п. Результат, если кому надо проследить к чему это привело.
• GUI на Rust для эмбедов. Пока просто пытаемся договориться, что делать и как попилить работу.

Это конечно только частные примеры. Возможно у вас более простые задачи, которые проще прокрутить в уме и сэкономить время. Но возможно кому-то это поможет понять, пора ли фигачить диаграммы или все-таки сначала лучше разобраться на более высоком уровне. Чем выше уровень проектирования, на котором произошла ошибка, тем дороже обходится исправление по прошествии времени. Поэтому перескакивать не желательно.

Насчет конкретных рисовалок - смотрите в чем удобнее. Если разработка идет в одно рыло, то вообще наплевать на многие вещи. Другой крайний случай, когда разработка это вероятностный процесс. То есть состав разработчиков может меняться, причем внезапно. Тогда крайне важно донести информацию до незнакомых людей с минимальными усилиями. То есть, если вы начинаете рассказывать "надо поставить программу" - это сразу фейл (по моим меркам). Поэтому я предпочитаю вебовские решения. Варианты с выкладыванием скриншотов (и постоянным обновлением после изменений) мне показались недостаточно удобными. Но это исключительно мое личное мнение, которое касается моих проектов. И конечно же это не "единственно верный путь", наверняка есть и другие, просто я делюсь тем, что лично мне и для моих случаев понравилось больше всего. Если это окажется кому-то полезным - ну и славно. Если кому-то не будет пользы - плакать тоже не стану

Теперь пройдемся еще раз по диаграммам. А точнее, по диаграммам данных (data flow). Допустим, с майндмапами вам уже все понятно (или с проектом все понятно и без них) и хочется двинуть дальше.

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

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

• По мере роста деталей затраты времени на диаграммы возрастают, и эта зависимость не линейна.
• Когда в код вносятся изменения - синхронизировать диаграммы это куча лишней работы. Примерно как возня с исправлением тестов, если их нафигачить "из принципа", до того как внутренние API достигли определенной стабильности.

Нет смысла упираться в абстрактные принципы. Важен баланс. Нам ведь не надо рисовать диаграммы ради вселенской справедливости или красивого вида. Мы обычно хотим с минимальными усилиями "правильно" разбить систему на части, чтобы не подставляться под дорогие переделки. Что будет балансом в конкретно вашем случае - можете решить только вы. Здесь универсальных советов, к сожалению, нет.

Конечно, всегда найдутся исключения, но я рассказываю про основной подход, с чего хотя бы начать, когда от страха дрожат ручки и дергается глазик. Если задуматься, то суть большинства систем - обработка данных. Есть черный ящик, у которого на входе ручки, за которые дергает безумный юзер, а на выходе (допустим) индикатор. Если проектируем библиотеку, то входы и выходы обзывают словом API. Как-то так, если совсем кратко и с упрощениями. Обращаю особое внимание, не надо путать данные с событиями. Данные можно какбэ "потрогать руками". В событиях проще запутаться. Пример исключения, когда выбирать не приходится - конечный автомат. Там без событий никак. Но не стоит усложнять себе жизнь раньше времени. Диаграммы данных вам понадобится рисовать практически всегда. Остальное - по обстоятельствам.

Профит: если вам удалось сделать корректную диаграмму данных, то налажать потом в коде практически невозможно .

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

Итак, начинаем с того, что фиксируем входы и выходы. Т.к. если мы не знаем, "что обрабатывать", то и внутренние блоки станут перемалывать какую-то туфту, и ничего хорошего не выйдет. На самом верхнем уровне входы и выходы называются "use cases" - как юзер захочет подергать ручки, как ему будет удобно дергать API и что он захочет получить взамен. Обычно use cases сначала выглядят несколько сумбурно, поэтому проще их выписать в столбик, чтобы найти что-то общее. Или откатиться на шаг назад и прогнать через mind map для особо тяжелых случаев.
Итого, у нас должно получиться:

• Исходные точки
• Стрелочки (данных), которые выходят из этих точек или приземляются в них.

Ну и остается дорисовать блоки, которые эти данные как-то переколбасят.

На что стоит обратить внимание:

• На "стрелочках" обязательно должны быть именно данные. В идеале - подписать. В крайнем случае вы как минимум должны быть готовы ответить до мельчайших деталей, что гонится по стрелочке. Если по стрелочке гонится фик знает что - хрен вам, а не полезная диаграмма в результате.
• Надо постоянно верифицировать, что данных на входе (стрелочек) будет достаточно для работы блока, чтобы выплюнуть то что хочется. Если что-то пропустили - дорисовываем (или помечаем отдельно). Если не подумав нарисовали лишнее - убираем.
• Бывает, что данных очень много. Например конфиг с 20 параметрами. Такую часть иногда удобнее записать сразу в виде кода, чтобы не превращать чертеж в месиво. Но верификацию целостности все равно надо проделывать.
• Содержимое стрелок - основа для API (внешний или внутренних). Еще один повод отнестись к ним серьезно, а не использовать их в качестве декоративных соединителей.

Примеры "стрелок":

• Фиговый вариант - "устройство ввода". Непонятно, какие данные и как оно выплевывает.
• Дельный вариант - "коды клавиш, байты, с клавиатуры".

Примеры очень упрощенные, только чтобы продемонстрировать суть объяснений.

По блокам внутри диаграммы. Тут универсального рецепта нет. Могу только посоветовать придерживаться некоторых ограничений:

• Избегайте большого количество блоков. Если диаграмма распухает - уводите "лишнее" в иерархии. Обычно советуют не превышать 7-9 блоков, но это субъективно. Если у вас сверхмозг - рисуйте хоть 20, раз можете объять разумом . Главное - не забывайте верифицировать входы-выходы у каждого блока. И не забывайте, что если планируете показывать диаграммы другим - у них может быть не такой сверхмозг как у вас.
• Избегайте "пустых" преобразований форматов данных и бездумных шаблонов. Типичная ошибка программиста - нарисовать класс с красивым названием "потому что так правильно", и потом пытаться подогнать стрелочки под этот класс. С надеждой, что в итоге все сойдется как надо. Если вас в качестве гарантий устраивает молитва и вера в лучшее - на здоровье. Если нужны гарантии посерьезнее - стоит опираться на содержимое "стрелочек", и дорисовывать блоки под них а не наоборот. Результат может получится абсолютно не такой, как вы предполагали в начале. Причем проще и лучше . Убеждался несколько раз.

Возможно, в конце у вас получится совсем простая диаграмма из пары-тройки блоков, и вы подумаете "неужели из-за такой тривиальщины я страдал фигнёй". Но ведь смысл именно в том, чтобы понять, как сделать просто, а не наворотить чумную вундервафлю. На практике у меня получались рисунки с 3-5 блоками, и очень редко - с подуровнем для одного-двух блоков. Просто я не вижу смысла упираться в диаграмму как в самоцель. Рисую только до той степени, которая позволить двинуться дальше - продолжить в коде.

Можно делать иначе, сложнее и т.п. Все зависит от мастерства, потребностей и т.п. Я описал один из вариантов, с чего можно начать. Очень часто этого оказывается достаточно.

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

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

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

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

TC показал достаточно подробную диаграмму своего дивайса.
Что там может быть не ясного? Чего еще интересоваться?
Там работы сделать плату на две недели еще две недели на софт. Все!
Профессионалы такие делают без всяких диаграм или с минимальным эскизом (в Visio) типа такого:


А пока поспорю относительно ваших представлений о проектировании дивайсов такого рода.
Первое, программно аппаратную часть такой системы вполне доступно разработать одному специалисту.
Посему отметаем всякую мишуру там с шарингом, броузерными приложениями и проч. Броузерные приложения однозначно тормозят работу и снижают эффективность.
Второе, привлекать Mind map в данном случае поздно ибо TC уже перешел на уровень детализации. Mind map скорее средство сосредоточения на задаче людям с синдромом дефицита внимания.
Далее про диаграммы логики работы софта. Не путаем DSP алгоритмы и машины состояний. Они моделируются (а не рисуются как у вас) совершенно в разном стиле.
В данном проекте речь о проектировании машины состояний. Она проектируется так:
Нажмите для просмотра прикрепленного файла
Т.е. мы формируем события из входов, делаем машину состояний и выдаем из нее действия которые драйверами превращаем в выходные сигналы.
Потоки данных тут не при чем.
А вот в DSP алгоритмах работаем с данными, но не с потоками, а с типами и сэмплированием. И там будут фреймы, вектора, матрицы, буфера и проч. И тоже делаем модели, а не рисунки.
На рисунки студенты могут тратить время, а инженера держат не за рисование.

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

У ВАС на ВАШИХ задачах - свой опыт. У МЕНЯ на МОИХ задачах - свой. Я не вижу тут предмета спора. Мой опыт не делает бесполезным ваш, а ваш не делает бесполезным мой. Потому что и там и там это реальный многолетний опыт, а не высосанный из пальца. Моделировать диаграммы состояний мне вообще не требуется, они рисуются очень редко, и я пытался объяснить почему обычно (возможно вы - необычный) практичнее начинать с диаграмм данных (после майндмапов).

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

Я даже ни разу не написал, что визио говно и пользуются им только упоротые лохи. Более того, я так не считаю. В чем проблема-то? Вас браузер покусал?

А почему вы думаете что я отвечал не TC-у?
Но только я делаю системы почти такие же как и у него, а вы делаете непонятно что-то софтовое.
Почему вы решили что ваш опыт можно экстраполировать на такие системы?

Мне кажется все-таки что разработчики определенного рода устройств приходят к одной и той же технологии их создания.
У TC я вижу этап который сам когда-то проходил. И он кончится когда автор перестанет ждать чуда от диаграмм и перейдет к нормальному моделированию.

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

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

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

Посмотрите. То о чем вы говорите, очень смахивает на Fpga Advantage. Продукт уже мертвый, но в точности соответствует всем вашим запросам)

Да, и если возможно, я был бы очень признателен за консультацию, как в Visio "симулировать, параметризировать, делать тесты, интегрировать в большую систему".
Я в нем картинки порисовать тоже люблю, а вот моделировать и интегрировать еще не научился, видимо кругозора не хватает((

сейчас я между прочим пытаюсь применить sybase PD16, так что действительно, у всех мозги по-своему. жестких временных рамок у проекта нет, потому есть время поизучать что-то новое. но пожалуста, не надо высказываться так категорично насчет того или иного подхода, я все их попробую и расскажу что у меня получилось. как не крути, они имеют примерно одну цель - смотрите, картинка с изображением электропривода изображает не что иное, как data flow.

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

Жесть!
Вместо моделирования, рисовалок и заточенных embedded тулсов вы выбрали корпоративный дизайнер SQL баз данных.
Абсолютно корпоративную хламоту (это метафора, не принимать ни на чей счет, выражает личное мнение автора) сделанную для убивания времени офисного планктона.
Хочу вам сказать что такой построитель реляционных структур вы найдете и в MS Access.
И не надо качать этот реально монструозный и замороченный SAP PowerDesigner ( больше 2 гиг, если кто не в курсе)

Ну ка , кто тут сравнит SAP PowerDesigner с yEd?
Mind map нервно курят.

А нельзя ли этот момент поподробней ? Это Ваше имхо, или базовый постулат откуда-то ?


Какой, если не секрет?)

Кстати, и насчёт машины состояний очень интересно: в каком формате (или стандарте, простите отсутствие кругозора) она нарисована ?)


Судя по непрерывному хамству, вы считаете что ваш кругозор самый большой.
А образования высшего судя по всему нет.
Вы вообще знаете что такое ТЗ на изделие ?

Или настоящим профессионалам такое знать необязательно ?

Это из методологии разработки, которую лет 20 назад пришлось экстренно изучать. К сожалению, теперь даже имен авторов не смог в интернете найти.

Мне с тех пор не попадались явные рекомендации "заниматься данными и не лезть в события". Что странно, т.к принцип невероятно полезный.

Visio учит правильному построению диаграмм, планов и чертежей для многих видов деятельности.
Куда входят UML, BPMN, IEEE и т.д.
К сожалению (или к счастью) мне, как независимому разработчику все это не нужно. Может только IEEE, но это гораздо удобнее делать в Altium-е и SolidWorks Electrical.

Машину состояний я здесь нигде не демонстрировал, если вы только по простоте душевной не приняли за таковую показанную мной упрощенную иллюстрацию технологии создания машин состояний из мануала VisualState.

Может вы не в курсе особенностей работы независимых разработчиков, но мне реально не нужны ТЗ.
Моя работа начинается с экспертизы потребностей заказчика.
Это моя забота и решение писать или не писать ТЗ или какие-то другие бумаги.
Тут как-то термин стал всплывать - "технический долг". Так вот в этот "долг" гораздо важнее всякого ТЗ.
Т.е. если хотите успешно продвигаться, то надо выполнять не ТЗ, а отдавать долг.

Очень жаль. Если Вы вдруг вспомните, или встретите какие-либо подробности или ссылки, очень интересно.


Как бы за всем этим словоблудием не оказалось пустоты.

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



Нужно завести в электрониксе копилку золотых цитат. Эта явно туда.

Да сам не люблю в качестве доводов использовать "авторитетное я". Уже несколько раз за последнюю неделю пытался найти, вообще дыра. 2 чела, фамилии кажется Cotton и Yordan. И кажется одного из них звали Eric. Лет 10 назад удавалось находить хотя бы упоминания, что эти люди что-то подобное написали. Сейчас даже людей нема.

Но самую великую мудрость из их методики я вам рассказал, а в остальном подобные книжки как близнецы-братья. Ну в одном месте напишут, что надо не больше 5 квадратов на лист, в другом не больше 7 , в третьем не больше 9 . Вы спрашивайте, если что-то непонятно. Мне временами приходится людей натаскивать, как рисовать диаграммы, чтобы это были не просто красивые картинки, рука набита уже

Из классики могу назвать Rapid Development и Code Complete, автор Steeve Mc Connel. Но по-моему про первую и так знают абсолютно все, кто хоть раз пытался въехать в разработку высокого уровня. А вторая специфична для программистов.

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

UML, BPMN, IEEE - это и стандарты оформления диаграмм и схем и методики одновременно.
У кого-то вся работа заключается в разработке диаграмм по этим стандартам, а кто кто-то исключительно ими руководствуется. Им Visio просто незаменим.

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

Да спасибо, почитаю тему.

Но что-то кроме примитивных, мягко говоря, mind map-ов вы ничего не показали.
Если вам так близка Java, то вам следовало бы показать нам что-то вроде концепции MVC (model-view-controller)
Нажмите для просмотра прикрепленного файла
(для неподготовленных - это не сам пример реализации MVC)
Взято из "Android Programming. The Big Nerd Ranch Guide"
С ней в частности создают программные проекты под embedded в Android Things.

Просто не в коня корм. Как я уже говорил, для вас понятие "методология" - пустой звук. Но меня вполне устраивает, что мои посты полезны другим.


Я вообще не пишу на яве. Не демонстрируйте свою "универсальную компетентность" столь явно, в очередной раз. Куда именно себе засовывать советы что мне делать - разберитесь самостоятельно.

Методологии познаются в сравнении, а вы не ушли дальше примитивных рисовалок проблесков сознания.
И это печально.
Я надеялся отзовется тот кто системно подходит к вопросу.
И ТС похоже продвинулся дальше всех.

Хоссподя... ну вот человек только что с треском обделался с "java", и как не бывало, отряхнувшить, лезет с новой демагогией. У вас там память что ли каждые пол часа зануляется? Дефицит внимания? Ну давайте один раз всем разделом отложим свои дела и попробуем вам как-то помочь. Очень уж утомительно вы лезете под руку со своими глупостями. Как один собакен из анекдота, у которого зубов нет но засасывает насмерть.

p_v
Пожалуста, не нужно развивать этот спор. Вы поделились действительно полезным опытом, мне еще предстоит его осмыслить. Я нашел еще одну замечательную программу (опять же на рутрекере =) Visual Paradigm и пробую с нуля пройти весь цикл разработки. У меня еще появятся вопросы) Поэтому хотелось бы, чтобы вы не составляли общее мнение обо всех участниках.

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

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