Size: a a a

Архитектура ИТ-решений

2020 November 18

MV

Mikhail Velkin in Архитектура ИТ-решений
cейчас на диаграмме насчитывается порядка 40 вершин 10 разных типов и 6 типов связей между ними. постепенно начинаю теряться в диаграмме, что явно не способствует качеству отображаемой информации. хотелось бы иметь возможность включать и выключать отображение узлов и связей, чтобы иметь возможность рассмотреть диаграмму и, по необходимости, добавить новые узлы/связи
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
в draw.io есть поддержка изменения свойств видимости через встроенный js

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

НО. в общем случае, это не очень удобно. Я бы рекомендовал упрощать\группировать. Перефразируя "нет такой конструкции, которую нельзя изобразить максимум 10-15 квадратиками и одним видом стрелочек".
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
но если очень хочется, то вот

https://drawio-app.com/interactive-diagrams-with-custom-links-and-actions/
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
а так есть тулзы для моделирования, думаю что накидают пяток сейчас.
Но у них есть одна проблема - прочитать потом диаграмму может только человек (или роль), её создавший. То есть, диаграмма в 99% случаев бесполезна
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Alexey Pryanishnikov
в draw.io есть поддержка изменения свойств видимости через встроенный js

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

НО. в общем случае, это не очень удобно. Я бы рекомендовал упрощать\группировать. Перефразируя "нет такой конструкции, которую нельзя изобразить максимум 10-15 квадратиками и одним видом стрелочек".
1. Есть аналогичная фича в LucidChart (actionable элементы + управление видимостью)
2. Во многих продвинутых mindmap managers, насколько помню, была функция фильтрации / скрытия на основе свойств (но не уверен, что прямо до уровня кастомных классификаторов)
3. Я видел похожие идейно проекты, где серьезно кастомизировали / обвешивали своим кодом MS Visio, для создания разных специфичных визуальных редакторов
4. Возможно, кто-то работал с Flying Logic? На уровне "слышал со стороны", там очень мощный движок диаграмм. Сам был бы рад узнать подробнее, никак не найдется достаточно поводов себе поставить ))
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Mikhail Velkin
Всем привет. Может кто-то подсказать инструмент для описания предметной области через направленную сеть? Нужна возможность типизировать связи, разделить все узлы по типам/категориям, возможность управлять видимостью узлов и связей как слоями в зависимости от типа/категории узла. Столкнулся с тем, что возможностей визио и draw.io уже не хвататет. слишком много объектов и типов/категорий узлов. Хотелось бы отобразить связи между всеми узлами как на горизонтальном уровне, так и между уровнями. Разносить всё это на 100500 разных диаграмм считаю нецелесообразным.
у Sparx EA можно настраивать несколько фильтров на диаграму и управлять видимостью объектов.
как минимум удобно отображать as is -> to be, или фильтровать по версии или по отвественности за компоненты/связи.
источник

SL

Sergey Lukin in Архитектура ИТ-решений
источник

PS

Petr Shmotov in Архитектура ИТ-решений
Sergey Lukin
у Sparx EA можно настраивать несколько фильтров на диаграму и управлять видимостью объектов.
как минимум удобно отображать as is -> to be, или фильтровать по версии или по отвественности за компоненты/связи.
Можете поподробнее про это рассказать? А, увидел ссылку, ушел читать
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Petr Shmotov
Можете поподробнее про это рассказать? А, увидел ссылку, ушел читать
источник

AG

Andrei Gordienkov in Архитектура ИТ-решений
Кстати, около месяца назад, тут пролетало сообщение об участии в Архитектурных Катах от Орейли. Кто-то участвовал?
источник

p

pragus in Архитектура ИТ-решений
В конце 2019 года Boeing впервые за 22 года отчитался о чистом годовом убытке. В компании спрогнозировали, что общие потери, связанные с катастрофами 737 MAX, составят не менее 18 миллиардов долларов.

по $8 индусов разработчиков покупали

могли на 18 миллиардов долларов купить 2.25 миллиарда часов

или 1 миллион разработчиков писал бы код 6+ лет каждый день без выходных.
источник

GM

Gerr Mes in Архитектура ИТ-решений
Топы получили свои бонусы за снижение издержек на предыдущем этапе, убытки национализируют, на пассажиров плевать - добро пожаловать в постмодерн
источник

N

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

AG

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

N

Nikolay in Архитектура ИТ-решений
Alex Glazunov
Нет, там ошибка принципиальная, в системе управления (если не говорить о дизайне самолёта  вообще). В условиях, когда пилот не может парировать отклонение стабилизатора штурвалом, и не может достаточно оперативно переставить вручную стабилизатор, который двигается автоматикой, это вопрос времени, когда именно и почему возникнет ситуация, при которой стабилизатор в "неправильном" положении. В данном случае был сбой логики автоматики, но может быть и механический отказ и человеческий фактор... Из-за этого и другие самолёты разбивали, даже где стабилизатор не двигался автоматикой.
А кто виноват? Программисты или конструкторы ?
источник
2020 November 19

AG

Alex Glazunov in Архитектура ИТ-решений
И те и те, но наверное, больше конструкторы. Они втиснули новый двигатель в старый самолёт, спроектировав при этом "костыли", которые оказались тонким местом. Причем как я уже сказал, из-за стабилизатора и на старом самолёте были катастрофы, в том числе в России. Отличие только в том, что раньше пилот слишком поздно понимал, что со стабом что-то не так и ситуация развивалась довольно быстро. А с 737MAX все уже все поняли, летели десятки минут и ничего не могли сделать, тупо боролись против робота.
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Вроде на хабре была подробная статья на эту тему
источник

AD

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

SL

Sergey Lukin in Архитектура ИТ-решений
немного offtopic, поэтому прошу без флейма, а только ссылками
Встречались ли вам статьи / исследования которые говорят что "выгорание" -  это чушь и люди просто не хотят думать и работать?
источник

AC

Andriy Cherneha in Архитектура ИТ-решений
Колеги, поделитесь, плз, мыслями/мнениями: является ли сторед-процедура в базе данных АРІ?
источник