Русский
Русский
English
Статистика
Реклама

Case

Tru3bic0n корпус в кубической орбитальной пространственной раме

26.02.2021 12:14:08 | Автор: admin

" Вы вообще очень странные существа, наконец сказал визирь. Вы даже устроены удивительно у вас мягкие ткани тела торчат наружу, а кость находится глубоко внутри.
А что тут такого? опешил я.
Нет логики, сказал кубарь. Логично, когда организм защищает панцирем свои мягкие ткани от внешней среды. Но какой смысл держать кости внутри организма, окружив их мягкой ранимой тканью? Словно вас раздирает что-то изнутри, словно вы опасаетесь агрессии изнутри больше, чем от окружающей среды." -- Леонид Каганов (рассказ 'Там где нет ветра')

Примерка для инкапсуляции. Слева направо - двойной RaspberryPi 4B, nVidia Jetson Nano B01, Intel NUC gen11.Примерка для инкапсуляции. Слева направо - двойной RaspberryPi 4B, nVidia Jetson Nano B01, Intel NUC gen11.

История tru3bicon

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

Суть tru3bic0n

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

Описание tru3bic0n

Итак, рассматриваемый корпус представляет собой объект класса Евклид своеобразный "кубик в кубе" - внутренний куб имеет сэндвичную структуру, будучи разделен на 2 подошвы теплообмена и картридж с инкапсулированной электроникой и вмонтирован диагональными ребрами во внешнюю орбитальную кубическую раму. Форма куба концептуально являет собой базовый не бионический элемент, который многим близок с детства - от наборов разноцветных кубиков, через кубические игральные кости, до культового кубика Рубика. Наиболее рациональными материалами для формирования данного корпуса сейчас видятся сплавы алюминия, магния, меди.

Применение tru3bic0n

Наболее целесообразными кейсами наполнения нового корпуса представляются одноплатники - туда с легкостью размещаются всевозможные Pi-образные платы с обилием обвязки и коннекторов. Также корпус представляется интересным для инкапсуляции системных плат микроПК, микроворкстейшнов, микросерверов. Не исключены и кейсы удобной инкапсуляции высокопроизводительной периферии - внешних видеокарт, сопроцессоров нейрокомпьютинга, asic-майнеров.

Контекст tru3bic0n

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

Технологии tru3bic0n

На ранних итерациях для небольших партий - наиболее продуктивным способом изготовления представляется вытачивание рамы из монолитных заготовок посредством ЧПУ-фрезерования. В мелкосерийном производстве для оптимизации потерь времени/материала/оснастки целесообразными выглядят технологии литья в заполняемую форму по SLA 3D-печатным испаряемым моделям и металлическая 3D-печать по SLM-процессу. Относительно картриджей для электроники - пока вполне здравим смотрится планомерный путь от полимерной SLA/DLP/LCD 3D-печати, через двухкомпонентное литье в силиконовые формы, к штамповке пластиком в пресс-формах под давлением.

Ценность tru3bic0n

Специфика применения корпуса расчитана на LTS-эксплуатацию, что позволяет в некоторой степени перейди от деструктивных потребительских паттернов запланированного/преждевременного/краткосрочного устаревания к внетрендовому/переиспользуемому/долгосрочному применению корпусов высокопроизводительной электроники. Единожды произведенный корпусной базис способен прослужить десятки лет, устранить потребность в быстроизнашивающихся механических системах воздушного/водяного/испарительного охлаждения, снизить расходы времени/химии/инструментов на очистительные мероприятия - что уже немалый профит в экологическом плане. Ну а по мере распространения такой корпусной концепции, процесс обновления устройств сводится к замене компактных картриджей с электроникой, что существенно упростит логистические цепочки поставок электроники.

Планы tru3bic0n

Сейчас концепция корпуса еще довольна сыра и поверхностна, но если вектор фидбека окажется в позитивном ключе - планирую интенсивную проработку/дополнение/исправление. Относительно реализации, на данный момент есть только FDM-напечатанные габаритные модели - запланированные посредством ЧПУ-фрезерования прототипы из Д16Т отложены на март/апрель/май по причине тотального отстуствия в ДефолтСити вменяемых розничных поставщиков крупных алюминиевых заготовок, прототипы посредством литья через выгораемые модели пока малореальны по факту отсутствия у потенциальных изготовителей SLA-3D-принтеров с достаточно крупной рабочей камерой, прототипы посредством SLM-3D-печати теплопроводящими сплавами еще нецелесообразны по факторам чрезмерных затрат времени и ресурсов, которые требуются для этой сыроватой технологии. Буду рад любой конструктивной критике концепта, любым рацпредложениям по конструктиву, любой полезной информации для совершенствования корпусировки.

Сопоставление габаритов Raspberry PiСопоставление габаритов Raspberry PiСопоставление габаритов Jetson NanoСопоставление габаритов Jetson NanoСопоставление габаритов Intel NucСопоставление габаритов Intel Nuc

"- Куб значит частица куб значит воксель куб значит пиксель куб значит цель куб значит выбор куб значит свобода куб значит жизнь куб значит всё...
- Куб начинается и куб заканчивается я живу ради куба - у жизни нет другого смысла и у жизни есть смысл - смысл значит куб.
- Жизнь бессмысленна без цели, а у меня есть цель - у меня есть куб!" -- я (небольшая графоманская импровизация на тему философии кубарей в scp-стиле)

Подробнее..

Recovery mode Очередной Wi-Fi Jammer на Очередной ESP8266

17.05.2021 18:06:47 | Автор: admin

Предупреждение ( некий АХТУНГ, так сказать)

Я не являюсь автором ПО и, тем более, не зазываю Вас повторять подобные устройства, так как это может быть запрещено законом и преследуется наказанием. Спасибо.

Вступление

Я в свои практически 20 лет (на момент написания статьи - через 3 дня) уже как года 4 слежу за всякими интересностями на Ардуино и околоАрдуинных платах для разработки. Сначала купил Нанку, с которой не понимал, что делать, потом поступил на разработку ПО и начал понимать, шо да как. От этого мой интерес увеличился настолько, что это стало моим хобби. Да, я не силён в программировании до сих пор, так как я банально прогуливал пары, но зато у меня есть база, так сказать основа, с помощью которой я снова вхожу в программирование через визуализирование этого во всяких поделках на Ардуино и им подобных. Мне не нравилось программирование из-за того, что результат ты увидишь далеко не сразу, а с помощью микроконтроллеров этапы готовности можно посмотреть прямо на глазах, да и потрогать, пощелкать, попереключать.

