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

Анализ и проектирование систем

Внутренняя автоматизация почему мы отказались от low-code системы в пользу Camunda

17.06.2021 10:17:44 | Автор: admin

Привет! Меня зовут Мирослав, я инженер-разработчик проекта по реализации BPM-решений для внутренней автоматизации КРОК.

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

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

Теперь пользователь просто прописывает путь к папке, выбирает тип доступа (чтение/редактирование), оставляет при желании какой-нибудь увлекательный комментарий и все, дальше все делает BPMN.

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

Каким мы хотели видеть BPMS

Потребность в новой BPM-системе стала очевидной еще в 2018 году. Текущая K2 4.7 не шла в ногу со временем, а K2 5.0 не устроила нашу команду. В конце 2018 года менеджер нашего проекта в компании пары аналитиков начали изучать рынок BPM-решений в поисках альтернативы.

Тогда как раз набирала обороты глобальная трансформация КРОК (что это значит, в одном абзаце не объяснить, поэтому просто оставлю это здесь как факт). Бизнес повсеместно стремился к изменениям, и это, конечно же, влияло на нас. То, как было по-старому, работать перестало нужны были гибкая разработка, регулярные демо, работа бок о бок с заказчиком на понятном ему языке.

Нашей идеальной системе предстояло усилить взаимодействие команды с заказчиками и ускорить процесс разработки. Для этого отлично подходили iBPMS, в которых, при нашем сценарии использования, ведущая роль разработки отводилась аналитику и автогенерируемому интерфейсу. Именно аналитик должен был проектировать BPM-схему, собирать модель данных и создавать страницы в UI-дизайнере. Разработчики, в свою очередь, должны были насытить BPM-схему логикой при помощи скриптов, а также развернуть окружение и наладить workflow внедрения новых бизнес-процессов.

Спустя пару месяцев наш выбор пал на Bonita, а в феврале 2019 года мне поручили ее внедрение на нашем проекте.

Опыт использования Bonita

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

Архитектура Bonita BPMАрхитектура Bonita BPM

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

Bonita Studio

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

С чем столкнулись

  • Моделлер рисования схем сам по себе показался не очень удобным, так как достаточно криво отрисовывал XML. Редактирование схем и приведение их к единому стилю иногда доставляло боль.

Вот так выглядит BPMN-схема для процесса "Выдача прав доступа" в BonitaВот так выглядит BPMN-схема для процесса "Выдача прав доступа" в Bonita
  • Ограничение лицензии не позволяло нам открыть два окна Bonita Studio, а значит, два проекта одновременно, чтобы скопировать схемы или скрипты.

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

    На деле UI-дизайнер оказался слишком негибким для того, чтобы отрисовывать на нем сложные формы. Аналитик мог "набросать" примерную схему страницы, но дальше на ее оживление разработчик тратил слишком много времени. И чем сложнее была страница, тем больше времени требовалось. А все дело было в том, что под капотом конструктора были примитивные и не расширяемые инструменты, а формируемые им страницы реализовывались на AngularJS.

    Дальше мы старались писать фронтенд по старинке, при помощи Angular 2+, и налаживать взаимодействие с Bonita через REST API.

Bonita Portal

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

С чем столкнулись

  • Такое пространство удобное решение, если нет необходимости его дорабатывать. У Bonita есть возможность кастомизировать портал при помощи архивов стилей, накатываемых прямо в Web. Мы легко перекрасили оформление и даже поменяли язык всего портала на русский. Но когда дело дошло до каких-то детальных изменений, не предусмотренных BonitaSoft, мы столкнулись с проблемой для подобных доработок Bonita Portal не был приспособлен.

  • В Bonita Portal можно редактировать скрипты и параметры бизнес-процессов в runtime. Это достаточно мощное решение, с которым можно здесь и сейчас устранить проблемы пользователей, но в перспективе эта опция создает огромные проблемы и хаос в Production среде. И естественно с этими перспективами мы столкнулись лицом к лицу. Но это уже совсем другая история :D.

Bonita Runtime

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

Version Control

Это опция Bonita Studio, которая обеспечивает взаимодействие с Git-репозиториями. Не очень красивая, и на самом деле, совершенно необязательная, так как можно воспользоваться каким угодно иным инструментом для работы с Git. Но работает исправно :)

Bonita Storage

С чем столкнулись

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

  • После создания модель данных содержалась в xml-файле, который необходимо было заархивировать и развернуть в Bonita Portal.

XML-схема, которую генерит Bonita на основе business data model. Далее в соответствии с этой схемой будут созданы таблицы в БДXML-схема, которую генерит Bonita на основе business data model. Далее в соответствии с этой схемой будут созданы таблицы в БД

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

  • После деплоя архива с xml-схемой в BonitaPortal на ее основе создавались таблицы в заранее указанной базе данных. Выглядели они не совсем так, как нам хотелось. При этом в самой Bonita были ограничения по именованию объектов BDM. Все таблицы лежали в одной БД, хранить их иначе было невозможно. Для того, чтобы исключить пересечения именований, мы добавили префиксы, но в названиях таблиц (сущностей в модели данных) нельзя было использовать точки или нижние подчеркивания. В результате это были просто буквы, с которых начинались все названия сущностей.

    Еще были сложности с изменением модели данных. Добавление нового столбца или изменение Nullable могло обернуться вынужденным сносом всех данных из таблицы этого в проде мы допустить не могли.

Information systems

Пласт коннекторов, позволяющий Bonita взаимодействовать с внешними системами.Этот механизм облегчает жизнь разработчику можно подключиться к БД, SOAP, REST, отправлять письма. Пласт коннекторов, позволяющий Bonita взаимодействовать с внешними системами.Этот механизм облегчает жизнь разработчику можно подключиться к БД, SOAP, REST, отправлять письма.

С чем столкнулись

  • Основная проблема этого механизма - в его предопределенности. Здесь ситуация очень сильно похожа на Bonita Portal. В рамках задач, обозначенных BonitaSoft, коннекторы справлялись хорошо, но расширить их настройки или спектр применения было попросту невозможно. Да, мы могли создать самописные коннекторы, но тогда какой же это low-code? В итоге некоторые взаимодействия с внешними системами происходили через проставку из самописного сервиса.

Выводы

Bonita отлично подошла нам для создания простых бизнес-процессов: в некоторых случаях нам пригодился UI-дизайнер и даже генерация несложной модели данных. Но при создании нетривиальных, многомерных BPM-приложений такой подход начинал пробуксовывать, порождать костыли, а само приложение становилось неподъемным в плане поддержки и развития.

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

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

Поиск новой BPMS

В этот раз в выборе BPM системы участвовала большая часть проектной команды все те, кто был причастен к разработке процессов на Bonita. Пропустив через этот опыт решения из прошлого исследования, выбрали четырех финалистов Bizagi, ELMA, BpmOnline и Camunda.

Bizagi не устроила нас по цене, ELMA показалась слишком похожей на Bonita. BpmOnline мы смогли изучить подробнее, благодаря опыту наших коллег она уже используется в КРОК в качестве внутренней CRM-системы. В нашем случае она казалась не самым удачным вариантом могли быть трудности с поддержкой нетривиальных схем. У Camunda не было богатого набора инструментов iBPMS как у Bonita (но именно к ним у нас и было больше всего вопросов). Но зато у нее была Community-версия что стало дополнительным аргументом "за". Нам хотелось быстро и безболезненно протестировать решение, и быстро отмести его, если вдруг что-то опять пойдет не так. В общем-то, по этой причине мы выбрали ее качестве объекта для исследования и внедрения в тестовой среде.

Новая BPMS

Camunda - BPM Engine

Рассказывать о том, что такое Camunda можно долго, но на самом деле об этом уже написано достаточно статей. Вот, например, отличный материал от Tinkoff, позволяющий быстро и легко погрузиться в особенности этого BPM движка.

Добавлю лишь немного лайфхаков.

  • Ссылка на git-репозиторий с огромным количеством тестовых проектов Camunda на любой вкус, которые помогут быстрому старту и поиску решений проблем, возникших при самостоятельном знакомстве.

  • Ссылка на telegram-канал русскоязычного сообщества Camunda, куда можно обратиться за помощью, когда документация и Google не смогли подсказать решение. Эти ребята ни раз меня выручали в период знакомства с движком, за что им огромное спасибо :)

Наша основная проблема

Начав исследовать Camunda я столкнулся с очевидной проблемой. Camunda написана на Java, разворачивается в среде Java и расширяется при помощи Java-подобных языков. А вся наша команда пишет на .NET (надеюсь, у вас тоже проигралась заставка из Ералаша).

Вероятных решений было два:

  • Научиться писать на Java или Kotlin, но не растерять при этом навыков .NET, так как на поддержке у команды остается еще более двадцати бизнес-процессов

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

Мы решили попробовать пойти по второму сценарию и вот что из этого получилось.

Новая концепция взаимодействия с BPM

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

Spring Boot

Java-часть нашей BPMS выглядит так:

Здесь мы используем Spring Boot, в который как зависимость импортируем Camunda.

У Camunda есть свой REST API и, конечно, BPMN-составляющая, а также своя БД, используемая для хранения процессных данных.BPM-движок через схему обращается к коду, написанному на Kotlin, который, в свою очередь, обращается к нашему .NET приложению для получения бизнес-данных.

.NET

Основная часть бизнес-процесса представляет из себя .NET приложение:

Бизнес-данные хранятся в БД, с помощью EF Core мы потребляем их в слой сервисов, где рассчитываем бизнес-логику и откуда обращаемся к Camunda REST API. Также у приложения есть формы на Angular для взаимодействия с пользователями и REST API для доступа к бизнес данным из Camunda и внешних систем.

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

Как теперь все устроено

За 8 месяцев мы исследовали и внедрили движок Camunda, а также мигрировали на него все бизнес-процессы, тем самым полностью отказавшись от Bonita BPM. Теперь у нас есть 3 отдельных Spring Boot приложения Camunda, под каждый бизнес-контур (Sales, HR и Production), самописный CROC BPM Portal, агрегирующий информацию о состоянии экземпляров процессов, и 4 бизнес-процесса, работающих в production-среде вот таких:


Выдача прав доступа

С него начался этот пост. Это инструмент, позволяющий автоматизировано получать права и доступ на файлы и папки КРОК.

Обходной лист

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

Согласование тендера

Мы упростили коммуникацию по согласованию участия в тендере и исключили из этого процесса электронную почту или мессенджеры. Теперь наши менеджеры используют автоматизированное приложение с продуманным WorkFlow.

Пульс проекта

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


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

Bonita Portal => CROC BPM Portal

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

Task-модуль CROC BPM Portal на тестеTask-модуль CROC BPM Portal на тесте

Bonita Runtime => Spring Boot и Camunda

Также, вместо standalone-подхода мы используем импорт библиотеки Camunda в Java-приложение. И таких приложений у нас несколько, в целях увеличения отказоустойчивости, каждое под свой бизнес-контур.

Bonita Storage => EF Core

Еще мы полностью контролируем бизнес-данные, для обновления БД используем миграции, а таблицы хранятся в удобном для нас виде:

Information systems => Самописные сервисы

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

Почему BPM это круто?

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

Центр любой BPMS это BPM-движок, и мы используем его по полной. Это удивительный инструмент, который действительно помогает ускорить разработку и повысить качество поставляемых решений. Фокус вовсе не в том, чтобы переложить ответственность на аналитика и автогенерацию. Основное преимущество в том, что BPMN это исполняемая документация.

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

Что дальше?

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

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

Подробнее..

Перевод Хватит организовывать код по типу файлов

06.06.2021 12:22:20 | Автор: admin

Какой самый популярный стиль организации кода вы встречали в корпоративных кодовых базах? Лично я чаще всего видел решение, подразумевающее группировку всех файлов по их типу. Таким образом, к примеру, в системе MVC все контроллеры, все сервисы, все репозитории, все POJO и так далее находятся вместе. Давайте назовем такое решение "стековым" стилем организации кода.

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

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

Теперь давайте разберемся, почему я считаю, что смысловая модель лучше, чем модель стека.

Неправильная абстракция

Люди не читают код по назначению файлов и классов. Никто никогда не говорит: "покажите мне весь API проекта" или "продемонстрируйте мне все запросы, отправляемые решением". Люди читают код, полагаясь на его смысл и роль. Как в системе управления гостиницами, например, люди отдельно думают о номерах, гостях, ценах и так далее.

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

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

Нарушения связи

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

Проблема этого аргумента в том, что он фокусируется на разделении, но полностью игнорирует потребность в связи между определёнными структурами. Допуская, что все файлы и классы определённого типа в такой системе расположены вместе, справедливо ли будет сказать, что их взаимная связь, как структур одинакового назначения, но разного смысла, нас устраивает? Положено ли все же, к примеру, контроллерам, находиться отдельно от своих классов и репозиториев? Можем ли мы позволить, скажем, всем репозиториям быть сильно зависимыми друг от друга, но отделенными от уровня сервисов? Очевидный ответ - НЕТ! Такой код стал бы хрестоматийным куском г*вна. Рефакторинг такой системы на более мелкие решения был бы абсолютным кошмаром, потому что вам пришлось бы отделить друг от друга все классы на каждом уровне стека. Это убивает основную цель использования стиля MVC.

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

Трудно менять

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

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

Ограничивает выбор дизайна

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

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


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

Подробнее..

Русский язык глазами инженера. Числительные

07.06.2021 20:11:26 | Автор: admin

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

Начинается всё просто, с уникальных числительных: Один, два, три ... восемнадцать, девятнадцать.

Десятки.

Дальше идёт образование десятков, добавлением к уникальному числительному окончания:

Два - два(дцать), три - три(дцать), четыре - четыре(дцать)? Нет. Сорок! Почему? Не спрашивайте.

Пять - пять(десят). Тут снова поворот. Очередное уникальное окончание для образования десятков, но кажется самое логичное - "десят". Пять десятков - пять(десят). Вроде неплохо звучит и даже логично. И не один я, видимо так подумал, потому что дальше идут: шесть(десят), семь(десят), восемь(десят)... и вот тут опять кто-то отвлёк дядю Фёдора и Шарик дописал - девяносто!

Почему у десятков разные окончания? Почему второй десяток вообще имеет уникальные названия чисел? Почему тогда уже не все числа до сотни уникальные? Чем второй десяток так отличился?

Может у кого-то и есть ответ на эти вопросы отличный от "так сложилось исторически", но мне он не известен. Было бы интересно послушать.

Но как бы то ни было, подытожим и обобщим, что мы имеем.

Мы имеем три группы:

1. Уникальное числительное + окончание обозначающее десятки (дцать, десят)

2. Совершенно уникальные названия десятков - сорок, девяносто.

3. Для каждого числа второго десятка используется уникальное название.

Едем дальше.

Сотни.

Сто, двести, три(ста), четыре(ста)... В этом моменте похоже опять вернулся дядя Фёдор и дописал - пять(сот), шесть(сот), семь(сот), восемь(сот), девять(сот).

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

Имеем две группы:

1. Уникальное числительное + окончание обозначающее сотни (ста, сот)

2. Уникальные названия сотен - сто, двести.

Итого:

1. 19 (девятнадцать) уникальных числительных.

2. 8 (восемь) уникальных названий десятков. Не смотрите, что кое где окончания повторяются, нам всё равно нужно помнить название каждого десятка.

