UML Design *

Привет! Меня зовут Даниил Нейман, я работаю в Positive Technologies в направлении развития инициатив ИБ-сообществ, где я активно занимаюсь поддержкой и развитием open-source-проектов и сообществ. Одна из наших целей — продвижение обмена знаниями между специалистами в области информационной безопасности.

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

Методы моделирования атак (attack modelling techniques), или AMT, используются для моделирования и визуализации последовательности событий, приводящих к успешной кибератаке на системы. Их можно разделить на три категории: 1. методы, основанные на диаграммах сценариев использования, 2. темпоральные методы (акцент на хронологическом порядке и последовательности событий в кибератаке) и 3. методы, основанные на графах.

В этой статье расскажу про первую категорию методов — на основе сценариев использования (use case methods).

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

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

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

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

Я веду телеграмм‑канал, посвященный системному анализу, и провожу тренинги, и в какой‑то момент задался вопросом — а актуален ли сейчас 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 которые нашла и сформировала для себя, чтобы в дальнейшем можно было легко оценить свой знания по всем пунктам.

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