Перейдем к железу

По железу все банально и просто: Китайский клон Wemos D1 Mini на базе ESP8266, I2C дисплейчик 128х64 и две кнопки, которые я вырвал с китайской магнитолы. В оригинале их 3, но у меня не влазило в корпус, поэтому решил оставить только кнопку "ок" и "вниз", так как если долистать меню до конца, то указатель начнет с самого начала. Да, больше времени уходит на листание менюшек, но зато компактнее .

Прошивка

Прошивку можно скачать по ссылочке ( ТЦ )

Так же там имеется подробная инструкция для таких, как я XD

Я не буду заостряться на подробностях настроек до прошивки, в конфиге все банально ясно. Есть два вида файлов: .bin, который шьется NodeMCU Flasher и исходный код со скетчем ардуино. Я использовал скетч, что бы настроить подключение дисплея, переназначить кнопки и изменить названия.

Корпус

Изначально я раскурочил старый 3G модем от МТС (который сейчас в Украине Vodafone), вырезал отверстия под дисплей и кнопки. Ровно после финальной сборки я понял, что выглядит не очень: кривые вырезы, лишние размеры для дисплея, болтающиеся кнопки, корпус плохо закрывался, питание подключалось путем разгибания нижней части корпуса. Короче, не комильфо. Надо думать что-то новое.

Новый корпус и формфактор.

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

По размерам устройство получилось 3х4см с учетом вылета кнопок с корпуса. И это меня очень радует. У меня не было конкретной цели собрать джаммер, я просто хотел своими руками сделать какое-то крутое устройство, да и еще в подобных размерах.

Возможности

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

  • Сканирование сетей и устройств ( если они подключены к сетям) с последующим просмотром количества отправляемых пакетов, MAC-Адреса и мощность сигнала.

  • Атака путем деаутентификации как полностью всей сети, так и конкретного устройства по MAC-адресу

  • Режим "Бекон", который создает до 80 точек доступа, названия которых можно скопировать с существующих сетей, записать свои или создать с помощью встроенного генератора.

  • Режим "Probe" с которым я так и не разобрался, да и фиг с ним )

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

Выводы

Хоть моей целью не было воспроизведение конкретно этого устройства - результатами я очень доволен, так как это моё первое самодельное устройство, размеры которого не превышают распределительную коробку из строй магазина за 15 гривен

P.S. Чуть позже запишу видео, как сие чудо техники работает на примере своей точки доступа и ноутбука

Подробнее..

PostgreSQL Antipatterns скованные одной цепью EXISTS

14.12.2020 14:08:42 | Автор: admin
Я уже как-то рассказывал про особенности вычисления условий в SQL вообще и в PostgreSQL, в частности. Сегодня продолжим тему и попробуем написать и пооптимизировать простой запрос у кого из сотрудников есть на выполнении суперприоритетные задачи.

CREATE TABLE task ASSELECT  id, (random() * 100)::integer person -- всего 100 сотрудников, least(trunc(-ln(random()) / ln(2)), 10)::integer priority -- каждый следующий приоритет в 2 раза менее вероятенFROM  generate_series(1, 1e5) id; -- 100K задачCREATE INDEX ON task(person, priority);

Слово есть в SQL превращается в EXISTS вот с самого простого варианта и начнем:

SELECT  *FROM  generate_series(0, 99) pidWHERE  EXISTS(    SELECT      NULL    FROM      task    WHERE      person = pid AND      priority = 10  );


все картинки планов кликабельны

Пока все выглядит неплохо, но

EXISTS + IN


тут к нам пришли, и попросили к супер отнести не только priority = 10, но еще и 8 и 9:

SELECT  *FROM  generate_series(0, 99) pidWHERE  EXISTS(    SELECT      NULL    FROM      task    WHERE      person = pid AND      priority IN (10, 9, 8)  );



Читать стали в 1.5 раза больше, ну и на времени выполнения это сказалось.

OR + EXISTS


Давайте попробуем воспользоваться нашим знанием, что встретить запись с priority = 8 много вероятнее, чем с 10:

SELECT  *FROM  generate_series(0, 99) pidWHERE  EXISTS(    SELECT      NULL    FROM      task    WHERE      person = pid AND      priority = 8  ) OR  EXISTS(    SELECT      NULL    FROM      task    WHERE      person = pid AND      priority = 9  ) OR  EXISTS(    SELECT      NULL    FROM      task    WHERE      person = pid AND      priority = 10  );



Обратите внимание, что PostgreSQL 12 уже достаточно умен, чтобы после 100 поисков по значению 8 делать последующие EXISTS-подзапросы только для ненайденных предыдущими всего 13 по значению 9, и лишь 4 по 10.

CASE + EXISTS + ...


На предыдущих версиях аналогичного результата можно добиться, спрятав под CASE последующие запросы:

SELECT  *FROM  generate_series(0, 99) pidWHERE  CASE    WHEN      EXISTS(        SELECT          NULL        FROM          task        WHERE          person = pid AND          priority = 8      ) THEN TRUE    ELSE      CASE        WHEN          EXISTS(            SELECT              NULL            FROM              task            WHERE              person = pid AND              priority = 9          ) THEN TRUE        ELSE          EXISTS(            SELECT              NULL            FROM              task            WHERE              person = pid AND              priority = 10          )      END  END;

EXISTS + UNION ALL + LIMIT


То же самое, но чуть быстрее можно получить, если воспользоваться хаком UNION ALL + LIMIT:

SELECT  *FROM  generate_series(0, 99) pidWHERE  EXISTS(    (      SELECT        NULL      FROM        task      WHERE        person = pid AND        priority = 8      LIMIT 1    )    UNION ALL    (      SELECT        NULL      FROM        task      WHERE        person = pid AND        priority = 9      LIMIT 1    )    UNION ALL    (      SELECT        NULL      FROM        task      WHERE        person = pid AND        priority = 10      LIMIT 1    )    LIMIT 1  );



Правильные индексы залог здоровья базы


А теперь зайдем на задачу совсем с другой стороны. Если мы точно знаем, что тех task-записей, которые мы хотим найти, в разы меньше, чем остальных так сделаем подходящий частичный индекс. Заодно сразу перейдем от точечного перечисления 8, 9, 10 к >= 8:

CREATE INDEX ON task(person) WHERE priority >= 8;

SELECT  *FROM  generate_series(0, 99) pidWHERE  EXISTS(    SELECT      NULL    FROM      task    WHERE      person = pid AND      priority >= 8  );