3. 9 (девять) уникальных названий сотен.

Ну, а если бы меня попросили сделать максимально простую, удобную и логичную систему?

Ну, что ж. Попробуем.

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

Сотни.

Самое массовое у нас окончание, "сот" - пять(сот), шесть(сот), семь(сот), восемь(сот), девять(сот). Оно же и самое логичное, "сот" - сотни. Ок. Значит его и оставим.

Получаем следующее: один(сот), два(сот), три(сот), четыре(сот), пять(сот), шесть(сот), семь(сот), восемь(сот), девять(сот).

Едем дальше.

Десятки.

Опять же, самое массовое, "десят" - пять(десят), шесть(десят), семь(десят), восемь(десят). Оно же, как и в случае с сотнями, самое логичное, "десят" - десятки. Определились. Оставляем его.

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

Получаем следующее: один(десят), два(десят), три(десят), четыре(десят), пять(десят), шесть(десят), семь(десят), восемь(десят), девять(десят).

Итого:

1. 9 (девять) уникальных числительных.

2. 2 (два) уникальных окончания обозначающие десятки и сотни ("десят" и "сот").

Вот и всё.

Мы получаем максимально простую, удобную, логичную систему.


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

Всего доброго!

Подробнее..

Чему можно научиться у фикуса-душителя? Паттерн Strangler

12.06.2021 20:19:26 | Автор: admin

Ссылка на статью в моем блоге

Тропические леса и фикусы-душители

В тропических лесах, где всегда тепло, влажно и много зелени живет одно интересное растение. С необычным названием фикус-душитель. Почему он получил такое имя? Как из фильма ужасов.

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

Крона дерева не может получать достаточно света, потому что фикус забирает его себе. Его листья выше. Корни фикуса высасывают из почвы воду и питательные вещества, так что дереву носителю достается все меньше. В какой-то момент дерево-носитель погибает, но фикусу оно уже не нужно. Его стебли образуют прочную основу, которая повторяет силуэт своей жертвы. Обычно старое дерево полностью сгнивает в таком заключении и от него не остается и следа.Однако внешний образ по прежнему остается его в точности повторяет сам фикус:

Рефакторинг сервиса приложения доставки продуктов

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

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

Допустим имеются следующие действия, которые у нас хранятся в одной таблице:

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

  • Можно оформитьвозврат товара. Если вам не понравился кефир - вы оформляете возврат и вам возвращают его цену.

  • Можносписать бонусысо счета. В таком случае часть стоимости оплачивается этими бонусами.

  • Начисляются бонусы. Каким-либо алгоритмом нам не важно каким конкретно.

  • Также заказ может бытьзарегистрирован в некотором приложении-партнере(ExternalOrder)

Все перечисленная информация по заказам и пользователям хранится в таблице (пусть она будет называтьсяOrderHistory):

id

operation_type

status

datetime

user_id

order_id

loyality_id

money

234

Order

Open

2021-06-02 12:34

33231

24568

null

1024.00

233

Order

Open

2021-06-02 11:22

124008

236231

null

560.00

232

Refund

null

2021-05-30 07:55

3456245

null

null

-2231.20

231

Order

Closed

2021-05-30 14:24

636327

33231

null

4230.10

230

BonusAccrual

null

2021-05-30 09:37

568458

null

33231

500.00

229

Order

Closed

2021-06-01 11:45

568458

242334

null

544.00

228

BonusWriteOff

null

2021-05-30 22:15

6678678

8798237

null

35.00

227

Order

Closed

2021-05-30 16:22

6678678

8798237

null

640.40

226

Order

Closed

2021-06-01 17:41

456781

2323423

null

5640.00

225

ExternalOrder

Closed

2021-06-01 23:13

368358

98788

null

226.00

Логика такой организации данных вполне справедлива на раннем этапе разработки системы. Ведь наверняка пользователь может посмотреть историю своих действий. Где он одним списком видит что он заказывал, как начислялись и списывались бонусы. В таком случае мы просто выводим записи, относящиеся к нему за указанный диапазон. Организовать в виде одной таблицы банальная экономия на создании дополнительных таблиц, их поддержании. Однако, по мере роста бизнес-логики и добавления новых типов операций число столбцов с null значениями начало расти. Записей в таблице сотни миллионов. Причем распределены они очень неравномерно. В основном это операции открытия и закрытия заказов. Но вот операции начисления бонусов составляют 0.1% от общего числа, однако эти записи используются при расчете новых бонусов, что происходит регулярно.В итоге логика расчета бонусов работает медленнее, чем если бы эти записи хранились в отдельной таблице. Ну и расширять таблицу новыми столбцами не хотелось бы в дальнейшем. Кроме того заказы в закрытом статусе с датой создания более 2 месяцев для бизнес-логики интереса не представляют. Они нужны только для отчетов не более.

И вот возникает идея.Разделить таблицу на две, три или даже больше.

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

Изменение структуры хранения в три этапа

Предположим, что наше legacy монолитное приложение хоть и плохое, но не совсем. Как минимум зарезервировано. То есть работает как минимум два экземпляра. Так, что при падении одного из них - второй продолжит обслуживать пользователей:

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

Оба экземпляра работают с одной базой данных. Реализуя паттернShared Database.

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

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

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

BonusOperations:

id

operation_type

datetime

user_id

order_id

loyality_id

money

230

BonusAccrual

2021-05-30 09:37

568458

null

33231

500.00

228

BonusWriteOff

2021-05-30 22:15

6678678

8798237

null

35.00

Отдельную таблицу для данных из внешних систем -ExternalOrders:

id

status

datetime

user_id

order_id

money

225

Closed

2021-06-01 23:13

368358

98788

226.00

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

Для оставшихся типов записей -OrderHistoryArchive(старше 2х недель). Где теперь также можно удалить несколько лишних столбцов.

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

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

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

Спустя какое-то время работы версии 2 мы получим заполненную новую базу данных. Если все хорошо, то мы готовы к следующей стадии переводу основной бизнес-логики на новую базу данных.

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

Итого. Внешне система никогда не менялась. Однако внутренняя организация радикально преобразилась. Возможно под капотом теперь работает новая система. Которая лишена недостатков предыдущей. Не напоминает фикусов-душителей? Что-то похожее есть. Поэтому именно такое название паттерн и получил Strangler.

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

Выводы

  • ПаттернStranglerпозволяет совершенствовать системы с высокими требованиями к SLA.

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

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

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

Подробнее..

Платформа управления бизнес-процессами практика внедрения

01.06.2021 12:20:22 | Автор: admin

MES-системы, мониторинг оборудования, платформенные стратегии, программирование роботов, сложные производственные системы все это имеет ключевое значение для отрасли, для повышения эффективности производства, цифровизации промышленности. Это важно для профессионалов, которые не просто говорят о цифровизации, а делают ее своими руками.

Производственные системы и их решения

Об одном из показательных примеров - о совместном решении Dassault Systemes и ГК Цифра - рассказал старший технический специалист компании Dassault Systemes Дмитрий Лопаткин. Группа компаний Цифра разрабатывает и внедряет платформенные решения на основе промышленного искусственного интеллекта и интернета вещей, а также развивает индустрию роботизированного промышленного транспорта.

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

Если говорить о программном продукте для оперативного управления производством компании Dassault Systemes - DELMIA Apriso и его архитектуре, то на его самом нижнем уровне лежит собственная, встроенная платформа управления бизнес-процессами Process Builder. И это единственный обязательный реквизит, необходимый для внедрения подобных систем. Именно здесь описываются все производственные процессы, входящие в контур цифровизации. Помимо самих процессов прописываются все интерфейсы подключения к оборудованию через системы автоматизации или непосредственно подключение бизнес-систем, таких как ERP. На эти бизнес-процессы наслаиваются функциональные модули, которые могут применяться на пользователями из различных производственных дисциплин: контроль качества, склады, ТОиР, декларация производства. Это те элементы, с которыми взаимодействует конечный пользователь оператор ЧПУ, плановик, сотрудники логистической или ремонтной службы и пр.".

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

Описание и моделирование бизнес-процессов

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

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

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

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

Ядро и интерфейсы пользователя

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

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

Как и во многом другом, главное - найти баланс, "золотую" середину между уникальностью каждой производственной площадки и применяемыми лучшими стандартными корпоративными практиками. Если производственная площадка работает по своим уникальным процессам, не факт что применяется наиболее оптимальный/эффективный подход, но и при внедрении практик необходимо учитывать особенности производственной площадки: планировку, различные типы оборудования, логистику и прочее. Поэтому рекомендуется комбинировать процессы в соотношении 70/30: 70 стандартных и 30 локальных, или 80/20.

Масштабирование системы

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

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

Что даёт такой подход с точки зрения информационных технологий? Во-первых, это высокая скорость внедрения. Обычно 60%-70% времени тратится на разработку основного решения (core), а дальнейшее внедрение требует уже незначительного времени. Например, на подключение новой производственной площадки уходит 2-3 недели, что по меркам систем управления производством очень малый срок.

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

Интеграция с "Цифрой"

Например, данный подход использовался для интеграции с решениями компании "Цифра". Изначально это был небольшой процесс, начинающийся с производственного заказа. В данном случае производственный заказ состоит из трех операций. Первая из них выполняется на оборудовании, имеющему свой АРМ.

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

Зная, что данная операция выполнена, Apriso начинается "толкать" к выполнению следующей операции - далее по маршруту следующему обрабатывающему рабочему центру. Там оператор также получает уведомление о том, что он должен выполнить, заходит в свой рабочий интерфейс, декларирует начало операции, выполнение операции. Фактическое время её выполнения заносится в систему управления производством.

Третья операция - операция сборки. У оператора на сборке своя задача и свои потребности: он хочет видеть весь процесс детально. Он проходит обязательный контроль соблюдения мер безопасности. Эта информация в рамках системы контроля качества сохраняется в системе управления производством Apriso. Каждый индивидуальный использованный материал и полуфабрикаты также заносятся в систему управления производством и добавляются в генеалогию изделия.

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

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

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

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

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

Преимущество такого решения в том, что оно позволяет собирать информацию c оборудования компании "Цифра". Есть система контроля процессов. Такой совместный подход дает большую синхронизированность работы всех производственных служб, увеличение эффективности использования оборудования и гибкости производства в целом. Всегда можно оперативно отреагировать на изменения, которые требует ситуация на рынке. Решение DELMIA Apriso обеспечивает глобальное управление процессами, контроль производительности, визуализацию и тщательный анализ влияния функциональных улучшений на всех производственных площадках в рамках предприятия.

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

Заинтересовала данная тематика?

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

Познакомьтесь с материалом "Системы управления производством и производственными операциями и современные вызовы".

Узнайте больше о продуктах DELMIA на официальном сайте компании

Подробнее..

Советы и трюки SOLIDWORKS

02.06.2021 10:16:01 | Автор: admin

В своей работе мы много общаемся с клиентами, и в результате у нас собрался целый пул часто задаваемых вопросов по линейке SOLIDWORKS. Тогда мы решили записать серию коротких видеороликов с ответами. Новые вопросы поступали, количество роликов росло В итоге мы решили организовать свой YouTube-канал Школа SOLIDWORKS, чтобы пользователи могли быстрее получать интересующую их информацию.

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

1. Как установить существующую библиотеку материалов

Файлы с расширением .sldmat содержат сведения о механических и физических свойствах материалов. Если вы скачали библиотеку с сайта i-tools.info, следующие 5 шагов помогут вам ее установить. Для добавления библиотеки необходимо открыть любую деталь в SOLIDWORKS:

1. В дереве конструирования FeatureManager нажимаем правой кнопкой мыши на Материал.

2. Выбираем пункт Редактировать материал.

3. В левом поле открывшегося окна кликаем в любом месте правой кнопкой мыши и выбираем Открыть библиотеку.

4. Выбираем директорию, в которой находится файл .sldmat, либо копируем его в папку с пользовательскими материалами SOLIDWORKS. Уточнить папку, выбранную по умолчанию, можно в разделе Настройки пользователя Месторасположение файлов Отобразить папки для Базы данных материалов.

5. Выбираем файл с расширением .sldmat и нажимаем кнопку Открыть.

Библиотека установлена! Если она не отображается в окне, необходимо закрыть и вновь открыть окно редактирования материала.

2. Можно ли работать на любом компьютере с установленным SOLIDWORKS, используя лишь свою лицензию?

ДА! Это называется онлайн-лицензирование SOLIDWORKS Online Licensing. Вам потребуются лишь компьютер с доступом в интернет и SOLIDWORKS выше версии 2018 года.

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

Можно сказать, это лицензия SOLIDWORKS, которая находится в облаке.

3. В чем отличие SOLIDWORKS Simulation Standard и пакета Simulation Standard, входящего в SOLIDWORKS CAD Premium?

a) В SOLIDWORKS CAD Premium нельзя строить диаграмму усталости, усталостные напряжения и получать количество циклов до разрушений.

b) В SOLIDWORKS Simulation Standard доступен анализ тенденций, то есть построение зависимостей в результатах различных повторов статического исследования. Например, меняя нагрузку, можно отслеживать напряжение, перемещение и т.д.

4. Как показать основные плоскости компонентов в сборке?

Для этого нужно включить Просмотр плоскостей:

А затем выбрать значок Скрыть / Показать основные плоскости:

5. Как выбирать спрятанные грани, не применяя функцию Скрыть деталь?

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

6. Как посмотреть на деталь из сборки, не открывая деталь отдельно?

Нажимаем правой кнопкой мыши на интересующую нас деталь и выбираем функцию Окно предварительного просмотра компонента.

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

Хотите узнать больше? Подписывайтесь на наш YouTube-канал и изучайте SOLIDWORKS самостоятельно. Нужно обучение с профессионалами? Переходите по ссылке и выбирайте курс.

Автор: Максим Салимов, технический специалист ГК CSoft, solidworks@csoft.ru

Подробнее..

Российские BIM-технологии проектирование архитектурно-строительной части в Model Studio CS

16.06.2021 16:13:28 | Автор: admin

Введение

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

Model Studio CS современная и мощная российская программная система, обеспечивающая все необходимое для комплексного параллельного трехмерного информационного проектирования.

Продолжая знакомить читателей с материалами, представленными ГК CSoft на вебинаре Унифицированные АРМ на базе Model Studio CS и nanoCAD, который состоялся 20октября 2020г., предлагаем вашему вниманию обзор АРМ Строителя (АР, КМ, КЖ).

В основу АРМ Строителя положен Model Studio CS Строительные решения эффективный и простой в использовании программный продукт для быстрого и удобного создания цифровой трехмерной модели объектов промышленного и гражданского назначения по разделам АР, АС, КМ и КЖ. Несомненным его плюсом является мультиплатформенность: в качестве графической платформы может использоваться и nanoCAD, стремительно набирающий популярность в нашей стране, и AutoCAD версий 2017-2022.

Технология совместной работы с единой базой Model Studio CS

О решениях, на которых базируется коллективная работа, подробно рассказано в статье Российские BIM-технологии: комплексное проектирование на базе Model Studio CS, поэтому здесь ограничимся кратким упоминанием основных моментов.

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

Коллективный доступ к комплексной BIM-модели и управлению инженерными данными информационной модели, структурирование, хранение, визуализация информационных моделей, их проверка на предмет коллизий осуществляются в среде общих данных CADLib Модель и Архив.

