UML Design *

Угадаете, какое изобретение кардинально изменило жизнь человечества?

Культура никогда не стоит на месте. Искусство, в частности живопись, графика и скульптура, долгое время были плодом человеческого ума и вдохновения. И внутри него постоянно менялись язык и инструменты, благодаря которым художник мог выразить себя, своё ощущение исторического момента или же показать уровень достатка и интеллекта заказчика. Не будем забывать, что искусство долгое время было развлечением для аристократии (элиты, олигархии, буржуа - подставьте тот вариант, что вам ближе). Но постепенно всё начало меняться. Искусство становилось ближе к народу благодаря одному инструменту, который переломил историю человечества на до и после. И нет, это не искусственный интеллект. Это печатный станок Гутенберга. 

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

Привет!

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

Если хочет — может раскрыть больше деталей, если нужно наоборот — может скрыть избыточные.

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

Будет PlantUML, JavaScript, HTML и немного разочарования в ИИ :-)

P.S. Не смотрите на то, что читать статью якобы много-много минут. Текста там не много, все код виноват :-)

Введение

Многие из нас начинали с книг Роберта Мартина и свято верили: чистый код — это святое. Мёртвый код нужно безжалостно удалять, рефакторинг проводить каждый спринт, а технический долг — гасить немедленно. Эта догма впитывается с первых месяцев работы.

Но если вы когда-нибудь работали в проекте, который живёт больше пяти лет, в high‑load системе или enterprise‑среде, вы наверняка сталкивались с парадоксом: самые стабильные части системы — это те, к которым никто не прикасается годами.

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

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

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

В рамках исследования я проанализировал ведущий польский сайт (более 4000 вакансий) с вакансиями для IT-специалистов. Отобрал 194 вакансии, где полностью или частично выполняются функции системного аналитика, знакомые российскому рынку. Что получилось…

В этом исследовании я проанализировал крупнейший немецкий сайт вакансий (более 600 000 объявлений), чтобы определить роли, в которых полностью или частично выполняются функции системного аналитика.

В статье рассмотрены названия позиций, требования работодателей, зарплаты, распределение по индустриям и топ работодателей в Германии. Результаты представлены в виде графиков и сопоставлены с данными по рынку США.

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

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

Заставить профессионала работать? Да тут весь Agile построен на том, да и практика подсказывает, что все манифесты и принципы разработки дают как раз базис для того, чтобы ты развивался "без потолка" и имел свой профессионализм и никто тебя не заставлял работать.

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

А вот тут мы сейчас затронули интересный момент. Кто видел хоть раз, как работает команда профессионалов? Вот они и задают фреймворки, ну, или точнее, фреймворки писались с них.

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

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

Ну вроде бы, окрестили встречи, возвели значимость, дабы коварный зверь бизнеса понимал что,для,чего и зачем и не снес тебе встречу, поставив свою с девизом "я сейчас сам всем скажу как надо работать"-опс, даже корпоративную культуру внутри компании можно задвинуть, ведь даже ценности Agile есть, а от них можно, в интеграции с HR даже цифровизацию профилей задвинуть и тогда мы можем наложить примерно 2 картинки для того, чтобы понять, как и чем должен обладать кандидат (конкретно, что развивать и как связать с обучением в корп.академии и у провайдеров).

За две недели я собрал бесплатный веб-сервис, который генерирует диаграммы по текстовому описанию — без ручного рисования и без мучений с кривыми картинками от ИИ. Ключевая идея: вместо генерации изображений — генерация PlantUML-кода, затем серверный рендеринг в PNG и выдача пользователю. В статье рассказываю, как я проектировал сущности и сервисы, строил микросервисную архитектуру с очередями, поднимал PlantUML-server и MinIO, настраивал мониторинг и деплой, а также танцы с бубнами вокруг локальной LLM — и как меня спас старый ноутбук с GPU. Отдельно — про боль вайбкодинга: где ИИ-агенты помогают, а где требуют жёсткого микроменеджмента и шаблонов промптов.

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

Я покажу, как некоторые подходы из мира программирования (те самые best practices и идеи из Clean Code) помогают рисовать sequence-диаграммы чище и понятнее. 

С помощью ИИ вполне можно сгенерировать сайт‑визитку или игру в крестики‑нолики, составить план отпуска или сделать более сложные вещи. А как насчёт того, чтобы сгенерировать ПО для управления атомной станцией или самолётом? Или как насчёт планирования не отпуска, а проекта на сотни человеко‑лет? Это в принципе возможно и можно ли доверять результатам работы ИИ?