В 2 раза быстрее и в 1.5 раза меньше пришлось читать!

Но ведь, наверное, вычитать сразу вообще все подходящие task сразу будет еще быстрее?..

SELECT DISTINCT  personFROM  taskWHERE  priority >= 8;



Далеко не всегда, и точно не в этом случае потому что вместо 100 чтений первых попавшихся записей, на приходится вычитывать больше 400!

А чтобы не гадать, какой из вариантов запроса будет более эффективен, а знать это уверенно пользуйтесь explain.tensor.ru.
Подробнее..

Хорошие BPM инструменты, которых нет и нет. Моделирование процессов

12.03.2021 20:06:18 | Автор: admin

Поговорим о том, какие инструменты хотелось бы иметь при описании бизнес-процессов. Инструментов BPMS (BPM systems) много, но выбрать то особо нечего

Ниже перечислим некоторые важные инструментальные возможности некоторых сред моделирования процессов (в основном АРИС-ARIS и MS visio).

Уточнения. BPM (business process management, управление бизнес-процессами) - это тот, который из области системной инженерии (SE), который почему-то теперь называют BPA (анализ). Он же CASE, где S= "system" (не "software").

"Бизнес-процесс" - это синоним "процесс" и даже таким терминам как: операция, действие, активность, функция, процедура. Приставку "бизнес" указывают, чтобы отличать процессы класса "административные" - "деловые" (см. BPM CBOK) от химических и физических (других "природных") процессов. Любой процесс, который реализуется человеком или компьютером (программой, роботом), - это "бизнес-процесс", несмотря на то, что непосредственно к "бизнесу" отношения может и не иметь. Настолько вот запутан этот BPM, хотя в реальности он прост.

Задача

Она очень простая. Нужно простым образом формализовывать процессы, нас окружающие. Так формализовать, чтобы модели процессов были адекватны реальным процессам, но чтобы их визуализацию хоть как-то понимало большинство людей, первый раз слышащих слово "BPM". Формально "интуитивно понятных" BPM-нотаций - много (также как много рекламно-маркетингового шума о BPM), но взять особо нечего. Однако здесь важна не только сама нотация (IDEF\VAD\EPC\BPMN\UML и т.п.), а механизмы ее представления на экране: слои, вариативность "точек зрения" (view-шек, представлений) и т.п. На мой взгляд, лучшим вариантом пока остается EPC (Event-driven Process Chain), но не суть, - представленные ниже подходы могут применяться к другим нотациям.

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

1. Подходы к визуализации диаграммы

1.1 Слои модели

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

Нарисовал нам наш архитектор (специалист по моделированию процессов) схему:

Рис. 1 Процесс оформления заявления

Visio Stencil Library for EPC - не нашел, поэтому "как то так" (штатная EPC - вообще "никакая").

Смотрят пользователи (Работник, Начальник, бизнес и системные аналитики) на схему и понять не могут, что нарисовано то и как этот процесс работает. Соглашение о моделировании прочитали, обучающие ролики посмотрели, но все равно не понятно.

Путь к пониманию - это упрощение схемы, например, будем отключать слои. В правильном инструменте (BPM-Tool) должны быть кнопки управления слоями - категориями. По кнопке "отключить ресурсы" - будет скрыт слой "ресурсы", в котором показаны объекты схемы (модели) типа "Роль" {Работник; Начальник} и Инструмент {MS Word}. Уже схема стала менее нагруженной (правой части не стало).

Далее отключаем слой "Документооборот" (docflow) и остается только последовательность действий (workflow, Process Flow), который говорит, что нужно провести всего две операции.

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

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

Пример такой реализации возможен в MS Visio:

Рис. 2 Управление слоями в MS Visio

Инструмент управления слоями, как управление сложностью - давно норма в векторных графических редакторах, ГИС и других CAD-системах, например, AutoCAD.

1.2 Плавательные дорожки

Swimlane позволяют группировать процесс по разрезам "Исполнители" и "Инструменты" (в общем случае - в разрезе любой иной категории объектов).

Применительно к Рис. 1 "Процесс оформления заявления": отключили слой "документы", а оставшуюся часть (функции и ресурсы) представили в виде одной или двух Swimlane (опять же "по кнопке").

Рис. 3 Swimlane по ролям в горизонтальной плоскости

Применительно к рассматриваемому случаю возможны следующие комбинации Swimlane:

- две одинарные (горизонт, вертикаль) по ролям;

- две одинарные (горизонт, вертикаль) по инструментам (часто в разрезе баз данных показывают);

- две двойные, "шахматка", таблица (горизонт - роли, вертикаль - инструменты и наоборот).

"Дорожки" помимо того, что позволяют создать другое (альтернативное) представление процесса (смена представления иногда играет решающую роль в понимании процесса), обеспечивают сортировку по указанным категориям, что позволяет быстро и просто найти: где применяется такой-то инструмент и где "нужно поработать" такому то исполнителю (роли).

Основная проблема "дорожек" в том, что когда "дорожки" не нагруженные, то "съедается" основная часть листа и плотность "упаковки" объектов в модели процесса становится мизерная (КПД бассейна, где загружены только две дорожки, а остальные пустые - низкое).

1.3 Объекты модели и их атрибуты, свойства

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

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

В Visio это могут быть данные фигуры и таблица свойств фигуры (ShapeSheet). Еще интереснее свойства хранить в отдельном файле Excel , например, связанном с visio (штатная функция visio). Такой подход позволяет иметь репозитарий свойств объектов в файле Excel и соответственно обширные инструменты поиска, сортировки и т.п. Любой BPM инструмент, включая АРИС, не имеет таких развитых возможностей для анализа как Excel , поэтому выгрузка в Excel интересуемой пользователя атрибутики была бы важным элементом любого BPM-инструмента.

При просмотре схемы процесса должна быть возможность выделения объекта и просмотр атрибутов схемы и ее объектов (с наложением фильтров, т.к. иначе будет избыток).

1.4 Задание своей нотации (на примере новой ЕРС ver. 2)

Посмотрим на примере нотации ЕРС. Что же в ней улучшить? Все улучшения запишем в гипотетическую ЕРС2 нотацию.

Есть предубеждение, что Событийная цепочка процессов обязательно должна иметь строгое чередование "функция" - "событие". Это не так: события указываются только тогда, когда это действительно нужно.