Информационная модель в CADLib Модель и АрхивИнформационная модель в CADLib Модель и Архив

В самом начале работы проектировщики, использующие Model Studio CS, подключаются к базе проекта из специализированных приложений с помощью технологии CADLib Проект. Это позволяет осуществлять доступ к актуальным настройкам проекта и 3D-моделям, а также быстро публиковать изменения в общую базу данных.

Экспорт в расчетные системы

Для выполнения прочностного анализа конструкции предусмотрена возможность прямой, без использования промежуточных форматов, передачи 3D-модели здания и данных по нему из Model Studio CS Строительные решения в расчетные комплексы ЛИРА-САПР, ЛИРА-СОФТ и SCAD Office. В случае ЛИРА-СОФТ обеспечена двусторонняя связь: модель можно не только передать для расчетов, но и получить обратно.

Экспорт модели железобетонного каркаса в расчетные комплексыЭкспорт модели железобетонного каркаса в расчетные комплексы

Кроме того, Model Studio CS Строительные решения обеспечивает выпуск проектной и рабочей документации в соответствии с требованиями ГОСТ, включая автоматический расчет объемов работ. Недавно в программе реализована интеграция с системой АВС для разработки сметной и ресурсной документации.

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

Работа с базой данных

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

Model Studio CS Строительные решения, как и вся линейка Model Studio CS, позволяет работать с базой данных строительных элементов, изделий и материалов, встроенной в среду проектирования и не требующей вызова сторонних программ: доступ к ней осуществляется посредством удобного диалогового окна. Более 18000 единиц строительных элементов, хранящихся здесь, содержат параметрические геометрические объекты с необходимым набором атрибутивной информации, а также дополнительную информацию и специальные элементы управления геометрией, обеспечивающие интеллектуальное поведение. Пользователь может самостоятельно пополнять базу данных новыми объектами с помощью встроенного Редактора параметрического оборудования.

База данных строительных элементов и изделий встроена в среду проектированияБаза данных строительных элементов и изделий встроена в среду проектирования

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

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

Ознакомившись с базой данных, сделаем краткий обзор технологий проектирования в Model Studio CS Строительные решения. Прежде всего остановимся на технологии проектирования разделов АР и АС.

Model Studio CS Строительные решения: основные инструменты

Model Studio CS Строительные решение предлагает инструменты, которые обеспечивают размещение в пространстве модели ограждающих конструкций в виде стен, перекрытий и кровли. В новейших версиях появился объект Стена, позволяющий при отрисовке автоматически производить сопряжение в углах поворота и создавать примыкающие соединения. Программа располагает инструментами раскладки стеновых сэндвич-панелей в пределах стен, размещения окон, дверей, технологических отверстий и других объектов, которые обеспечивают взаимодействие со стеной. Кроме того, пользователю доступны средства создания перекрытий с заданным уклоном и расширенный интерфейс для работы с маркером помещения, позволяющий формировать на выходе ведомость отделки помещения и экспликацию полов. Следует отметить, что ведомость полов формируется автоматически при вводе соответствующих данных в свойства объекта. И наконец, Model Studio CS Строительные решения предоставляет обширную базу данных мебели и оборудования.

Размещение ограждающих конструкцийРазмещение ограждающих конструкций

Теперь о технологии проектирования раздела КМ, позволяющей работать с базой профилей металлопроката и сталей по ГОСТ, СТО и ТУ. Отметим, что при изменении нормативных документов база данных пополняется и актуализируется. Обеспечена возможность использовать библиотеку типовых параметрических узлов, а также разрабатывать пользовательские параметрические узловые соединения и сохранять их как библиотечные элементы.

Формирование трехмерной информационной модели по разделу КМФормирование трехмерной информационной модели по разделу КМ

В Model Studio CS Строительные решения реализован функционал, позволяющий генерировать металлический каркас путем ввода основных параметров. При этом отдельно хотелось бы упомянуть некоторые аспекты, касающиеся формирования металлических сборок КМ с последующим сохранением их в базу данных. При создании сборки КМ стало возможным автоматически определять вес изделия. Кроме того, для внесения новых элементов или удаления существующих металлическую сборку не требуется расформировывать. Отслеживание состава сборки при ее редактировании, а также расчет количества и состава подчиненных элементов выполняются в онлайн-режиме.

Отдельная тема технология проектирования кабельных эстакад. База данных содержит огромное количество параметрических объектов (фундаменты, стойки, балки кабельной эстакады). Процесс построения кровли эстакады автоматизирован. В новых версиях Model Studio CS база данных пополнилась узлами сопряжения кровли эстакады: крестообразными и примыкающими соединениями, а также угловым соединением, в котором можно редактировать угол наклона примыкающих частей кровли, а подрезка будет осуществляться автоматически. При работе со стойками и фундаментами поддерживается расстановка объектов с привязкой к рельефу местности.

Кабельная эстакадаКабельная эстакада

Теперь рассмотрим технологию проектирования раздела КЖ. Model Studio CS Строительные решения предоставляет проектировщикам широкие возможности для работы со сборными и монолитными железобетонными конструкциями из базы данных. Например, существует команда, позволяющая производить детальное армирование монолитных конструкций с учетом защитного слоя бетона. В программе заложены такие объекты, как рабочая арматура, сварные арматурные сетки по ГОСТ, арматурные изделия хомуты, шпильки, скобы. После создания конструкции из набора отдельных элементов можно заняться сборкой и маркировкой элементов армирования для последующего сохранения готового изделия в базу данных. По этим арматурным изделиям можно выводить табличные документы в виде ведомости расхода стали, а также групповую спецификацию.

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

Пример армирования столбчатого фундаментаПример армирования столбчатого фундамента

Предусмотрены отдельные команды для работы со свайным полем: в новых версиях Model Studio CS Строительные решения можно одним щелчком мыши сформировать свайное поле по сетке осей либо с одиночной расстановкой свай по пересечению осей, либо с расстановкой свайного куста, также с последующей спецификацией.

Выпуск документации

После формирования модели в Model Studio CS Строительные решения мы можем приступить к выпуску проектной документации. Планы, разрезы и сечения здесь формируются автоматически. Также автоматически по заранее определенным правилам оформляется графика (с возможностью проставить выноски, отметки уровня, оси). Автоматизирован и процесс получения табличной документации в различных форматах (nanoCAD, AutoCAD, MS Word, MS Excel и др.). Пользователь может настроить собственные правила оформления чертежей и спецификаций.

Автоматическая генерация чертежей в Model Studio CS Строительные решенияАвтоматическая генерация чертежей в Model Studio CS Строительные решения

Помимо отчетной документации в виде таблиц, есть возможность сформировать ведомость объемов работ. А если объектам назначены сметные свойства, вы можете с помощью специального инструмента экспортировать данные модели в систему ABC Смета и получить отчетные документы в виде смет.

Формирование ведомости объемов работФормирование ведомости объемов работ

В Model Studio CS Строительные решения при выпуске проектной документации можно учитывать рельеф местности: в пределах строительной площадки создавать модели траншеи, площадки и скважины, получать ведомости объемов земляных масс в зависимости от геологических слоев грунта и формировать продольные профили с учетом строительных конструкций.

Учет рельефа местностиУчет рельефа местности

Заключение

Model Studio CS Строительные решения является гармоничной составляющей комплексной системы проектирования единственной на платформе nanoCAD/AutoCAD, работающей с учетом национальных стандартов и традиций проектирования.

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

Приятным сюрпризом для новых пользователей станет тот факт, что в комплект поставки Model Studio CS Строительные решения входит обширная русскоязычная документация в виде руководства пользователя, учебного пособия, тестовых примеров для получения тех или иных видов спецификаций и чертежей. Кроме того, срок обучения этой системе составляет всего 3-4 дня.

Александр Белкин,
заместитель руководителя
отдела комплексной автоматизации
в строительстве
ГК CSoft
E-mail:
belkin@csoft.ru

Подробнее..

Перевод UML умер, а никто и не заметил?

06.06.2021 16:09:40 | Автор: admin

UML, нам будет тебя не хватать
Unified Modelling Language (UML), разработанный Rational Software и принятый в качестве стандарта Object Management Group (OMG) в 1997 году, призван был стандартизировать множество различных типов графических нотаций, принятых в отрасли разработки ПО.

Моя история отношений с UML началась почти десяток лет назад, когда я стал евангелистом этого языка как моста между ИТ и бизнесом. Я никогда не был полностью убеждён в ценности UML как нотации для моделирования конкретных программных продуктов; моя цель заключалась в использовании UML для описания требуемых структурных и поведенческих свойств, ожидаемых от проектируемой системы.

Откровением для меня стала формальная семантика, связанная с UML Activity Diagrams. Я не мог терпеть неформальные схемы Visio из-за множества неопределённостей в них. Например, что означают две стрелки, исходящие их прямоугольника: выбор или разделение потока на два параллельных пути? Аналогичный пример: две стрелки, указывающие на один прямоугольник, означают, что действие начинается сразу после достижения первым потоком прямоугольника? А может, это OR, XOR или AND? В общем, смысл вы поняли. UML решает эту проблему благодаря введению чёткой и недвусмысленной семантики.


Игра была нечестной изначально: правильного ответа нет

Я по-настоящему вкладывал душу в UML:

  • Я чертил схемы для собственных решений с 2004 по 2015 годы для семи разных работодателей и клиентов почти исключительно с помощью UML.
  • Я проводил буткемпы по UML (для бизнес-аналитиков) у двух крупных клиентов.
  • В качестве кандидатской диссертации я определил ключевое множество дискретной математики, являющееся фундаментом для большинства структурных и поведенческих моделей UML. Я даже написал на Haskell инструмент на основе GraphViz для визуализации этой математики в графическом UML.

Спустя несколько лет, примерно в 2015 году, я осознал, что практически перестал пользоваться UML, как и остальные мои коллеги, а также почти все клиенты из списка Fortune 500, которых я консультировал в последнее время. Что же произошло?

Я знаю: это была смерть от тысячи порезов. И нет, UML не убило бизнес-сообщество из-за его сложности или строгости. Напротив, людям из бизнеса нравилась возможность чётких и недвусмысленных коммуникаций при помощи нескольких новых символов. Айтишники возвысили UML (в своё время этим занимался и я), и они же стали причиной его падения.

Но жертвой стал не UML сам по себе. Если откровенно, UML стал просто побочной потерей. Настоящая резня развернулась в сфере разработки требований, включающей в себя бизнес-аналитику и проектирование. Убийцей стал Agile, а его отравленными стрелами были user stories.

В модели, куда на входе засовывают user stories, а на выходе получают демо (или feature production release), больше нет места для содержательного структурного анализа задач.

В современном дивном новом мире понимание напрямую кристаллизуется в код, готовый к продакшену. Даже моделирование бизнес-структур, по сути, было убито родственной Agile дисциплиной: Domain Driven Design (DDD). Ограниченные контексты инкапсулируют (заметают под ковёр) сложность, чтобы энтерпрайз мог масштабироваться на команды на две пиццы. Компании, использующие BDD и требующие от своих рабочих групп писать спецификации Cucumber, имеют здесь перевес, но этим занимаются очень немногие бизнесы.

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

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


Пример масала-диаграммы

Хотя некоторые используют легковесные техники моделирования наподобие C4, большинство применяемых сегодня диаграмм относятся к типу, который я несколько пренебрежительно называю масала-диаграммами. В конце концов, почему бы не назвать так диаграммы, которые я и сам делаю? Почему масала? Потому что они неформальные; они одновременно покрывают несколько размерностей, они могут быть и структурными, и поведенческими, логическими и физическими. Часто они являются мешаниной визуализаций архитектурной модели 4+1.


Как готовить масала-диаграмму

Системы стоимостью в миллионы долларов, от которых зависят наши жизни и финансы, создаются, финансируются и реализуются полностью на основе этих масала-диаграмм, которые часто не содержат ничего лишнего, кроме нескольких эпиков и user stories.

Автор, ну архитектура ипотечной системы моего банка уж точно не была спроектирована на основе этих ваших ужасных масала-моделей!

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

Неужели мир сошёл с ума? Нет мы просто отказались от инженерного проектирования ПО. Теперь это просто авантюра с кодом. Я не говорю, что те, кто пишет ПО, сами не являются инженерами; чаще всего, это не так. Смысл в том, что на организационном уровне ПО больше не проектируется, как это делается в других сферах, например, в машиностроении. Boeing никогда бы не заказал у Rolls Royce реактивный двигатель на основе подобной неформальной масала-диаграммы.

Однако у масала-диаграмм есть своё предназначение. Если использовать их там, где им место, то они прекрасны. Видите ли, это не спецификации. Их цель вызывать эмоции. Масала-диаграммы ценны, когда нужно вызвать радость в сердце руководителя, для которого они предназначены.

Как бы я ни спорил с моими друзьями из лагеря Agile, я не могу остаться слепым к счастью людей. Мои клиенты и коллеги не только просят больше масала-диаграмм, но и настаивают, чтобы я делал их ещё более масала (чтобы я объединял в них больше архитектурных размерностей!). Зачем же этому противиться?

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



На правах рекламы


Эпичные серверы это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов!

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

RPA инструменты и не только

06.06.2021 16:09:40 | Автор: admin

Однажды на работе мне поставили R&D задачу создать бота, который будет "ходить" по сайту, выбирать товары, заполнять формы и оплачивать покупки. На тот момент мы писали часть Antifraud системы, которая позволяла детектировать ботов в браузере. И с этого момента все началось...

Оглавление

  1. Коротко о RPA

  2. Open source проекты

  3. Платные сервисы

  4. Test Automation

  5. RPA vs Test Automation

  6. Парсинг сайтов и RPA

  7. BPM и RPA

  8. Безопасный RPA...

  9. Пример работы бота на Python

  10. Как детектировать бота?

  11. Выводы

Коротко о RPA

RPA (Robotic process automation) - это система, которая позволяет автоматизировать рутинные задачи (заполнение формы, перенос почты, и пр.), также можно сделать бота, который будет постоянно мониторить цены у конкурента, но это уже совсем другое... Если какое-то действие повторяется, то стоит задуматься над автоматизацией. Но не стоит пытаться автоматизировать все вокруг, хотя этого иногда очень хочется.

Более четкое определение:

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

За время создания своего бота я нашел несколько направлений RPA:

Направления в RPAНаправления в RPA

Open source проекты

Начнем сразу с open source проектов, т.к. они представляют большой интерес.
Рассмотрим инструменты относительно языков программирования:

RPA open sourceRPA open source

Конечно это не все инструменты, но по крайней мере основные, которые мне удалось найти. Я Python разработчик, поэтому рассмотрю только те инструменты, которые попробовал на практике.

Selenium & rpaframework

Объединил 2 технологии в 1 короткий обзор т.к. использовал их для одной и той же задачи: создание бота, который выбирает товары, добавляет их в корзину и оплачивает покупки. Цель: сдетектировать и заблокировать бота, используя fingerprint и треки мыши. О том как детектировать ботов будет в разделе "Безопасный RPA...".

Selenium

SeleniumWebDriver это инструмент для автоматизации действий веб-браузера. В большинстве случаев используется для тестирования Web-приложений, но этим не ограничивается. Очень часто с помощью данного инструмента создаются различные боты.
Selenium IDE - инструмент для создания сценариев быстрого воспроизведения ошибок; расширение Chrome и Firefox, которая будет выполнять простую запись и воспроизведение взаимодействий с браузером.

