Перейти к содержанию
    

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

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/ - очень приятная рисовалка, с возможностью делиться ссылками.
Изменено пользователем p_v

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Скажем честно - все эти инструменты просто попытки приблизиться к Visio.

Каждый из них решает часть работ которые все может сделать один Visio.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем p_v

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

Это тот случай когда инструмент учит технологии.

Да все продвинутые инструменты выполняют такую функцию.

 

Не даром тут UML всплыл.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Скажем честно

 

1. Кто вам дал право определять, что есть честно?

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот я и хочу спросить, кто в каком редакторе составляет такие диаграммы? Может быть, хотя бы для чисто софтовых проектов?

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Кто вам дал право определять, что есть честно?

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

Ну так для того и обсуждаем.

Или будем обсуждать обсуждение?

Вы тоже имеете право применять риторику. :laughing:

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

Редактор решает все!

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

 

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

 

Показанный там вами по ссылке автомат состояний только доказывает это.

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

Это по сути снипет, а не проект.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

 

<tl;dr>

 

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

 

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

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

 

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

Изменено пользователем p_v

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Теперь пройдемся еще раз по диаграммам. А точнее, по диаграммам данных (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) типа такого:

51bddb5cf24465ca56fc6f64e578702b.png

 

А пока поспорю относительно ваших представлений о проектировании дивайсов такого рода.

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

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

Второе, привлекать Mind map в данном случае поздно ибо TC уже перешел на уровень детализации. Mind map скорее средство сосредоточения на задаче людям с синдромом дефицита внимания.

Далее про диаграммы логики работы софта. Не путаем DSP алгоритмы и машины состояний. Они моделируются (а не рисуются как у вас) совершенно в разном стиле.

В данном проекте речь о проектировании машины состояний. Она проектируется так:

post-2050-1529349856_thumb.jpg

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

Потоки данных тут не при чем.

А вот в DSP алгоритмах работаем с данными, но не с потоками, а с типами и сэмплированием. И там будут фреймы, вектора, матрицы, буфера и проч. И тоже делаем модели, а не рисунки.

На рисунки студенты могут тратить время, а инженера держат не за рисование.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...