Вообще, от workflow (схема алгоритма) ЕРС отличается в основном двумя параметрами: наличие указания ресурсов и документов (материалов) и иное задание условия разветвления алгоритма (ветвление по условию). Использование элемента "событие" - как указание результата, вместо "да" и "нет" - более функциональное и позволяет кроме того сократить номенклатуру графических примитивов. Событие - как "что-то произошло" и событие - как результат проверки условия.

Как показано в п. 1.1 "Слои модели": выделяем зону docflow, EPC-workflow и ресурсную зону. Docflow, а также любые другие входы и выходы функции (включая материалы, заготовки, полуфабрикаты и конечные продукты) - отображаем слева от функции (отдельная стрелка для всех входов, отдельная для всех выходов) с соответствующим направлением движения, а все ресурсы - справа от функции (без направленных коннекторов). Это позволит иметь стандартный "взгляд" на процесс и сразу фокусироваться на конкретной зоне.

В ЕРС2 будет классификация моделей: приведенная и мультиресурсная. В приведенной схеме будет к каждой функции привязано не более одной роли (инструмента), чтобы была однозначность по исполнителю (инструментарию), что важно не только для анализа, но и при построении Swimlane (каждому "пловцу - исполнителю" по выделенной дорожке).

Возможность задания своей нотации в инструменте моделирования означает подсказку (блокировку) при некорректном построении модели, как в момент отрисовки, так и через проверочный отчет построенной диаграммы. Например, в ЕРС2 предусматриваются следующие типы коннекторов: для входящих сущностей (входящие документы, материалы-заготовки), для выходящих (исходящие документы, продукты операции), соединитель потока (функции, события), соединитель ресурса. В объекте "функция" предусматриваются три "Connection Point" (visio):

- вверху и внизу объекта "функция" (и "события") - для указания структуры потока (очередность действий, событий);

- слева в овале "функция" два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);

- справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.

Такой подход позволит легче читать схему ЕРС, сегодня же "глаза разбегаются", когда видишь паутину и вперемешку разбросанные а) "роли" - и слева и справа функции и б) "документы" - и слева и справа функции.

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

Вопрос: кроме как в visio, где можно задавать новые нотации и делать проверки на соответствие (валидность), аналогичные показанным выше?

1.5 Из таблицы - схему, а из схемы - таблицу

Если посмотреть на ЕРС схему (рис. 1), то видно, что она однозначно задается таблицей. Поля таблицы: вход, выход, функция, исполнитель, инструмент. Заполнили табличку, нажали кнопку "построить" - и схема сгенерировалась. Справедливо и обратное: по нарисованной схеме можно построить адекватную табличку без потери информации (lossless).

Механизм "Из таблицы - схему" в ARIS \ ARIS Express называется Smart Designer. Только он не умеет строить ветвление процесса. На всякий случай: поиск по "ARIS Smart Designer EPC", закладка "картинки".

Преимущества: человек, вообще не знающий нотации (ни одной), по простым правилам заполнил табличку и сгенерировал "по кнопке" схему процесса. Более того, возможно итерационно: вначале заполнил поле "функция" (оно же и "событие", - только с указанием соответствующего признака) - увидел "ствол" функций и событий (магистраль потока, workflow), а потом начал наращивать их левые (вход\выход) и правые (ресурсные) связи.

Можно предусмотреть в таблице отдельное поле "полное описание функции" с подробным (большим, т.е. не влезающим в надпись) описанием операции, отображаемое на диаграмме в виде, например, всплывающей подсказки (или в отдельном окне) при активации конкретной функции (при наведении мышью).

Концептуально изложенный подход близок к выделенной в АРИС нотации "табличная ЕРС" (см. "Нотация ЕРС в виде таблицы"), но здесь реализация в виде обычной текстовой таблицы, т.е. ближе к ARIS Smart Designer. Причем логику процесса также можно указать в составе таблицы, например, как ссылка на предшествующий объект (этого нет Smart Designer, но не сложно добавить "что-то" для ЕРС2). Таблицу можно вставлять в текстовые регламенты word и макросом (VBA) генерить схему процесса ("не отходя от кассы") с дублированием конечно в общем каталоге моделей.

В теме автоматического создания диаграмм из таблицы (особенно Excel) нельзя обойти MS Visio Data Visualizer. Как обычно, - идея "на отлично" (идея далеко не новая), но реализация Видимо в погоне за максимальным универсализмом "выплеснулся ребенок BPM". Я ожидал увидеть что-то такое же простое, функциональное (мощное) и BPM-ориентированное как ARIS Smart Designer. Может это впечатление сложилось из-за отсутствия мастера автопостроения EPC. Кроме того, исключительная модель по подписке не позволяет популяризацию инструмента.

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

1.6 Из скрипта - схему, а из схемы - скрипт

Подход аналогичный генерации схемы по таблице (см. п. 1.5.), только используется язык, наподобие plant uml \ dot (graphviz). Структурные схемы (другие с простой нотацией) и UML строить уже можно, но вот EPC (лучше EPC2, т.е. задание языком специфических правил нотации) и другие со сложной нотацией - нет (красиво не получилось).

Применительно к graphviz: в случае, когда репозитарий объектов хранится в Excel, можно автоматически генерировать схемы, используя инструменты типа: Excel to Graphviz (sourceforge.net).

Пример простого VAD из dot:
digraph g {

rankdir=LR;

node [shape = cds];

Step1 -> Step2 -> Step3 -> Step4;

}

Посмотреть схему можно, вставив код в окно "Online Graphviz Generator":

http://fiane.mooo.com:8080/graphviz/

Кстати, редкий Online Graphviz понимает несокращенный набор параметров спецификации.

Кратко: LR - говорит, что схема строится "слева - направо" (для EPC ставим "сверху - вниз"), cds - это код объекта в виде "кораблика" (VAD). Далее через "->" указывает последовательность процессов. Можно задавать последовательно-параллельные структуры, подписи и тип стрелок, добавлять объекты "исполнители", "продукты" и другие "VAD-примочки", но при этом код становится сложным, а отсутствие нормального управления надписью (перенос, вписывание в фиксированный размер объекта и т.п.) ограничивают применимость инструмента.

Применять подход "скрипт -> схема" можно в сочетании с табличным представлением: например, скриптом VBA читаем поля заполненной пользователем таблички бизнес-процесса (см. 1.5 Из таблицы - схему ) и генерируем dot-последовательность, которую "скармливаем" локальному генератору dot (Graphviz устанавливается на компьютер) или Online Generator. Прямо в word- документе под табличкой "Процесс такой-то" размещаем "кнопочку" и пользователю даем возможность просмотра в графике того, что он ввел в табличку (как он описал в табличной форме свой процесс).

