[_Pasha 0]

Короче я против диаграмм как инструмента проектирования.

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

[yanvasilij 0]

как то всё в кучу. у Вас.

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

 

UML - это язык записи. и ничего больше. Он помогает людям записывать-читать-делится полётом мысли.

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

 

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

 

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

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

А разработка это ведь итеративный процесс.

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

 

Короче я против диаграмм как инструмента проектирования.

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

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

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

[Виктория 0]

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

 

 

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

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

 

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

 

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

[AlexandrY 3]

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

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

 

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

 

Но если посмотреть ту же книгу "Practical UML Statecharts" можете ли вы там понять любую попавшуюся случайно UML диаграмму?

Гарантирую что нет. Все диаграммы там абсолютно зависят от контекста, как математические формулы.

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

Чем это отличается от чтения чистых исходников?

 

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

 

Проект FreeMODBUS как раз сделан на этой концепции.

Не далее как весной разбирался с портированием FreeMODBUS.

Надо было сделать мост между сетью MODBUS устройств на шине RS485 и сетью Ethernet.

 

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

FreeMODBUS достаточно простой проект. Там объем реальных исходников не больше 100 кБ. Но возиться с ним пришлось наверно около недели.

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

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

Да, красиво, эффектно, масштабируемо Но по сути дурь.

 

Автоматы состояний - зло.

Применение RTOS позволяет отказаться от автоматов состояний.

В результате я написал полностью свой MODBUS мост немного основываясь на исходниках от Micrium без всяких диаграмм в линейном стиле только на вложенных if else.

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

 

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

Например uC/OS от Micrium и весь их промежуточный софт или MQX от Freescale.

[yanvasilij 0]

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

 

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

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

 

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

Например uC/OS от Micrium и весь их промежуточный софт или MQX от Freescale.

 

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

Изменено 15 ноября, 2013 пользователем yanvasiij

[Aner 3]

...

Автоматы состояний - зло.

Применение RTOS позволяет отказаться от автоматов состояний.

...

Это вопрос философский, ...

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

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

[Idle 0]

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

Книжка хорошая, фреймворк хороший. Сам фреймворк QP не использую, т.к. работодатель его не купил. Использую самописные автоматы по аналогии - без иерархических автоматов и без активных объектов. Сначала рисую UML state charts (на сайте есть stencils для Visio), потом кодирую. В шаблонах нет графического представления для if внутри else - посмотрите как это сделано у них в QM.

 

 

И, да - графическое представление помогает.

 

Я уверен, что с опытом необходимость в таких диаграммах может отпасть.

Да наоборот, с опытом быстрее их рисовать будет.

[Harbour 0]

Использую dia для красоты и обыкновенную классную доску с магнитиками и фломастерами шириной в 5м в реальной жизни, для проекта на год и 5-10 чел кое-как хватает ;) Понял что программы управления проектами и составления разных диаграмм - полная туфта и никак не заменят живого общения специалистов перед доской с нарисованной архитектурой и примагниченными бумажками с тестами модулей.

[syoma 1]

А может есть смысл подумать о MATLAB/Simulink - и особенно о StateFlow? Там как раз концепцию очень легко можно проработать и отладить. Даже если потом из этого не будет генериться код - все-равно будет полезно поизучать, как оно будет работать.

[ukpyr 0]

бред эти все диаграммы и UML.

гораздо проще записать просто списком по пунктам.

[walsv 0]

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

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

 

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

 

"алгоритм должен быть энергоэффективным" это что такое? чтобы не рубил пустые циклы что ли?, там где GSM, спутниковый канал, и ethernet можно не беспокоится за энергоэффективность.

 

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

Не скупиться на комментарии, названия процедур и функций и переменных и их сокращений выбирать по одному стандарту.

 

"Как планировать, как разбивать? Как прорабатывать концепцию?" - главное чтобы было написано ТЗ, не для кого то а для себя. Каждый пункт в ТЗ это и есть твоя разбивка. А концепция построения программы такая, что если начальник скажит все вывернуть наизнанку - то ты бы смог это выполнить. Т.е универсальность и гибкость. А по поводу "Как планировать" так c утра и до вечера, а читать нужно не книжки, а форум с какими проблемами сталкивались люди при реализации подобного набора ваших датчиков и оконечных устройств (MODBUS, GSM, спутниковый канал, и ethernet)

 

Насколько я вижу здесь корячится RTOS. (не хочу спорить, ваше дело, как решите так и будет)

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

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

 

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

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

[yanvasilij 0]

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

Книжка хорошая, фреймворк хороший. Сам фреймворк Q...

Использую dia для красоты и обыкновенную классную доску...

А может есть смысл подумать о MATLAB/Simulink - и особенно...

бред эти все диаграммы и UML.

...

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

...

 

Спасибо, за советы и высказанные мнения!

[ARV 0]

Понял что программы управления проектами и составления разных диаграмм - полная туфта и никак не заменят живого общения специалистов перед доской с нарисованной архитектурой и примагниченными бумажками с тестами модулей.

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

[Гость TSerg]

И как мы раньше обходились без UML:)

 

[fpgaz 0]

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

Обратите внимание на методологию SADT (IDEF0), которая как раз для этого и придумана. Хотя мне для программ порядка 10000 строк кода хватает 30-40 тетрадных листов и обычных блок-схем.

А методологий и языков помимо UML куча...

 

Но как применить UML к embedded на простом Си.

При такой постановке вопроса выходит, что UML применяется ради UML, а не ради решения задачи.

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

Внятная система имен - мощнейший инструмент.

Если программа или алгоритм плохо спроектированы, то это сразу будет заметно, так как пасьянс из структур данных не разложится, все корявости будут видны,

все несимметричности, натяжки и нестыковки засверкают.

Потом можно будет дополнить описание блок-схемами и временными диаграммами (если нужно).

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