UML Design *

Являюсь продуктовым дизайнером.

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

Часто ли сталкивались с подобным отношением в своей практике? Это что, стало некой нормой в обществе изнеженных додиков, и западная форма социальных отношений проникла и в наше общество, где нельзя сказать даже слова "петух" не то что относительно дизайнеров (кем они и являются по большей мере, как видно даже из примера про админов этих каналов) так ещё и к инфоцыганам?

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

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

Да. В интересное время живём с безумцами и ссыкунами, что боятся любой реакции, которая портит им восприятие их мирка.

Я написал этот гайд для использования аналитиками в компании (мы интегратор решений 1С в медицине), как настольная шпаргалка и некий базовый «стандарт унификации» формируемых диаграмм данного типа.

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

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

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

1. Не стройте иллюзий относительно IT курсов и рекламы

Без должного энтузиазма и желания развиваться в сфере UX/UI-дизайна, а также продуктового дизайна (далее по тексту – дизайн) курсы чаще не помогут вам достичь высоких результатов в форме высокооплачиваемых должностей на рынке дизайна. Рынок зарабатывает на том, что модно и всё ещё старается продать вам мечту о беззаботной работе с высокими зарплатами независимо от географии за относительно небольшую плату за курс. На мой взгляд это в большинстве случаев просто фарс и надувательство, эксплуатация модного явления и спекуляция разношёрстных подонков на этой основе. Вы сами должны достаточно сильно желать стать дизайнером, желать служить этому делу или какому-либо другому делу, чтобы начать путь без дополнительных стимулов и самообманов, мол вот сейчас куплю курс и это уже обяжет меня начать какой-то путь, ведь я потратил деньги, а значит должен начать проходить курс и стать дизайнером, ну или ещё какие-то подобные убеждающие себя предлоги.Если твоя цель служить профессии – шаблонные программы курсов часто не твой путь.

Если хочешь просто «влиться в тему» и работать на «галере» выполняя задачи механизмом системы, курсы – твой путь. Однако, есть случаи, когда и после курсов люди добивались высоких результатов в карьере. Всё неоднозначно и исключения есть всегда, однако общая практика и данность, на мой взгляд, такова.

От переводчика:

Я веду телеграмм‑канал, посвященный системному анализу, и провожу тренинги, и в какой‑то момент задался вопросом — а актуален ли сейчас UML? Если посмотреть обсуждения на SO, Reddit'e и в блогах — видно очень много постов в вопросом «Is UML Dead?». Я начал искать публикации на эту тему, и через некоторое время обнаружил этот пост, в котором были ссылки на статьи, которые я уже нашел, и ещё на некоторые, которых я до этого не видел. Мне показалось, это очень хороший сборник мнений, если вас тоже интересует судьба UML.

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

В основе сборки любых компонентов лежит общий шаблон того, как они выполняют прокидывание зависимостей, это концепция, которую разработчики называют очень общим именем Inversion of Control (IoC: инверсия контроля). В этой статье я углублюсь в то, как работает этот паттерн под более конкретным названием «Dependency Injection» (Инъекция зависимостей), и сравню его с альтернативой - Service Locator

Привет! Меня зовут Настя, я старший системный аналитик в X5 Tech. Я рисую sequence-диаграммы каждый день на протяжении четырёх лет. За это время я прошла все круги ада по Данте, то есть попробовала разные инструменты для рисования этих самых диаграмм. Пока не встретила его – PlantUML. 

Что удивительно, инструмент довольно не новый, но тем не менее лучше него я пока не встречала. А ещё удивительно, что он не особо популярный. Когда мы запустили в управлении системного анализа первый воркшоп по PlantUML, за 3 минуты после анонса пришли 12 заявок от аналитиков разных грейдов – от Junior до Lead. 

В процессе подготовки материалов к воркшопу мы искали статьи и литературу, которые помогли бы дополнительно изучить sequence-диаграммы в PlantUML. Ничего интересного мы не нашли. 

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

Поэтому и появилась эта статья. 

Привет, чемпионы!

Часто ли вы обращаетесь к Midjourney или Stable Diffusion, чтобы нарисовать фантастический арт? Я да - нравится позалипать пару минут на фантастический арт. Давайте сегодня учиться генерировать подобные пикчи за пару кликов:

Что такое диаграмма последовательности? Из чего она состоит? Где и как пользоваться?

Простым языком о sequence диаграммах.

А еще тут есть интересные возможности, о которых ты мог не знать.

Привет, меня зовут Сергей, я ведущий разработчик в DDoS-Guard и человек из мемов xkcd, который любит всё экстраполировать, истовый фанат визуализации данных. Диаграммы и графики решают кучу моих проблем с онбордингом джунов и объяснением задачи исполнителям. 

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

Сценарии использования ИИ для учебы на поверхности. Тот же ChatGPT как стандарт по умолчанию студенты (да и преподаватели тоже) используют для написания текстов (рефераты, курсовые, дипломы и тому подобное), для анализа данных, изучения языков и, конечно же, для решения задач. Поговорим же здесь про то, как можно использовать ChatGPT для обучения программированию. Типично, студенты и школьники «скармливают» чату условие своей задачки, а на выходе получают код программы на требуемом языке. Часто чат дает еще и объяснения основных моментов в коде, рассказывает про алгоритм. Так можно учиться программированию, имея под боком «умного» консультанта. Не всегда, правда, код чата адекватен, а решения полные. Но, это очевидные вещи. Попробуем тут составить список примеров, которые могут быть полезны и тем, кто изучает программирование и тем кто учит. Начнем с простого.

Хабр, привет! В прошлых статьях про UML (Часть 1, Часть 2) мы узнали что такое язык моделирования UML и зачем он нужен, а также рассмотрели диаграмму классов и диаграмму компонентов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме объектов.

Цвет имеет важное значение для человека, он влияет на его эмоциональное состояние, восприятие окружающего мира и самочувствие. Умение правильно использовать цвета позволяет создавать и поддерживать интерес к представляемой информации, а также положительно воздействовать на её восприятие.

В предыдущих частях статьи (часть 1 и часть 2) мы прикоснулись к теоретическим основам этих процессов и впоследствии рассмотрели множество полезных подходов к использованию цвета при анализе и проектировании информационных систем.

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

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

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

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

Такие схемы на проектах готовят наши архитекторы. Достаточно ли их чтобы оценить состав и сложность каждого модуля, объем и трудоемкость работ в целом. Поможет ли такая схема при планировании работ?

В статье рассуждение о том что могло бы помочь.

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

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

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

Настоящая публикация ставит перед собой целью сделать шаг вперёд в этом направлении.

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

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

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

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

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

В данной статье я попытался заполнить этот пробел и предложить своё видение решения.

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

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

Обзорная статья о QPR Enterprise Architect. Основные возможности и преимущества данного инструмента.

Хочу поделиться с вами Key skils Systems Analyst которые нашла и сформировала для себя, чтобы в дальнейшем можно было легко оценить свой знания по всем пунктам.