Из "BPM-связанного" особенно удобен dot для построения графов переходов. Если в модели есть docflow с документами со многими состояниями, то без схемы переходов состояний понимание многочисленных переходов осложнено, особенно когда смена состояний документа размазана по многим листам схемы. В итоге заполнив табличку и "скормив" её генератору dot мы увидим всевозможные переходы из состояний. Например, для документа "Отчет" возможны следующие состояния: Шаблон отчета - Шаблон отчета заполнен - Отчет согласован в отделе 1 - Отчет согласован в отделе 2 - Отчет подписан первой подписью - Отчет подписан второй подписью - Отчет оправлен регулятору - Отчет принят регулятором (возможны различные переходы из состояний).

В теме автоматического создания диаграмм из "текстового описания языком" нельзя не упомянуть про Object Process Diagram (OPD) \ Object Process Language (OPL). Тезисы у Object Process Methodology (OPM) вроде как BPM-ориентированные, но поверхностное знакомство с ним породило уверенность, что эта методология намного дальше от "workflow \ business process" (народа), чем те же plant uml \ dot (graphviz). OPCloud доступен тут: https://sandbox.opm.technion.ac.il/

Если немного помечтать, то настоящий BPM - инструмент должен из любого текстового "процессного" регламента (порядка действий) строить схему процесса. Когда это появится, то загрузив в такую систему многостраничные регламенты (листов под 200-300) мы обязательно увидим противоречивость и неоднозначность этих "пухлых" регламентов (несмотря на это, по ним как-то все работают же).

2. Другое

2.1 Навигация по связанным моделям (каталог моделей)

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

Обычно связанный набор моделей (и их объектов) называют репозитарий (репозитОрий). Часто в интерфейсе программы предусмотрено два окна: иерархическое дерево моделей (слева вверху) и окно диаграммы (основное). В идеале навигация по моделям должна быть трех видов:

- по дереву моделей (treeview );

- по кликабельным объектам схемы (детализация - проваливаемся в низ, кнопка "выше" - переход к верхнеуровневой модели);

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

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

2.2 Разные фишки и отчеты по атрибутике

Поиск по названиям моделей, атрибутам. Задание правил отбора, например, по диапазону значений последнего редактирования модели. Выгрузка данных фильтрации \ сортировки во внешний файл (отчет), причем разного формата (например, excel для анализа, pdf для презентабельности) и т.п.

Правила работы с одноименными объектами (разрешение конфликтов), например, при наименовании нового объекта система смотрит - использовался ли одноименный объект и при выявлении такового предложит варианты, например, подтвердить или переименовать. У объекта в терминах АРИС только один Definition (Определение объекта, образ), но сколько угодно Occurrence (Отображение объекта, экземпляры на схемах).

2.3 Специфические отчеты

Отчеты могут быть разнообразны (зависит от воображения), но в первую очередь, нас будут интересовать выгрузки в распространенные формы. Универсальный генератор отчетов "на все случаи жизни" видимо проблема, но инструменты создания отчетов должны быть изначально в среде моделирования.

Для примера рассмотрим матрицу ответственности\ участия RACI. Требуется автоматическая генерация усеченной RACI-матрицы (здесь показано только для участников процесса, но часто плюс владельцы процесса) по имеющейся, например, VAD-диаграмме (value added chain diagram). Набор ключевых "мега процессов" компании показан в виде VAD и нужно по ним построить (синхронизировать) матрицу участников (RACI по одной только роли "участник процесса").

Рис. 4 Построение RACI матрицы

Алгоритм построения таблицы на VBA Visio\Excel может быть следующий:

1) Создаем в таблице Excel новую строку и в поле "Ключевые процессы" подставляем значение с активного листа visio из объекта типа "название мега процесса".

2) Далее циклом пробегаем по всем VAD-элементам схемы (листа) и через связь (объект "соединитель" для связки с объектами "исполнитель") находим связанные объекты типа "исполнитель" (участник подпроцесса).

3) Находим соответствующее название подразделения в шапке таблицы и на пересечении с процессом ставим символ участия (признак).

4) Переход к следующему листу visio.

Когда в организации десятки подразделений и около сотни "мега процессов" (их выделение достаточно субъективно), то задача синхронизации схем мега-процессов и матрицы участия подразделений в таких ключевых процессах становится достаточно трудоемкой.

2.4 Упаковка необъятной схемы процесса в печатный лист

Когда рисуют гигантскую "портянку" из "тучи элементов" на одной схеме, а потом нужно ее распечатать (А4, А3) или представить в ином интерфейсе (без скролинга такой "портянки"), то возникает ступор. Должна быть поддержка многостраничной схемы и элементов перехода между страницами (в том числе, кликабельными).

2.5 Разное

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

Авто-размещение объектов на схеме: набросал невпопад объекты на лист (главное правильно связи указать и никого не забыть) и нажал кнопку: "расположить как надо" и система сама оптимально и красиво разместила объекты на схеме (в visio функции выравнивания и распределения фигур).

Открытые стандарты хранения и экспорта \ импорта (внешний графический импорт \ экспорт как минимум в visio), как самих графических объектов модели, так и их атрибутов. К сожалению, тот же MS visio так и не научился нормально экспортировать схемы в pdf и svg (например, всплывающие подсказки).

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

Заключение

Устаревшие подходы, реализованные в "современных" платных инструментах моделирования не адекватны времени. За механизацией пришли модные: "информатизация", потом "автоматизация", а теперь и "цифровизация" (аж Digital Transformation / digital disruption и совсем "свежий" Digital process Automation), но возможности инструментов моделирования процессов за три десятка лет почти не изменились. Функциональность древних ARIS, BPwin и т.п. практически не осовременилась в современных BPMS, несмотря на то, что интерес к классическому моделированию процессов постоянно растет, т.к. проблема замены текстовых регламентов на что-то прогрессивное - в целом так и не решена (диаграммы рабочих процессов не заменили текст). Имитационное моделирование и исполняемые модели (также направления, process mining, enterprise architecture - ЕА и др.) - не в счет, рассматриваем "классическое моделирование процессов" - оно же просто "формализация процессов".

Дождаться Open Source системы, в которой было бы реализовано указанное выше, - в обозримом будущем - маловероятно, поэтому, направление улучшайзинга для себя вижу как связку: visio VBA (core, графика) + Excel (как репозитарий для хранения атрибутов моделей, а в будущем и атрибутов графических объектов, инструменты аналитики) + web (publisher & collaboration).