В статье сначала будет немного теоретических рассуждений на эту тему, идея банальная: сложные задачи нужно декомпозировать. Затем рассмотрим это на конкретном примере, разобьём разработку приложения для HR отдела на три шага: 1) описание процесса приёма сотрудников на работу, 2) описание модели состояний для кандидата при прохождении собеседований, 3) генерация кода.

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

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

Современная документация архитектуры должна решать множество задач одновременно. Она должна быть понятна разработчикам, архитекторам и бизнесу, поддерживать версионирование, интегрироваться в CI/CD процессы и оставаться актуальной.

ArchiMate — это язык моделирования архитектуры предприятия. Я часто о нём слышал, но никогда не пользовался. Он казался мне очень сложным с очень странной солянкой из разносортных объектов, с замороченным десктопным редактором. Изначально мы даже не рассматривали ArchiMate как первый кандидат на реализацию в нашем инструменте моделирования, а больше склонялись к моделям данных, C4, UML, BPMN. И добавили эту нотацию совершенно случайно. Но пока рисовали примеры моделей для статьи я просто обалдевал на сколько ArchiMate клёвый, какими гениями он придуман и зачем ИТ архитекторам могут быть нужны ещё какие‑то языки моделирования.

Мы попробовали описать разные аспекты нашего программного продукта в этой нотации от миссии и стратегической карты до сценария резервного копирования базы данных. В итоге у нас получилось что‑то среднее между небольшим руководством по ArchiMate и тупой неприкрытой саморекламой. Решайте сами полезно для вас это или нет. Статья получилась очень объёмная, смело пролистывайте не интересные разделы.

Сегодня я хотел бы поговорить об онтологии и сделать это так. Мы возьмём учебный пример - онтологию для пиццерии (Pizza Shop) - и на основе этого примера разберём основные термины, ключевые элементы онтологии и обсудим, чем этот подход отличается от привычных способов моделирования.

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

Всем привет! Мы добавили новую фичу в наш инструмент моделирования — текстовые представления для моделей. В статье я покажу что это такое и расскажу про детали реализации.

Привет! На связи Кнышенко Марина, системный аналитик Рунити. В этой статье мы попробуем сделать из UML универсальное средство общения, чтобы диаграммы помогали наладить диалог между командой и не лежали в архиве в качестве средства устрашения. Статья будет интересна системным аналитикам, которые ищут универсальные инструменты для работы и хотят настроить коннект с командой. 

UML — унифицированный язык моделирования… На втором слове коллеги заснули. На практике из академического определения можно запомнить, что UML — это язык. Язык необходим для передачи мыслей от одного человека к другому. Точно также на языке UML можно составить синтаксически верное описание системы, пустив в дело весь доступный арсенал «стрелочек» и «квадратов», но эти многоэтажные диаграммы так никто и не поймет.

Всем привет! Продолжаем делиться тем как мы разрабатываем наш инструмент моделирования. К предыдущей статье было много вопросов о том можно ли модели хранить и редактировать в текстовом виде, как насчёт architecture as code, code first и т. д. Мне хотелось бы написать, что мы добавили эту фичу в текущем релизе, но нет, пока есть только такая демка с исходниками. И в этой статье я расскажу как она сделана, как запилить свой предметно‑ориентированный язык (DSL) и текстовый редактор для него.

Сегодня я хочу поделиться глубоким исследованием того, как применять золотое сечение в современном дизайне 2025 года. Эта статья основана не только на теории, но и на реальном опыте работы с крупными проектами, A/B тестах и исследованиях пользователей.

Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Несмотря на то, что UML-диаграммы являются популярным и востребованным инструментом, не все системные аналитики используют его в своей работе. Одной из причин может быть непонимание пользы для требований и проработки задачи.

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

Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Наверное многие хотя бы раз сталкивались с диаграммой, которая сделала процесс более понятным. И с диаграммой, после которой пришлось перечитывать описание процесса еще не раз. Грамотная модель делает требования более качественными, а некорректно построенная модель может привести к непониманию хорошо проработанной документации.

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

Системный аналитик как термин в США почти не используется. Если вы просто наберёте "System Analyst", то в 9 из 10 случаев увидите совсем не то. Либо вакансии из финансового сектора, либо вообще нечто около-административное.

Так кто же тогда делает ту работу, которую в России выполняет системный аналитик?