Я иногда призываюсь экспромтом к электронной доске (нефактически) потоки данных, схемы архитектуры и т.д., и для технической и для нетехнической аудитории. К сожалению, мои навыки рисунка (и четкость печати) ужасны.
Как я могу стать более эффективным при выполнении этого? Я ищу подсказки относительно стандартных символов и коннекторов, чтобы использовать, некоторые стандартные способы организовать и категоризировать информацию (например, плавать маршруты), и т.д.
Что я могу практиковать для становления лучше в этом? Я хочу, чтобы эти визуальные представления были эффективными при выражении моих мыслей, и плохо представленные схемы могут заставить идеи казаться замысловатыми и неэлегантными, даже когда они не.
Белая доска - отличный инструмент. Я сам довольно часто этим занимаюсь, и я обнаружил, что несколько вещей очень эффективны:
Помедленнее.
Нет ничего плохого в том, чтобы писать аккуратно.
Довольно простой, но этот совет по рисованию мультипликационных речевых пузырей сделал для меня огромную разницу: не рисуйте прямоугольники, а затем пишите текст внутри них. Обычно вы неверно оцениваете требуемый размер, что приводит к сжатому и неразборчивому тексту. Вместо этого напишите сначала свой ярлык , а потом обведите его рамкой.
Я был поражен тем, насколько ясность моих диаграмм улучшилась благодаря применению этого одного простого принципа.
Еще один хороший совет для белой доски - взять с собой цифровую камеру и сделать снимок сеанса. Вы можете добавить это в общий доступ после собрания, и здорово иметь возможность таким образом просматривать прошлые сеансы.
Я часто пишу в Post It Notes, потому что вы можете легко перемещать их при обсуждении отношений между объектами. Кроме того, разные цвета Post Its могут передавать смысл.
Ниже приведен пример:
альтернативный текст http://www.matterco.com/wp-content/themes/matter/images/art057.jpg
Wiki содержит базовую информацию о различных диаграммах, которые могут подходить для разных сценариев.
Надеюсь, это поможет.
ура
Я сам большой поклонник языка галактического моделирования .
Вы знакомы с диаграммами ER? Если вы моделируете базу данных, диаграммы ER довольно универсальны для большинства людей.
Убедитесь, что у вас большая доска.
Чем крупнее, тем четче вы сможете детализировать свои идеи.
Я знаю, что многие программисты склонны думать о UML как «ту дурацкую чушь, которую они хотят, чтобы я вложил в документ, который никогда не будет рассматриваться», но на самом деле он был разработан для решения проблемы общения программистов.
Знайте UML, даже если это редко имеет значение, используете ли вы открытую стрелку или закрытую стрелку, потому что факт в том, что это запутает некоторых людей, если вы воспользуетесь неправильной стрелкой. Программисты - очень целеустремленные твари, и это одна из тех вещей, на которых им часто нравится «застревать».
Знать несколько основных типов диаграмм UML. Всем известен какой-то уровень диаграммы объекта, я часто совмещаю диаграммы наследования и включения в одном рисунке - не будьте слишком строгими.
Прочтите несколько блок-схем и создайте одну для сложного потока, над которым вы работаете. Они чертовски круты в анализе того, что происходит, и в передаче чего-либо, кроме тривиального вызова / возврата одного метода. Я не знал об этом примерно 1/3 своей карьеры и был просто ошеломлен, когда в первый раз кто-то выбросил один на доску (это было после того, как я все узнал, но, конечно, каждый год я узнаю больше, а затем решаю Я НАКОНЕЦ все знаю).
Наконец, вы стоите и разговариваете с этим человеком. На самом деле прямоугольник на белой доске - это просто то, на что вы можете указать, чтобы в следующий раз, когда вы на него укажете, человек понял, что вы имеете в виду то же самое ... это визуальный помощник для улучшения вашего вербального общения, вот и все.
Изменить:
Эта страница представляет собой хорошее введение в диаграммы последовательностей с множеством отличных примеров.
Диаграммы архитектуры «должны» быть в UML.
Однако.
Подробные диаграммы UML - головная боль, поэтому не углубляйтесь в технические подробности.
Однако существуют некоторые стереотипы классификаторов, которые очень и очень помогают, позволяя сводной диаграмме «высокого уровня» охватить ряд оснований.
«Стереотипы классов объектов» (см. http://doc.sumy.ua/prog/umld/AD970806.PDF ) для классов Control, Boundary и Entity на вес золота. Добавление этих стереотипов в диаграмму классов - полезный, быстрый и формальный способ определить, как класс (или пакет) вписывается в целое.