Динозавр - монстр АРИС до сих пор остаётся продуктом 1 в данном сегменте, несмотря на то, что он "заморозился" во времени (в части toolset) и ничего нового в этом направлении не предлагает. АРИС (1994г) и многочисленные visio-надстроенные инструменты (Business Studio, BPM-Х, Orbus iServer и десяток аналогичных) хорошо показали саму концепцию моделирования процессов, которая неизменна десятилетиями. Концептуально подходы понятны, но вот для построения моделей процессов из free взять нечего: через BPMN описать сложные процессы компании - это утопия, если нужно чтобы пользователь понимал нарисованное. Вроде бы удобный трамплин для амбициозного стартапа

Если в CASE, где S="software", еще наблюдается вялотекущая "движуха", например, UML-UML2- SysML или "всяко исполняемое" (no code\ low code), то направление CASE, где S="system" в части BPM (не EA), - фактически "замерло на месте", а робкие попытки, что методологического плана, что инструментального - прежде всего Open Source инструменты "классического" моделирования процессов - скорее отождествляются термином "застой". Правда может я чего-то не заметил.

Немного поутихнет мода на BPMN2 (фетиш в плане замещения нотации ЕРС) и мы вернёмся к "вечному", к классическим подходам BPM, т.к. другого ничего пока так и нет (задачу описания небольших процессов - не рассматриваем). Вернувшись к исходной точке описания процессов, следует смотреть в сторону чего-то интуитивно понятного "простому смертному": бухгалтеру, кассиру, секретарю и т.п., т.е. не программисту. Скорее всего, вернемся к "старине" ЕРС (т.е. фактически к "разбитому корыту") и начнем двигаться к нотации "ЕРС+" (показано на примере ЕРС2) и более гибким (см. предложенные выше фишки) и открытым (free, Open Source) инструментам моделирования. Ориентация на человека, а не машину - ключевой вектор развития. Нотации и инструменты должны быть более "человечными", схемы процессов должны создавать не "специально обученные люди", а сами участники процесса, возможно, даже не подозревая об этом и непосредственно не рисуя процессы.

В 2000-ном году мной использовались ровно такие же подходы и ровно те же инструменты моделирования (основные: ARIS toolset, MS visio), что и сейчас, но тогда была настолько интенсивная "движуха в мире ВРМ", что казалось "вот-вот и прогресс всё поменяет", но это оказалось иллюзией. "Старику ARIS" (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово "cloud"), но похоже перемены придут еще совсем не скоро и светлое будущее обычного BPM откладывается

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

Подробнее..

Из песочницы Как оптимизировать блок проверок case

16.08.2020 16:17:46 | Автор: admin
Почему в delphi блок case работает медленно и как это исправить.

Делюсь способами оптимизации и хаками.

Почему case плох


Даже начинающие delphi-программисты знают как выглядит блок case. Однако не все знают, что для нашего процессора, он выглядит как множество if блоков.

Вот что видит программист:

procedure case_test(Index:Integer);begin  case Index of    0: writeln('Hello');    1: writeln('Habr!');  end;end;

А вот что видит процессор:

procedure case_test(Index:Integer);begin  Index:=0;  if Index = 0 then     writeln('Hello')  else      if Index = 1 then     writeln('Habr!');end;

К сожалению никакой магии за словом case не оказалось. Более того, слишком активное использование case может замедлить выполнение кода. Например если у Вас не 2 варианта проверок, а 50, 250 или ещё больше. Худшим решением для вас будет блок case.

Чем заменить case


Решение у этой проблемы есть. Само строение блока case подсказывает нам, что наши варианты должны быть достаточно прибраны, чтобы поместиться в перечисляемом типе данных например: Integer, Word, Byte, Enum или Char.

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

const   Data:Array[0..1] of String = ('Hello', 'Habr!');procedure case_test(Index:Integer);begin    writeln(Data[Index]);end;

Это работает когда в действиях внутри блока case меняется только один параметр. Но что делать если параметров несколько?

Чем заменить сложный case


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

type  TMyTextWord = record    Text:String;    NeedLinebreak:Boolean;  end;const  Data:Array[0..2] of TMyTextWord = (     (Text:'Hello'; NeedLinebreak:False),     (Text:' '; NeedLinebreak:False),     (Text:'Habr!'; NeedLinebreak:True)   );procedure case_test(Index:Integer);var  MyTextWord:TMyTextWord;begin    MyTextWord:=Data[Index];  write(MyTextWord.Text);  if MyTextWord.NeedLinebreak then writeln;end;

Здесь мы заменили блок case, который мог выглядеть вот так

procedure case_test(Index:Integer);begin  case Index of    0: write('Hello');    1: write(' ');    2:     begin      write('Habr!');       writeln;       end;  end;end;

Таким образом мы сводим количество действий для выполнения любого из случаев в блоке case до минимума, одинакового для всех случаев. Хотя здесь не сильно видна разница т.к. один набор из 3-ех действий заменился другим. Но подумайте, что выполнится быстрее: 50 раз проверить, является ли переменная одним из чисел? или Получить по индексу из массива 1 параметр из 50 возможных?. Ответ очевиден.

И так мы пришли к тому что case не далеко ушёл от известного нам if.
А раз мы научились оптимизировать case почему бы не пойти дальше?

Чем заменить if


Допустим у нас case не использует настроек, которые можно было бы записать в обычный массив. Например такой case:

class procedure ActiveRecord<T>.SetFields(Fields: TArray<TField>;  Data: Pointer);var  I:Integer;  PRec:Pointer;begin  PRec:=@Data;  for I:=0 to Length(Fields)-1 do  begin    case Fields[I].Kind of      tkUString,      tkWideString:  PString(PRec)^:=PString(Fields[I].Data)^;      tkInteger:     PInteger(PRec)^:=PInteger(Fields[I].Data)^;      tkInt64:       PInt64(PRec)^:=PInt64(Fields[I].Data)^;      tkFloat:       PDouble(PRec)^:=PDouble(Fields[I].Data)^;      tkEnumeration: PWord(PRec)^:=PWord(Fields[I].Data)^;    end;    IncPtr(PRec,Fields[I].Size);  end;end;

Но перед главным решением я сделаю отступление, чтобы описать ход своих мыслей.

Допустим у нас есть некая процедура содержащая несколько блоков кода.

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

Мы знаем заведомо простое решение этой проблемы: перечислить в массиве процедуры, вот так