RPA Framework

RPA Framework - это набор библиотек и инструментов с открытым исходным кодом для RPA, предназначенный для использования с Robot Framework и с Python. Имеет синхронизацию с Selenium и Playwright, библиотека для автоматизации Chromium, Firefox и WebKit с помощью единого API. Входит в набор инструментов Robocorp для автоматизации с открытым исходным кодом.

3 in 1 (Desktop / Web / Mobile)

Robocorp

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

TagUI

TagUI - бесплатный инструмент RPA от AI Singapore, финансируемой программой по ускорению развития ИИ. Проект TagUI является открытым и бесплатным. Его легко настроить и использовать, он работает в Windows, macOS и Linux.

TagUI RPATagUI RPA

Из всех инструментов мне больше всего понравился RPA Framework, у которого есть возможность работать с Playwright, также в этом фреймворке очень удобные selector в отличие от Selenium, что позволяет гораздо быстрее писать код.

Пример на Selenium и на RPA Framework

Selenium

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysfrom webdriver_manager.chrome import ChromeDriverManagerdriver = webdriver.Chrome(executable_path=ChromeDriverManager().install())driver.get("https://www.google.com/")elem = driver.find_element_by_xpath("/html/body/div[1]/div[3]/form/div[1]/div[1]/div[1]/div/div[2]/input")elem.send_keys("Python news")elem.send_keys(Keys.RETURN)driver.close()

RPA Framework

from RPA.Browser.Playwright import Playwrightfrom Browser.utils.data_types import KeyActionlib = Playwright()lib.open_browser("https://www.google.com/")lib.fill_text(selector="input", txt="Python news")lib.keyboard_key(KeyAction.press, "Enter")lib.close_browser()

На мой взгляд у RPA Framework более удобное API.

Платные сервисы

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

RPA productsRPA products

Список ведущих поставщиков RPA на основе матрицы пиковых значений Everest Group для поставщиков технологий RPA 2020:

Everest группирует инструменты RPA в три основных сегмента в зависимости от их возможностей, влияния на рынок и способности успешно поставлять продукт. Everest также выделяет UiPath, Automation Anywhere, Blue Prism, Intellibot и Nividous в качестве лидеров.

UiPath vs Automation Anywhere vs Blue Prism

Компания Blue Prism, основанная в 2001 году, была пионером в секторе RPA и использовала термин Robotic Process Automation. Четыре года спустя генеральный директор UiPath Дэниел Дайнс технически основал UiPath как компанию под названием DeskOver. Однако только в 2015 году она действительно родилась и была переименована в RPA-компанию.

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

VSVS

Изначально более длинная траектория Blue Prism сделала ее идеальным решением. Большинство его клиентов были крупными банковскими и финансовыми учреждениями - одними из немногих организаций, которые могли позволить себе изначально высокую стоимость входа RPA.

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

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

  1. UiPath - 4.6 / 5 звезд с 4722 отзывами

  2. Automation Anywhere оценивает 4,5 / 5 звезд с 4310 отзывами

  3. Blue Prism 4,4 / 5 звезд по 158 отзывам

Что делает UiPath самой популярной платформой RPA?

UiPath превратился в единственную платформу RPA на рынке, созданную для поддержки полного жизненного цикла автоматизации. Портфель продуктов компании продолжает оставаться в авангарде инноваций, постоянно расширяя свои традиционные возможности RPA за счет включения таких инструментов, как интеллектуальный анализ процессов, встроенная аналитика, улучшенные компоненты AI Fabric, RPA на основе SaaS и автоматизация тестирования.

UiPath также считается одним из самых быстрых решений RPA в отрасли - часто в 3-4 раза быстрее, чем другие продукты RPA.

Другие ключевые сильные стороны UiPath:

  1. Long Running Workflows

  2. Machine Learning and Predictive Analytics

  3. Seamless Interconnectivity

  4. Process Document Understanding

  5. Citizen Development

  6. Customer Satisfaction

  7. Flexible Licensing Model and Low Cost of Entry

Оригинал статьи со сравнением: https://www.auxis.com/blog/top-rpa-tools

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

G2 GridG2 GridМини обзор популярных и не очень RPA

UiPath

Самое замечательное в UiPath - это простота использования.

UiPath прост в установке и имеет возможности разработки на основе пользовательского интерфейса. Подробное онлайн-руководство поможет быстро освоиться. Согласно Quadrant Review компании Gartner, UiPath имеет первоклассную команду поддержки клиентов, и в целом UiPath идеально подходит для компаний, стремящихся к быстрому внедрению RPA.

GUI UiPathGUI UiPath

Automation Anywhere

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

GUI Automation Anywhere GUI Automation Anywhere

Blue Prism

Blue Prism, старейший инструмент в индустрии RPA, в последние годы неуклонно растет.

Blue Prism специализируется на сквозной RPA для компаний из списка Fortune. Blue Prism также предлагает высококлассных роботов. Роботы не только очень сложные, но и обладают глубокими возможностями создания сценариев для настройки расширенных сетей RPA. Имеет отличные возможности отладки и потрясающую масштабируемость.

GUI Blue PrismGUI Blue Prism

Microsoft Power Automate

Microsoft Power Automate предоставляет простое и эффективное решение RPA. Самым значительным преимуществом Microsoft Power Automate является простота настройки. Данные из экосистемы Microsoft легко доступны. Легко управлять оркестрацией робота.

WinActor

WinActor - это инструмент RPA, разработанный NTT Group. Он широко используется в таких отраслях, как разработка программного обеспечения и финансы.

GUI WinActorGUI WinActor

Test Automation

Автоматизация тестирования помогает разработчикам и тестировщикам экономить время и увеличивать охват тестированием за счет автоматизации повторяющихся тестовых случаев.

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

Automation Testing Tools

Инструментов ни сколько не меньше чем у RPA.

Вот небольшой список:

Инструмент

Open source

Платная

Selenium

+

Appium

+

SoapUI

+

TestProject

+

Cerberus Testing

+

Katalon Studio

+

IBM Rational Functional Tester

+

Telerik Test Studio

+

TestComplete

+

Ranorex

+

Kobiton

+

Subject7

+

HPE Unified Functional Testing (UFT)

+

Сводная картинка по некоторым инструментам:

QA Automation toolsQA Automation tools

RPA vs Test Automation

Коротко: это практически одно и то же.

RPA и Test Automation можно рассматривать как одно и то же. Компании используют их для автоматизации задач, экономии затрат и освобождения времени сотрудников для других дел.

Сходства:

  • инструменты для обеих практик автоматизируют взаимодействие пользовательского интерфейса.

Различия:

  • сценарии тестирования, созданные для автоматизации тестирования, зависят от тестируемой системы (SUT).

  • RPA не различают, автоматизируют ли они перенос данных в систему бухгалтерского учета или, например, помечают ваши электронные письма.

  • RPA инструменты не зависят от программного обеспечения, в котором запущен процесс.

Парсинг сайтов и RPA

Цели у компаний, которые занимаются парсингом сайтов, разные, но тем не менее такие инструменты есть и некоторые из них являются полноценным RPA инструментом (например, Octoparse).

Process Bots VS Search Bots

Process Bots VS Search BotsProcess Bots VS Search Bots

Сильные стороны RPA:

  • Low Code UX

  • Управление входами и выходами через UX

  • Работа с авторизацией для бизнес-приложений

  • Передача данных в бизнес-процессе

  • Бизнес-шаблоны для определенных шаблонов использования (обслуживание клиентов, финансовые таблицы и т.д.)

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

  • Масштабирование для одновременной обработки десятков тысяч страниц

  • Отсутствие конфигурации и автоматическая обработка для множества типов веб-страниц

  • Поисковые роботы автоматически адаптируются при изменении страниц

  • Богатая индивидуальная конфигурация

  • Всестороннее чтение HTML страницы (Имя автора; UPC продукта)

  • Автоматическое извлечение настроения из текста

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

Но какие боты лучше?

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

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

Сегодня все наши приложения находятся в облаке. А конвейеры данных сильно зависят от неструктурированных данных из интернета. С появлением RPA вывод используемых нами приложений стал значительно более динамичным. Ключевое различие между поисковыми и технологическими роботами заключается в том, что поисковые боты созданы для адаптации к постоянно меняющимся веб-страницам, а RPA прерывается, когда сайты меняются, а точнее когда меняется дом-дерево в html разметке.

Теперь возьмем поискового бота с поддержкой AI. Вводим один сайт например, в Crawlbot Diffbot, ждем несколько минут, и тысячи страниц распознаются и анализируются как страницы продуктов. Загружаем данные в формате JSON или CSV, либо загружаем приложение или панель инструментов с выбранными результатами. Основная технология, лежащая в основе этого варианта использования, возможно будет чем боты RPA. Поисковые боты сами ускоряют чтение и классификацию Интернета!

Инструменты для парсинга

Scrape.do

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

Scrapingdog

Scrapingdog - это инструмент для очистки веб-страниц, который упрощает работу с прокси-серверами, браузерами, а также с CAPTCHA. Этот инструмент предоставляет HTML-данные любой веб-страницы за один вызов API. Одна из лучших особенностей Scraping dog - это наличие API LinkedIn.

ParseHub

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

Diffbot

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

Octoparse

Octoparse выделяется как простой в использовании инструмент для парсинга веб-страниц без кода. Он предоставляет облачные сервисы для хранения извлеченных данных и ротации IP-адресов для предотвращения блокировки IP-адресов. Вы можете запланировать парсинг в любое определенное время. Кроме того, он предлагает функцию бесконечной прокрутки. Результаты загрузки могут быть в форматах CSV, Excel или API.

ScrapingBee

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

Luminati

Luminati - это веб-парсер с открытым исходным кодом для извлечения данных. Это сборщик данных, обеспечивающий автоматизированный и настраиваемый поток данных.

Scraper API

Scraper API - это прокси API для парсинга веб-страниц. Этот инструмент помогает управлять прокси-серверами, браузерами и CAPTCHA, поэтому вы можете получить HTML-код с любой веб-страницы, выполнив вызов API.

Scrapy

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

Import.io

Инструмент для парсинга веб-сайтов с оперативным управлением всеми веб-данными, обеспечивая точность, полноту и надежность. Import.io предлагает конструктор для формирования собственных наборов данных путем импорта данных с определенной веб-страницы и последующего экспорта извлеченных данных в CSV. Кроме того, он позволяет создавать более 1000 API-интерфейсов в соответствии с вашими требованиями. Есть приложение для Mac OS X, Linus и Windows.

BPM и RPA

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

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

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

CAMUNDACAMUNDAСервисы BPM с интеграцией RPA

Camunda

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

Основные преимущества:

  • Проектирование сквозного процесса

  • Согласование сценариев RPA

  • Оперативноенаблюдение задействиями ботов RPA

  • Аналитика RPA

ELMA

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

Выгоды длябизнеса отиспользования RPA + BPM:

  • Снижение издержек нарутинные операции.

  • Масштабирование бизнеса безрасширения штата.

  • Освобождение времени сотрудников наболее интеллектуальный труд.

  • Лучший Customer Experience засчет качества искорости сервиса.

ProcessMaker

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

Безопасный RPA...

Взлом RPA

Можно ли взломать RPA? Да, можно. Например, обработка данных с сайта (загрузка картинок, текста и пр.), откуда робот может скачать зараженный скрипт под видом обычной картинки, а скаченный скрипт может повлиять на работу бота, добавляя новые правила в обработку, или просто остановит его. Много что можно сделать, выбор огромный.

Риски безопасности, на которые стоит обратить внимание:

  • Риски выбора инструмента: выбор нужного инструмента от проверенного производителя. Компании обычно выбирают инструменты, не соответствующие их требованиям.

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

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

  • Раскрытие конфиденциальных данных:malware проникает в систему и создает сценарий при котором данные пользователей утекают в сеть.

  • Отказ в обслуживании: создания необходимых условия для остановки работы бота.

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

Проблема безопасности данных может быть разбита на два тесно взаимосвязанных момента:

  • Безопасность данных

  • Безопасность доступа: Цель - исключить возможность неавторизованного доступа пользователей и манипулирования личными данными, с которыми имеют дело роботы.

RPA для пентеста

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

Продолжение следует...

В следующей статье мы создадим своего бота, рассмотрим какие есть алгоритмы детектирования ботов, которые написаны на Selenium и с помощью RPA. Создадим свой алгоритм, подведем итоги.

Подробнее..

Масштабный проект по внедрению SAP S4HANA в удаленном режиме Гибридный интеграционный ландшафт

08.06.2021 10:08:20 | Автор: admin

В предыдущей нашей статье мы рассказывали о том, какие уроки мы усвоили, как мы обучали коллег удаленно и как проводили тестирование системы. В данной статье речь пойдет об интеграционных ландшафтах. Для реализации решения в рамках нашего проекта мы выбрали гибридный интеграционный ландшафт на базе SAP PO и SAP MII. В данной статье мы рассмотрим особенности систем SAP PO и SAP MII, их предназначение, достоинства и недостатки. А также расскажем о трудностях, с которыми мы столкнулись при реализации проекта в 2020 году.

Итак, по порядку.

Интеграционные платформы: как выбрать?

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

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

Согласно SAP CIO Guide: Process and Data Integration in Hybrid Landscapes, существуют следующие классы интеграционных систем:

Process Integration охватывает интеграцию распределённого между системами/приложениями бизнес-процесса. Наиболее предпочтительные инструменты интеграции на базе ESB (Enterprise Service Bus)

Data Integration охватывает синхронизацию данных между приложениями, базами данных и озером данных вне транзакционного контекста. Наиболее предпочтительные инструменты интеграции на базе ETL (Extract, Transform, Load).

User Integration охватывает все задачи интеграции между сервером приложений и интерфейсами взаимодействия с пользователем.

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

Cross Use Cases остальные сценарии, применяемые для сквозного взаимодействия.

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

Опыт российской практики показывает, что компании в основном делают выбор в пользу таких интеграционных систем, как SAP PO (ранее SAP PI). Однако существуют и другие системы, которые также предназначены для интеграции между системами различных уровней. В нашем случае мы использовали интеграционные системы SAP PO и SAP MII.

Ключевые аспекты использования SAP PO и SAP MII

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

1. SAP PO следует использовать для интеграции процессов в качестве основной Корпоративной сервисной шины (ESB) предприятия (Например, ERP с Банк-клиентом), а также когда требуется:

Использовать репозиторий корпоративных сервисов в качестве центрального репозитория SOA

Использовать поддержку дополнительных стандартов WS (web service), таких как UDDI, WS-BPEL, и задач, WS-RM в корпоративной среде.

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

Использование новых функций, таких как аутентификация конечных пользователей, валидация XML и возможности BAM

Взаимодействие с системами, находящимися за рамками DMZ корпоративной сети.

2. SAP MII следует использовать в основном, когда стоит задача обрабатывать данные уровня заводов (MES, LIMS), которые представлены в разнородных хранилищах, которые требуется организовать и проанализировать, а также, когда нужно:

Получать согласованные отчеты о производственных операциях на разных сайтах.

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

Подключить собственные производственные приложения к данным и рабочим процессам SAP S/4HANA - через стандартные и встроенные адаптеры и инструменты (BAPI/RFC синхронный запрос).

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

Следует отметить, что система SAP MII по своему прямому назначению, помимо выполнения функции интеграционной шины, также дает возможность выполнять оперативные функции с использованием UI/UX-приложений и реализовать процессы по регистрации данных оперативного учета. Однако использование системы SAP MII только как платформы интеграции не дает никаких преимуществ по сравнению другими системами (например, SAP PO).

3. Наряду с отдельным использованием платформ SAP PO или SAP MII (рассматриваемых в данной статье) также нередки случаи совместного использования одновременно двух этих систем, а именно в тех ситуациях, когда:

SAP MII должен взаимодействовать c SAP S/4HANA (и другими системами корпоративного уровня) через SAP PO в интеграционных сценариях, требующих гарантированную доставку.

SAP PO должен использоваться для централизованного управления потоками данных.

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

В SAP MII должны быть реализованы правила и обработки, специфичные для уровня завода.

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

Преимущества и недостатки SAP PI

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

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

Среди недостатков функционала обеих систем отмечены следующие:

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

Вызовы нашего проекта, и как мы с ними справились

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

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

В связи с этим мы пересмотрели весь рабочий процесс, а именно:

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

2. Перешли на scrum-методологию:

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

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

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

3. Хорошей практикой стала демонстрация Клиенту прототипа интеграционного решения. Мы показываем не только интеграцию, но и реализацию бизнес-процессов, и таким образом исключаем неприятные неожиданности.

4. Мы сделали оптимизацию с учетом разных часовых поясов:

Приоритизировали и распределяли задачи в соответствии с часовым поясом членов команд

Планировали ключевые встречи с учетом разницы во времени

С пониманием относились к экстренным запросам во внерабочее время.

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

Пересмотренный подход позволил нам скоординировать работу команд и её в срок.

Выводы

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

В нашем случае при принятии решения об использовании интеграционных систем мы полагались на опыт команды внедрения и опыт наших глобальных коллег, внедрявших системы SAP PO и SAP MII на проектах ранее. Это позволило нам учесть особенности обеих систем и построить эффективную архитектуру.

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

Надеемся, наша статья поможет вам в поиске наилучшего для вас решения. Да пребудет с Вами Сила!

Подробнее..

Как упростить доработки и поддержку хранилища данных?

08.06.2021 12:19:01 | Автор: admin

1. Адаптированная методология Anchor modeling

Архитектура ядра хранилища данных должна соответствовать описанной ниже адаптированной (не оригинальной) методологии Anchor modeling (но не Data Vault).

Тип таблицы

Примеры имени таблицы (в скобках описание)

С таблицами каких типов может быть связана

Обязательный тип поля

Примеры имени поля

Сущности (Anchor, Entity type). Обозначается квадратом

TR_Transaction (полупроводка по дебету или по кредиту), AC_Account (синтетический счет)

Связи, Атрибут сущностей

Суррогатный ключ сущности

TR_ID, AC_ID

Атрибут сущностей (Attribute). Обозначается кругом

TR_TDT_TransactionDate (дата заключения сделки)

Сущности

Суррогатный ключ сущности (является первичным ключом в течение срока действия записи)

TR_ID

Дата и время начала срока действия записи

TR_TDT_FROM

Дата и время окончания срока действия записи (не включительно)

TR_TDT_BEFORE

Атрибут сущностей

TR_TDT

Связи (Tie, Relationship). Обозначается ромбом

TR_AC_DC_Transaction_Account_DrCr (счет главной книги в полупроводке)

Сущности

Суррогатные ключи каждой связанной сущности (вместе с некоторыми атрибутами связей, обозначающими тип связи, образуют составной ключ в течение срока действия записи)

TR_ID, AC_ID

Дата и время начала срока действия записи

TR_AC_DC_FROM

Дата и время окончания срока действия записи (не включительно)

TR_AC_DC_BEFORE

Опциональный атрибут или несколько атрибутов связей

DC (дебет/кредит)

Схема данных примераСхема данных примера

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

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

В ядре хранилища данных не должны использоваться значения NULL, за исключением тех атрибутов связей, которые не входят в составной ключ (обычно это наименования, обозначения, коды, ссылки, выбранные значения, флаги). Если неизвестны начало и/или окончание срока действия записи, то должны указываться принятые условные даты (например, '0001-01-01', '-infinity', '9999-12-31', 'infinity').

Для облегчения создания полиморфных связей двухсимвольный код в именах должен совпадать с двумя последними символами в соответствующих суррогатных ключах, которыми обозначается тип сущностей или атрибут связей (см. ниже). Поэтому в нем необходимо использовать символы алфавита Crockford's base32.

Таблицы типа узел (knot) исключены из адаптированной методологии Anchor modeling. Однако типовое обозначение узла на схеме в виде квадрата с закругленными углами удобно использовать для обозначения атрибутов связей.

Набросок БД может быть сделан (в том числе, офлайн) с помощью наглядных и удобных веб-инструментов Online Modeler или Online Modeler (test version), но сгенерированный ими SQL-код непригоден для использования. Для генерации SQL-кода (включая SQL-запросы) по методологии Anchor modeling все известные компании используют самостоятельно разработанные ими инструменты на основе языка программирования Python и Microsoft Excel.

2. Суррогатные ключи в адаптированном формате ULID

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

В качестве суррогатного ключа должна использоваться адаптированная (не оригинальная) версия ULID (но не UUID), имеющая любой из двух форматов:

  • ttttttttttrrrrrrrrrrrrrrxx (пример: 01F5B023PBG3C48TSBDQQ3V9TR)

  • ttttttttttsssrrrrrrrrrrrxx (пример: 01F5B023PB00448TSBDQQ3V5TR)

где

t дата и время генерации с точностью до миллисекунды (Timestamp) (10 символов или 48 бит), UNIX-time в миллисекундах (UTC)

s счетчик от 0 до 32768, сбрасываемый каждую миллисекунду, (Sequence) (3 символа или 15 бит)

r случайное число (Randomness) (14/11 символов или 65/55 бит)

x тип сущностей (Entity type) (2 символа или 10 бит)

Должна использоваться кодировка и алфавит Crockford's base32.

Генератор ULIDов должен удовлетворять следующим требованиям:

  1. Соблюдение требуемого формата ULIDов

  2. Однократное использование каждого генерируемого ULIDа в качестве суррогатного ключа сущности

  3. Использование (достаточно производительного) криптографически стойкого генератора псевдослучайных чисел или генератора истинно случайных чисел

  4. Монотонное возрастание ULIDов в интервале менее миллисекунды (за счет инкремента случайного числа для формата без счетчика, или за счет счетчика для формата со счетчиком)

  5. Генерация ULIDов в формате (текстовый, бинарный, UUID или целочисленный), наиболее производительном для операций поиска в применяемых СУБД и носителе данных (HDD или SSD)

  6. Пиковая (в течение 5 мс) производительность генерации ULIDов должна быть выше максимальной производительности записи в применяемых СУБД и носителе данных (HDD или SSD) (например, за счет буферизации заранее вычисленных частей ULIDа)

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

3. Указание начала и окончания срока действия записи

Для сохранения историчности данных должен применяться второй тип медленно меняющегося измерения SCD2 с добавлением двух унифицированных полей (столбцов): Дата и время начала срока действия записи (имя столбца с суффиксом _FROM) и Дата и время окончания срока действия записи (не включительно) (имя столбца с суффиксом _BEFORE).

Единственным условием связи записей в таблицах, помимо суррогатного ключа, должно быть одновременное действие (valid time) связанных записей, определяемое унифицированными полями начала и окончания срока действия записи, но не датой загрузки в систему или датой создания записи (transaction time). Данные не должны храниться в форме срезов на отчетные или на текущую дату или за календарный период (например, месяц).

4. Указание даты и времени создания записи

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

Примеры имени поля: TR_TIMESTAMP, TR_TDT_TIMESTAMP, TR_AC_DC_TIMESTAMP.

5. Только внешние источники пунктов классификаторов

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

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

6. Фасетная классификация

Необходимо по возможности использовать фасетную классификацию вместо иерархической классификации.

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

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

  • признак счета активный/пассивный,

  • глава,

  • раздел,

  • счет первого порядка,

  • тип контрагента,

  • срок.

7. Теги

Если есть большое количество атрибутов с логическими значениями true и false, то эти атрибуты удобнее заменить соответствующими тегами, которые можно хранить в одном поле типа array, типа hstore или типа jsonb.

8. Полиморфные связи

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

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

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

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

9. Устранение витрин данных

Каждый отчет должен формироваться непосредственно из реплики ядра хранилища данных.

Нежелательно использовать витрины данных, так как они сводят на нет все достоинства методологии Anchor modeling. Особенно большими недостатками обладают универсальные витрины данных, предназначенные для формирования любых видов отчетности.

10. Типовые SQL-запросы и материализованные представления

Разработка SQL-запросов к базе данных, соответствующей методологии Anchor modeling, трудоемка. Поэтому для облегчения работы системных аналитиков и SQL-программистов могут быть созданы типовые SQL-запросы или материализованные представления, соединяющие сущности с их атрибутами на задаваемую дату. Но использование таких SQL-запросов и материализованных представлений может привести к усложнению БД и снижению производительности. Поэтому для рабочей системы вместо них необходимо использовать автоматическую генерацию SQL-запросов (с использованием языка программирования Python и Microsoft Excel).

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

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

11. Вынесение логики из программного кода в таблицы решений

Логику необходимо по возможности выносить из программного кода на языках программирования, SQL и различных ORM в таблицы решений. Например, в таблице решений может быть закодирован выбор дебетуемого синтетического счета в зависимости от типа операции, категории контрагента и срока погашения финансового инструмента. Таблица решений может быть реализована двумя способами:

  • таблица сущностей правил, к которой привязаны входные атрибуты и один выходной атрибут,

  • таблица связей, соединяющая входные сущности и атрибуты с выходной сущностью либо с выходным атрибутом.

Первый способ очевидно более гибкий и упорядоченный.

Подробнее..

Как я пробовал внедрять DDD. Тактические паттерны

10.06.2021 14:04:32 | Автор: admin

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


Поначалу мне попали в работу легаси проекты, архитектура которых была Transactional Script или Table Module. Модули требовали рефакторинга, решения тех.долгов, встал вопрос о целесообразности рефакторинга и альтернативных реализаций. Как инженер, я решил, что единственный верный шаг прокачать себя, а затем и команду, теоритически, а потом предпринимать стратегические шаги. Если с TS и TM архитектурами я был хорошо знаком, то шаблон Domain Model был знаком только в самых общих чертах по книге Мартина Фаулера. На фоне общения на конференциях, чтения матёрых книг про рефакторингу, SOLID, Agile, пришло понимание почему именно изучение подобных архитектур оправдано: в Enterprise есть смысл стремиться к максимально адаптируемому к изменениям ПО, а для доменной модели изменения требований стоят несравнимо дешевле в реализации. И меня напрягало, что как раз доменные модели я если и применяю, то понаитию, бессистемно, невежественно. Так началось моё знакомство с предметно-ориентированным проектированием.


В этой первой части, о том какие наработки удалось получить команде.


Тактические паттерны


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


Доменная модель


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


  1. Абстрактная модель. Публичные интерфейсы модели, которые могут быть доступны в других слоях. Сами интерфейсы пишутся так, чтобы они наследовали интерфейсы из нашего Seedworks, что позволяет избежать зоопарка в различных проектах. Абстрактная модель первое с чего начинается любой сервис, т.к. содержит в себе ОБЩЕУПОТРЕБИМЙ ЯЗК.
  2. Реализация модели. Internal реализация агрегата, содержатся необходимые проверки, скрываются фабрики, бизнес-методы, утверждения и т.д.

Реализация агрегата


Команда рассматривала следующие способы реализации агрегата:


  1. Свойства с модифицированными set'ерами, в которых сокрыта логика обнаружения изменений. Код получается неоправданно усложнённым, и не совсем понятно зачем. Мы имели такую реализацию, когда ещё оперировали анемичной моделью (вспоминаю как страшный сон).
  2. Aggregate Snapshots. Механизм делает регулярно или по триггеру снимки агрегата и, если что-то поменялось, регистрируется событие.
  3. Иммутабельные агрегаты, порождающие через бизнес-методы новую версию агрегата. В нашей команде прижился 3й вариант он сулит самые большие перспективы для распределённой системы.

Итак, строение агрегата.


  • Анемичная модель. Анемичных модели у нас две: обычная, и "дефолтная", с пустыми объект-значениями и корнем. При этом анемичная модель условная часть агрегата, существующая только для организации жизненного цикла данных, т.е. в репозитории, фабриках.
    • Идентификаторы. Мы используем составной ключ <guid, long>. Первая часть идентифицирует агрегат, вторая его версию.
    • Корень агрегата. Обязательная сущность, вокруг которой и строится ограниченный контекст. С этим элементом у нас были проблемы, мы ожидали что корень будет иммутабельным на всём протяжении жизненного цикла агрегата, однако, практика показала другое, нежели в книгах. Позже слышал на DDDevotion от Константина Густова то же самое.
    • Объект-значения. Простой иммутабельный класс: конструкторы закрыты, фабричные методы открыты.
  • Бизнес-методы. В нашей реализации составной объект, состоящий из предусловий и постусловий. Результат выполнения операции усложнённая монада Result или сложная структура, возвращающая две анемичных модели и результат операции. Результаты операций на данный момент делим на:
    • Успешные.
    • Ошибочные по бизнес-проверкам, которые могут порождать новую версию агрегата, однако, могут иметь место проблемы с постусловиями.
    • Фатальная проблема, когда предусловие говорит о том, что данная операция не может быть выполнена.

Доменные сервисы


Этот слой ответственен за работу с агрегатом. Состоит двух механизмов:


  • Нотификатор доменных сообщений. Декорирует методы агрегата, реализуя его абстракцию. Данный механизм служит для обработки анемичной модели до вызова новой версии анемичной модели и результата операций. Из этих сообщений формируются доменное событие, которое жёсткой схемой отражено в SeedWorks и реактивно помещается в Шину Доменных Событий.
  • Провайдер агрегатов. Данный механизм инкапсулирует репозитории и фабрики, т.е. служит для получения по идентификатору агрегата и поддержки жизненного цикла агрегата. Задача провайдера построить агрегат из анемичной модели, декорировав его методы нотификатором.

Сначала мы пытались реализовать поиск через провайдер с применением спецификации, однако, отловили проблемы с EF. Эти проблемы застали думать о CQS. Теперь CQRS+ES у нас из коробки, т.е. доменные события отражаются на материализованных представлениях, и, в свою очередь, с их помощью происходит поиск нужного агрегата. В случае если агрегат не найден в мат.представлениях, провайдер соберёт агрегат с пустой моделью это удобно тем, что бизнес-методы всегда остаются внутри агрегатов.


Слой приложения


Слой приложений довольно обыденный. Где-то свои обработчики, где-то на основе MediatR, но, в любом случае, всем командам ограниченного контекста надлежит получить из DI-контейнера провайдер агрегатов, а затем в обработчике из него (что?) определённую версию агрегата, у которой уже вызывается бизнес-метод.


Слой сервисов


С сервисами всё интересно. По умолчанию, мы продолжаем использовать .NET Core Web API, т.е. REST, протокол. Однако, REST это про архитектуры TableModule и нельзя использовать глаголы PUT, DELETE для модифицирования агрегата. Контроллеры наших микросервисов повторяют методы агрегата, используя глагол POST, ведь для стратегических паттернов нужны идемпотентные операции. В итоге получается дисфункция использования контроллеров. Возможно, следует использовать gRPC.


Инфраструктурный слой


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


Хранилище и материализованное представление напрямую не привязано к агрегату. Вместо этого, они прослушивают ШДС(шину доменных событий), асинхронно обрабатывая эти события. Из этого не трудно понять, что ШДС становится для нас механизмом масштабирования.


Как это выглядит в итоге


С одной стороны:


Описание Зарисовка
Гексогональная архитектура микросервисов, декомпозированных по субдомену. image
Команда над доменной сущностью порождает новый объект (версию). image
Сравнение версий агрегата и метаданные команды (источник доменного события). image
Для распространений изменений используется ШДС, что открывает возможности для CQRS и ES. image
Версионирование команд и агрегатов должны помочь избежать блокировок и перепроверок при помощи оптимистичных блокирок. Появлется возможность ветвлений-сессий. image

С другой стороны:


  1. Тактические паттерны освоены костяком команды. Каждый может вести свою команду, распространять подход дальше.
  2. Наработки позволяют начинать работу с контестом даже если единый язык беден, оставив от модели лишь корень. По мере уточнения общеупотребимого языка, модель будет расширяться.
  3. Из всех взятых в работу ограниченных контекстов генерируются доменные события пригодные к использованию в смежных ограниченных контекстах.
  4. Предметная сложность полностью в модели. Даже инфраструктурных сложностей нет как таковых понятная работа по материализованным представлениям, обработчикам слоя приложения. Вместе с решением технической сложности, появляется soft-slills сложности.

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




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

Подробнее..

Ускорение проектирования РЧ-, СВЧ-устройств (45)

11.06.2021 18:10:18 | Автор: admin

РЧ-, СВЧ-платы являются одним из самых быстрорастущих секторов в производстве печатных плат. С увеличением количества датчиков IoT, беспроводной электроники и смартфонов легко понять, почему. Но как узнать, работаете ли вы с РЧ или СВЧ-платой? Индустрия печатных плат считает, что любая плата, работающая на частоте выше 100 МГц, является РЧ-платой. Все, что приближается к 2 ГГц, является СВЧ.

Урок 4 Расширенные возможности трассировки РЧ-цепей


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

  1. Дважды кликните по иконке PADS Pro Designer VX.2.x на рабочем столе или выберите
    Меню ПУСК > PADS Pro Tools VX.2.x > PADS Pro Designer VX.2.x.
  2. На стартовой странице PADS Professional Designer нажмите кнопку Open и откройте
    C:\RF Design\Lesson4\PCB\Lesson4.pcb.
    • Если появится диалоговое окно лицензирования, убедитесь, что опция PADS Professional RF Design установлена, и нажмите OK

  3. Убедитесь, что выбрана схема отображения RF Routing. Это обеспечит видимость панели инструментов RF
  4. Доступны 2 специальных инструмента трассировки РЧ-цепей: Add Meander и Route Meander. Опции Add и Route очень похожи по функционалу. Add обеспечивает более точный контроль и поддерживает специальную опцию для тюнинга проводников. Route более прост и удобен в использовании, но в некоторых случаях его функционала может оказаться недостаточно. В этом уроке мы будем использовать оба этих инструмента:
    • Для трассировки антенны TX мы будем использовать инструмент Add Meander. Выберите Add Meander на панели инструментов RF

    • Кликните по пину TX2 усилителя в корпусе BGA, как показано на картинке:

    • По умолчанию Corner Type установлен на Miter. Измените значение на Free Radius и проложите трассу от пина до антенны. Обратите внимание на то каким образом прокладывается трасса
    • Отмените последнее действие. Выполните трассировку заново, но в этот раз установите Corner Type = Miter. Не забудьте установить контрольную точку перед соединением с самой антенной для того чтобы уменьшить длину тейпера
  5. Теперь давайте проложим трассу для TX1, одновременно согласовав ее длину с TX2 при помощи серпантина
    • Если функция не активна, снова выберите Add Meander на панели инструментов
    • Кликните по пину TX1 и начните трассировку
    • Кликните, чтобы зафиксировать трассу (установить контрольную точку) напротив входа антенны
    • Во время трассировки вернитесь в диалоговое окно Meander и измените General Mode на Serpentine
    • Вы должны увидеть серпантин (змейку) там где уже проложена трасса. Настройте параметры серпантина следующим образом:
      • Length: 150
      • Slope Height: 20
      • Gap Width: 50

    • Подключите трассу к антенне. Не забудьте установить контрольную точку непосредственно перед соединением с самой антенной, чтобы минимизировать влияние тейпера
    • Вы должны получить следующий результат:

  6. Давайте проделаем некоторые изменения с трассой
    • Выделите трассу TX2
    • Кликните ПКМ и выберите RF Parameters
    • Для настройки угловой конусности (corner taper) кликните по полю Miter % и установите значение 60
    • Нажмите Apply

  7. Теперь нужно проверить и подкорректировать добавленный серпантин. С помощью диалога RF Parameters можно проверить длину проводника для TX2 и TX1. Для изменения длины серпантина используйте функцию Edit Meander:
    • Выделите верхний сегмент серпантина
    • Кликните ПКМ и выберите Edit Meander
    • Теперь Вы можете отодвинуть верхний сегмент серпантина вверх, чтобы увеличить длину проводника. Отрегулируйте до тех пор, пока длина не будет в пределах 10 mils от ТХ2

  8. После того как мы растрассировали TX сигналы теперь можно перейти к RX. Для трассировки этих 4-х цепей мы будем использовать инструмент Route Meander:
    • Активируйте инструмент Route Meander

    • Ознакомьтесь с диалоговым окном настроек, но не вносите никаких изменений
    • Выберите одну из цепей RX и проложите трассу от пина усилителя (BGA) до порта антенны
    • Повторите этот процесс для всех 4 цепей

  9. Вы также можете использовать стандартные возможности трассировки для работы с РЧ-объектами
    • Удалите одну из проложенных трасс
      • Просто кликните ЛКМ по трассе, указанной на картинке

      • Нажмите кнопку Delete на клавиатуре
    • Нажмите F3, чтобы активировать интерактивную трассировку
      • Проложите трассу от усилителя (BGA) к порту антенны
  10. Обычный проводник может быть преобразован в РЧ-меандр, чтобы вы могли применять расширенные правила или добавлять скосы углов
    • Чтобы выделить весь проводник кликните по сегменту, показанном на рисунке
    • Кликните ПКМ и выберите Selection > Add Partially Selected Traces

    • Кликните ПКМ еще раз и выберите Convert to Meander
    • В диалоговом окне Convert Trace to Meander выберите из списка Group значение PA
    • Нажмите Convert

    • Вокруг трассы появятся области правил подобно тем проводникам, что вы уже растрассировали.
  11. На этом урок 4 завершен.

Тестовые 30-дневные лицензии можно запросить ЗДЕСЬ
Материалы для этого и последующих уроков можете скачать ЗДЕСЬ
Вы также можете посмотреть видеоверсию этого урока:


Предыдущие уроки:
Урок 3 Настройка правил проектирования для РЧ-объектов
Урок 2 Обновление схемы и размещение РЧ-объектов на плате
Урок 1 Создание РЧ-объектов в топологии и схеме

Присоединяйтесь к нам в соц. сетях:
Telegram-канал
Telegram-чат
YouTube

Филипов Богдан pbo, Product Manager по решениям PADS в компании Нанософт.
Подробнее..

Проблемы мониторинга дата-пайплайнов и как я их решал

16.06.2021 00:20:01 | Автор: admin

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

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

Чтобы понять, как все это мониторить, давайте разберемся кто вообще работает с данными, которые мы с таким трудом намайнили:

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

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

Код - запускается следующий в цепочке пайплайн, происходят преобразования, рисуются графики и т.п.

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

Вот примеры:

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

  • Пайплайн стучится в источник с надеждой получить свежие данные, которые появляются в API источника с неопределенной задержкой (привет Apple), пайплан может успешно завершиться как скачав отчет, так и получив сообщение о том, что отчета еще нет. Тут, конечно, можно делать бесконечные ретраи внутри, либо просто ронять пайплайн, но тогда не особо очевидно будет, по какой причине он упал - что-то пошло не так, или данные в источнике еще не подтянулись.

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

ETL как он естьETL как он есть

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

Чего не хватает во встроенных мониторингах систем работы с данными:

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

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

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

Все это превращается в такие вот проблемы:

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

  2. Люди из бизнеса хотят более наглядного отображения состояния данных и системы, чем оно представлено в технических мониторингах.

  3. Статистика, если и собирается, то собирается по техническим проблемам и нельзя понять, насколько эти технические проблемы повлияли на бизнес.

Концепция

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

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

Почему вообще вебхуки?

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

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

  • запустилась ли наша задача 10 раз за последний день?

  • не превышает ли количество падений (определяем падение, если полученное значение > 0, например) 15% от всех запусков за сегодня?

  • нет ли процессов, которые длятся больше 20 минут?

  • не прошло ли больше часа с момента последнего успешного завершения?

  • стартовало ли событие по планировщику в нужное время?

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

Реализация

Я начал с дашборда, дизайн - не моя профессия, так что просто взял за основу дашборд, показывающий состояние крон-джобов на сайте Nomadlist, у меня получилось как-то так:

Дашборд состояния серверов Sensorpad средствами SensorpadДашборд состояния серверов Sensorpad средствами Sensorpad

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

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


Для инженера тут все понятно:

  • скрипт отрабатывает быстро (еще бы, простая крон-джоба);

  • монитор вполне живой, 25 минут назад обновился;

  • места еще с запасом (цифра 53 в левом нижнем углу - это последнее принятое значение);

Для людей из бизнеса тут тоже все просто:

  • монитор зеленый;

  • статус прописан в первой же строчке;

  • никакой лишней информации;

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

И насколько просто такое настроить?

  1. Создаем вебхук в самом сервисе, они там называются сенсорами, по аналогии со всякими штуками из физического мира.

  2. Настраиваем крон-джобу на сервере, которая будет отсылать события со значением свободного места в процентах:

    df -h |grep vda1 | awk  '{ print $5 }'| sed 's/.$//' | xargs -I '{}' curl -G "https://sensorpad.link/<уникальный ID>?value={}" > /dev/null 2>&1
    
  3. Присоединяем к этому вебхуку монитор, называем его: количество свободного места (но можно еще и другие, например, то, что события уходят по графику означает, что сервер не упал)

  4. Настраиваем правила, по которым монитор меняет свой статус.

  5. Присоединяем каналы для отправки уведомлений.

  6. Добавляем монитор на один или несколько дашбордов.

А можно поподробнее?

Для вебхуков я пока что сделал саму простую имплементацию:

  • базовый вебхук, который будет нужен для 80% проектов;

  • cron-вебхук, который ожидает события в заданное через cron-синтаксис время;

  • chain-вебхук, который умеет отслеживать события от процессов, соединенных в цепочки;

главное в нашем деле - не усложнять интерфейсыглавное в нашем деле - не усложнять интерфейсы

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

Догфудинг в действииДогфудинг в действии

Дальше создаем тот самый монитор - квадратик, меняющий статус и цвет.

Можно даже иконку выбратьМожно даже иконку выбрать

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

Теперь, собственно то, из-за чего я и написал эту балалайку: правила и гибкая логика.

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

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

На скриншоте выше видно уже созданные правила, но я покажу как они создаются.

Например правило, которое можно сформулировать так: "установи статус Warning, если за последний день было больше 5 джоб, которые работали дольше 10 секунд".

А вот какие вообще можно выбирать проверки в каждом из пунктов:

И какие реальные кейсы можно покрыть этими правилами?

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

  • Cron job, Airflow DAG или любой другой процесс не запустился по расписанию;

  • 20% задач одного и того же пайплайна за день не отработали как надо;

  • связанная задача в пайплайне не запустилась через 2 минуты после окончания родительской задачи;

  • интервал между запусками двух задач меньше 1 минуты (похоже, у нас две конкурентные джобы);

  • с момента последнего успешного завершения пайплайна прошло 2 часа (а данные должны считаться каждый час);

  • время работы пайплайна уже целых 20 минут (а должен был отработать за 5, что-то подвисло).

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

А теперь - статистика!

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

Немного полезных и не очень графиковНемного полезных и не очень графиков

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

Вот такой концепт. Чего не хватает?


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

Потыкайте его вживую, заодно зацените, какой я у мамы дизайнер лендингов: https://sensorpad.io

Подробнее..

Краеугольный камень анализа. Часть 1

16.06.2021 02:22:40 | Автор: admin

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

Я придерживаюсь убеждения, что задача анализа в IT это борьба с неопределённостью, с целью прийти к пониманию, которое выражается в виде модели. Неважно как представлена модель: в виде диаграммы, текста, таблиц, всё равно это модель. Модели бываю разные: модель проблемы, решения, предметной области, модель бизнеса, модель системы, разные модели. И статья целиком состоит из моделей, где будет использоваться простой вымышленный случай, когда потребовалось создание системы. Клиент: Пекарня ООО Три яблока, которая специализируются на производстве выпечки с начинкой из яблок. Заказ: Информационная система поддержки нового продукта пекарни на всех этапах жизненного цикла продукта. Итак, допустим бизнес-аналитики собрали все бизнес-требования, описали все бизнес-процессы. Системные аналитики описали модель данных и процессы на системном уровне. А разработчики реализовали систему по этим описаниям. Тестировщики тоже отработали, критических багов нет. А клиент говорит: Это не то, что нужно! Давай разбираться, где что-то в анализе могло пойти не так. Нас интересует только проблемы анализа.

Нам потребуется следующая иерархия уровней абстракций:

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

Этих крупных уровней достаточно, чтобы определить следующие возможные проблемы анализа:

  • Модели не соответствует решаемой задаче аналитика.

  • Модели не согласованы внутри себя.

  • Модели не согласованы между собой.

  • Реализация по моделям не соответствует тому, что требуется пользователям и бизнесу.

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

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

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

А если эти два способа совместить, получим приближение к Agile. В нем эти способы закреплены следующими 2-мя принципами:
1. Частая поставка работающего программного обеспечения;
2. Общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта.

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

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

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

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

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

Задача анализа это борьба с неопределённостью, с целью прийти к пониманию, которое выражается в виде модели.

А что есть модель? Что описывают модели? Если убрать из рассмотрения парадигмы, то в сухом остатке (исходные, базовые, основные) модели описывают, как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом. Дополнительными моделями и элементами моделей могут выступать события, интерфейсы и состояния.

Но основой, вокруг которой всё строится это: субъект, действие, объект. При этом без разницы в каком виде построена модель: BPMN, Use case или UML Диаграмма последовательности. Всё равно, это модель как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом.

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

Напомню проблемы, которые нужно решить:

  • Модели не согласованы внутри себя.

  • Модели не согласованы между собой.

Для этого нужно выставить первое требование к моделям: Модели на всех уровнях абстракции должны представить собой систему.

Есть еще одна проблема, которую я указал в начале доклада:

  • Реализация по моделям не соответствует тому, что требуется пользователям и бизнесу.

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

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

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

Если подходить напрямую, то вероятнее всего вы попробуете построить верхеуровневую модель бизнеса. Поискав различные представления, скорее всего найдете Business Model Canvas Александра Остервальдера. И в этом табличном представление обнаружите элементы, которые могут оказать непривычными, если до это вы описывали только операционную деятельность организации. Вы можете попробовать использовать Архитектурные фреймворки, BIZBOK или TOGAF. Но без конкретных примеров они представляют собой теоретические абстракции. По моему мнению, сложность в том, что они созданы не для того, чтобы кого-то научить, они нужны для тех, кто уже знает и понимает, и хочет систематизировать знания.

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

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

И с этим выводом формируется Краеугольный камень анализа:
1) Модели на всех уровнях абстракции должны представить собой систему.
2) Назначение элементов системы определяет система.
3) Назначение самой системы находится на вышестоящем уровне абстракций. То есть его определяет вышестоящая система (экосистемы).

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

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

Есть еще технические приемы. Как много вы думали над тем, почему часть User Story после слова чтобы очень тяжело написать? И почему критерии INVEST именно такие?

Шаблон User Story:

Как <субъект>, я хочу/могу <выполнить деятельность или получить объект>, чтобы <зачем или почему>.

INVEST критерии хорошей User Story:

Independent независимая от других историй;
Negotiable обсуждаемая, отражает суть, а не детали;
Valuable ценная для клиентов, бизнеса и стейкхолдеров;
Estimable оцениваемая по сложности и трудозатратам;
Small компактная, может быть сделана командой за одну итерацию;
Testable тестируемая, имеет критерии приемки.

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

В 2020 в руководство по Scrum добавлен понятие Цель продукта, а рамках планирования особое внимание уделяется вопросу Почему для цели спринта. Agile сосредоточен на верхней части пирамиды абстракций. Авторы не глупые люди, они понимают, что это залог успеха.

Для проработки вопроса назначения и ограничений вместе с Agile подходом можно использовать дополнительные методики: Дизайн мышление, Impact mapping и JTBD. Все они хорошие, рекомендую попробовать практиковать. Но тут есть большое НО это не будет работать, если у вас команда неопытных аналитиков. Несмотря на кажущуюся легкость и заявленную опору на простой здравый смысл использовать Agile могут только квалифицированных специалисты с достаточным опытом. Потому что Agile игнорирует уровни абстракций. А в Scrum, по идее, вообще нет аналитиков, есть кроссфункциональная команда, которая работает, не обращая внимание на уровни абстракции.

Примечание

Даже с профессионалами, это возможно только для одной команды из 7-9 человек, как только у вас появляется большой проект и 3-4 команды, то требуется архитектура, модели, проектирование.

Итак, Agile это подход, который делает упор на организационные способы решения задач с опытными профессионалами. Используя различные приемы, указанные ранее, можно получить некоторое представление о назначении и ограничениях, в виде набора стикеров, job stories и mind map.

А есть ли более строгий, аналитический способ понять назначение и ограничения?

Этому будут посвящена вторая часть статьи.

Подробнее..

Краеугольный камень анализа. Часть 2

18.06.2021 00:22:38 | Автор: admin

Потребуется достроить пирамиду абстракций. За основу я использовал метамодели OMG Business Motivation Model и Open Group ArchiMate.

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

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

Оказывается, движущей идеей было создание пекарни с самыми вкусными яблочными пирогами. Это его vision. Логично, что у такой пекарни должен быть свой фирменный, самый вкусный яблочный пирог. Уметь делать его - является целью. А какой пирог является самым вкусным? Только свежий. Значит, нужно обеспечить длительное сохранение свежести это задача. Клиент рассчитывает, что реализация этой цели принесет ему ценность в виде дохода, а покупателям качественный товар.

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

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

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

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

Общий вид модели мотивации и стратегии, а также связь с моделью бизнеса. Пробежимся еще раз: Третья колонка слева это: Vision, Цели, Задачи. Элементы слева это ценности, которые представляются по достижению целей. Далее колонка в центре это способы: Миссия для достижения Vision, детализуется в Стратегии для достижения целей, далее стратегии детализируется в тактики для решения задач. Вторая колонка справа это средства реализующие способы. Это Бизнес-модель в интерпретации Остервальдера для выполнения миссии, Продукты, реализующие стратегии и операционная деятельность, реализующая соответствующие тактики. Последняя колонка это нижележащий уровень абстракций с бизнес-процессами, привычными для бизнес-аналитиков.

Метамодель

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

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

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

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

Добавим в таком представлении элементы стратегии и мотивации, который мы получили ранее.

Свернем их в один элемент, получим краеугольный камень анализа.

И вот ключевой вопрос:
Можно ли хорошо построить модель операционной деятельности без понимания стратегии и мотивации?

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

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

Примечание

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

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

А еще, наверно, можно развернуть мысль: Если у вас команда профессионалов, то неважно по какой методологии они работают.

Подробнее..

BAдайджест, май 2021 подкаст сКарлом Вигерсом, Docs asCode

18.06.2021 00:22:38 | Автор: admin

Всем привет! Встречайте свежий дайджест ссамыми сочными статьями замай.

Вскобках возле заголовков уровень сложности статьи (Normal * Hard ** Expert ***) ипримерное время наизучение материала

Business Analysis

Подкаст. MBA220: Thoughtless Design with Karl Wiegers(**, 32мин). Карл Вигерс продолжает радовать нас своим опытом. Вэтот раз онделится принципами иуроками, которые извлек изнекачественного дизайна, атакже рассказывает, чтоВы можете сделать, чтобы помочь всоздании дизайна.

Нужнали сертификация для бизнес-аналитика?(**, 10мин). Все осертификацииВА: список популярных, какие преимущества каждая даёт инужнали сертификация вообще.

Docs asCode: введение впредмет(**, 21мин). Автор делится многолетним опытом, приобретенным напути кDocs asCode, атакже рекомендациями повнедрению этого фреймворка.

Business Analyst: Tools and Principles for Professional Self-Development(*, 16мин). Структурированный набор материалов, который поможет обнаружить изаполнить пробелы всвоих навыках. Статью готовил аналитик с15+лет опыта, всоавторстве сдругими опытными БА.

Как проводить интервью сзаказчиком(*, 11мин). Кирилл Белявский делится секретом проведения успешных интервью.

User Experience inProduct(*, 8мин). Как исследования ианализ пользователей помогут увеличить значимость вашего продукта для конечных пользователей.

Моделирование данных: обзор(**, 6мин). Встатье автор раскрывает понятие моделирование данных, атакже делится оптимальной пошаговой инструкцией поприменению.

Цикл статей про бизнес-анализ напресейле. Статья первая, или почему всем нужен БА?(*, 5мин). Старт цикла статей ороли изадачах бизнес-аналитика напресейле. Впервой части: что такое пресейл, роль ивлияние бизнес-аналитика наэтом этапе, артефакты, которые могут понадобиться.

Расширяем кругозор

Этический антидизайн. Разработка продуктов, которые невызывают привыкания(*, 6мин). Оглавных принципах антидизайна, атакже когнитивных искажениях, которые располагают кзалипанию набесполезной/произвольной информации.

SCRUM: Гибкое управление продуктовыми направлениями(*, 9мин). Третья часть изцикла статей, окотором говорил впрошлом дайджесте. Вэтой части предложена система метрик для измерения ианализа процесса гибкого управления продуктовыми направлениями.

Frustrating Design Patterns That Need Fixing: Birthday Picker(*, 16мин). Подробный обзор неудачных шаблонов проектирования поля для выбора даты рождения.

Как работать сбэклогом иприоритизацией фич взрелом продукте(*, 8мин). CTO одной изпродуктовых компаний делится опытом приоритезации фич врамках канбан-процесса.

Three Levels ofPain Points inCustomer Experience(*, 8мин). Что такое болевые точки вклиентском опыте, накаких уровнях взаимодействия возникают ипонять какие наиболее критичны.

Left-Side Vertical Navigation onDesktop: Scalable, Responsive, and Easy toScan(*, 12мин). Статья овесьма непривычном подходе кпостроению навигации, когда она находится невшапке сайта, анаместе левой боковой панели: каким доменам подходит, преимущества ирекомендации поиспользованию.

Все, что выхотели знать про диалоговый UX/UIв проектировании чат-ботов(*, 9мин). Встатье покрыто определение диалогового UX/UI-дизайн, есть пошаговые рекомендации счего начать, атакже годные лайфхаки для проектирования сценариев для чат-бота.

Какие рефералки работают: сбонусами для себя, для того парня или для обоих? Исследование(*, 4мин). Саммари исследования видов рефералок.

The role ofpassword verification atsign up(*, 7мин). Анализ практик реализации поля ввода пароля.

UX-Roadmapping Workshops: Agenda + Activities(**, 16мин). Содержательная статья осоздании дорожных карт UX.

6способов снизить когнитивную нагрузку отинтерфейса(**, 12мин). Если вычувствуете, что ваш интерфейс перегружен, тоэта статья подкинет вам инсайтов отом, как сохранить нервные клетки ваших пользователей.

UI& UXmicro-tips: Volume five(*, 4мин). Коллекция небольших, нополезных подсказок поUI/UX.

Подробнее..

Распознавание эмоций в записях телефонных разговоров

21.06.2021 02:14:29 | Автор: admin

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

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

1) Empath

В 2017 году был основан японский стартап Empath. Он создал платформу Web Empath, основанную на алгоритмах, обученных на десятках тысяч голосовых образцов японской медицинской технологической компании Smartmedical. Недостатком платформы является то, что она анализирует только голос и не пытается распознать речь.

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

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

2) Центр речевых технологий

В составе программного продукта Smart Logger II компании ЦРТ есть модуль речевой аналитики QM Analyzer, позволяющий в автоматическом режиме отслеживать события на телефонной линии, речевую активность дикторов, распознавать речь и анализировать эмоции. Для анализа эмоционального состояния QM Analyzer измеряет физические характеристики речевого сигнала: амплитуда, частотные и временные параметры, ищет ключевые слова и выражения, характеризующие отношение говорящего к теме [2]. При анализе голоса первые несколько секунд система накапливает данные и оценивает, какой тон разговора был нормальным, и далее, отталкиваясь от него, фиксирует изменения тона в положительную или отрицательную сторону [3].

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

3) Neurodata Lab

Компания Neurodata Lab разрабатывает решения, которые охватывают широкий спектр направлений в области исследований эмоций и их распознавания по аудио и видео, в том числе технологии по разделению голосов, послойного анализа и идентификации голоса в аудиопотоке, комплексного трекинга движений тела и рук, а также детекции и распознавания ключевых точек и движений мышц лица в видеопотоке в режиме реального времени. В качестве одного из своих первых проектов команда Neurodata Lab собрала русскоязычную мультимодальную базу данных RAMAS комплексный набор данных об испытываемых эмоциях, включающий параллельную запись 12 каналов: аудио, видео, окулографию, носимые датчики движения и другие о каждой из ситуаций межличностного взаимодействия. В создании базы данных приняли участие актеры, воссоздающие различные ситуации повседневного общения [4].

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

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

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

Empath

ЦРТ

Neurodata Lab

Разрабатываемый сервис

семантический анализ

-

+

+

+

русский дата-сет

-

нет

+

+

дата-сет спонтанных эмоций

+

-

+

В качестве материалов для создания русскоязычного эмоционального дата-сета со спонтанной речью мне была предоставлена база записей телефонных разговоров от IT-компании Эм Си Арт.

Общий алгоритм работы разрабатываемого сервиса выглядит следующим образом.

Блок-схема алгоритма обработки звонкаБлок-схема алгоритма обработки звонка

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

  1. Шумоочистка RNNoise_Wrapper

  2. Диаризация pyAudioAnalysis

  3. Транскрибация vosk-api

  4. Анализ эмоций текста dostoevsky

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

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

Я выбрала пять наиболее часто используемых признаков:

  • мел-частотные кепстральные коэффициенты (MFCC)

  • вектор цветности

  • мел-спектрограмма

  • спектральный контраст

  • тональный центроид (Tonnetz)

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

Сначала я попробовала обучить простые классификаторы библиотеки scikit-learn:

  • SVC

  • RandomForestClassifier

  • GradientBoostingClassifier

  • KNeighborsClassifier

  • MLPClassifier

  • BaggingClassifier

В результате обучения на дата-сете Emo-DB получилось достичь точности распознавания 79%. Однако при тестировании полученной модели на размеченных мной записях телефонных разговоров, точность оказалась равной всего 23%. Это подтверждает тезисы о том, что при многоязычной классификации и переходе от модельных эмоций к спонтанным точность распознавания значительно снижается.

На составленных мной дата-сетах получилось достичь точности 55%.

База данных

Количество классов

Количество записей

Модель

Точность

Emo-DB

4

408

MLPClassifier

79.268%/22.983%

MCartEmo-admntlf

7

324

KNeighborsClassifier

49.231%

MCartEmo-asnef

5

373

GradientBoostingClassifier

49.333%

MCartEmo-pnn

3

421

BaggingClassifier

55.294%

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

Далее я попробовала обучить сверточную нейронную сеть на дата-сете MCartEmo-pnn. Оптимальной архитектурой оказалась следующая.

Точность распознавания такой сети составила 62.352%.

Далее я провела работу по расширению и фильтрации дата-сета, в результате чего количество записей увеличилось до 566. Модель заново была обучена на этих данных. По итогу точность распознавания увеличилась до 66.666%. Это говорит о необходимости дальнейшего расширения набора данных, что приведет к увеличению точности распознавания эмоций по голосу.

График истории обучения и матрица ошибок полученной CNNГрафик истории обучения и матрица ошибок полученной CNN

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

Сервис Gateway API производит аутентификацию пользователей по стандарту JSON Web Token и выполнять роль прокси-сервера, направляя запросы к функциональным микросервисам, находящимся в закрытом контуре.

Разработанный сервис был проинтегрирован с Битрикс24. Для этого было создано приложение Аналитика речи. В понятиях Битрикс24 это серверное приложение или приложение второго типа. Такие приложения могут обращаться к REST API Битрикс24, используя протокол OAuth 2.0, а также регистрировать свои обработчики событий. Поэтому достаточно было в сервере добавить роуты для установки приложения (по сути регистрация пользователя), удаления приложения (удаление аккаунта пользователя) и обработчик события OnVoximplantCallEnd, который сохраняет результаты анализа записей в карточках связанных со звонками CRM-сущностей. В качестве результатов приложение добавляет расшифровку записи к звонку и комментарий с оценкой успешности разговора по пятибалльной шкале с прикреплением графика изменения эмоционального состояния по каждому участнику разговора.

Заключение

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

Данная работа выполнялась по заказу компании Эм Си Арт в рамках ВКР бакалавра образовательной программы "Нейротехнологии и программирование" университета ИТМО. Также по этой теме у меня был доклад на X КМУ и была принята на публикацию в "Сборнике трудов Конгресса" статья.

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

Список источников

  1. Давыдов, А. Классификация эмоционального состояния диктора по голосу: проблемы и решения / А. Давыдов, В. Киселёв, Д. Кочетков // Труды международной конференции "Диалог 2011.". 2011. С. 178185.

  2. Smart Logger II. Эволюция систем многоканальной записи. От регистрации вызовов к речевой аналитике [Электронный ресурс]. Режим доступа: http://www.myshared.ru/slide/312083/.

  3. Smart logger-2 не дремлет. Эмоции операторов call-центров и клиентов под контролем [Электронный ресурс]. Режим доступа: https://piter.tv/event/_Smart_logger_2_ne_drem/.

  4. Perepelkina, O. RAMAS: Russian Multimodal Corpus of Dyadic Interaction for Studying Emotion Recognition / O. Perepelkina, E. Kazimirova, M. Konstantinova // PeerJ Preprints 6:e26688v1. 2018.

Подробнее..

Что нам стоит дом построить? (часть 2)

21.06.2021 12:17:59 | Автор: admin

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

Напомню, что в результате анализа мы пришли к следующей структуре объекта:

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

Таким образом, есть большое количество сущностей с разнообразным атрибутивным составом, который нужно хранить, тратя как можно меньше ресурсов, и расширять который хотелось бы также с минимальными усилиями.

Какие есть варианты?

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

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

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

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

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

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

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

А что у нас?

Второй вариант - это использование специализированных документоориентированных (или документных, как больше нравится) баз данных, реализующих NoSQL-подход к хранению и обработкенеструктурированной или слабоструктурированной информации. Наиболее часто данные хранятся в виде JSON объектов, но с предоставлением производителями СУБД инструментария для доступа к данным внутри этих структур.

У такого подхода, применительно к проектируемой системе, можно выделить несколько плюсов:

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

  • ограничиваем ситуации случайного воздействия на данные - модифицировать json объект гораздо сложнее, чем данные в колонке.

  • проще описывать объекты в коде - иногда можно вообще не описывать структуру документа в коде, а работать прямо с полями в JSON.

Но есть и минусы:

  • невозможно нативно реализовать проверки данных при размещении в хранилище.

  • валидацию данных придется проводить в коде.

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

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

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

Делаем прототип

Возьмем гипотезу, что NoSQL-подход для нашей системы применим как минимум не хуже, чем классический. Для ее проверки создадим прототип, в рамках которого реализуем оба подхода. В качестве СУБД возьмем Postgre, который уже давно умеет хорошо работать с JSON полями.

Создадим следующие таблицы:

Для описания объектов в табличном виде:

  • r_objects, базовые данные по объектам: тип, дата создания и ссылка на хранилище атрибутов.

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

Для описания объектов в виде JSON:

  • objects. Данные по объектам, где в поле data формата jsonb хранятся искомые атрибуты.

Остальные таблицы - это различные вспомогательные хранилища.

Реализуем в коде 5 разных типов объектов, для каждого из них описав программную структуру, механизм извлечения данных из хранилища и наполнения этими данными самих объектов.

Методика тестирования

Для тестирования обоих подходов хранения данных используем следующие методы:

  • добавление данных по объекту. Критерий успешности: объект с данными появился в хранилище, метод вернул в ответе его идентификатор.

  • обновление данных по объекту. Критерий успешности: данные в хранилище были изменены, метод вернул отметку об успехе. Удаление данных в системе не предусматривается, поэтому удаление объекта является операцией, аналогичной обновлению.

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

Генерация запросов будет происходить в 20 параллельных потоков по 50 запросов в каждом потоке. Для того, чтобы тестирование было действительно показательным с точки зрения производительности, предварительно наполним базу 200 млн. объектов.

Тестирование показало следующие результаты:

График по тестированию табличного хранилищаГрафик по тестированию табличного хранилищаГрафик по тестированию NoSQL-хранилищаГрафик по тестированию NoSQL-хранилища

Первая (высокая) часть графика - это получение объектов по случайной странице - пагинация. Здесь в обоих случаях пришлось применить небольшой трюк - так как Postgres не агрегирует точное число строк в таблице, то узнать, сколько всего записей на объеме данных теста простым count - это долго, и для получения количества записей пришлось брать статистику данных по таблице. Также время получения данных на страницах свыше 10000-й неприлично велико, поэтому верхняя планка для получения случайного номера страницы была установлена в 10000. Учитывая специфику нашей системы, получение пагинированных данных не будет частой операцией, и поэтому такое извлечение данных применяется исключительно в целях тестирования.

Вторая (средняя) часть графика - вставка или обновление данных.

Третья (низкая) часть графика - получение данных по случайному идентификатору.

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

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

Результаты тестов на 40000 запросов приведу в виде таблицы:

Табличная

NoSQL

Объем хранилища

74

66

Среднее количество операций в секунду

970

1080

Время тестирования, секунды

42

37

Количество запросов

40000

40000

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

Что получилось?

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

Подробнее..

Создание терминала для СКУД и УРВ

21.06.2021 12:17:59 | Автор: admin

Вступление

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

Историю можно начать с того, что наша компания очень долгое время сотрудничает со всемирно известной сетью фастфудов - KFC (на территории Беларуси и Украины). Головной болью такой сферы, как HoReCa, был и будет учет рабочего времени сотрудников. Учитывая огромную текучку кадров, в том числе и обычных студентов, которые пришли подработать на непродолжительное время, становится сложно проконтролировать, сколько часов отработано тем или иным сотрудником. Плюс немаловажным моментом стало то, что сотрудники часто перемещаются с ресторана на ресторан, а это требует дополнительного контроля. Как же быть?

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

Поэтому был придумал предельно простой и быстрый сценарий действий на терминале:

  1. Прийти на рабочее место, подойти к терминалу и пройти идентификацию (приложить палец, карту к считывателю или ввести PIN)

  2. Выбрать на тачскрине Работа, после чего отправиться на свое рабочее место и приступить к работе

  3. При необходимости перерыва подойти к терминалу, пройти идентификацию, выбрать Перерыв

  4. При возвращении на рабочее место - подойти к терминалу, пройти идентификацию, выбрать Работа

  5. По окончанию рабочей смены подойти к терминалу, пройти идентификацию и выбрать Завершить работу.

То есть все события должны были фиксироваться на терминале, после чего все данные залетали бы на облако системы рабочего времени TARGControl. И там, административным персоналом, формировались табели и отчеты по объектам (ресторанам), что позволило бы корректно начислять заработную плату сотрудникам.

Разработка

Имея на руках техническое задание, была разработана структурная и функциональная схема. Далее пошло самое интересное: мы начали рассматривать различные варианты одноплатных компьютеров, которые бы смогли обеспечить нужный функционал терминала. Среди вариантов были следующие компьютеры: Banana Pi M4, Orange Pi PC+, ODROID-C4, NanoPi M4 и Raspberry PI Computer Module 3+. Произведем небольшое сравнение данных моделей.

Banana Pi M4

Orange Pi PC+

ODROID-C4

NanoPi M4

Raspberry PI CM3+

Память

Слот MicroSD с поддержкой расширения до 256 ГБ и флэш-память eMMC 8 ГБ с поддержкой до 64 ГБ

TF-карта (макс. 32ГБ) / слот для карты eMMC

8 ГБ флэш-память EMMC

1x разъем EMMC (доступно 8/16/32/64 ГБ)

1 слот Micro SD

нет встроенной eMMC, но есть разъем eMMC,
1 слот для MicroSD до 128 GB

8 GB eMMc + поддержка 1 слота microSD

RAM

1 GB DDR4 (опционально 2 GB)

1GB DDR3

4GB DDR4

Двухканальный 2GB DDR3-1866

1GB LPDDR2 SDRAM

CPU

Realtek RTD1395 ARM Cortex-A53 Quad-Core 64 Bit 1.8 GHz

H3 Quad-coreCortex-A71.2 GHz

Amlogic S905X3 Quad-Core Cortex-A55 ARMv8.2-A 64-bit 1.5GHz

RK3399- Cortex-A72 + Quad Core Cortex-A531.8 GHz

Broadcom BCM2837B0 с четырьмя ядрами Cortex A53 1.2 GHz

GPU

Mali 470 MP4 GPU OpenGL ES 1.1/2.0

Mali400MP2 GPU 600MHz
с поддержкой OpenGL ES 2.0

Mali-G31, поддержка OpenGL ES 3.2 и API Vulkan последнего поколения

Mali-T864поддержка OpenGL ES1.1/2.0/3.0/3.1, OpenCL, DX11 и AFBC

Broadcom VideoCore IV

Сеть

Ethernet 10/100/1000 Мбит / с
Опциональный USB-ключ Wi-Fi. Поддержка PoE

10/100 Ethernet RJ45

RJ45 Ethernet порт (10/100/1000)

Порт Gbps Ethernet

10/100 для подключения маршрутизатора или коммутатора с функцией PoE

После детального изучения и анализа цены (все модели находились в примерно одном ценовом диапазоне на момент их анализа - 2019 год), мы все же пришли к выводу, что лучше всего подойдет Raspberry PI Computer Module 3+. Почему Raspberry ? Да, некоторые характеристики уступают конкурентам, однако главным преимуществом стало то, что по Raspberry банально больше поддерживаемых библиотек и лучше техническая поддержка, т.к Raspberry на рынке с 2012 года и вокруг него сформировалось активное комьюнити.

Решение со встроенной памятью eMMC, предусмотренное в CM3, позволяет не использовать флеш-карту в качестве носителя ОС. Большое количество циклов перезаписи eMMC повышает надежность и срок службы памяти по сравнению с флеш-картами. При этом мы зарезервировали разъем для SD карт. Сразу можно сказать, что заявленной памяти для терминала хватает с лихвой, ибо сохраняемые события весят от силы пару килобайт. Что касается хранения фотографий, то здесь все сложнее: программно мы поставили ограничение в 5000 фото, но так как у нас зарезервирована флеш-карта, то данный лимит можно расширить до приемлемого значения.

Разработку управляющей платы мы начали с организации необходимых питающих напряжений. На нашей плате нам необходимо было обеспечить 3 значения напряжений: 5.0В, 3.3В и 1.8В. Внешний источник питания у нас 12В 3А. Для получения 5В и 3.3В мы использовали схему на основе широтной импульсной модуляции. Для источника питания 1.8В мы задействовали линейный понижающий преобразователь. Это выглядит, примерно, следующим образом.

Схема питания терминалаСхема питания терминала

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

Отметим также и схему защиты питания внешних считывателей, представленную ниже.

Схема защиты питания считывателя от диверсийСхема защиты питания считывателя от диверсий

То есть если закоротить питание, считыватель уйдет в защиту (питание считывателя отключится), а терминал продолжит работу. Номиналы резисторов R51 и R52 задают выходной ток. Изменяя номинал резистора R51 можно менять ток ограничения в значительных пределах (у нас стоят заданные на схеме номиналы исходя из рассчитанной нами нагрузки).

Питание мы организовали, самое время перейти к периферии.

К слову, Raspberry поддерживает UART-интерфейс и 2 USB версии 2.0. Через один из доступных USB мы решили организовать доступ к Ethernet с помощью микросхемы LAN9514 . Второй USB используется для подключения периферии, например индикатор алкоголя. Также задействовав GPIO для подключения кнопок, электромагнитных замков, защёлок, алкостестера в дискретном режиме работы и картаприемников.

Схема реализации Ethernet и USBСхема реализации Ethernet и USB

У CM3 на борту всего 2 UART. Один нам пригодится для организации интерфейса RS-485, а второй - debug. Поэтому мы использовали микросхему FT4232HL, для увеличения количества интерфейсов. У нее есть входной интерфейс USB, который поддерживает связь с LAN9514, он же в свою очередь коннектится с CM3.

Схема расширения количества UART-овСхема расширения количества UART-ов

Вот теперь у нас стало больше на целых 4 UARTa (задействуем всего 2). Один используется для подключения биометрического модуля отпечатков пальцев от южнокорейского производителя Suprema-SFM6020-OP6-8M/16M (8M - 5К отпечатков, 16М- 25К отпечатков).

Второй для подключения карточного модуля 7941D (поддерживает 2 частоты Emarine (125 кГц) и Mifare (13,56 МГц).

Suprema-SFM6020-OP6-8MSuprema-SFM6020-OP6-8M

Один из выделенных UART, как и планировали, мы задействовали под RS-485, позволяющий подключать внешние карточные или биометрические считыватели, а также передавать информацию во внешние системы при необходимости интеграции. Схема 485-го представлена ниже.

RS-485RS-485

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

Что касается интеграции с другими системами традиционным для СКУД способом, для передачи минимальной информации у нас организован выходной Wiegand. Есть и два входных Wiegand'а для подключения внешних считывателей. Ниже представлены их электрические принципиальные схемы.

Входной WiegandВходной WiegandВыходной WiegandВыходной Wiegand

Немаловажным моментом будет, что терминал имеет 2 реле для управления замком, турникетом или шлагбаумом. Рассмотрим данный момент на примере подключения турникета (стандартная ситуация для СКУД). Есть два режима управления турникетом, потенциальный режим и импульсный. При потенциальном режиме управления для разблокировки турникета в направлении А срабатывает выход L1 OUT (в направлении В выход L2 OUT). При окончании данного времени или при совершении прохода выходной сигнал возвращается в исходное состояние.

В импульсном режиме для разблокировки выхода L1 OUT и L2 OUT срабатывают кратковременно, посылая управляющий импульс на турникет (обычно 0,2-0,3 секунды). При получении импульса турникет разблокируется в соответствующем направлении на время 5 секунд либо пока не будет совершен проход в данном направлении.

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

Например, для работы с турникетами PERCo в контроллере должен быть установлен импульсный режим управления. Для этого время срабатывания сигналов L1 OUT и L2 OUT должно быть установлено в пределах от 0,2 до 1 секунды.

Подключение турникета PERCoПодключение турникета PERCo

Как описано в самом начале статьи, по нашему техническому заданию, на терминале должна была быть организована фотофиксация, поэтому решили выбрать камеру от Raspberry, которая в терминалах имеет 2 исполнения:

  1. RPi D - 72.4 градуса обзор, 5 mpx, размер камеры 25x24 мм (старое исполнение).

  2. RPi G - 160 градусов обзор, 5 mpx, размер камеры 25x24 мм (теперь используем только этот вариант).

Схема организации интерфейсов DSI и CSIСхема организации интерфейсов DSI и CSI

Выбирая дисплей, выбор снова пал на знакомый бренд - 7-ми дюймовый touch-screen от Raspberry с разрешением 800x480 и DSI интерфейсом.

Исходя из размеров дисплея, считывателя и общей компоновки плат, были определены габариты корпуса для терминала - 210 x 173 x 44. Корпус решено было сделать цельнометаллическим алюминиевыми с гальваническим покрытием, что обеспечивало хотя бы минимальную вандалоустойчивость. Дисплей, конечно же, так не защищен.

Корпус терминалаКорпус терминала

Собрав все воедино мы получили терминал данного вида.

Знакомьтесь, терминал D1!Знакомьтесь, терминал D1!

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

На данный момент с 2019 года нашей компаний было продано более 500 терминалов данной модели, а это показывает, что решение оказалось весьма успешным и надежным. В данной статье я коснулся лишь одной части - железа, однако большая работа была проделана и над прошивкой терминала. В следующей статье я расскажу, как реализована программная часть терминала. В случае возникновения вопросов или критических замечаний, прошу последовать в комментарии для бурного обсуждения!

Подробнее..

Категории

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

© 2006-2021, personeltest.ru