procedure SetString(A,B:Pointer); inline;procedure SetInt(A,B:Pointer); inline;procedure SetInt64(A,B:Pointer); inline;procedure SetDouble(A,B:Pointer); inline;procedure SetBool(A,B:Pointer); inline;implementationprocedure SetString(A,B:Pointer); begin PString(A)^:=PString(B)^; end;procedure SetInt(A,B:Pointer); begin PInteger(A)^:=PInteger(B)^; end;procedure SetInt64(A,B:Pointer); begin PInt64(A)^:=PInt64(B)^; end;procedure SetDouble(A,B:Pointer); begin PDouble(A)^:=PDouble(B)^; end;procedure SetBool(A,B:Pointer); begin PBoolean(A)^:=PBoolean(B)^; end;type  TTypeHandlerProc = reference to procedure (A,B:Pointer);var  TypeHandlers:Array[TTypeKind] of TTypeHandlerProc;class procedure ActiveRecord<T>.SetFields(Fields: TArray<TField>;  Data: Pointer);var  I:Integer;  PRec:Pointer;begin  PRec:=@Data;  for I:=0 to Length(Fields)-1 do  begin    TypeHandlers[Fields[I].Kind](PRec, Fields[I].Data);    IncPtr(PRec,Fields[I].Size);  end;end;initialization  TypeHandlers[tkUString]:=SetString;  TypeHandlers[tkWideString]:=SetString;  TypeHandlers[tkInteger]:=SetInt;  TypeHandlers[tkInt64]:=SetInt64;  TypeHandlers[tkFloat]:=SetDouble;  TypeHandlers[tkEnumeration]:=SetBool;end.

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

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

Если вы уверенный в себе программист и хотите максимальной оптимизации, но не хотите засорять модуль кучей примочек. Я представляю вам решение прямиком из тёмной стороны кодинга. Все кодеры вокруг говорят, что использовать goto не безопасно, что сам оператор устарел и в 90% случаях существуют решения без goto. Говорят что использование ассемблерных вставок доступно только злым хакерам. Но что будет, если мы пустимся во все тяжкие?

Я давно мечтал о таком способе переключения между блоками кода, чтобы хранить в массиве тип label, для осуществления прыжка goto. Таким образом я бы мог перемещаться между кусками одной процедуры при этом использовать для этого не case, а индекс по массиву адресов прыжка. Но возможно ли такое решение? Оказалось что да.

К сожалению в generic методах и классах нельзя использовать ассемблерные вставки, по этому решение пришлось переместить в метод другого объекта, хотя на самом решении это не отразилось. Решение представлено для x32 мода.

procedure TTestClass.Test(Fields: TArray<TField>; Data: Pointer);label  LS,LI,LI64,LF,LE,FIN;var  I:Integer;  PRec:Pointer;  ADR:Cardinal;  Types:Array[TTypeKind] of Cardinal;begin  FillChar(Types,Length(Types)*4,#0);  asm    lea EDX, [EAX].Types    mov [EAX-$4C+tkUString*4], offset LS    mov [EAX-$4C+tkWideString*4], offset LS    mov [EAX-$4C+tkInteger*4], offset LI    mov [EAX-$4C+tkInt64*4], offset LI64    mov [EAX-$4C+tkFloat*4], offset LF    mov [EAX-$4C+tkEnumeration*4], offset LE  end;  PRec:=Data;  for I:=0 to Length(Fields)-1 do  begin    ADR:=Types[Fields[I].Kind];    asm jmp ADR end;    LS:   PString(PRec)^:=PString(Fields[I].Data)^;   goto FIN;    LI:   PInteger(PRec)^:=PInteger(Fields[I].Data)^; goto FIN;    LI64: PInt64(PRec)^:=PInt64(Fields[I].Data)^;     goto FIN;    LF:   PDouble(PRec)^:=PDouble(Fields[I].Data)^;   goto FIN;    LE:   PByte(PRec)^:=PByte(Fields[I].Data)^;       goto FIN;    FIN:      IncPtr(PRec,Fields[I].Size);  end;end;

Трюк этого способа заключается в том, что компилятор delphi сам хранит адреса всех label и в ассемблерных вставках дает к ним доступ. Решение нашлось неожиданно просто[1]. Когда я искал как считать регистр EIP, в котором хранится адрес текущей исполняемой команды. Оказалось, что регистр считать нельзя, а вот адрес label'а как раз можно.

Ну а дальше всё просто, на ассемблере заполняем массив адресами нужных нам label'ов.
В цикле по массиву, берется каждый элемент. Тип элемента = индекс адреса его обработчика. Берем по индексу адрес обработчика, прыгаем на адрес, профит.

    ADR:=Types[Fields[I].Kind];    asm jmp ADR end;

Остались чисто формальности: после каждого блока ставим прыжок вконец цикла goto FIN;, чтобы не попадать на следующие label блоки.

Константа $4C это количество байт до начала блока с памятью массива, чтобы её вычислить можете записать в массив заполненный нулями mov [EAX], 1 и посмотреть в дебагере какая ячейка приняла это значение, количество ячеек от начала до неё * 4 и будет ваша константа.

Пишите своё мнение, и правки к статье в комментариях. Желаю успехов с оптимизацией кода.

References:

1. Хак с адресом EIP через label
Подробнее..
Категории: Оптимизация , Delphi , Case , If , Asm

Внедрение Atlassian продуктов в банк. Личный опыт

07.08.2020 12:20:56 | Автор: admin
Сегодня я расскажу о нашем опыте реорганизации процессов IT департамента для одного из банков Украины с помощью внедрения Atlassian инструментов. В таких проектах важно не забывать, что настройка новой системы под существующие процессы не приведет к существенному результату. Довольно часто корень находится в процессах работы, а это уже более глобальный вопрос. Мы помогаем нашим клиентам сначала обдумать бизнес-процессы, упростить их, сделать более гибкими и быстрыми, что дает значительный результат для бизнеса в целом, а только потом внедрять систему управления.




Историческое отступление


До недавнего времени система HP Service Desk 4.5 для автоматизации ITSM процессов, была практически стандартом в корпоративном мире. Первая версия HP SD была выпущена 2002 году, а в 2012 году, спустя 4 крупных обновления, официальная поддержка системы была прекращена. Конечно, учитывая популярность системы в корпоративном сегменте на смену ей была разработана Omnitracker, которая, фактически, была продолжением культовой 4.5. Она изначально делалась с прицелом на замену HP SD, поэтому ее интерфейс не сильно отличался от старшего брата, хотя функциональные возможности и расширились спустя 10 лет с релиза первой версии HewlettPackard. HP также хотели сделать продолжение ITSM системы Service Management Automation X, но сейчас на рынке она не пользуется успехом.

В 2020 году любому ентерпрайз бизнесу требуется поддержка процессов и инструменты для эффективного ведения дел, как внешних, так и внутренних. Для работы с ITSM и ITIL нужно уже не просто понимать что это такое, но и сокращать издержки на поддержание этих процессов, например, за счет использования правильных инструментов. За последние 2 года появился тренд использования быстрых, гибких и универсальных инструментов, упрощения и движения в сторону гибкости бизнес-процессов с разумным уровнем бюрократии и строгости. Компании стараются отходить от решений за миллионы долларов с десятками модулей, из которых использоваться будет лишь часть.

Старт проекта


Теперь о проекте. На момент старта проекта в банке был HP Service Desk 4.5, стояла задача перейти к использованию Atlassian продуктов во всех возможных департаментах (IT департамент, ПМО, АХО, HR, Юристы и пр.). Проект начался с департамента IT. Мы провели дискавери фазу для изучения бизнес процессов департамента, их связи с другими отделами банка, определили объем и задачи проекта и сформировали план работ. На этом этапе начали проявлятся особенности работы с клиентом-банком. Банк это огромная структура, практически маленькое государство, с внутренней политикой, интересами и курсом развития. Например, получение доступа к серверу может занимать не час-два, как в ИТ компании, а несколько дней, за которые запрос пройдет все круги согласований и проверок. Чтобы уменьшить критический путь выполнения проекта, мы планировали работы в несколько параллельных потоков: задачи, которые находятся на стороне банка, и наши задачи. За это время мы уже ускорили процессы коммуникации из классической почты и ответов на следующий день на более быстрые мессенджеры, начали проводить больше личных встреч.

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

Как иногда бывает при внедрении новых систем, во время выхода в продакшн мы столкнулись с сопротивлением сотрудников, которые привыкли работать в старой системе. Но нашим прямым заказчиком был руководитель подразделения, поэтому мы перебороли сопротивление достаточно жестко. Для упрощения ввода системы в эксплуатацию, при реализации проекта мы применяли итеративный подход к релизам с промежуточным результатом, поэтому было принято административное решение отключать в старой системе процесс, когда он был готов в новой. Да, конечно, некоторое время банку нужно было использовать 2 системы; например, запросы пользователей уже обрабатывались в Atlassian, а управление изменениями проходило в HP SD. Но это дало время сотрудникам привыкнуть к новым условиям, а также позволило нам получить быстрый фидбэк.

Технологический стэк


Используя свою экспертизу и имеющуюся структуру IT в банке, мы совместно построили службу поддержки из четырех линий. Нулевая линия работает в Jira Service Desk, она производит первичную обработку заявок внутренних пользователей и обеспечивает выполнение установленных SLA по всем заявкам. Далее, на первую и вторую линии поддержки задачи эскалируются, и сотрудники работают над задачами в Jira Software. Такой подход позволяет разделить инструменты по назначению. Сотрудникам первой, второй, третьей линии далеко не всегда нужны возможности классического Service Desk. Эти люди, а их больше 100 человек, обычно выполняют поставленную задачу одну за другой, и им незачем видеть поток всего, что приходит в ИТ поддержку.
Как козырь в рукаве, остается третья линия. Для них задачи создаются внутри банка, эта линия внутренние разработчики, тестировщики, аналитики. Они исправляют ошибки программного обеспечения или разрабатывают новое. Возможность передать задачу на работу такой внутренней команде есть только при условии, что все предыдущие линии не смогли решить запрос по какой-то причине либо если это Change request.
Кроме IT на новую систему перешли также департаменты АХО и ПМО.
У департамента АХО есть свой набор запросов, то есть свой портал на сервис деске, а ПМО использует классические Jira Core проекты для внутренних задач.

По верхам ITIL стандарта


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

  • Управление инцидентами (Incident management). Целью этого процесса является управление жизненным циклом всех инцидентов. Процесс направлен на быстрое решение запросов пользователя, которые непредвиденно начали мешать его работе.
  • Управление проблемами (Problem management). Этот процесс помогает ИТ департаменту предотвратить инциденты и минимизировать влияние инцидентов, которые невозможно предотвратить или предвидеть.
  • Запросы пользователей (Request fulfillment). Основной процесс службы поддержки выполнение запросов на обслуживание. Как правило, это помощь в решении базовых вопросов или незначительные изменения, например, рабочего места пользователя.
  • Управление изменениями (Change management). Процесс контролирует все изменения, которые могут выполняться одновременно несколькими департаментами банка. Это могут быть доработки программного обеспечения, изменения инфраструктуры, внедрение новых инструментов.
  • Управление конфигурациями (Configuration management). Этот процесс направлен на управление ИТ инфраструктурой и все что с ней связано. Хранение в едином месте информации по серверам, приложениями, доступам, лицензиями, рабочим местам и использование этих данных во всех остальных процессах помогает четко прослеживать изменения или инциденты. Мы использовали дополнительный плагин Insight Asset management, который красной нитью проходит через все продукты и позволяет работать с конфигурационными единицами на всех линиях поддержки.
  • Управление знаниями (Knowledge management). Отвечает за управление информацией о системе в целом. Предоставляемые услуги для пользователей, имеющаяся инфраструктура, типовые инструкции для пользователей. Все это должно хранится в одном месте и быть доступно для клиентов службы поддержки. В этом кейсе мы использовали Confluence, как продукт для работы с базой знаний и местом для технической документации ИТ департамента.

Результат


Таким образом в течении внедрения проекта, процесс за процессом, банк перешел с морально устаревшей HP Service Desk 4.5, выпущенной в 2002 году, на современную, поддерживаемую систему из комплекса продуктов Atlassian. Доработаны и реорганизованы ITIL процессы с учетом сложности банковской структуры. Это дало заказчику несколько важных улучшений:
  1. Проведена ревизия бизнес-процессов для работы с запросами пользователя и внутри банка;
  2. Получены прозрачные SLA, которые можно отслеживать и использовать для улучшения департаментов;
  3. Разделены зоны ответственности на явные линии поддержки и снижена нагрузка на департамент в целом. Вместо того, чтобы обрабатывать каждую заявку по прямой цепочке нулевая-первая-вторая-третья линии, теперь часть заявок автоматически распределяется на нужные линии;
  4. Ускорилось время реакции и время решения задач.
Подробнее..
Категории: Atlassian , Case , Atlassian implement

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru