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

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

Перевод О том, что происходит, когда в поиске Google используют слово vs

01.07.2020 16:06:10 | Автор: admin
Случалось у вас такое: ищете что-нибудь в Google и вводите после искомого слова vs, надеясь на то, что поисковик автоматически предложит вам что-то, немного похожее на то, что вам нужно?


Ввод vs после искомого слова

Со мной такое бывало.

Как оказалось, это большое дело. Это приём, который, при поиске альтернативы чему-либо, способен сэкономить массу времени.

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

  1. Лучший способ изучить что-то новое заключается в том, чтобы выяснить, чем это, новое, похоже на то, что уже известно, или чем новое от известного отличается. Например, в списке предложений, появляющемся после vs, можно увидеть что-то такое, о чём можно сказать: А, так, оказывается, то, что я ищу, похоже на это, мне уже знакомое.
  2. Это простой приём. Для того чтобы им воспользоваться нужно, в буквальном смысле, несколько секунд.
  3. Слово vs это чёткое указание, говорящее Google о том, что пользователя интересует прямое сравнение чего-то с чем-то. Тут можно воспользоваться и словом or, но оно далеко не так сильно выражает намерение сравнить что-то с чем-то. Поэтому, если воспользоваться or, Google выдаст список предложений, в котором более вероятно появление чего-то постороннего.


Обрабатывая запрос bert or, Google выдаёт предложения, касающиеся Улицы Сезам. А запрос bert vs даёт подсказки по Google BERT

Это заставило меня задуматься. А что если взять те слова, что Google предложил после ввода vs, и поискать по ним, тоже добавляя после них vs? Что если повторить это несколько раз? Если так, можно получить симпатичный сетевой граф связанных запросов.

Например, он может выглядеть так.


Эго-граф для запроса bert с радиусом 25

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

Расскажу о том, как строить такие графы.

Автоматизация сбора vs-данных из Google


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

http://suggestqueries.google.com/complete/search?&output=toolbar&gl=us&hl=en&q=<search_term>

URL-параметр output=toolbar указывает на то, что нас интересуют результаты в формате XML, gl=us задаёт код страны, hl=en позволяет указать язык, а конструкция q=<search_term> это как раз то, для чего нужно получить результаты автозавершения.

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

Давайте со всем этим поэкспериментируем, начав поиск, скажем, с запроса tensorflow.

Первый шаг работы заключается в том, чтобы обратиться по указанному URL, воспользовавшись следующей конструкцией, описывающей запрос: q=tensorflow%20vs%20. Вся ссылка при этом будет выглядеть так:

http://suggestqueries.google.com/complete/search?&output=toolbar&gl=us&hl=en&q=tensorflow%20vs%20

В ответ мы получим XML-данные.

Что делать с XML?


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


Проверка полученных результатов

Я, при проверке результатов, пользовался следующими критериями:

  • Рекомендованный поисковый запрос не должен содержать текст исходного запроса (то есть tensorflow).
  • Рекомендация не должна включать в себя запросы, которые были признаны подходящими ранее (например pytorch).
  • Рекомендация не должна включать в себя несколько слов vs.
  • После того, как найдено 5 подходящих поисковых запросов, все остальные уже не рассматриваются.

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

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


5 результатов

Следующая итерация


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


Поиск результатов автозавершения для уже найденных слов

Этот процесс можно продолжать, изучая ещё не исследованные слова из столбца target.

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

Эго-графы


Сетевой граф, который я вам показывал в начале статьи, это так называемый эго-граф (ego graph), построенный, в нашем случае, для запроса tensorflow. Эго-граф это такой граф, все узлы которого находятся на каком-то расстоянии от узла tensorflow. Это расстояние не должно превышать заданного расстояния.

А как определяется расстояние между узлами?

Давайте сначала посмотрим на готовый граф.


Эго-граф для запроса tensorflow с радиусом 22

Вес ребра (weight), соединяющего запрос A и B, мы уже знаем. Это ранг рекомендации из списка автозавершения, изменяющийся от 1 до 5. Для того чтобы сделать граф неориентированным, можно просто сложить веса связей между вершинами, идущими в двух направлениях (то есть от A к B, и, если такая связь есть, от B к A). Это даст нам веса рёбер в диапазоне от 1 до 10.

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

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

Рассматриваемый эго-граф имеет радиус (radius) 22. Это означает, что добраться до каждого запроса, начиная с вершины tensorflow, можно, пройдя расстояние, не превышающее 22. Взглянем на то, что произойдёт, если увеличить радиус графа до 50.


Эго-граф для запроса tensorflow с радиусом 50

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

И всё это построено на основе одного единственного ключевого слова.

Как рисовать подобные графы?


Я, для рисования такого графа, использовал онлайн-инструмент Flourish.

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

Как создать эго-граф с заданным радиусом?


Для создания эго-графа с заданным радиусом можно воспользоваться Python-пакетом networkx. В нём есть очень удобная функция ego_graph. Радиус графа указывают при вызове этой функции.

import networkx as nx#Формат исходных данных#nodes = [('tensorflow', {'count': 13}),# ('pytorch', {'count': 6}),# ('keras', {'count': 6}),# ('scikit', {'count': 2}),# ('opencv', {'count': 5}),# ('spark', {'count': 13}), ...]#edges = [('pytorch', 'tensorflow', {'weight': 10, 'distance': 1}),# ('keras', 'tensorflow', {'weight': 9, 'distance': 2}),# ('scikit', 'tensorflow', {'weight': 8, 'distance': 3}),# ('opencv', 'tensorflow', {'weight': 7, 'distance': 4}),# ('spark', 'tensorflow', {'weight': 1, 'distance': 10}), ...]#Построить исходный полный графG=nx.Graph()G.add_nodes_from(nodes)G.add_edges_from(edges)#Построить эго-граф для 'tensorflow'EG = nx.ego_graph(G, 'tensorflow', distance = 'distance', radius = 22)#Найти двусвязные подграфыsubgraphs = nx.algorithms.connectivity.edge_kcomponents.k_edge_subgraphs(EG, k = 3)#Получить подграф, содержащий 'tensorflow'for s in subgraphs:if 'tensorflow' in s:breakpruned_EG = EG.subgraph(s)ego_nodes = pruned_EG.nodes()ego_edges = pruned_EG.edges()

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

Например, storm это опенсорсный фреймворк для распределённых вычислений в реальном времени. Но это ещё и персонаж из вселенной Marvel. Как вы думаете, какие поисковые подсказки победят, если ввести в Google запрос storm vs?

Функция k_edge_subgraphs находит группы вершин, которые невозможно разделить, выполнив k или меньшее число действий. Как оказалось, тут хорошо показывают себя значения параметров k=2 и k=3. Остаются, в итоге, только те подграфы, которым принадлежит tensorflow. Это позволяет обеспечить то, что мы не слишком удаляемся от того, с чего начали поиск, и не уходим в слишком далёкие области.

Использование эго-графов в жизни


Давайте отойдём от примера с tensorflow и рассмотрим другой эго-граф. В этот раз граф, посвящённый ещё кое-чему такому, что меня интересует. Это шахматный дебют, получивший название Испанская партия (Ruy Lopez chess opening).

Исследование шахматных дебютов



Исследование Испанской партии (ruy lopez)

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

Теперь давайте рассмотрим другие примеры использования эго-графов.

Здоровое питание


Капуста! Вкуснятина!

Но что если у вас возникло желание заменить прекрасную, несравненную капусту на что-то другое? Вам в этом поможет эго-граф, построенный вокруг капусты (kale).


Эго-граф для запроса kale с радиусом 25

Покупаем собаку


Собак так много, а времени так мало Мне нужна собака. Но какая? Может что-то вроде пуделя (poodle)?


Эго-граф для запроса poodle с радиусом 18

Ищем любовь


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


Эго-граф для запроса coffee meets bagel с радиусом 18

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


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


Эго-граф для запроса the office с радиусом 25

Итоги


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

Пользуетесь ли вы какими-нибудь необычными приёмами при поиске в интернете?



Подробнее..

Григорий Бакунов об электронном голосовании

06.07.2020 02:17:13 | Автор: admin

Григорий Бакунов


Директор по распространению технологий Яндекса Григорий bobuk Бакунов в эфире Точки на Эхе Москвы поделился мнением о системе голосования, которая использовалась на выборах в городскую думу в 2019 году и на голосовании по вопросу изменения конституции в 2020. Получился любопытный разбор технических деталей для неспециалистов. На Хабре уже была хорошая публикация на эту тему.


Ниже приведена стенограмма эфира, который провёл Александр plushev Плющев. Его реплики выделены полужирным.


Я не делал этого сам, но я помог другому человеку поучаствовать в этом онлайн, поэтому весь процесс я всё-таки посмотрел, и теперь я его знаю.


То есть он голосовал не тайно? Была нарушена тайна голосования? Я прошу обратить на это внимание центризбирком.


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


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


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


Так, что ты имеешь в виду? Прежде всего?


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


Поясни, что это значит. Чем это чревато?


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


То есть ты сейчас как эксперт заявляешь, что электронное голосование может подвергаться последующему изменению записей о нём, верно?


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


Давай-давай, интересно.


Я покопал большое количество дополнительной информации. И вот статья, которую ты мне скинул Спасибо тебе большое за неё, потому что я бы, конечно, сам не взялся, а так я просто проверил. Действительно, выяснилось, что довольно простым набором действий можно подтвердить, что голосование было устроено Вот как сейчас, смотрите. Вы заходите на сайт. Для простоты, mos.ru. Вы получаете там, грубо говоря, разрешение или бюллетень на голосование. Там генерируется особенная строчка в вашем собственном браузере, и после этого, внимание, эта строчка отправляется на сервер, который называется elec.moscow. Я пошёл специально посмотреть по адресам, где находятся эти замечательные сервера, которые называются elec.moscow. И там, внезапно, знаете, такие странные штуки: московский минздрав, штука, которая, вот я до сих пор не знаю, что такое Moscow District Council. Ты мне можешь сказать? Я не знаю.


Районный совет?


Ну, вероятно Я не знаю, что это такое. Тем не менее, это всё московские государственные организации. То есть когда нам говорили, что вот этот сайт голосования, который будет эту промежуточную страницу выдавать, он будет на независимых узлах Ну, вот настолько они независимые. То есть они принадлежат московскому правительству. Это те узлы, по которым смог пройти я. В чём здесь фокус. В том, что вы получаете действительно уникальный идентификатор, который вроде как mos.ru не знает. Но этот промежуточный сайт, который назвается elec.moscow, он его всё равно получает. И этого в принципе достаточно по времени для того, чтобы идентифицировать и связать вас как человека, пользующегося mos.ru...


Смотри, в результате ты выяснил уже две вещи: первая вещь, что голосование можно подменить, верно?


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


И второе, что его можно проконтролировать.


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


У главного редактора, ты имеешь в виду.


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


Не знаю.


Наверное, заволновался. Ну, ты понял меня.


Да.


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


Подожди, что за сайт ты имеешь в виду?


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


Ты имеешь в виду constitution.observer?


Да-да. Что-то такое там было. Я, к сожалению, не очень запоминаю...


Нет, боюсь, не то. Я, правда, не знал даже о таком.


Ты можешь посмотреть, у нас с тобой где-то в новостях была ссылка на этот сайт. Нет: observer2020.mos.ru. Я тебе сейчас пришлю ссылку, чтобы ты посмотрел на неё. Так вот, на самом деле, на этом сайте очень интересно смотреть за происходящим. Я не очень понимаю, по какой причине там возникают такие флуктуации, когда иногда ноль, иногда одна, а иногда пятьдесят записей в один блок попадает, но, допустим, что это нормально. Но когда выяснилось, что этот сайт по какой-то причине периодически падает, ломается, при том, что заходит на него пять инвалидов Это я сейчас не про конкретных людей, а в смысле пять людей, которые изредка что-то нажимают. Пять, десять, пятнадцать, несколько сотен человек. Это, в общем-то, всё мелочи для вебсайта, конечно. У меня возникает вопрос о квалификации тех людей, которые этот сайт запустили. И, конечно, когда выяснилось, что в работе этого сайта были прямо конкретные проблемы. Например, было несколько часов, когда данные по этим самым закрытым блокам вообще не показывались, то есть создавались нулевые файлы, и историю их было совершенно не посмотреть. И, насколько я знаю, эта история до сих пор не исправлена. Нам остаётся только верить в то, что в блокчейне в этот момент не происходило никаких изменений, потому что нас же не допускают к самому блокчейну, нам предоставляют только вот такой веб-интерфейс, в котором мы можем посмотреть, что в блоке номер 1452184 ноль транзакций. Или одна транзакция.


Да-да-да, есть такое дело.


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


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


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


Да, но ты говоришь, что возможность того, чтобы эти фальсификации были, оставлена.


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


Понятно. Слушай, ещё хотел несколько штук Для меня очень комичная ситуация, что сайт, который нам очень долго рекламировали, 2020og.ru, вот он упал утром первого дня голосования и до сих пор, главное, не вставал. Там, по сути, есть информационный сайт, и есть на его поддомене сайт, на котором проходит голосование. Вот информационный сайт упал и лежит. И не встаёт. То есть формально, если бы это было единственное место, где можно узнать о поправках в конституцию, то вы бы больше нигде не узнали, потому что всё, он лежит. Что они сделали. Они просто сделали переадресацию на голосование. Если вы заходите на 2020og.ru, то вы уходите на голосование. И вам говорят, можете вы проголосовать или нет. Всё. Всё остальное закончилось. Это ЦИКовский проект, это уже не ДИТ, это ЦИК делал, центризбирком России. И вот, видимо, это из того же ряда, о котором говорил Григорий Бакунов, насчёт высочайшей квалификации, с которой всё это сделано. Ну, потому что, что тут можно сказать. Это что, не рассчитали нагрузку и поняли, что даже если его поднимут, то лучше и не надо? Или что, объясни.


Ну, у меня нет никакого объяснения. Я думаю, что причина здесь в том, что сайт просто откровенно не выдерживал нагрузку. У программистов, вообще у технарей, которые делают сайты, есть такая традиция: мы, прежде чем запускать какой-нибудь сервис, его, есть такое хорошее слово, обстреливаем. Мы прогоняем через него большой поток ненастоящего, как будто пользовательского, трафика, проверяя, что сайт выдерживает нагрузку. В данном случае, судя по всему, этим никто не озаботился. Вот мы получили этот результат. А то, что на этом сайте с обзёрвером блоков происходило с ошибками, тебя совершенно не удивляет, да? То есть, когда выяснилось, например, что не формируются отчёты, которые вроде бы нам обещали. Что там будут прямо настоящие наблюдатели за голосованием, которые должны по отчётам смотреть...


Отчёты это то, что ты можешь скачать оттуда?


Да. Когда оно просто не формировалось. То есть, нет, не так, вру. Оно формировалось. Видимость того, что отчёты есть, была. Просто отчёты были нулевой длины.


А, это вот то, о чём писали Открытые Медиа насчёт сбоя, который Слушай, а почему произошёл этот сбой, о которых писали Открытые Медиа? Давай я просто напомню, в чём там было дело. Главное, что ДИТ Москвы признал, что сбой произошёл. Организаторы плебисцита не рассчитали размер файлов и забыли, что при многодневном голосовании следует обозначать не только время, но и дату. С вечера первого дня голосования по поправкам к конституции департамент информационных технологий Москвы больше 12 часов публиковал пустые выписки из блокчейн-системы для наблюдения за ходом электронного голосования, обнаружили Открытые медиа. Как удалось выяснить изданию, неполадка произошла из-за проблем, связанных с размером файла. Но не объясняется, почему, собственно, размер файла таковым оказался, непредсказуемым.


Я не знаю, а какой размер-то был непредсказуемым? Нечётный или что? Что такое непредсказуемый размер? Вы заранее знали, какое количество людей придёт голосовать. Было заранее известно, что больше миллиона человек. Какие там могут быть размеры файла? По утверждениям специалистов и по редким замечаниям человека, который всем этим руководил, я не знаю, можно назвать его специалистом или нет, вся проблема была в том, что...


Ты про начальника управления смарт-проектов правительства Москвы Артёма Костырко?


Да-да. В смысле, что у него была прямая речь о том, что они не успевали из блокчейна забирать все данные, которые нужно было выкладывать в отчёт. Но, прошу прощения, а проверить вы это не могли заранее? Вот опять же Я не знаю Вот была такая же история с голосованием в мосгордуму. Это уже второе такое голосование, и в нём по-прежнему просто детские ошибки. И вот, повторюсь ещё раз. У нас, у технарей, есть простое правило. Ну, давайте я на автомобильный лад что ли переведу. Если вы сидите в машине, которая должна вас провезти, я не знаю, там, тысячу километров, а у вас на приборной панели кнопочки отваливаются. Вы будете на такой машине ехать? Не знаю, как вы, а я нет, потому что я думаю, что в двигателе то же самое. Кнопочки тоже не работают. В смысле, в двигателе не работает ничего. Не дай бог взорвётся. И такая же логика у меня в отношении этого проекта. Я на него смотрю, я вижу, как он работает по внешним признакам, и думаю, что внутри там всё настолько же ужасно.


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


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


Кто-то один из нас издевается над московскими властями.


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

Подробнее..

Как с помощью веб-скрапинг и Puppeteer проанализировать аукционы Christies, Sothebys и Phillips. Кейс от Lansoft

29.06.2020 10:05:23 | Автор: admin
Как Web Scraping помог собрать нам данные по официальным коллекциям как у Белгазпромбанка.

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

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

Для чего используется Web Scraping?

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


Команда Lansoft достаточно успешно освоила данный метод. Поэтому хотим поделиться с вами одним из кейсов по сбору данных для анализа датасэтов предметов искусства для нью-йоркской компании Pryph.

Pryph анализируют знаменитые аукционные дома такие как Christies, Sothebys и Phillips и резюмируют выводы о популярности различных авторов.

Кстати на этих аукционах были куплены несколько картин в нашумевшем деле Белгазпромбанка и Виктора Бабарико. По нашему мнению эти сделки никак нельзя назвать незаконными (ссылка news.tut.by/culture/349226.html)

Для работы мы выбрали инструмент Puppeteer. Это JavaScript библиотека для Node.js, которая управляет браузером Chrome без пользовательского интерфейса.

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

На самом деле есть более оптимальные способы скрапинга сайтов средствами node.js
(описаны тут habr.com/ru/post/301426).

Причины выбора Puppeteer в нашем случае были:

  • анализ всего 3 сайтов с понятными разделами и структурой;
  • активное продвижение данного инструмента компанией Google;
  • эмуляция работы реальных пользователя на UI без риска попасть в бан, как потенциальные DDOS атаки.


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

Для примера мы вставили кусок кода, написанного на Puppeteer для извлечения ссылок картинок лотов с аукционного дома Phillips:

image

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

image

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

www.phillips.com/detail/takashi-murakami/HK010120/110

www.sothebys.com/en/buy/auction/2020/contemporary-art-evening-auction/lynette-yiadom-boayke-cloister?locale=en

Например, на картинке выше мы видим имя автора TAKASHI MURAKAMI, название картины Blue Flower Painting B и данные по цене в $231,000-359,000. Все необходимые поля мы собирали и записывали в csv файлы, разбитые по годам.

Выглядело это так:

image

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

Результаты работы можно найти на сайте pryph.org/insights

Но в работе с Puppeteer есть некоторые нюансы:
  1. некоторые ресурсы могут блокировать доступ при обнаружении непонятной активности;
  2. эффективность Puppeteer не высока, ее можно повысить за счет троттлинга анимации, ограничения сетевых вызовов и т. д.;
  3. необходимо завершать сеанс, используя экземпляр браузера;
  4. контекст страницы/браузера отличается от контекста ноды, в которой работает приложение;
  5. использовать браузер, даже в Headless режиме не так эффективно и быстро по времени для больших анализов данных.
Подробнее..

Что такое алгоритм?_? Часть 3.1 Эволюция памяти

05.07.2020 08:18:54 | Автор: admin

Идём в глубь острова сокровищ с названием "Алгоритм".


Title


Задача


Перед Вами новая статья серии "Что такое алгоритм?". И снова непростая задача. Нам необходимо "нырнуть глубже" в структуры памяти живого организма. К сожалению, в ракурсе, предлагаемом статьёй, это направление еще исследовано слабо. Что делает материал, приведённый далее, более сложным по сравнению с излагаемым в предыдущих частях, в которых использовалась близость с методами "генетических алгоритмов", автоматизированных систем управления, систем машинного обучения с учителем и подкреплением. Поэтому прокладывать тропинку в глубь неизведанных "территорий" процессов памяти придется во многом самостоятельно. С одной стороны это очень интересно. Ведь мы с Вами первопроходцы! А с другой стороны есть опасность "заблудиться". . Чтобы приободрить в начале дороги, могу лишь сказать, что путь один раз уже пройден, туры сложены вдоль нашей дороги, карта местности прорисовывается, а клад в конце пути обещает быть внушительным.


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


Для вскрытия структуры памяти потребуются все результаты, полученные в предыдущих статьях серии (Часть 1 "Действие", Часть 2 "Исполнение", Часть 3 "Память"). Без перечисленных там выкладок читать дальше будет сложнее.


Давайте приступим.


Эволюция цепочек


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


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

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


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


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


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


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



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


Этап "Зарождение действия"


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


Как организм может повлиять на действие? Он может его использовать или не использовать. Он может его использовать изредка и часто. Он может исполнять его периодически.


Для организма в ситуации с едой, целесообразно использовать действие("Двигаться") время от времени:


  1. передвинулся в новое место;
  2. остановил движение;
  3. некоторое время не используй движение (вместо него попробуй поесть в новом месте);
  4. продолжи с пункта 1.

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


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


Первый алгоритм собран! Он тривиален, но уже может работать (помогать организму выжить). Его реализация доступна даже на биологической элементной "функциональной базе", а у программиста эта простая задача даже интереса не вызовет. Но перед тем как усложнить программисту ТЗ, давайте введём структуру описания "коммита" (этапа эволюции памяти).


Для каждого этапа развития памяти необходимо указать следующие сведения:


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

Пример эволюционного фактора Универсальное описание Требуемые дополнительные функции Добавляемый тип алгоритма
Двигаться полезнее чем находиться в одном месте Время от времени организм выполняет действие и это ему полезнее чем не выполнять "Накопление потенциала разрядка исполнением" Бесконечный цикл для исполнения операции с настраиваемым интервалом

stage action


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


Этап "Формирование торможения"


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


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


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

stage suppression


Этап "Формирование рефлекса"


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


Пример эволюционного признака Универсальное описание Требуемые дополнительные функции Добавляемый тип алгоритма
Полезнее двигаться-убегать при наличии опасности чем оставаться на одном месте Организм обязательно начинает выполнение действия при наличии признака "Возбуждение", то есть старт разрядки по признаку Бесконечный цикл со спящим ожиданием установки флага для исполнения операции

stage excitation


Этап "Универсализация"


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


Первой рассмотрим универсализацию нескольких ограничений.


Пример эволюционного фактора Универсальное описание Требуемые дополнительные функции Добавляемый тип алгоритма
Вредно убегать при наличии в текущем месте запаса еды или особи для спаривания Время от времени организм может выполнять действие, но не начинает его выполнение при наличии ограничивающего признака("1") или при наличии ограничивающего признака("2") - Бесконечный цикл со спящим ожиданием (снятия флага1) OR (снятия флага2) для исполнения операции

stage suppression2


Универсализация нескольких признаков для рефлекса представлена далее.


Пример эволюционного фактора Универсальное описание Требуемые дополнительные функции Добавляемый тип алгоритма
Убегать от хищника и убегать от огня полезнее чем оставаться на одном месте Время от времени организм может выполнять действие, но обязательно его выполняет при наличии признака("1") или при наличии признака("2") - Бесконечный цикл со спящим ожиданием (установки флага1) OR (установки флага2) для исполнения операции

stage excitation2


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


Этап "Соревнование стратегий"


Как и прежде этап начинается с неприятного подарка среды, подготовленного для "многострадального" организма. Этот "подарок" возможность нахождения и "еды", и "опасности" в одном месте. Организму никак не выработать алгоритм поведения на основе типов алгоритмов, которые имеются в его арсенале. Значит "придётся" развиваться.


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

stage competition


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


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


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


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


Этап "Группировка признаков"


Цепочки памяти во всех предыдущих этапах были односвязными. То есть в них запоминалась (то есть укреплялась) и взвешивалась (то есть оценивалась пользой) одна связь "признак-действие". Для разбора группировки признаков нужно запоминать больше связей. На этом этапе появляется необходимость в объединении связей в "цепь" друг за другом.


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


Пример эволюционного фактора Универсальное описание Требуемые дополнительные функции Добавляемый тип алгоритма
Полезно убегать от большого и зубастого организма (льва), но не от просто большого (слона) и не от просто зубатого (кролика) Время от времени организм может выполнять действие, но обязательно его выполняет при одновременном наличии признака("1") и признака("2") Запись в цепочку обнаружения сочетания признаков и способ повторного обнаружения такого сочетания признаков Бесконечный цикл со спящим ожиданием одновременной (последовательной) установки флага1 и флага2 для исполнения операции

stage sign chain


Теперь опишем "сложности" признаковой операции И (AND) и особенности их решения методом построения цепочки. Первая и самая главная сложность состоит в том, что если количество базовых признаков у организма $n$, то количество макро-признаков, которые возможно выделить на синхронном парном сочетании из этих признаков $C^2_n = \frac{n!}{{(n-2)!} \cdot 2!}$. Это число больше $n$ (для $3 < n$). И общее число макро-признаков увеличивается с добавлением каждой дополнительной возможности детектировать сочетания базовых признаков. Таких возможностей как:


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

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


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


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


Описанный способ отделения формирования макро-признака от оценки исполненного действия позволяет:


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

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


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


Этап "Группировка действий"


И если признак повторяемости является дискуссионным в биологическом распознавании зрительных образов, то его использование для группировки действий сомнения почти не вызывает (вспомним пример игры на фортепиано, рассмотренный в статье 3). Основа способа формирования алгоритма, использующего последовательность действий, это повтор организмом требуемой последовательности действий! Но о каких действиях мы говорим? Ранее у организма мы рассматривали лишь одно действие, и он учился им пользоваться с пользой для себя. Такое ограничение было использовано намеренно (в угоду простоты описания вышеизложенных шагов развития). Давайте пожалеем организм и снимем это ограничение.


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


Пример эволюционного фактора Универсальное описание Требуемые дополнительные функции Добавляемый тип алгоритма
Для перемещения организма в воде полезно использовать последовательность движения жгутиком (хвостом) сначала в одну и потом в другую сторону Время от времени организм может выполнять последовательность действие("1") и действие("2") и это полезнее чем не выполнять эту последовательность или выполнять действия разрозненно Запись в цепочку сочетания исполняемых действий и способ повторного исполнения такого сочетания действий Бесконечный цикл для исполнения последовательности операции с настраиваемым интервалом

stage action chain


Схема, конечно, красивая. Но.


  1. Каким способом организм подбирает действия к обнаруженной новой ситуации в среде?
  2. Где он хранит оценку полезности (вредности) запомненных действий?
  3. Каким образом он синтезирует цепочку последовательности действий?

Давайте разберем эти "сложности" по порядку.


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


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


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


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


Общая схема памяти завершена?


Выводы


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


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

Мы на финальной черте этой статьи. Высадка на остров сокровищ "Алгоритм" произошла. Она получилась длиннее (по количеству букв), чем мне бы этого хотелось, но нас не должно волной прибоя отбросить обратно в море. Поэтому пришлось укрепиться на берегу основательней. С другой стороны количества букв в статье явно не хватает, чтобы описать всё что хочется рассказать, и некоторые подводные камни остались неосвещенными за бортом повествования. Есть предложение выстроить диалог обсуждения этих сложностей в формате вопрос-ответ в отдельной ветке Issues (Open source (GPL) проекта на GitLab).


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


stage action chain


Спасибо Вам за внимание.


Отзывы


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


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


Ссылки


Подробнее..

Edge-ик в тумане и другие приключения периферийных вычислений

25.06.2020 10:15:49 | Автор: admin

Edge-ик в тумане и другие приключения периферийных вычислений


Добрый день.


Меня зовут Игорь Хапов. Я руководитель разработки в Научно-техническом центре IBM. И сегодня я хотел бы вам помочь окунуться в мир периферийных вычислений, или edge computing, как его ещё называют. Я расскажу о том, что же такое edge computing и как он может повлиять на наш с вами мир. Также хотелось бы пояснить различия между edge computing и fog computing, какие преимущества даёт этот подход. В статье я также описал референсную архитектуру приложения на edge computing. И под конец немного расскажу о проекте с открытым исходным кодом Open Horizon, который совсем недавно присоединился к Linux Foundation.


edge computing align=center


Что же такое edge computing


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


Что же такое edge устройство? Многие считают, что edge computing это когда приложение работает на Raspberry Pi или других микрокомпьютерах. На самом деле edge computing может быть и на мобильных устройствах, персональных ноутбуках, умных камерах и других устройствах, на которых можно запустить приложение по обработке данных.


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


Edge computing и IoT


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


edge computing vs fog computing


Когда я однажды рассказал коллеге про edge computing, он ответил так это же fog computing. Давайте попробуем разобраться, в чём же разница. С одной стороны, edge computing и fog computing часто используются как синонимы, однако fog computing, или "туманные вычисления", все-таки немного отличаются.


И edge computing, и fog computing это вычисления, которые находятся в непосредственной близости к получаемым данным. Различие заключается в том, что при туманных вычислениях обработка осуществляется на устройствах, которые постоянно подключены к сети. В edge computing вычисления осуществляются как на сенсорах, умных устройствах без передачи на уровень gateway, так и на уровне gateway и на микрокластерах.


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


Преимущества и недостатки edge computing


При выборе технологий для своего проекта я в первую очередь основываюсь на двух критериях "Что я от этого получу?" и "Какие проблемы я от этого получу?".
Начнём с преимуществ:


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


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


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


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



Хотя, конечно, проектируя систему с edge computing, не стоит забывать, что как и любую другую технологию её стоит использовать в зависимости от требований к системе, которую вам необходимо реализовать.


Среди недостатков edge computing можно выделить следующие:


  • Крайне тяжело обеспечить гарантию отказоусточивости для всех edge-устройств.


  • Устройства могут иметь различные платформы и версии OS, для чего, вероятно, потребуется создавать несколько версий сервисов (например, для x86 и ARM).


  • Для управления большим количеством устройств потребуется платформа, решающая технические задачи edge computing.



С одной стороны, последний пункт является наиболее критичным, но, к счастью, консорциум Linux Foundation Edge (LF EDGE) включает в себя всё больше и больше проектов с открытым исходным кодом, а их зрелость стремительно растет.


Принципы компании IBM при создании платформы edge computing


Компания IBM, являясь одним из лидеров в области гибридных облаков, использует определённые принципы при разработке решений для edge computing:


  • Развивать инновации (Drive Innovation)
  • Обеспечить безопасность данных (Secure data)
  • Управлять в масштабе (Manage at scale)
  • Открытость исходного кода (Open Source)

IBM применяет эти принципы при декомпозиции задачи построения фреймворка edge computing.


edge computing align=center


Как вы можете видеть, всё решение разбито на 4 сегмента использования:


  • Edge-устройства
  • Edge-сервера или шлюзы
  • Edge-облако
  • Гибридное облако в частном или публичном дата центре

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


Референсная архитектура edge computing


edge computing align=center


Edge devices


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


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

Hybrid multicloud


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


Edge server and Edge micro data center


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


Edge framework


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


Именно наличие данного фреймворка раскрывает преимущества edge computing перед разнородными разнесёнными вычислениями.


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


Open Horizon и IBM Edge Application Manager


Именно для решения задач в области edge computing IBM разработала и выложила в open-source проект Open Horizon. Если вы помните, один из принципов, которые IBM заложила в edge computing все компоненты должны быть основаны на open source технологиях. В мае 2020 года проект Open Horizon вошел в Linux Foundation Edge Международный фонд open-source технологий для созданий edge-решений. Также Open Horizon является ядром нового продукта от RedHat и IBM IBM Edge Application Manager, решения для управления приложениями на всех устройствах edge computing: от Raspberry Pi до промежуточных кластеров обработки данных.


edge computing align=center


Несмотря на то, что проект Open Horizon вошел в консорциум только в мае, он уже достаточно давно развивается как open-source проект. И мы в Научно-техническом центре IBM не только успели его попробовать, но и довести свое решение до промышленного использования. О том, как мы разрабатывали проект с использованием edge computing, и что у нас получилось будет отдельная статья, которая выйдет в ближайшие несколько недель.


Сценарии использования


edge computing align=center


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


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


Ссылки


Подробнее..

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 4

26.06.2020 00:04:47 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 3

В отличии от operational drift, внедрение новых языков для интернационализации сервиса и новых технологий, таких как контейнеры, это сознательные решения добавить новую сложность в окружающую среду. Моя группа операционистов стандартизировала асфальтированную дорогу лучших технологий для Netflix, которые запекались в заранее определенных наилучших практиках, основанных на Java и EC2, однако по мере развития бизнеса разработчики стали добавлять новые компоненты, такие как Python, Ruby, Node-JS и Docker.



Я очень горжусь тем, что мы первыми сами выступали за то, чтобы наш продукт отлично работал, не дожидаясь жалоб клиентов. Все начиналось достаточно просто у нас были операционные программы на Python и несколько бэк-офисных приложений на Ruby, но все стало намного интересней, когда наши веб-разработчики заявили, что намерены отказаться от JVM и собираются перевести веб-приложение на программную платформу Node.js. После внедрения Docker вещи стали намного сложнее. Мы руководствовались логикой, и придуманные нами технологии стали реальностью, когда мы внедрили их для клиентов, потому что они имели большой смысл. Расскажу вам, почему это так.

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

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

Логично было взять эти endpoints и вытянуть их из API-сервиса. Для этого мы создали компоненты Node.js, которые запускались как небольшие приложения в контейнерах Docker. Это позволило изолировать любые неполадки и сбои, вызванные этими node-приложениями.

Стоимость этих изменений достаточно велика и складывается из следующих факторов:

  • Инструменты повышения производительности. Управление новыми технологиями требовало новых инструментов, потому что UI-команда, использующая очень удачные скрипты для создания эффективной модели, не должна была тратить много времени на управление инфраструктурой, она должна была заниматься только написанием скриптов и проверкой их работоспособности.
    Инсайт и сортировка возможностей ключевым примером являются новые инструменты, необходимые для выявления информации о факторах производительности. Нужно было знать, на сколько % занят процессор, как используется память, и сбор этой информации требовал разных инструментов.
  • Фрагментация базовых образов простая базовая AMI стала более фрагментированной и специализированной.
  • Управление узлами. Не существует доступной готовой архитектуры или технологий, которые позволяют управлять узлами в облаке, поэтому мы создали Titus платформу управления контейнерами, которая обеспечивает масштабируемое и надежное развертывание контейнеров и облачную интеграцию с Amazon AWS.
  • Дублирование библиотеки или платформы. Предоставление новым технологиям одних и тех же основных функций платформы потребовало ее дублирования в облачные инструменты разработчиков Node.js.
  • Кривая обучения и производственный опыт. Внедрение новых технологий неизбежно создает новые проблемы, которые необходимо преодолеть и извлечь из них уроки.

Таким образом, мы не могли ограничиться одной асфальтированной дорогой и должны были постоянно строить новые пути для продвижения своих технологий. Для снижения стоимости мы ограничивали централизованную поддержку и фокусировались на JVM, новых узлах и Docker. Мы расставляли приоритеты по степени эффективного воздействия, информировали команды о стоимости принятых ими решений и стимулировали их искать возможность многократного использования уже разработанных эффективных решений. Мы использовали этот подход при переводе сервиса на иностранные языки для доставки продукта интернациональным клиентам. Примерам могут служить относительно простые клиентские библиотеки, которые могут генерироваться автоматически, так что достаточно легко создавать Python-версию, Ruby-версию, Java-версию и т.д.

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

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



Как можно достичь высокой скорости внедрения программных инноваций, то есть постоянно вносить новые изменения в систему, не вызывая перерывов в доставке сервиса и не создавая неудобств нашим клиентам? Netflix добились этого благодаря использованию Spinnaker новой глобальной облачной платформы управления и непрерывной доставки (СD).



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



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

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



В конце выступления я коротко расскажу об организации и архитектуре Netflix. В самом начале у нас была схема под названием Electronic Delivery электронная доставка, представлявшая собой первую версию потоковой передачи медиаконтента NRDP 1.x. Здесь можно использовать термин обратный поток, потому что изначально пользователь мог только скачивать контент для последующего воспроизведения на устройстве. Самая первая платформа электронной доставки Netflix образца 2009 года выглядела примерно так.



Пользовательское устройство содержало в себе приложение Netflix, которое состояло из интерфейса UI, модулей безопасности, активации сервиса и воспроизведения, базирующихся на платформе NRDP Netflix Ready Device Platform.

В то время пользовательский интерфейс был очень прост. Он содержал так называемый Queque Reader, и пользователь заходил на сайт, чтобы добавить что-то в Queque, а затем просматривал добавленный контент на своем устройстве. Положительным было то, что клиентская команда и серверная команда принадлежали одной организации Electronic Delivery и имели тесные рабочие взаимоотношения. Полезная нагрузка была создана на основе XML. Параллельно был создан API Netflix для DVD бизнеса, который стимулировал сторонние приложения направлять трафик в наш сервис.

Однако Netflix API был хорошо подготовлен к тому, чтобы помочь нам с инновационным пользовательским интерфейсом, в нем содержались метаданные всего контента, сведения о том, какие фильмы доступны, что создавало возможность генерировать списки просмотра. У него был общий REST API, базирующийся на схеме JSON, HTTP Response Code, такой же, что используется в современной архитектуре, и модель безопасности OAuth то, что требовалось в то время для внешнего приложения. Это позволило перейти от публичной модели доставки потокового контента к приватной.



Проблема перехода заключалась во фрагментации, так как теперь в нашей системе функционировали два сервиса, основанные на совершенно разных принципах работы один на Rest, JSON и OAuth, другой на RPC, XML и механизме безопасности пользователей на основе системы токенов NTBA. Это была первая гибридная архитектура.

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



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

Можно сказать, что в этом случае хвост машет собакой. У нас на первом месте не решение, а организация, именно она является драйвером архитектуры, которую мы имеем. Постепенно от мешанины сервисов мы перешли к архитектуре, которую назвали Blade Runner Бегущий по лезвию, потому что здесь речь идет о граничных сервисах и возможностях NCCP разделяться и интегрироваться напрямую в Zuul-прокси, API-шлюз, причем соответствующие функциональные куски были превращены в новые микросервисы с более продвинутыми функциями безопасности, воспроизведения, сортировки данных и т.д.

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


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Kонференция NDС London. Предотвращение катастрофы микросервисов. Часть 1

27.06.2020 16:12:41 | Автор: admin
Вы потратили месяцы, переделывая свой монолит в микросервисы, и наконец, все собрались, чтобы щелкнуть выключателем. Вы переходите на первую веб-страницу и ничего не происходит. Перезагружаете ее и снова ничего хорошего, сайт работает так медленно, что не отвечает в течение нескольких минут. Что же случилось?

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



Приветствую всех, я Джимми, и сегодня вы услышите, как можно избежать мегакатастроф при создании микросервисов. Эта история компании, в которой я проработал около полутора лет, чтобы помочь предотвратить столкновение их корабля с айсбергом. Чтобы рассказать эту историю должным образом, придется вернуться в прошлое и поговорить о том, с чего начиналась эта компания и как со временем росла ее ИТ-инфраструктура. Чтобы защитить имена невиновных в этой катастрофе, я изменил название этой компании на Bell Computers. На следующем слайде показано, как выглядела IT инфраструктура таких компаний в середине 90-х. Это типичная архитектура большого универсального отказоустойчивого сервера HP Tandem Mainframe для функционирования магазина компьютерной техники.



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

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

Первоначальный дизайн выглядел довольно симпатично и состоял из сайта верхнего уровня bell.com и ряда поддоменов для отдельных приложений: каталога catalog.bell.com, аккаунтов account.bell.com, заказов orders.bell.com, поиска товаров search.bell.com. Каждый поддомен использовал фреймворк ASP.Net 1.0 и собственные базы данных, и все они общались с бэкендом системы. Однако все заказы продолжали обрабатываться и выполняться внутри единственного огромного мейнфрейма, в котором оставался весь мусор, зато фронтенд представлял собой отдельные веб-сайты с индивидуальными приложениями и отдельными базами данных.



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



Все элементы адресовали вызовы друг другу, обращались к API, встраивали сторонние библиотеки dll и тому подобное. Часто случалось, что системы управления версиями хватали чужой код, запихивали его внутрь проекта, и затем все ломалось. MS SQL Server 2005 использовал концепцию линк-серверов, и хотя я не показал стрелками на слайде, каждая из баз данных также общалась друг с другом, потому что как бы нет ничего плохого в том, чтобы строить таблицы на основании данных, полученных из нескольких БД.

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



Самое смешное было то, что этот мейнфрейм был построен конкурентами Bell Сomputers и до сих пор обслуживался их техническими консультантами. Убедившись в неудовлетворительной работе своих приложений, компания решила от них избавиться и сделать редизайн системы.

Существующее приложение было в продакшене на протяжении 15 лет, что является рекордным для приложений на базе ASP.Net. Сервис принимал заказы со всего мира, и ежегодная прибыль от этого единственного приложения достигала миллиарда долларов. Значительную часть прибыли формировал именно веб-сайт bell.com. По черным пятницам число заказов, сделанных через сайт, достигало несколько миллионов. Однако существующая архитектура не позволяла никакого развития, поскольку жесткие взаимосвязи элементов системы практически не позволяли вносить в сервис никаких изменений.

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

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

Руководство Bell Сomputers приняло решение построить именно такую архитектуру, придерживаясь неких основных принципов. Во-первых, они отказались от дублирования данных, используя подход общего доступа к БД. Никакие данные не пересылались, напротив, все, кто в них нуждался, должны были обращаться к централизованному источнику. Далее следовали изолированность и автономность каждый сервис был независим от других. Они решили использовать Web API абсолютно для всего если вы хотели получить данные или внести изменения в другую систему, все это делалось через Web API. Последней важной вещью был новый главный мейнфрейм под названием Bell on Bell в отличие от мейнфрейма Bell, основанного на железе конкурентов.

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

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

После этого до них дошло, что сложившаяся ситуация нуждается в тщательном разборе, и они пригласили нас. Первое, что мы выяснили в течение всех 18 месяцев разработки так и не было создано ни одного реального микро все становилось только еще больше. После этого мы приступили к написанию post-mortem, известного также как regretrospective, или печальная ретроспектива, она же blame storm обвинительный штурм по аналогии с мозговым штурмом brain storm, чтобы разобраться в причине катастрофы.

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



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

Мы сделали некоторые математические вычисления. Каждый API-вызов имел SLA не более 150 мс и 99,9% аптайм. Один запрос вызывал 200 различных вызовов, и в наилучшем случае страница могла быть показана через 200 х 150 мс = 30 секунд. Естественно, это никуда не годилось. Перемножив 99,9% аптайм на 200, мы получали 0% доступность. Получается, что эта архитектура была обречена на провал с самого начала.

Мы обратились к разработчикам с вопросом, как же они не сумели разглядеть эту проблему на протяжение 18 месяцев работы? Оказалось, что они подчитывали SLA только для запущенного ими кода, но если их сервис вызывал другой сервис, они не считали это время в своих SLA. Все, что запускалось в пределах одного процесса, придерживалось значения 150 мс, но обращение к другим сервисным процессам многократно увеличивало суммарную задержку. Первый извлеченный из этого урок формулировался так: Распоряжаетесь ли вы своим SLA или же SLA распоряжается вами? В нашем случае выходило второе.

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



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



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



Здесь появляется балансировщик нагрузки для распределения трафика между двумя веб-серверами, кэш, расположенный между веб-сервисом и бизнес-логикой и еще один кэш между бизнес-логикой и базой данных. Именно такую архитектуру использовала компания Bell для своего приложения балансировку нагрузки и blue/green развертывание, выполненное в середине 2000-х. До некоторого времени все работало хорошо, поскольку данная схема предназначалась для монолитной структуры.

На следующей картинке показано, как MS рекомендует осуществлять переход от монолита к микросервисам просто разделить каждый из основных сервисов на отдельные микросервисы. Именно при внедрении этой схемы Bell и совершили ошибку.



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

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

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



Она складывается из 4 уровней: уровень пользовательского интерфейса UI, уровень бизнес-логики, уровень доступа к данным и база данных. Более прогрессивна DDD (Domain-Driven Design), или программно-ориентированная архитектура, где два средних уровня представляют собой доменные объекты и репозиторий.



Я попытался рассмотреть в этой архитектуре различные области изменений, различные области ответственности. В обычном N-tier приложении классифицируются различные области изменений, которые пронизывают структуру вертикально сверху вниз. Это Catalog, настройки Config, выполняемые на индивидуальных компьютерах и проверки Checkout, которыми занималась моя команда.



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

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

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

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

Теперь рассмотрим определение микросервисов:

  • микросервис имеет малый размер и предназначен для решения одной конкретной задачи;
  • микросервис автономен;
  • при создании архитектуры микросервиса используется метафора городской планировки town planning metaphor. Это определение из книги Сэма Ньюмана Создание микросервисов.

Определение Bounded Context взято из книги Эрика Эванса Domain-Driven Design. Это основной паттерн в DDD, центр проектирования архитектуры, который работает с объемными архитектурными моделями, разделяя их на разные Bounded Context и явно определяя взаимодействие между ними.



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

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

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



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

22:30 мин

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

От забоя до перегрузочного пункта. Пример интеграции GEOVIA Surpac и автоматизированной системы диспетчеризации ГТК

29.06.2020 12:20:00 | Автор: admin
image
Что добывают предприятия? Золото, железную руду, уголь, алмазы? Нет!
Каждое предприятие добывает деньги. Это и есть цель каждого предприятия. Если добытая тонна золота или железной руды не принесет вам доход или, хуже того, ваши затраты будут выше, чем прибыль от реализации продукции, какая ценность этой руды для предприятия?
Каждая тонна руды должна приносить максимальный доход или нести минимальные издержки в условиях безопасного производства и соблюдении технологии добычи. Т.е. распределение движения горной массы во времени должно приводить предприятие к цели. Для того чтобы достичь цели, необходимо создать хороший план, который будет моделировать производственный процесс с максимальным достижением объемно-качественных показателей. Каждый план необходимо обеспечивать верными, точными и актуальными данными. Особенно, если речь идет о краткосрочном или оперативном планировании.

Какие данные обеспечивают планирование горных работ? Это маркшейдерская и геологическая информация, данные проектирования и производственно-техническая информация (например, из ERP систем).
image

Все эти процессы несут в себе огромное количество графической, цифровой и текстовой информации, такой как облако точек лазерного сканирования, маркшейдерская база данных, оперативная съемка забоев, геологическая блочная модель, данные опробования скважин БВР, изменение контактов во взорванной горной массе, производственные показатели и их изменения, изменение динамики работы оборудования и т.д. Поток данных постоянен и бесконечен. И большая часть информации зависит друг от друга. Нужно не забывать, что все эти данные это первоисточник, информация, с которой начинается создание плана.
Поэтому для создания оптимального плана необходимо уметь получать максимально точный данные. Корректность исходной информации в геометрической прогрессии влияет на конечную цель.
image

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

Если говорить о краткосрочном планировании, то важно, чтобы эти данные были не только точными, но еще и актуальными. Необходимо иметь возможность получать информацию в любой момент времени, чтобы реагировать на изменения и оперативно редактировать сценарий производства. Соответственно, нужны такие системы и оборудование, которые позволят повысить эффективность процессов по получению и обработке информации. Лидарные сканеры позволяют оперативно получать данные с высокой точностью, технологии опробования горной массы дают картину положения рудного тела в массиве, системы позиционирования отслеживают положение и состояние оборудования в реальном времени, а системы проектирования и планирования GEOVIA Surpac и GEOVIA MineSched являются инструментами для создания проектов и сценариев развития горных работ. Для максимально быстрого достижения цели системы должны быть связаны в единую продуктивную цепочку. Представьте: вы получаете данные из разных систем и источников, но они доступны вам только по запросу, к тому же эти данные передает вам специалист, который в любой момент может изменить содержимое. Это ведет не только к снижению скорости получения данных, но и к потере точности или достоверности на одном из этапов передачи данных. Поэтому данные должны быть централизованными, храниться на одной платформе, в одной цифровой экосистеме и быть доступными в любой момент времени. Кроме того, важно обеспечить совместную работу всех подразделений, версионность, целостность и безопасность данных. С этой задачей справляется платформа 3DEXPEREINCE.

Информация, полученная из различных источников электронных систем, систем ГГИС (GEOVIA Surpac), ERP-систем, систем автоматизированного планирования горных работ (GEOVIA MineSched), систем управления горными работами (например, ВИСТ Групп) имеет разный формат данных.
Здесь встает вопрос об интеграции систем. Зачастую все решения в цепочке горного планирования и проектирования могут быть в большей или меньшей степени интегрированы между собой.
Но интенсивность потока данных, количество их типов, и изменчивость таковы, что человек не способен в относительно быстрое время произвести конвертацию из одной системы в другую. Будь то геолог или инженер по планированию, специалист должен тратить время не на импорт и экспорт файлов из одной системы в другую, он должен создавать ценность и двигать предприятие к цели. Поэтому процесс интеграции важно автоматизировать, настроить таким образом, чтобы количество манипуляций по обработке данных сводилось к минимуму.

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

Автоматизированный процесс обработки и интеграции данных при маркшейдерском и геологическом обеспечении горных работ с использованием GEOVIA Surpac выглядит следующим образом. Съемка готова, маркшейдер подключает прибор к ПК, открывает GEOVIA Surpac, запускает функцию импорта и обработки данных съемки, выбирает из списка, что необходимо получить в результате.
Система формирует графические и табличные данные, обновляет на сетевом ресурсе рабочий файл и сохраняет предыдущую версию файла. Геолог запускает функции обновления блочной модели по актуальным маркшейдерским данным и/или данным систем диспетчеризации.
Все данные подгружаются с сетевого ресурса/платформы, макрокоманда конвертирует и импортирует необходимые данные, геологу необходимо только выбрать соответствующие настройки. После проверки при помощи соответствующих функций результат сохраняется и экспортируется в другие системы.
image

Такой процесс реализован в маркшейдерской и геологической службах на Качканарском ГОКе компании ЕВРАЗ.

ЕВРАЗ КГОК входит в пятерку крупнейших в России горнорудных предприятий. Комбинат расположен в 140 км от ЕВРАЗ НТМК, в Свердловской области. ЕВРАЗ КГОК разрабатывает Гусевогорское месторождение титаномагнетитовых железных руд, содержащих примеси ванадия. Содержание ванадия позволяет выплавлять высокопрочные легированные сорта стали. Производственная мощность комбината составляет порядка 55 млн тонн железной руды в год. Основным потребителем продукции ЕВРАЗ КГОКа является ЕВРАЗ НТМК.

В настоящее время ЕВРАЗ КГОК добывает руду из четырех карьеров с дальнейшей ее переработкой в цехах дробления, обогащения, агломерации и окускования. Конечный продукт (агломерат и окатыши) загружается в железнодорожные вагоны и отправляется потребителям, в том числе за рубеж.

В 2018 году на ЕВРАЗ КГОКе добыто более 58,5 млн тонн руды, произведено 3,5 млн тонн агломерата, 6,5 млн тонн окатышей, около 2,5 млн тонн щебня.

Добыча руды производится в четырех карьерах: Главном, Западном, Северном, а также карьере Южная залежь. С нижних горизонтов руда доставляется БелАЗами, на дробильную фабрику горная масса перевозится железнодорожным транспортом. В карьерах используются мощные 130-тонные самосвалы, современные локомотивы НП-1, экскаваторы с объемом ковша 12 кубических метров.

Среднее содержание железа в руде составляет 15,6 %, содержание ванадия 0, 13 %.

Технология добычи железной руды на ЕВРАЗ КГОКе следующая: бурение взрывание экскавация транспортировка к месту переработки и вскрыши в отвалы. (Источник )

В 2019 году на Качканарском ГОКе была внедрена автоматизированная система диспетчеризации ВИСТ Групп. Внедрение данного решения позволило увеличить производственный контроль работы горнотранспортного оборудования, движения руды от забоев до перегрузочных пунктов, а также оперативно получать данные по объемно-качественным показателям в забоях и на перегрузочных пунктах. Была произведена двусторонняя интеграция систем АСД ВИСТ и GEOVIA Surpac, что позволило использовать получаемые данные (положение оборудования, степень отработки забоя, баланс горной массы на перегрузочных пунктов, распределение качества на перегрузочных пунктах и т.п.) для оперативного планирования и проектирования горных работ, а также контролировать производственный процесс на уровне линейного руководителя и машиниста экскаватора.
image

Благодаря разработкам ведущего геолога С.М. Некрасова и главного маркшейдера А.В. Безденежных, специалистами маркшейдерского и геологического отделов с использованием инструментов GEOVA Surpac было автоматизировано большинство процессов по обработке данных маркшейдерской съемки, проектирования, создания печатной документации, создания геологических блочных моделей, обновления геологической и маркшейдерской информации на сетевом ресурсе. Теперь специалистам не нужно выполнять повторяющиеся процессы ежедневно, будь то выгрузка/загрузка съемки с прибора/на прибор, поиск нужных данных для повседневной работы в огромном множестве папок. Макрокоманды GEOVIA Surpac делают это за них. Важно отметить, что эти данные доступны для всех причастных специалистов разных отделов. Например, чтобы открыть последнюю съемку карьера, обновленную блочную модель, блок БВР, коммуникации и т.п., специалисту по планированию не нужно искать это в большом числе маркшейдерских и геологических файлов. Все, что ему требуется для этого открыть в GEOVA Surpac соответствующее меню и выбрать данные, которые нужно загрузить в рабочее окно.
image

Инструменты автоматизации позволили легко произвести интеграцию GEOVIA Surpac и АСД ВИСТ Групп и сделать этот процесс максимально простым и быстрым.

Выбрав соответствующее меню в панели GEOVIA Surpac, геолог получает из АСД ВИСТ оперативные данные по отработке блока или данные на определенную дату и время. Эти данные используются для анализа текущей ситуации и обновления блочной модели.

image

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

image

image

Благодаря объединению возможности инструментария позиционирования горнотранспортного оборудования в системе АСД ВИСТ Групп и инструментов GEOVIA Surpac были настроены процессы контроля движения горной массы от забоя до перегрузочного пункта, размещения горной массы в секторах перегрузочных пунктов, контроля баланса прихода/ухода горной массы по секторам и ведения мобильных остатков за период оперативного заполнения.
Для этого в GEOVIA Surpac были созданы блочные модели перегрузочных пунктов и разработана методика по их заполнению. По желанию геолога, процесс внесения в блочную модель (БМ) горной массы на виртуальный перегрузочный пункт, как и отгрузку с него, можно осуществлять как целиком за прошедший период, так и в оперативном режиме. Поставив на заполнение БМ с указанием времени окончания, макропрограмма сама производит запрос (через определенный интервал времени) на извлечение данных по экскаваторам, производящих черпание, а также извлекает информацию по движению и выгрузке автотранспорта на перегрузочный пункт.
Таким образом, по окончании работы макропрограммы формируется текущая информация по состоянию склада, наличию на данный период времени горной массы в трехмерном графическом виде и сводная таблица результатов оперативного изменения. Это позволило оперативно отслеживать движение руды, баланс и распределение горной массы на секторах перегрузочных пунктов, а также представлять графически эту информацию в обеих системах и обеспечить быстрый, свободный и безопасный доступ к информации для всех сотрудников. В частности, по словам ведущего геолога С.Н. Некрасова, такой процесс позволил повысить точность планирования отгрузки по качеству с перегрузочных пунктов на железнодорожный транспорт.
Также он отмечает, что если раньше можно было лишь предполагать, что было привезено на перегрузочные пункты и представлять только среднее значение качества по секторам, то сегодня известны показатели на каждом отдельно взятом участке сектора.

image

image

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

image

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

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

Подписывайтесь на новости Dassault Systmes и всегда будьте в курсе инноваций и современных технологий.

Dassault Systmes официальная страница

Facebook
Vkontakte
Linkedin
3DS Blog WordPress
3DS Blog on Render
3DS Blog on Habr
Подробнее..

Внедрение зависимостей проще, чем кажется?

27.06.2020 14:19:52 | Автор: admin
Привет, Хабр!

У нас готовится к выходу второе издание легендарной книги Марка Симана, Внедрение зависимостей на платформе .NET



Поэтому сегодня мы решили кратко освежить тему внедрения зависимостей для специалистов по .NET и C# и предлагаем перевод статьи Грэма Даунса, где эта парадигма рассматривается в контексте инверсии управления (IoC) и использования контейнеров

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

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

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

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

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

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

Подготовка


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

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

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

Приложение


Рассмотрим следующий код. Он написан для простого приложения-калькулятора, принимающего два числа, оператор и выводящего результат. (Это простое рабочее приложение для командной строки, поэтому вам не составит труда воспроизвести его как C# Console Application в Visual Studio и вставить туда код, если вы хотите следить за развитием примера. Все должно работать без проблем.)

У нас есть класс Calculator и основной класс Program, использующий его.

Program.cs:

using System;using System.Linq;namespace OfferZenDiTutorial{    class Program    {        static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            var calc = new Calculator();            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }        private static float GetNumber(string message)        {            var isValid = false;            while (!isValid)            {                Console.Write(message);                var input = Console.ReadLine();                isValid = float.TryParse(input, out var number);                if (isValid)                    return number;                Console.WriteLine("Please enter a valid number. Press ^C to quit.");            }            return -1;        }        private static char GetOperator()        {            var isValid = false;            while (!isValid)            {                Console.Write("Please type the operator (/*+-) > ");                var input = Console.ReadKey();                Console.WriteLine();                var operation = input.KeyChar;                if ("/*+-".Contains(operation))                {                    isValid = true;                    return operation;                }                Console.WriteLine("Please enter a valid operator (/, *, +, or -). " +                                  "Press ^C to quit.");            }            return ' ';        }        private static float GetResult(Calculator calc, float number1, float number2,             char operation)        {            switch (operation)            {                case '/': return calc.Divide(number1, number2);                case '*': return calc.Multiply(number1, number2);                case '+': return calc.Add(number1, number2);                case '-': return calc.Subtract(number1, number2);                default:                    // Такого произойти не должно, если с предыдущими валидациями все было нормально                     throw new InvalidOperationException("Invalid operation passed: " +                                                         operation);            }        }    }}

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

Calculator.cs:

namespace OfferZenDiTutorial{    public class Calculator    {        public float Divide(float number1, float number2)        {            return number1 / number2;        }        public float Multiply(float number1, float number2)        {            return number1 * number2;        }        public float Add(float number1, float number2)        {            return number1 + number2;        }        public float Subtract(float number1, float number2)        {            return number1 - number2;        }    }}

Логирование


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

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

Calculator.cs:

using System.IO;namespace OfferZenDiTutorial{    public class Calculator    {        private const string FileName = "Calculator.log";        public float Divide(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} / {number2}");            return number1 / number2;        }        public float Multiply(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} * {number2}");            return number1 * number2;        }        public float Add(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} + {number2}");            return number1 + number2;        }        public float Subtract(float number1, float number2)        {            File.WriteAllText(FileName, $"Running {number1} - {number2}");            return number1 - number2;        }    }}

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

Но, возможен вопрос: а в самом ли деле уместно, чтобы класс Calculator отвечал за запись в текстовый файл?

Класс FileLogger


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

Первым делом создаем совершенно новый класс, назовем его FileLogger. Вот как он будет выглядеть.

FileLogger.csh:

using System;using System.IO;namespace OfferZenDiTutorial{    public class FileLogger    {        private const string FileName = "Calculator.log";        private readonly string _newLine = Environment.NewLine;        public void WriteLine(string message)        {            File.AppendAllText(FileName, $"{message}{_newLine}");        }    }}

Теперь все, что касается создания файла логов и записи информации в него обрабатывается в этом классе. Дополнительно получаем и одну приятную мелочь: что бы ни потреблял этот класс, не требуется ставить между отдельными записями пустые строки. Записи должны просто вызывать наш метод WriteLine, а все остальное мы берем на себя. Разве не круто?
Чтобы использовать класс, нам нужен объект, который его инстанцирует. Давайте решим эту проблему внутри класса Calculator. Заменим содержимое класса Calculator.cs следующим:

Calculator.cs:

namespace OfferZenDiTutorial{    public class Calculator    {        private readonly FileLogger _logger;        public Calculator()        {            _logger = new FileLogger();        }        public float Divide(float number1, float number2)        {            _logger.WriteLine($"Running {number1} / {number2}");            return number1 / number2;        }        public float Multiply(float number1, float number2)        {            _logger.WriteLine($"Running {number1} * {number2}");            return number1 * number2;        }        public float Add(float number1, float number2)        {            _logger.WriteLine($"Running {number1} + {number2}");            return number1 + number2;        }        public float Subtract(float number1, float number2)        {            _logger.WriteLine($"Running {number1} - {number2}");            return number1 - number2;        }    }}

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

Внедрение зависимости


Очевидно, ответ на последний вопрос отрицательный!

Именно здесь, уважаемый читатель, в дело вступает внедрение зависимости. Давайте изменим конструктор нашего класса Calculator:

Calculator.cs:

        public Calculator(FileLogger logger)        {            _logger = logger;        }

Вот и все. Больше в классе ничего не меняется.

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

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

Итак, чья же это ответственность?

Как раз того, кто инстанцирует класс Calculator. В нашем случае это основная программа.

Чтобы это продемонстрировать, изменим метод Main в нашем классе Program.cs следующим образом:

Program.cs

  static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            // Следующие две строки изменены            var logger = new FileLogger();            var calc = new Calculator(logger);            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }

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

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

Расширение возможностей: сделаем другой логгер


Несмотря на вышесказанное, у интерфейсов есть свое место, и по-настоящему они раскрываются именно в связке с Внедрением Зависимостей.

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

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

Вот здесь нам и пригодятся интерфейсы.

Давайте напишем интерфейс. Назовем его ILogger, поскольку его реализацией будет заниматься наш класс FileLogger.

ILogger.cs

namespace OfferZenDiTutorial{    public interface ILogger    {        void WriteLine(string message);    }}

Как видите, он определяет единственный метод: WriteLine, реализованный FileLogger. Сделаем еще шаг и формализуем эти отношения, сделав так, чтобы этот класс официально реализовывал наш новый интерфейс:

FileLogger.cs

public class FileLogger : ILogger

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

Для начала изменим класс Calculator таким образом, чтобы он использовал интерфейс ILogger, а не конкретную реализацию FileLogger:

Calculator.cs

private readonly ILogger _logger;        public Calculator(ILogger logger)        {            _logger = logger;        }

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

Поскольку все, что бы вы ни получили, реализует интерфейс ILogger (и, следовательно, имеет метод WriteLine), с практическим использованием проблем не возникает.

Теперь давайте добавим еще одну реализацию интерфейса ILogger. Это будет класс, который ничего не делает при вызове метода WriteLine. Мы назовем его NullLogger, и вот как он выглядит:

NullLogger.cs

namespace OfferZenDiTutorial{    public class NullLogger : ILogger    {        public void WriteLine(string message)        {            // Ничего не делаем в этой реализации        }    }}

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

Нам потребуется изменить только лишь метод Main в нашем файле Program.cs, чтобы передать в него иную реализацию. Давайте этим и займемся, чтобы метод Main принял следующий вид:

Program.cs

 static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            var logger = new NullLogger(); // Эту строку нужно изменить            var calc = new Calculator(logger);            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }

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

Небольшая оговорка об интерфейсах


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

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

Контейнеры для внедрения зависимостей


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

Знакомьтесь с контейнером для внедрения зависимостей. Он упрощает вам жизнь, но принцип работы такого контейнера может показаться весьма запутанным, особенно, когда вы только начинаете его осваивать. На первый взгляд эта возможность может отдавать некоторой магией.
В данном примере мы воспользуемся контейнером от Unity, но на выбор есть и много других, назову лишь наиболее популярные: Castle Windsor, Ninject. С функциональной точки зрения эти контейнеры практически не отличаются. Разница может быть заметна на уровне синтаксиса и стиля, но, в конечном итоге, все сводится к вашим персональным предпочтениям и опыту разработки (а также к тому, что предписывается в вашей компании!).

Давайте подробно разберем пример с использованием Unity: я постараюсь объяснить, что здесь происходит.

Первым делом вам потребуется добавить ссылку на Unity. К счастью, для этого существует пакет Nuget, поэтому щелкните правой кнопкой мыши по вашему проекту в Visual Studio и выберите Manage Nuget Packages:



Найдите и установите пакет Unity, ориентируйтесь на проект Unity Container:



Итак, мы готовы. Измените метод Main файла Program.cs вот так:

Program.cs

 static void Main(string[] args)        {            var number1 = GetNumber("Enter the first number: > ");            var number2 = GetNumber("Enter the second number: > ");            var operation = GetOperator();            // Следующие три строки необходимо изменить            var container = new UnityContainer();            container.RegisterType<ILogger, NullLogger>();            var calc = container.Resolve<Calculator>();            var result = GetResult(calc, number1, number2, operation);            Console.WriteLine($"{number1} {operation} {number2} = {result}");            Console.Write("Press any key to continue...");            Console.ReadKey();        }

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

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



Вероятно, это одна из причуд с той версией пакета Unity, которая была актуальна на момент написания этой статьи. Надеюсь, что у вас все пройдет гладко.
Все дело в том, что при установке Unity также устанавливается неверная версия другого пакета, System.Runtime.CompilerServices.Unsafe. Если вы получаете такую ошибку, то должны вернуться к менеджеру пакетов Nuget, найти этот пакет под вкладкой Installed и обновить его до новейшей стабильной версии:



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

Все начинается со строки var calc = container.Resolve<Calculator>();, поэтому именно отсюда я изложу смысл этого кода в форме диалога контейнера с самим собой: о чем он думает, когда видит эту инструкцию.

  1. Мне задано разрешить что-то под названием Calculator. Я знаю, что это такое?
  2. Вижу, в актуальном дереве процессов есть класс под названием Calculator. Это конкретный тип, значит, у него всего лишь одна реализация. Просто создам экземпляр этого класса. Как выглядят конструкторы?
  3. Хм, а конструктор всего один, и принимает он что-то под названием ILogger. Я знаю, что это такое?
  4. Нашел, но это же интерфейс. Мне вообще сообщалось, как его разрешать?
  5. Да, сообщалось! В предыдущей строке сказано, что, всякий раз, когда мне требуется разрешить ILogger, я должен передать экземпляр класса NullLogger.
  6. Окей, значит тут есть NullLogger. У него непараметризованный конструктор. Просто создам экземпляр.
  7. Передам этот экземпляр конструктору класса Calculator, а затем верну этот экземпляр к var calc.

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

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

Вот и все. Ничего таинственного и особо мистического.

Другие возможности


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

Если вы хотите сами поэкспериментировать с примерами, приведенными в этой статье: смело клонируйте с Гитхаба репозиторий, в котором они выложены github.com/GrahamDo/OfferZenDiTutorial.git. Там семь веток, по одной на каждую рассмотренную нами итерацию.
Подробнее..

Учебник по симулятору сети ns-3 теперь одним pdf-файлом

25.06.2020 16:23:50 | Автор: admin


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

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

Применение CQRS amp Event Sourcing в создании платформы для проведения онлайн-аукционов

07.07.2020 14:13:48 | Автор: admin
Коллеги, добрый день! Меня зовут Миша, я работаю программистом.

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


Прелюдия


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

Теперь чуть-чуть терминологии. Аукцион это когда продаются некие предметы лоты (lots), а покупатели (bidders) делают ставки (bids). Обладателем лота становится покупатель, предложивший самую большую ставку. Timed-аукцион это когда у каждого лота заранее определен момент его закрытия. Покупатели делают ставки, в какой-то момент лот закрывается. Похоже на ebay.

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

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

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

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

Какая еще есть специфика работы онлайн-аукционов:

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

Краткий обзор подхода CQRS & ES


Не буду подробно останавливаться на рассмотрении подхода CQRS & ES, материалы об этом есть в интернете и в частности на Хабре (например, вот: Введение в CQRS + Event Sourcing). Однако кратко все же напомню основные моменты:

  • Самое главное в event sourcing: система хранит не данные, а историю их изменения, то есть события. Текущее состояние системы получается последовательным применением событий.
  • Доменная модель делится на сущности, называемые агрегатами. Агрегат имеет версию. События применяются к агрегатам. Применение события к агрегату инкрементирует его версию.
  • События хранятся в write-базе. В одной и той же таблице хранятся события всех агрегатов системы в том порядке, в котором они произошли.
  • Изменения в системе инициируются командами. Команда применяется к одному агрегату. Команда применяется к последней, то есть текущей, версии агрегата. Агрегат для этого выстраивается последовательным применением всех своих событий. Этот процесс называется регидратацией.
  • Для того, чтобы не регидрировать каждый раз с самого начала, какие-то версии агрегата (обычно каждая N-я версия) можно хранить в системе в готовом виде. Такие снимки агрегата называются снапшотами. Тогда для получения агрегата последней версии при регидратации к самому свежему снапшоту агрегата применяются события, случившиеся после его создания.
  • Команда обрабатывается бизнес-логикой системы, в результате чего получается, в общем случае, несколько событий, которые сохраняются в write-базу.
  • Кроме write-базы, в системе может еще быть read-база, которая хранит данные в форме, в которой их удобно получать клиентам системы. Сущности read-базы не обязаны соответствовать один к одному агрегатам системы. Read-база обновляется обработчиками событий.
  • Таким образом, у нас получается разделение команд и запросов к системе Command Query Responsibility Segregation (CQRS): команды, изменяющие состояние системы, обрабатываются write-частью; запросы, не изменяющие состояние, обращаются к read-части.



Реализация. Тонкости и сложности.


Выбор фреймворка


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

В целом наш технологический стек это Microsoft, то есть .NET и C#. База данных Microsoft SQL Server. Хостится все в Azure. На этом стеке была сделана timed-платформа, логично было и live-платформу делать на нем.

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

Зачем вообще нужен фреймворк CQRS & ES? Он может из коробки решать такие задачи и поддерживать такие аспекты реализации как:

  • Сущности агрегата, команды, события, версионирование агрегатов, регидратация, механизм снапшотов.
  • Интерфейсы для работы с разными СУБД. Сохранение/загрузка событий и снапшотов агрегатов в/из write-базы (event store).
  • Интерфейсы для работы с очередями отправка в соответствующие очереди команд и событий, чтение команд и событий из очереди.
  • Интерфейс для работы с веб-сокетами.

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

  • Azure Service Bus в качестве шины команд и событий, Chinchilla поддерживает его из коробки;
  • Write- и read-базы Microsoft SQL Server, то есть обе они SQL-базы. Не скажу, что это является результатом осознанного выбора, скорее по историческим причинам.

Да, фронтенд сделан на Angular.

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

Выбор агрегатов


Одной из первых вещей, которую надо сделать при реализации подхода CQRS & ES это определить, как доменная модель будет делиться на агрегаты.

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

public class Auction{     public AuctionState State { get; private set; }     public Guid? CurrentLotId { get; private set; }     public List<Guid> Lots { get; }}public class Lot{     public Guid? AuctionId { get; private set; }     public LotState State { get; private set; }     public decimal NextBid { get; private set; }     public Stack<Bid> Bids { get; }} public class Bid{     public decimal Amount { get; set; }     public Guid? BidderId { get; set; }}


У нас получилось два агрегата: Auction и Lot (с Bidами). В общем, логично, но мы не учли одного того, что при таком делении состояние системы у нас размазалось по двум агрегатам, и в ряде случаев для сохранения консистентности мы должны вносить изменения в оба агрегата, а не в один. Например, аукцион можно поставить на паузу. Если аукцион на паузе, то нельзя делать ставки на лот. Можно было бы ставить на паузу сам лот, но аукциону на паузе тоже нельзя обрабатывать никаких команд, кроме как снять с паузы.

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

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

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

Мы на данном этапе эволюции проекта живем с двумя агрегатами, Auction и Lot, и нарушаем архитектуру, меняя в рамках некоторых команд оба агрегата.

Применение команды к определенной версии агрегата


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

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

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

Ошибки при выполнении команды с использованием очереди


В нашей реализации, в большой степени обусловленной использованием Chinchilla, обработчик команд читает команды из очереди (Microsoft Azure Service Bus). Мы у себя явно разделяем ситуации, когда команда зафейлилась по техническим причинам (таймауты, ошибки подключения к очереди/базе) и когда по бизнесовым (попытка сделать на лот ставку той же величины, что уже была принята, и проч.). В первом случае попытка выполнить команду повторяется, пока не выйдет заданное в настройках очереди число повторений, после чего команда отправляется в Dead Letter Queue (отдельный топик для необработанных сообщений в Azure Service Bus). В случае бизнесового эксепшена команда отправляется в Dead Letter Queue сразу.



Ошибки при обработке событий с использованием очереди


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

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



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

В итоге, в качестве временной меры мы отказались от использования Azure Service Bus для передачи событий из write-части приложения в read-часть. Вместо нее используется так называемая In-Memory Bus, что позволяет обрабатывать команду и события в одной транзакции и в случае неудачи откатить все целиком.



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

Отправка команды в качестве реакции на событие


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

Обработка множества событий одной команды


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



Обработка одного события несколькими обработчиками


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

Например, обработчик события в read-базе добавляет ставку на лот величиной 5 рублей. Первая попытка сделать это будет успешной, а вторую не даст выполнить constraint в базе.



Выводы/Заключение


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

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

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

Из песочницы Ключи к успеху ИТ-проекта

29.06.2020 22:07:32 | Автор: admin
Всем привет!

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



О себе


9 лет ИТ-консультант SAP ERP. Обязанности: проектирование, тимлидинг, тестирование и отладка, обучение, пилотирование.

Рамки применимости


Писал ориентируясь на проекты от 3-4 месяцев до 1 года со сложной межсистемной интеграцией.

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

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

Глоссарий


БА бизнес-аналитик
БЗ база знаний проекта
БТ бизнес-требования
ИТ архитектор и консультанты проектной команды
КП ключевой пользователь
МК младший консультант, эникейщик
ПР проектное решение
Прод продуктивная система
Разраб разработчик
СТ сценарии тестирования
СК старший консультант, проектировщик
ТЗ техническое задание

Ключи к успеху ИТ-проекта


Общий посыл налаженная коммуникация


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

Детальные и продуманные БТ


По БТ должно быть полное и синхронное понимание между бизнесом и ИТ. Для этого его должен составлять БА и КП (идеально, когда БА бывший КП).

Полный набор сценариев тестирования


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

Разделение труда внутри ИТ


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

Тоже касается содержания ТЗ/ПР в актуальном состоянии:

  1. СК пишет разрабу о корректировках и ставит МК в копию
  2. МК собирает и отражает изменения в режиме редактирования используя версионность
  3. СК принимает правки
  4. МК обновляет документацию в БЗ

Тестирование также следует делегировать МК.

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

Тестирование сценариев перед релизом


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

Общее пространство для команд интегрирующихся систем


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

Техническая адекватность принимающей стороны


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

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

Модератор на пилот


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

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

2.МАТЕМАТИЧЕСКОЕ ОПИСАНИЕ СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ

29.06.2020 02:20:27 | Автор: admin

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


2.1. Получение уравнений динамики системы. Статическая характеристика. Уравнение динамики САУ (САР) в отклонениях
2.2. Линеаризация уравнений динамики САУ (САР)
2.3. Классический способ решения уравнений динамики


Лекции по курсу Управление Техническими Системами, читает Козлов Олег Степанович на кафедре Ядерные реакторы и энергетические установки, факультета Энергомашиностроения МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.


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


Первая часть: Введение в теорию автоматического управления. Основные понятия теории управления техническим системами




2.1. Получение уравнений динамики системы. Статическая характеристика. Уравнение динамики САУ (САР) в отклонениях


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


На рис. 2.1.1 представлено схематичное представление САУ (звена) в переменных вход-выход, где x(t) (или u(t)) входное воздействие, а y(t) выходное воздействие, соответственно. Нередко входное воздействие будет называться управляющим, а выходное воздействие регулируемой величиной (переменной).



Рис. 2.1.1 Схематическое представление САУ (звена)

При составлении уравнений динамики используются фундаментальные законы сохранения из разделов Механики, Физики, Химии и др.


Например, при описании перемещения узла какого-то механизма силового привода используются законы сохранения: момента, энергии, импульса и др В теплофизических (теплогидравлических) системах используются фундаментальные законы сохранения: массы (уравнение неразрывности), импульса (уравнение движения), энергии (уравнение энергии) и др


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


$\left[ \begin{gathered} y(t) =y_0 + \Delta y(t)\\ u(t) = u_0 + \Delta u(t)\\ \end{gathered} \right.$


где: $y_0,u_0$ стационарные значения входного и выходного воздействий;
$\Delta y, \Delta u$ отклонения от станционара, соотвесвенно.

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



Рис. 2.1.2 Механический демпфер

Согласно 2-му закону Ньютона, ускорение тела пропорционально сумме сил, действующих на тело:

$m \cdot \frac{d^2 y(t)}{dt} = \sum F_j \ \ \ \mathbf{(2.1.1)}$


где, m масса тела, Fj все силы воздействующие на тело (поршень демпфера)


Подставляя в уравнение (2.1.1) все силы согласно рис. 2.2, имеем:


$m \cdot \frac{d^2y(t)}{dt} = m\cdot g+ u(t) - k \cdot y(t) - c \cdot \frac{dy(t)}{dt} \ \ \ \mathbf{(2.1.2)}$

где $m\cdot g$ сила тяжести; $k \cdot y(t)$ сила сопротивления пружины, $c \cdot \frac{dy(t)}{dt}$ сила вязконо трения (пропорциональна скорости поршеня)


Размерности сил и коэффициентов, входящих в уравнение (2.1.2):

$m \cdot g \Rightarrow [\frac{кг \cdot м}{ с^2}]; c \Rightarrow [\frac{кг}{с}]; k \Rightarrow [\frac{кг}{с^2}]$

Предполагая, что при t 0 поршень демпфера находился в равновесии, то есть

$$display$$\left \{ \begin{eqnarray} t &\le 0 \\ u(t) &= u_0\\ y(t) &= y_0\\ \end{eqnarray} \right.$$display$$

перейдем к отклонениям от стационарного состояния:
Пусть при t>0 $\left[ \begin{gathered} y(t) =y_0 + \Delta y(t); u(t) = u_0 + \Delta u(t);\\ y'(t) = [\Delta y(t)]; y''(t) =[\Delta y(t)]'\\ \end{gathered} \right.$. Тогда, подставляя эти соотношения в уравнение (2.1.2), получаем:

$m \cdot \frac{d^2\Delta y(t)}{dt^2} = m \cdot g - k \cdot y_0- k \cdot \Delta y(t) - c\frac{d\Delta y(t)}{dt} \ \ \ \mathbf{(2.1.3)}$


если $t \le 0$, то уравнение принимает вид:

$0 = m \cdot g+u_0 - k \cdot y_0 \ \ \ \mathbf{(2.1.4)}$

или

$y_0 = \frac{1}{k} \cdot[u_0+m \cdot g] \ \ \ \mathbf{(2.1.5)}$


Соотношение (2.1.4) уравнение звена (демпфера) в равновесном (стационарном) состоянии, а соотношение (2.1.5) статическая характеристика звена демпфера (см. рисунок 2.1.3).



Рис. 2.1.3 Статическая характеристика механического демпфера

Вычитая из уравнения (2.1.3) уравнение (2.1.4), получаем уравнение динамики демпфера в отклонениях:

$m\cdot g \frac{d^2 \Delta y(t)}{dt^2} = \Delta u(t) - k \cdot \Delta y(t) - c \cdot \frac{d \Delta y(y)}{dt}, $


тогда, разделив на k, имеем:

$T_2^2 \cdot \frac{d^2 \Delta y(t)}{dt^2}+ T_1 \cdot \frac{d \Delta y(t)}{dt} + \Delta y(t) = k_1 \cdot \Delta u(t) \ \ \ \mathbf{(2.1.6)}$


где:

$T_2^2= \frac{m}{k}; T_1= \frac{c}{k}; k_1=\frac{1}{k}.$


Уравнение (2.1.6) это уравнение динамики в канонической форме, т.е. коэффициент при y(t) равен 1.0!


Легко видеть, что коэффициенты перед членами, содержащими производные, имеют смысл (и размерность!) постоянных времени. В самом деле:


$T_1 = \frac{c}{k} \Rightarrow [\frac{кг \cdot c^2}{c \cdot кг}] = [c]$


$T_2^2 = \frac{m}{k} \Rightarrow [\frac{кг \cdot c^2}{kg}] =[c^2]$


Таким образом, получаем, что:
коэффициент перед первой производной имеет размерность [c] т.е. смысл некоторой постоянной времени;
коэффициент перед второй производной: [$c^2$];
коэффициент в правой части ($k_1$): [$\frac{c^2}{кг}$].
Тогда уравнение (2.1.6) можно записать в операторной форме:


$(T_2^2 \cdot p^2 + T_1 \cdot p+1)\Delta y(t) = k_1 \Delta u(t)$, что эквивалентно

$L(p)\Delta y(t) = N(p) \Delta u(t) \ \ \ \mathbf{(2.1.6.а)}$

где: $p= \frac{d}{dt}$ оператор диффренцирования;
$L(p) = T_2^2 \cdot p + T \cdot p + 1$ -линейный дифференциальный оператор; $L(p)$
$N(p)$ линейный дифференциальный оператор, вырожденный в константу, равную $k_1$.

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


Введем новые нормированные (безразмерные) переменные:

$\left[ \begin{gathered} \widetilde y(t) = \frac {y(t)-y_0}{y_0} = \frac {\Delta y(t)}{y_0}\\ \widetilde u(t) = \frac {u(t)-u_0}{u_0} =\frac {\Delta u(t)}{u_0}\\ \end{gathered} \right. \Rightarrow \left[ \begin{gathered} y(t) =y_0 \cdot [1+ \widetilde y(t)]\\ u(t) = u_0 \cdot [1+ \widetilde u(t)]\\ \end{gathered} \right. \Rightarrow \left[ \begin{gathered} y'(t) =y_0 \cdot \widetilde y(t)\\ y''(t) = y_0 \cdot \widetilde y(t)''\\ \end{gathered} \right. $


Подставляя эти соотношения в уравнение (2.1.2), имеем:

$m \cdot y_0 \cdot \frac{d^2 \widetilde y(t)}{dt^2} = m \cdot g +u_0 \cdot[1+\widetilde u(t)] -k \cdot y_0 \cdot[1+\widetilde y(t)] - c \cdot y_0 \cdot \frac{d \widetilde y(t)}{dt}; или$

$m \cdot y_0 \cdot \frac{d^2 \widetilde y(t)}{dt^2} = \underline {m \cdot g} + \underline {u_0} +u_0 \cdot \widetilde u(t) - \underline {k \cdot y_0} - k \cdot y_0 \cdot \widetilde y(t) - c \cdot y_0 \cdot \frac{d \widetilde y(t)}{dt}.$


Поддчеркнутые члены выражения в сумме дают 0 (см. 2.1.4) Перенося в левую часть члены, содержащие $\widetilde y(t)$, и, разделив на $k \cdot y_0$, получаем:

$\frac{m \cdot y_0}{k \cdot y_0} \cdot \frac{d^2 \widetilde y(t)}{dt^2} + \frac {c \cdot y_0}{k \cdot y_0} \cdot \frac{d \widetilde y(t)}{dt} +\widetilde y(t)= \frac{u_0}{k \cdot y_0} \cdot \widetilde u(t) \Rightarrow $

$(T_2^2 \cdot p + T \cdot p + 1) \cdot \widetilde y(t) = k_x \cdot \widetilde u(t) \ \ \ \mathbf{(2.1.7)}$


где: $T_2^2= \frac{m}{k}; T_1= \frac{c}{k}; k_x=\frac{u_0}{k \cdot y_0} $ коэффициент усиления, причем безразмерный.

Проверим размерность коэффициента $k_x$

$\left[\frac{кг \cdot м}{с^2} \cdot \frac{c^2}{кг} \cdot \frac{1}{м}\right] =[1].$


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


На рис. 2.1.4 представлены статические характеристики для механического демпфера:



Рис. 2.1.4 Статические характеристики механического демпфера

Процедура нормировки отклонений позволяет привести уравнения динамики к виду:

$L(p) \cdot \widetilde y(t) = N(p) \cdot \widetilde u(t) \ \ \ \mathbf{(2.1.8)}$

где $L(p), N(p) - $ дифференциальные операторы.

Если дифференциальные операторы $L(p), N(p) - $ линейные, а статическая характеристика САУ (звена) тоже линейна, то выражение (2.1.8) соответствует линейному обыкновенному дифференциальному уравнению (ОДУ).


А если $L(p), N(p) - $ нелинейные дифференциальные операторы, или $\widetilde y_{stat} \neq k \cdot \widetilde u_{stat}$, то уравнение динамики нелинейное. Под нелинейными действиями понимаются все математические действия, кроме сложения (+) и вычитания (-).


Пример создания модели демпфера можно посмотереть здесь: Технология получения уравнений динамики ТАУ



2.2. Линеаризация уравнений динамики САУ (САР)


Практически все реальные системы автоматического управления (САУ) являются нелинейными, причем нелинейность САУ может определяться различным причинами:


  1. Нелинейностью статической характеристики.
  2. Нелинейностью динамических членов в уравнениях динамики.
  3. Наличием в САУ принципиально нелинейных звеньев.

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


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



Рис. 2.2.1 Пример изменения мощности реактора

Рассмотрим некоторое звено (или САР в целом), описание динамики которого можно представить в переменных вход-выход:



Рис. 2.2.2 Звено САР

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

$L(p) \cdot y(t) = N(p) \cdot u(t) \ \ \ \mathbf{(2.2.1)}$


Перенесем $N(p) u(t)$ в левую часть уравнения и запишем уравнение в виде%

$F(y,y',y'',...y^{n}, u, u',u'', ...u^m,t)=0 \ \ \ \mathbf{(2.2.2)}$


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


Будем считать, что при t 0 САУ (звено) находилось в равновесии (в стационарном состоянии). Тогда уравнение (2.2.2) вырождается в уравнение статической характеристики:

$y'=y''=...y^n=u'=u''=...u^m=0 \Rightarrow F(y_0,u_0)=0 \ \ \ \mathbf{(2.2.3)}$


Разложим левую часть уравнения (2.2.2) в ряд Тейлора в малой окрестности точки равновесного состояния $(y_0, u_0)(y0, u0)$.


Напомним, что разложение в ряд Тейлора трактуется следующим образом: если $y = f(x)$, то простое разложение функции в ряд Тейлора в окрестности точки $x = x_0$ будет выглядеть так:


$ \begin{eqnarray} y(x) = f(x) = f(x_0)+ \frac{1}{1!} \cdot \left( \frac{df}{dx}\right)_{x=x_0} \cdot (x-x_0)+ \frac{1}{2!} \cdot \left( \frac{d^2f}{dx^2} \right)_{x=x_0} \cdot (x-x_0) +\\ ...+\frac{1}{n!} \cdot \left( \frac{d^nf}{dx^n} \right)_{x=x_0} \cdot (x-x_0) \end{eqnarray}$


C учетом вышеприведенного разложение принимает вид:


$ \begin{eqnarray} F(y,y',y'',...y^{n}, u, u', ...u^m,t) = F(y_0,u_0)+\frac{1}{1!}\cdot \left( \frac{dF}{dy}\right)_{ y=y_0;u =u_0 } \cdot (y-y_0)+\\ + \frac{1}{2!} \cdot \left( \frac{d^2F}{dy^2}\right)_{y=y_0;u =u_0}\cdot (y-y_0)^2+\frac{1}{3!} \cdot \left( \frac{d^3F}{dy^3}\right)_{y=y_0;u =u_0}\cdot (y-y_0)^3 +..\\+\frac{1}{k!} \cdot \left( \frac{d^kF}{dy^k}\right)_{y=y_0;u =u_0}\cdot (y-y_0)^k+ \frac{1}{1!}\cdot \left( \frac{dF}{dy'}\right)_{ 0 } \cdot (y') +\frac{1}{2!}\cdot \left( \frac{d^2F}{d(y')^2}\right)_{ 0 } \cdot (y')^2+\\ ..+\frac{1}{1!}\cdot \left( \frac{dF}{dy^{(n)}}\right)_{ 0 } \cdot (y^{(n)})+ \frac{1}{2!}\cdot \left( \frac{d^2F}{d(y^{n})^2}\right)_{ 0 } \cdot (y^{(n)})^2+..\\ ..+\frac{1}{1!}\cdot \left( \frac{dF}{du}\right)_{ 0 } \cdot (u-u_0)+\frac{1}{2!} \cdot \left( \frac{d^2F}{du^2}\right)_{0}\cdot (u-u_0)^2+..\\ ..+\frac{1}{k!}\cdot \left( \frac{d^kF}{d(u^{m})^k}\right)_{ 0 } \cdot (u^{(m)})^k+.. \end{eqnarray}$


Предполагая, что отклонения выходных и входных воздействий незначительны, (т.е.:$\frac{\Delta y(t)}{y_0} <<1; \frac{\Delta u(t)}{u_0} <<1;$), оставим в разложении только члены первого порядка малости (линейные). Поскольку $[y(t)-y_0] \equiv \Delta y(t); y'(t) = [y_0+\Delta y(t)]' = (\Delta y(t))'$, получаем:


$ F(y,y',y''..y^{(n)},u,u',u''..u^{m})\simeq \left( \frac{\partial F}{\partial y} \right)_0\cdot \Delta y+\left(\frac{\partial F}{\partial y'}\right)_0 \cdot (\Delta y)' +\left(\frac{\partial F}{\partial y''}\right)_0 \cdot (\Delta y)''+..\\ ..+\left(\frac{\partial F}{\partial u}\right)_0 \cdot \Delta u+ \left(\frac{\partial F}{\partial u'}\right)_0 \cdot (\Delta u)' + \left(\frac{\partial F}{\partial u''}\right)_0 \cdot (\Delta u)''+..+ \left(\frac{\partial F}{\partial u^{m}}\right)_0 \cdot (\Delta u)^{(m)}\ \ \ \mathbf{(2.2.4)}$


Подставляя соотношение (2.2.4) в уравнение (2.2.2), и перенося множители при у и u в разные части получаем уравнения:

$a_n^0 \cdot \frac{d^{(n)}}{dt^n} \Delta y +a_{n-1}^0 \cdot \frac{d^{(n-1)}}{dt^{n-1}} \Delta y +..+a_{1}^0 \cdot \frac{d}{dt} \Delta y +a_{0}^0\cdot\Delta y = \\ =b_m^0 \cdot \frac{d^{(m)}}{dt^m} \Delta u +b_{m-1}^0 \cdot \frac{d^{(m-1)}}{dt^{m-1}} \Delta u +..+b_{1}^0 \cdot \frac{d}{dt} \Delta u +b_{0}^0\cdot\Delta u \ \ \ \mathbf{(2.2.5)}$

где:

$a_0^0= \left( \frac{\partial F}{\partial y} \right)_{y =y_0;u =u_0};a_1^0= \left( \frac{\partial F}{\partial y'} \right)_{y =y_0;u =u_0}; ...a_n^0= \left( \frac{\partial F}{\partial y^{(n)}} \right)_{y =y_0;u =u_0} ; \\ b_0^0= \left( \frac{\partial F}{\partial u} \right)_{y =y_0;u =u_0};b_1^0= \left( \frac{\partial F}{\partial u'} \right)_{y =y_0;u =u_0}; ...b_m^0= \left( \frac{\partial F}{\partial u^{(m)}} \right)_{y =y_0;u =u_0}.$


Коэффициенты $a_i^0, b_j^0$ постоянные коэффициенты, поэтому уравнения 2.2.5 линейное дифференциальное с постоянными коэффициентами.


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

$L(p)\cdot\Delta y(t) = N(p) \cdot \Delta u(t)\ \ \ \mathbf{(2.2.6)}$


где $p = \frac{\partial }{\partial t}$ оператор дифференцирования;
$L(p)$ линейный дифференциальный оператор степени n;
$N(p)$ линейный дифференциальный оператор степени m, причем обычно порядок оператора $L(p)$ выше порядка оператора $N(p)$: $ n m.$

Уравнения (2.2.5) и (2.2.6) уравнения динамики системы (звена) в отклонениях.


Если исходное уравнение (2.2.1) дифференциальное уравнение в физических переменных (температура, скорость, поток и т.д.), то размерность коэффициентов $a_i^0, b_j^0$ может быть произвольной (любой).


Переход к нормализованным отклонениям позволяет упорядочить размерность коэффициентов. В самом деле, разделив уравнение (2.2.5) на $(y_0, u_0)$ и выполнив некоторые преобразования, получаем:


$a_n^* \cdot \tilde{y}^{(n)} +a_{(n-1)}^* \cdot \tilde{y}^{(n-1)} +..+a_1^* \cdot \tilde{y}'+a_0^* \cdot \tilde{y} = \\ =b_m^* \cdot \tilde{u}^{(m)} +b_{(m-1)}^* \cdot \tilde{u}^{(m-1)} +..+b_1^* \cdot \tilde{u}'+b_0* \cdot \tilde{u} \ \ \ \mathbf{(2.2.7)}$


Приведение уравнения динамики САУ (звена) к нормализованному виду позволяет унифицировать размерность коэффициентов уравнений: ==>


$$display$$[a_0^*] = [1] ;\ \ [a_1^*]= [c];\ \ [a_2^*]= [c^2];\ \ [a_3^*]= [c^3];...[a_n^*]= [c^n]\\ [b_0^*] = [1] ;\ \ [b_1^*]= [c];\ \ [b_2^*]= [c^2];\ \ [b_3^*]= [b^3];...[b_m^*]= [c^m]$$display$$


Если вынести в правой части (2.2.7) коэффициент $b_0^*$ за общую скобку и разделить все уравнение на $a_0^*$, то уравнение принимает вид:


$a_n \cdot \tilde{y}^{(n)} +a_{(n-1)}\cdot \tilde{y}^{(n-1)} +..+a_1\cdot \tilde{y}'+\tilde{y} = \\ =k \cdot [b_m \cdot \tilde{u}^{(m)} +b_{(m-1)} \cdot \tilde{u}^{(m-1)} +..+b_1 \cdot \tilde{u}'+ \tilde{u}] \ \ \ \mathbf{(2.2.8)}$


где:

$a_n = \frac{a_n^*}{a_0^*};\ a_{n-1} = \frac{a_{n-1}^*}{a_0^*}; \ ...a_{1} = \frac{a_{1}^*}{a_0^*}; \ k = \frac{b_0^*}{a_0^*} \\ b_n = \frac{b_n^*}{b_0^*};\ b_{n-1} = \frac{b_{n-1}^*}{b_0^*}; \ ...b_{1} = \frac{b_{1}^*}{b_0^*}; $

или в операторном виде:

$(a_n \cdot p^{(n)} +a_{(n-1)}\cdot p^{(n-1)} +..+a_1\cdot p'+1) \cdot \tilde{y} = \\ =k \cdot (b_m \cdot p^{(m)} +b_{(m-1)} \cdot p^{(m-1)} +..+b_1 \cdot \tilde{u}'+ 1)\cdot \tilde{u}\\ L(p)\cdot \tilde{y} =k \cdot N(p) \cdot \tilde{u} \ \ \ \mathbf{(2.2.9)}$


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


$$display$$Если \ t 0 \Rightarrow \left[ \begin{gathered} \tilde {y}(t) = \tilde {y}(0) =0;\\ \tilde u(t) = \tilde u(0) = 0.\\ \end{gathered} \right.$$display$$


Пример


Выполнить линеаризацию уравнения динамики некоторой абстрактной САР в окрестности состояния (x0, y0), если полное уравнение динамики имеет вид:


$a_3^0 \cdot y'''(t) +a_2^0 \cdot y''(t)+a_1^0 \cdot y'(t) \cdot[y(t)-d]+ a_2^0 \cdot y^2(t)=b_1^0 \cdot x'(t) +b_0^0 \cdot x(t); $


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


во-первых, в нелинейности статической характеристики:


$a_0^0 \cdot y^2(0) = b_0^0 \cdot x(0); \Rightarrow y_0 = \sqrt{\frac{b_0^0}{a_0^0} \cdot x_0} = \sqrt {k_0 \cdot x_0}$



Рис. 2.2.3 Линеаризации статической характеристики

во-вторых, слагаемое в левой части $a_1^0 \cdot y'(t) \cdot[y(t)-d]$ чисто нелинейное, так как действие умножения является нелинейным.


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


Преобразования выполним в следующей последовательности:


  1. Перейдем к безразмерным переменным (нормализованным);
  2. Выполним линеаризацию, отбросив нелинейные члены 2-го и выше порядков малости.

Перейдем к новым безразмерным переменным:


$\tilde{y}(t) = \frac{y(t) - y_0}{y_0};\ \Rightarrow y(t) = y_0 \cdot [1+ \tilde{y}(t)]; \\ \tilde{x}(t) = \frac{x(t) - x_0}{x_0};\ \Rightarrow x(t) = x_0 \cdot [1+ \tilde{x}(t)].$


Заметим, что:
$x(t) = x_0+ \Delta x(t) = x_0+ x_0 \cdot \tilde{x}(t) \ и \ y(t) = y_0+ \Delta y(t) = y_0+ y_0 \cdot \tilde{y}(t)$.


Подставляя значения x(t) и y(t) в исходное уравнение:


$ a_3^0 \cdot y_0 \cdot \tilde y'''(t) +a_2^0 \cdot y_0 \cdot \tilde y''(t)+a_1^0 \cdot y_0 \cdot \tilde y'(t) \cdot[y_0+y_0 \cdot \tilde y(t) -d]+a_0^0 \cdot y_0^2 \cdot[1+ \tilde y(t)]^2 = \\ = b_1^0 \cdot x_0 \cdot \tilde x'(t) + b_0^0 \cdot х_0 \cdot[1+\tilde x(t)]; \ \Rightarrow \ раскрыв \ скобки \Rightarrow \\ a_3^0 \cdot y_0 \cdot \tilde y'''(t)+a_2^0 \cdot y_0 \cdot \tilde y''(t)+a_1^0 \cdot y_0^2 \cdot \tilde y'(t) + a_1^0 \cdot y_0^2 \cdot \tilde y'(t) \cdot \tilde y(t)-a_1^0 \cdot y_0 \cdot \tilde y'(t) \cdot d + \\ +a_0^0 \cdot y_0^2 +2 \cdot a_0^0 \cdot y_0^2 \cdot\tilde y(t) +a_0^0 \cdot y_0^2 \cdot\tilde y(t)^2 = b_1^0 \cdot x_0 \cdot \tilde x'(t) + b_0^0 \cdot х_0+ b_0^0 \cdot х_0 \cdot \tilde x(t)];$


Удаляем полученного уравнения уравнения стационара: $a_0^0 \cdot y_0^2= b_0^0 \cdot х_0$, а так же пренебрегая слагаемыми второго прядка малости: $\ a_1^0 \cdot y_0^2 \cdot \tilde y'(t) \cdot \tilde y(t)$, получаем следующее уравнение:


$ a_3^0 \cdot y_0 \cdot \tilde y'''(t)+a_2^0 \cdot y_0 \cdot \tilde y''(t)+(a_1^0 \cdot y_0^2 -a_1^0 \cdot y_0 \cdot d) \cdot \tilde y'(t)+2 \cdot a_0^0 \cdot y_0^2 \cdot\tilde y(t) =\\ = b_1^0 \cdot x_0 \cdot \tilde x'(t) + b_0^0 \cdot х_0 \cdot \tilde x(t);$


Вводим новые обозначения:

$a_3^* = a_3^0 \cdot y_0 ; \ \ a_2^* = a_2^0 \cdot y_0; \ \ a_1^* = a_1^0 \cdot y_0^2 -a_1^0 \cdot y_0 \cdot d; \ \ a_0^* =2 \cdot a_0^0 \cdot y_0^2; \\ b_1^* = b_1^0 \cdot x_0; \ \ b_0^*=b_0^0 \cdot х_0 \ $


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


$a_3^* \cdot \tilde y'''(t)+a_2^* \cdot \tilde y''(t)+a_1^* \cdot \tilde y'(t)+ a_0^* \cdot\tilde y(t) = b_1^* \cdot \tilde x'(t) + b_0^* \cdot \tilde x(t);$


Если в правой части вынести за общую скобку $b_0^*$ и разделить все уравнение на $a_0^*$, то уравнение (линеаризованное) принимает вид:


$a_3 \cdot \tilde y'''(t)+a_2 \cdot \tilde y''(t)+a_1 \cdot \tilde y'(t)+ \tilde y(t) = k \cdot[ b_1 \cdot \tilde x'(t) + \tilde x(t)]$


где:

$a_3 = \frac{a_3^*}{a_0^*}; \ \ a_2 = \frac{a_2^*}{a_0^*}; \ \ a_1 = \frac{a_2^*}{a_0^*}; \ \ k = \frac{b_o^*}{a_0^*}; \ \ b_1 = \frac{b_1^*}{b_0^*}; $


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


2.3. Классический способ решения уравнений динамики


Классический метод решения уравнений динамики САУ (САР) применим только для линейных или линеаризованных систем.


Рассмотрим некоторую САУ (звено), динамика которой описывается линейным дифференциальным уравнением вида:


$L(p) \cdot y(t) = N(p)*x(t), \ \ \ \mathbf{(2.3.1)}\\ где: L(p) = a_n\cdot p^n + ..+a_1 \cdot p + a_0 \\ N(p) = b_m \cdot p^m+..+b_1 \cdot p+b_0 $


Переходя к полной символике, имеем: $\Rightarrow$


$a_n \cdot y^{(n)}+a_{n-1} \cdot y^{(n-1)}+..+a_1 \cdot y'+a_{0} = b_m \cdot x^{(m)}+b_{n-1} \cdot x^{(n-1)}+..+b_1 \cdot y'+b_{0} \ \ \mathbf{(2.3.2)};$


Выражение (2.3.2) обыкновенное дифференциальное уравнение (ОДУ), точнее неоднородное ОДУ, так как правая часть 0.


Известно входное воздействие x(t), коэффициенты уравнения и начальные условия (т.е. значения переменных и производных при t = 0).


Требуется найти y(t) при известных начальных условиях.


Известно, что


$y(t) = y_{общ.}(t)+y_{част.}(t),\ \ \ \mathbf{(2.3.3)}$


где: $y_{общ.}(t)$ решение однородного дифференциального уравнения $L(p) y(t) = 0; $y_{част.}(t) $inline$ - частное решение. $inline$


Будем называть решение однородного дифференциального уравнения $y_{общ.} = y_{собств.}$, собственным решением, так как его решение не зависит от входного воздействия, а полностью определяется собственными динамическими свойствами САУ (звена).


Вторую составляющую решения (2.3.3) будем называть $y_{част.} = y_{вын.}$, вынужденным, так как эта часть решения определяется внешним воздействием $x(t)$, поэтому САУ (САР или звено) вынуждена отрабатывать это воздействие:


$y(t) = y_{собств.}(t)+y_{вын.}(t),\ \ \ \mathbf{(2.3.4)}$


Напомним этапы решения:


1) Если имеется уравнение вида $L(p) \cdot y(t) = N(p)*x(t)$, то сначала решаем однородное дифференциальное уравнение:


$a_n \cdot y^{(n)}+a_{n-1} \cdot y^{(n-1)}+..+a_1 \cdot y'+a_{0} =0 $


2) Записываем характеристическое уравнение:


$L(\lambda) =0; \ \Rightarrow \ a_n \cdot \lambda^{n}+a_{n-1} \cdot \lambda^{n-1}+..+a_1 \cdot \lambda+a_{0} =0 \ \ \ \mathbf{(2.3.5)}$


3) Решая уравнение (2.3.5), которое является типичным степенным уравнением, каким-либо способом (в том числе и с помощью стандартных подпрограмм на компьютере) находим корни характеристического уравнения $\lambda_i$
4) Тогда собственное решение записывается в виде:


$y_{собств.}(t)=\sum_{j=1}^n C_j \cdot e^{\lambda_j \cdot t}, \ \ \ \mathbf{(2.3.6)}$


если среди $\lambda_i$ нет повторяющихся корней (кратность корней равна 1).


Если уравнение (2.3.5) имеет два совпадающих корня, то собственное решение имеет вид:


$y_{собств.}(t)=\sum_{j=1}^{n-2} C_j \cdot e^{\lambda_{j} \cdot t} +C_{n-1} \cdot e^{\lambda_{n-1} \cdot t}\cdot [1+C_n\cdot t]. \ \ \ \mathbf{(2.3.7)}$


Если уравнение (2.3.5) имеет k совпадающих корней (кратность корней равна k), то собственное решение имеет вид:


$y_{собств.}(t)=\sum_{j=1}^{n-k} C_j \cdot e^{\lambda_{j} \cdot t} +C_{n+1-k} \cdot e^{\lambda_{n+1-k} \cdot t}\cdot [1+C_{n+2-k}\cdot t+C_{n+3-k}\cdot t^2+.. \\ ..+C_{n}\cdot t^{k-1}]. \ \ \ \mathbf{(2.3.8)}$


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


Если вид правой части дифференциального уравнения относительно несложная функция времени, то предпочтительным является способ а): подбор решения. $y_{вын.}(t) = f_{вын}(t)$.


6) Суммируя полученные составляющие (собственную и вынужденную), имеем: $\Rightarrow$


$y_{полн.}(t)=\sum_{j=1}^n C_j \cdot e^{\lambda_j \cdot t} + f_{вын}(t).$


7) Используя начальные условия (t = 0), находим значения постоянных интегрирования $C_j$. $\Rightarrow$ Обычно получается система алгебраических уравнений. $\Rightarrow$ Решая систему, находим значения постоянных интегрирования $C_j$


Пример


Найти аналитическое выражение переходного процесса на выходе звена, если


$\left\{ \begin{gathered} 2 \cdot y''(t)+5 \cdot y'(t)+2 \cdot y(t) =1- e^{-t}\\ Начальные \ условия \ t = 0; \Rightarrow y(0) = 0; y'(0) =0.\ \end{gathered} \right.$


Решение. $\Rightarrow$ Запишем однородное ОДУ: $2 \cdot y''(t)+5 \cdot y'(t)+2 \cdot y(t) =0$
Характеристическое уравнение имеет вид: $2 \cdot \lambda ^2+5 \cdot \lambda+2 = 0$; Решая, имеем: $\lambda_1 = -2; \ \ \lambda = 0.5,$ тогда:

$y_{соб} = С_1 \cdot e^{-2 \cdot t}+С_2 \cdot e^{-0.5 \cdot t},$


где $С_1, С_2$ неизвестные (пока) постоянные интегрирования.

По виду временной функции в правой части запишем $y_{вын}(t)$ как:


$у_{вын}(t) =A+B \cdot e^{-t} \Rightarrow у_{вын}'(t) = -B\cdot e^{-t} \Rightarrow у_{вын}''(t) = B\cdot e^{-t} $


Подставляя в исходное уравнение, имеем:


$2\cdot B \cdot e^{-t} - 5 \cdot B \cdot e^{-t}+2\cdot A +2 \cdot B \cdot e^{-t} =1 - e^{-t} \Rightarrow \left\{ \begin{gathered} 2 \cdot A =1\\ -B = -1\ \end{gathered} \right. \Rightarrow\\ \Rightarrow \left\{ \begin{gathered} A = \frac{1}{2}\\ B = 1\ \end{gathered} \right. \Rightarrow y_{вын.}(t) = \frac{1}{2} -e^{-t};$


Суммируя $y_{соб}, y_{вын}$, имеем: $y(е) = С_1 \cdot e^{-2 \cdot t}+С_2 \cdot e^{-0.5 \cdot t}+\frac{1}{2}+ e^{-t}.$


Используя 1-е начальное условие (при t = 0), получаем: $0 =C_1+C_2+0.5+1$, а из 2-го начального условия имеем: $0 = -2 \cdot C_1 - 0.5 \cdot C_2 -1.$


Решая систему уравнений относительно $С_1$ и $С_2$, имеем: $С_1 = -1/6; \ \ \ C_2 = -4/3. $
Тогда окончательно:


$y(t) = - \frac{1}{6} e^{-2t}- \frac{4}{3} e^{-0.5t}+\frac{1}{2}+e^{-t};$


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


$2 \cdot y''(t)+5 \cdot y'(t)+2 \cdot y(t) =1- e^{-t} \Rightarrow \\ \Rightarrow y''(t) = 0.5 - 0.5\cdot e^{-t} - 2.5 \cdot y'(t)- y(t)$


Создадим модель SimInTech, содержащую исходное динамическое уравнение и полученное аналитическое решение, и выведем результаты на один график (см. рис. 2.3.1).



Рис. 2.3.1 структурная схема для проверки решения


На рис. 2.3.2 приведено решение по вышеприведенному соотношению и численное решение задачи в среде SimInTech (решения совпадают и линии графиков наложены друг на друга).



Рис. 2.3.2 Решение уравнения динамики

Ссылки по теме:


  1. Википедия про ряд Тейлора
  2. Дифференциальные уравнения на Match24.ru
  3. Пример создания модели груза на пружине.
  4. Начало лекций здесь: Введение в теорию автоматического управления. Основные понятия теории управления техническим системами
Подробнее..

Модельно-ориентированное проектирование. Построение активного выпрямителя (на основе математической модели)

06.07.2020 06:04:37 | Автор: admin

Продолжение цикла статей про модельно ориентированное проектирование. В предыдущих сериях:


В этой серии, авторы Ю. Н. Калачев и А.Г. Александров, представляют математическую модель активного выпрямителя в среде структурного моделирования.




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



Рис. 1 Принципиальная схема активного выпрямителя

1. Как это работает?


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


При этом заряженную емкости Cdc</sub> инвертора можно рассматривать как источник напряжения, из которого инвертор с помощью ШИМ способен формировать трехфазное напряжение различной амплитуды и фазы (естественно, вследствие импульсного управления речь идет о среднем напряжении). Это напряжение совместно с напряжением сети формирует напряжение, на трехфазном дросселе определяющее фазу и амплитуду его тока.

На холостом ходу (если потребление тока от сети отсутствует) инвертор формирует напряжение, совпадающее с напряжением входной сети по амплитуде и фазе. Ток в дросселе при этом, естественно, не течет.


В режиме активного потребления на дросселе формируется напряжение, фаза которого опережает фазу сети на /2. При этом ток в индуктивности, отстающий от напряжения на /2, совпадет по фазе с напряжением сети. Его амплитуда, необходимая для поддержания в звене постоянного тока заданного напряжения, определяется амплитудой напряжения на дросселе.

В режиме рекуперации (при отдаче энергии в сеть) на дросселе формируется напряжение, отстающее от сетевого по фазе на /2, что приводит к протеканию тока дросселя в противофазье с напряжением сети. Заданное напряжение в звене постоянного тока при этом поддерживается амплитудой напряжения на дросселе.


На Рис.2 показаны векторные диаграммы, поясняющие вышесказанное.



Рис. 2 векторные диаграммы в различных режимах

На диаграммах:
$\vec U_ 1 $ вектор напряжения входной сети
$\vec U_ 2 $ вектор напряжения, формируемый инвертором
$\vec U_ 1 - \vec U_ 2 $ вектор напряжения дросселя
$\vec I $ вектор тока сети
Система координат ABC неподвижная, трехфазная
Система координат XY вращающаяся система координат, ось X которой совпадает с вращающимся вектором напряжения сети.


ПРИМЕЧАНИЕ Глядя на диаграммы на Рис.2 можно заметить интересную деталь: малейшее отличие фазы вектора напряжения инвертора от фазы вектора напряжения сети приводит к фазовому скачку напряжения на дросселе на 90, и соответственно, к смене режима холостого хода на рекуперацию или активное потребление.


Итак, как уже говорилось, на трехфазном дросселе и инверторе строится повышающий преобразователь, обеспечивающий поддержание заданного напряжения звена постоянного тока (Udc). Это поддержание осуществляется с помощью управления вектором входного тока. За счет ШИМ-управления и повышения частоты переключения IGBT-ключей инвертора удается добиться снижения индуктивностей входного дросселя до разумных значений при получении синусоидальной формы входного тока и обеспечении его активного характера.


2. Математическое описание работы активного выпрямителя


Для схемы на Рис.1 можно записать следующее выражение:

$\vec U_1 = \vec U_2+ \vec I \cdot R +L \cdot \frac{d \vec I}{dt}$

где:
R активное сопротивление дросселя;
L индуктивность дросселя.

Для вращающейся системы координат XY, связанной с вектором напряжения входной сети, можно записать:


$\left \{ \begin{gathered} U_1 =U_{2X} + I_X R +L \frac{dI_X}{dt} - \omega L I_Y\\ 0= U_{2Y} + I_Y R +L \frac{dI_Y}{dt} + \omega L I_X\\ \end{gathered} \right.$


где:
$\omega = 2\pi f = 100 \pi $ для 50 Гц
$I_X$ активная составляющая входного тока (совпадает с фазой сети);
$I_Y$ реактивная составляющая входного тока (отстает или опережает фазу сети на 90).

Для того, чтобы характер потребления корректора был активным необходимо поддерживать $I_Y = 0$.


Кроме того, корректор должен обеспечивать функции выпрямителя, то есть поддерживать заданное значение $U_{dc} $, независимо от тока нагрузки.


3. Структура системы управления активного выпрямителя


Рассмотрим структуру системы на основе ее модели в SimInTech (Рис.3).



Рис. 3 структурная схема модели

Система регулирования строится во вращающейся синхронно с вектором напряжения входной сети системе координат XY по двухконтурной структуре. Внешний контур напряжения с помощью регулятора напряжения вырабатывает задание на активную согставляющую тока дросселя ($I_X $), необходимую для поддержание заданного$U_{dc}$.


Внутренний контур тока обеспечивает отработку задания активной составляющей тока ($I_X$) при нулевой реактивной составляющей ($I_Y=0$).


Ниже перечислены и кратко описаны блоки системы:
Uset задатчик напряжения Udc,.
ВФ вычислитель фазы сети, определяет угол поворота вектора напряжения входной сети в неподвижной системе координат и формирует сигналы необходимые для координатных преобразований.
ABC=>XY преобразователь координат, осуществляет переход из неподвижной трехфазной системы координат во вращающуюся прямоугольную систему координат ХY, связанную с вектором входного напряжения.
XY=>ABC преобразователь координат осуществляет переход из вращающейся системы координат ХY в неподвижную трехфазную.
PU регулятор напряжения (ПИ), преобразует сигнал ошибки $U_{dc}$ в сигнал задания активной составляющей входного тока $I_{1X}$.
РIx регулятор тока, преобразует сигнал ошибки активного тока в сигнал задания напряжения по оси Х вращающейся системы координат.
РIy регулятор тока, преобразует сигнал ошибки реактивного тока в сигнал задания напряжения по оси Y вращающейся системы координат.
Огр.U ограничитель напряжения ограничивает вектор напряжения по модулю максимально возможным значением с приоритетом Y составляющей.
КПС блок компенсации предназначен для компенсации перекрестных связей между токами координат (см. последние члены в уравнениях 1.1). Компенсация не осуществляется по координате X, так как предполагается равенство нулю тока по оси Y.
ФЗМ Формирователь Закона Модуляции блок алгоритма ШИМ с полным использованием напряжения звена постоянного тока.


ВНИМАНИЕ:
  • Имеющий глаза да увидит несколько необычное построение вычитающих блоков на входе регуляторов тока. В них сигнал задания тока вычитается из сигнала обратной связи, а не наоборот, как обычно бывает. Это связано с тем, что при координатных преобразованиях положительным считается фазный ток, вытекающий из источника напряжения. Для преобразования АВС=>XY источником является сеть, а для обратного преобразования, XY => АВС, источником является инвертор. Так как фазные токи с точки зрения сети и инвертора противоположны, требуется инвертирование задания и обратной связи в контуре тока, что и реализуется в структуре вычитающих блоков на входе его регуляторов.
  • На описании математики блоков подробно не останавливаюсь, так как она присутствует во внутренних структурах блоков, доступных пользователю SimInTech (смотрите внутреннюю структуру, читайте help на элементы).

4. Структура силовой части выпрямителя


Структура силовой части выпрямителя рассмотрена на основе ее математической модели в представлена на Рис.4.



Рис. 4 структурная схема модели силовой части выпрямителя

Параметры силовой схемы следующие:
L = 0.0015 Гн
С = 10 000 мкФ
Частота ШИМ 8.33 кГц


5. Работа модели


Пакет модели состоит из двух проектов, схемы которых приведены выше. Время интегрирования проекта системы управления равно такту ШИМ 160мкс Время интегрирования проекта силовой части 1мкс Синхронизация проектов с частотой обсчета проекта системы управления моделирует временную дискретность реальной (цифровой) системы управления.
Ниже приведено описание алгоритма работы пакета модели и поясняющие его работу графики (Рис.5, 6 и 7).


На участке 1 транзисторы инвертора выключены, происходит заряд емкости звена постоянного тока через диоды инвертора с ограничением тока на зарядном резисторе.
На участке 2 зарядный резистор шунтируется реле и на холостом ходу происходит повышение напряжения до заданного (700В).
На участке 3 ток нагрузки (50А) потребляется из сети.
На участке 4 ток нагрузки (-50А) рекуперируется в сеть.



Рис. 5

Рис. 6

Рис. 7

Токи сети имеют активный и синусоидальный характер. Содержание высших гармоник в токе по данным анализатора спектра графика в SimInTech составляет 4.4% .


Осциллограмма тока и напряжения фазы А и экран измерения режимов снятые при работе реального активного выпрямителя в качестве звена постоянного тока преобразователя частоты приведены на Рис.8 ниже.



Рис. 8

Можно констатировать, что ток и напряжение совпадают по фазе и Cos=1


Для связи с автором Юрий Николаевич Калачёв (Kalachev_i@mail.ru)
Подробнее..

Как определить размер переменных во время выполнения Go-программы

27.06.2020 22:14:45 | Автор: admin
Аннотация: в заметке рассматривается один из способов анализа потребления памяти компонентами Go-приложения.
Зачастую в памяти программы хранятся структуры данных, которые изменяют свой размер динамически, по ходу работы программы. Примером такой структуры может быть кэш данных или журнал работы программы или данные, получаемые от внешних систем. При этом может возникнуть ситуация, когда потребление памяти растёт, возможностей оборудования не хватает, а конкретный механизм утечки не ясен.
Основным способом профилирования Go-приложений является подключение инструмента pprof из пакета net/http/pprof. В результате можно получить таблицу или граф с распределением памяти в работающей программе. Но использование этого инструмента требует очень больших накладных расходов и может быть неприменимо, особенно если вы не можете запустить несколько экземпляров программы с реальными данными.
В таком случае возникает желание измерить потребление памяти объектами программы по запросу, чтобы, например, отобразить статистику системы или передать метрики в систему мониторинга. Однако средствами языка это в общем случае невозможно. В Go нет инструментов для определения размера переменных во время работы программы.
Поэтому я решил написать небольшой пакет, который предоставляет такую возможность. Основным инструментом является рефлексия (пакет reflection). Всех интересующихся вопросом такого профилирования приложения приглашаю к дальнейшему чтению.


Сначала нужно сказать пару слов по поводу встроенных функций
unsafe.Sizeof(value)
и
reflect.TypeOf(value).Size()

Эти функции эквивалентны и зачастую в Интернете именно их рекомендуют для определения размера переменных. Но эти функции возвращают не размер фактической переменной, а размер в байтах для контейнера переменной (грубо размер указателя). К примеру, для переменной типа int64 эти функции вернут корректный результат, поскольку переменная данного типа содержит фактическое значение, а не ссылку на него. Но для типов данных, содержащих в себе указатель на фактическое значение, вроде слайса или строки, эти функции вернут одинаковое для всех переменных данного типа значение. Это значение соответствует размеру контейнера, содержащего ссылку на данные переменной. Проиллюстрирую примером:
func main() {s1 := "ABC"s2 := "ABCDEF"arr1 := []int{1, 2}arr2 := []int{1, 2, 3, 4, 5, 6}fmt.Printf("Var: %s, Size: %v\n", s1, unsafe.Sizeof(s1))fmt.Printf("Var: %s, Size: %v\n", s2, unsafe.Sizeof(s2))fmt.Printf("Var: %v, Size: %v\n", arr1, reflect.TypeOf(arr1).Size())fmt.Printf("Var: %v, Size: %v\n", arr2, reflect.TypeOf(arr2).Size())}

В результате получим:
Var: ABC, Size: 16Var: ABCDEF, Size: 16Var: [1 2], Size: 24Var: [1 2 3 4 5 6], Size: 24

Как видите, фактический размер переменной не вычисляется.
В стандартной библиотеке есть функция binary.Size() которая возвращает размер переменной в байтах, но только для типов фиксированного размера. То есть если в полях вашей структуры встретится строка, слайс, ассоциативный массив или просто int, то функция не применима. Однако именно эту функция я взял за основу пакета size, в котором попытался расширить возможности приведённого выше механизма на типы данных без фиксированного размера.
Для определения размера объекта во время работы программы необходимо понять его тип, вместе с типами всех вложенных объектов, если это структура. Итоговая структура, которую необходимо анализировать, в общем случае представляется в виде дерева. Поэтому для определения размера сложных типов данных нужно использовать рекурсию.
Таким образом вычисление объёма потребляемой памяти для произвольного объекта представляется следующим образом:
  • алгоритм определение размера переменной простого (не составного) типа;
  • рекурсивный вызов алгоритма для элементов массивов, полей структур, ключей и значений ассоциативных массивов;
  • определение бесконечных циклов;

Чтобы определить фактический размер переменной простого типа (не массива или структуры), можно использовать приведённую выше функцию Size() из пакета reflection. Эта функция корректно работает для переменных, содержащих фактическое значение. Для переменных, являющихся массивами, строками, т.е. содержащих ссылки на значение нужно пройтись по элементам или полям и вычислить значение каждого элемента.
Для анализа типа и значения переменной пакет reflection упаковывает переменную в пустой интерфейс (interface{}). В Go пустой интерфейс может содержать любой объект. Кроме того, интерфейс в Go представлен контейнером, содержащим два поля: тип фактического значения и ссылку на фактическое значение.
Именно отображение анализируемого значения в пустой интерфейс и обратно послужило основанием для названия самого приёма reflection.
Для лучшего понимания работы рефлексии в Go рекомендую статью Роба Пайка в официальном блоге Go. Перевод этой статьи был на Хабре.
В конечном итоге был разработан пакет size, который можно использовать в своих программах следующим образом:
package mainimport ("fmt""github.com/DmitriyVTitov/size")func main() {a := struct {a intb stringc boold int32e []bytef [3]int64}{a: 10,                    // 8 bytesb: "Text",                // 4 bytesc: true,                  // 1 byted: 25,                    // 4 bytese: []byte{'c', 'd', 'e'}, // 3 bytesf: [3]int64{1, 2, 3},     // 24 bytes}fmt.Println(size.Of(a))}// Output: 44

Замечания:
  • На практике вычисление размера структур объёма около 10 ГБайт с большой вложенностью занимает 10-20 минут. Это результат того, что рефлексия довольно дорогая операция, требующая упаковки каждой переменной в пустой интерфейс и последующий анализ (см. статью по ссылке выше).
  • В результате сравнительно невысокой скорости, пакет следует использовать для примерного определения размера переменных, поскольку в реальной системе за время анализа большой структуры фактические данные наверняка успеют измениться. Либо обеспечивайте исключительный доступ к данным на время расчёта с помощью мьютекса, если это допустимо.
  • Программа не учитывает размер контейнеров для массивов, интефейсов и ассоциативных массивов (это 24 байта для массива и слайса, 8 байт для map и interface). Поэтому, если у вас большое количество таких элементов небольшого размера, то потери будут существенными.
Подробнее..

Схема против нейросети

28.06.2020 14:08:19 | Автор: admin
Мы снова недооцениваем сложность задач.

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

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

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

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

Постоянно, а не обучили CNN и используем ее в статике для классификации.
Еще и соревнования устраиваем на лучшую архитектуру нейросети. Но лучшая она лишь для определенного набора данных и постоянно эволюционирует.
Автопилот Тесла увидел частично заляпанный знак и всё авария. Сразу шумиха в прессе: Не работает DeepLearning!, Роботы зло.
Или вот еще интереснее сюжет про рекламу Burger King и Tesla.

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

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

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

Как бы и не надо.

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

Если задана формула, машина считает её со скоростью недостижимой человеку. Яркий пример: траектории полетов космических кораблей. А ведь начиналось все с таких приборов, но даже они превосходили в итоге людей в скорости расчетов.
Нет нужды заставлять C/G/TPU имитировать биологические нейроны.

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

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

Функция cos в качестве активационной и ограничение значений входов и выходов [-1;1] повысила качество управления и скорость обучения в разы, снизила размер сети.

Да cos не самая быстрая функция она вычисляется по таблице или разложением в ряд Тейлора, но она уже есть. Тем более если делать подобные функции как ядро ASIC, то будем иметь примерно 10-тикратный прирост в скорости вычислений.
Её не надо искать, вычислять, тратить время на обучение ИНС уже всё давно сделано с помощью наших нейросеток.
Есть множество функций еще более ресурсоемких, чем тригонометрия. Алгоритм тот же:
Берем функцию из базы соединяем с нужными блоками входы и выходы.

Эти функции могут быть очень высокого порядка. Вроде тех, что используются в программировании. А их параметры ID объектов класса Товар, Марка, Цвет, Адрес и так далее.
Другими словами передаем спайк (код объекта, ID) в нужное место, а не вектор из рациональных чисел, который обозначает непонятно что.

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

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

В итоге Data Scientist программируют схемы архитектуры нейросетей. Где-то интуитивно, где-то на основании литературно-технического опыта или после отбора AutoML.
Танцы с бубном по другому не получается. Потому что DeepLearning красиво работает на учебных датасетах реальность ставит всё на место.

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

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

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML

29.06.2020 12:20:00 | Автор: admin


Аве Кодер!

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


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

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

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

UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:
  • Техника объектного моделирования OMT [James Rumbaugh 1991], которая была лучшей для анализа информационных систем с большим объемом данных.
  • Booch [Grady Booch 1994] отлично подходит для разработки и реализации. Грэди Буч много работал с языком Ада и был крупным игроком в разработке объектно-ориентированных методов для языка. Хотя метод Буча был сильным, нотация была воспринята менее хорошо, например, в его моделях преобладали формы облаков, что выглядело не очень аккуратно.
  • OOSE (объектно-ориентированная программная инженерия [Ivar Jacobson 1992]) модель, известная как модель прецедентов это мощная методология для понимания поведения всей системы, область, где ООП традиционно была слабой.

В 1994 году Джим Рамбо, не путать с Джоном Рэмбо, хотя Джим тоже был крут, потому что был, на секундочку, создателем вышеупомянутой техники объектного моделирования, ошеломил мир программного обеспечения, когда он покинул General Electric и присоединился к Грэди Бучу в Rational Corp. Цель партнерства состояла в том, чтобы объединить их идеи в единый унифицированный метод (рабочее название для метода действительно было Единый метод).

К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция прецедентов) были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.
В противовес всем известной Банде Четырех, Команда Румбо, Буча и Якобсона известна как Три Амигоса.

На UML также повлияли другие объектно-ориентированные нотации:
  • Меллор и Шлаер [1998]
  • Coad и Yourdon [1995]
  • Вирфс-Брок [1990]
  • Мартин и Оделл [1992]


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

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

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


Диаграммы UML подразделяют на два типа это структурные диаграммы и диаграммы поведения.



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

  • Диаграмма составной структуры
  • Диаграмма развертывания
  • Диаграмма пакетов
  • Диаграмма профилей
  • Диаграмма классов
  • Диаграмма объектов
  • Диаграмма компонентов


Диаграммы поведения показывают динамическое поведение объектов в системе, которое можно описать, как серию изменений в системе с течением времени. А к диаграммам поведения относятся:

  • Диаграмма деятельности
  • Диаграмма прецедентов
  • Диаграмма состояний
  • Диаграмма последовательности
  • Диаграмма коммуникаций
  • Диаграмма обзора взаимодействия
  • Временная диаграмма


Теперь пару слов о каждой из них

Диаграмма классов

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

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



Диаграмма компонентов

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



Диаграмма развертывания

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



Диаграмма объектов

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



Диаграмма пакетов

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



Диаграмма составной структуры

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

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



Диаграмма профилей

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



Диаграмма прецедентов

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



Диаграмма деятельности

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



Диаграмма состояний

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



Диаграмма последовательности

Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.



Диаграмма Коммуникации

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



Диаграмма обзора взаимодействия

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



Временная диаграмма

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




Зачем в UML столько диаграмм?

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



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

Для тех, кому лень читать: youtu.be/0I9aIP5gKCg

Аве!
Подробнее..

UML. Взгляд со стороны или Как UML удерживает аналитиков в прошлом

01.07.2020 16:06:10 | Автор: admin
Данная статья является переработанным материалом моего доклада на конференции Analyst Days 6 (2017).

Статья посвящена UML и особенностям его применения в настоящее время. Немного исторических сведений, совсем немного, только основные моменты:

  • UML зародился в 90-х годах как результат работы по создания языка объектно-ориентированного моделирования.
  • Спецификация 1.0 вышла в 1997 году.
  • Спецификация 2.0 вышла в 2005 году.
  • На сегодняшний день версия UML 2.5, развитие получили несколько профилей, такие как SysML и SoaML.

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

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

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

  • Все методики использования UML ходят вокруг Use Case Driven Development.
  • Моделям на UML не хватает целостности. Выбранный подход раздельного описания аспектов структуры и поведения, уровней бизнеса и приложений усложняет восприятие моделей в целом.
  • UML является объектно-ориентированным языком, это затрудняет с помощью него выражать другие концепции.

Про подход Use Case Driven Development я ничего говорить не буду, одно из воплощений его это Rational Unified Process. Далее я расскажу про последние два пункта.

Аспекты представления


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



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



Уровни представления


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



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

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

В результате опять получается множество диаграмм и таблиц.



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

Сервис-ориентированная подход


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

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

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

Посмотрим, как это моделируется на SoaML. Заодно сравним, как будет отличаться объектно-ориентированное моделирование на UML и сервис-ориентированное моделирование на SoaML.

Человек и Магазин


Задача простая, описать модель покупки товара в магазине.

Объектно-ориентированный подход, я думаю, всем понятен и прост. Чтобы не тратить время, не будем рассматривать бизнес-уровень. Думаю, все могут представить в голове советующий Use Case и его детализацию в виде диаграммы деятельности или диаграммы последовательности.



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



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



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



В рамках данного сервиса: Продавец выступает как provider, а Покупатель как consumer.
Продавец как поставщик предоставляет одну операцию продать. Бизнес-анализ закончен, переходим на уровень системы.

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



Из обновленного бизнес-процесса можно выделить одну операцию продать, оформим ее в базовый интерфейс Умеющий продавать.

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

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



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



Сравним результаты объектно-ориентированного моделирования на UML и сервис-ориентированного моделирования на SoaML.



Визуально вся разница вот в этих маленьких квадратиках на границе компонентов. Я отметил их красным цветом.Неужели это вся разницы?

Разница между объектно-ориентированным и сервис-ориентированным моделирование на самом деле есть, просто SoaML свел всё к объектам. Но об этом позже.

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



Что же не так, по моему мнению, с SoaML.

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

Во-вторых: Сервис описывается как объект структуры, это нехорошо. В русской речи распространена фраза Поставщик представляет сервис, вот это компонент-ориентированный подход, который реализован в SoaML.

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

С этой точки зрения Сервис это не Объект, это Поведение.

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

Парадигмы


Вернемся к UML. UML посредством своей парадигмы пытается описать другие парадигмы.



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

Относится к парадигмам лучше как обозначено ниже.



Продемонстрирую, чем отличается сервис-ориентированное моделирование, от объектно-ориентированного.

Человек и Собака


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



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

Вот что я хотел бы получить. (Подумай сам, потом открой)


Нужно понимать, что это простая задача и это простая модель. Но она отражает суть сервис-ориентированного подхода.
Человек предоставляет (оказывает) для Собаки сервис (услугу) Гулять.


Можно вспомнить историю объектно-ориентированного программирования.
Как к нему скептически относились в начале его появления даже очень авторитетные люди, такие как Эдсгер Дейкстра и Никлаус Вирт.
И до сих пор некоторые люди считают ООП недостойным внимания.

Ну так вот, данная модель тоже может вызвать усмешки. Дело в том что сервис-ориентированная парадигма не имеет достаточной поддержки на начальном уровне программирования и проектирования.
Для программистов поддержка осуществляется только фреймворками, например, Java Enterprise Edition или Spring. Думаю, что программисты добираются до них с головой, уже отформатированной под объектно-ориентированный подход.
Аналитики строят свое представление о сервис-ориентированной архитектуре и проектирование по статьям в интернете, которые по-разному понимают, что это такое, а некоторые статьи без глубокого погружения в специфику и технические детали вообще малопонятны. В результате аналитики возвращаются к общепринятым Use Case между системой и пользователями. Распространено также, что архитектура системы и ее компонентный состав уже зафиксированы архитектором или обусловлены выбранной платформой. И тогда аналитики опять просто описывают Use Case между системой и пользователями.

Сравните объектно-ориентированный подход и эту, казалось бы, смешную, где Человек оказывает Собаке услугу Гулять.
Когда она перестанет быть для вас смешной, а будет смешным казаться объектно-ориентированный подход, где Человек реализует метод гулять, на вход которому подается Собака!!! Вот тогда к вам пришло понимание сервис-ориентированной парадигмы.

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

Еще один момент: В этом примере я ввел новое понятие Сервис.
При этом я пока четко не определил правила его использования, но оно отличается от того что в SoaML. Тут нужно быть аккуратным, не стоит этим сильно увлекаться, так как такого рода расширения относятся к метамоделированию. Может так получиться, что создаваемые модели окажутся противоречивыми и малопонятными.

Вместо заключения


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

Симуляторы компьютерных систем всем знакомый полноплатформенный симулятор и никому неизвестные потактовый и трассы

02.07.2020 20:17:59 | Автор: admin
Во второй части статьи о симуляторах компьютерных систем продолжу рассказывать в простой ознакомительной форме о компьютерных симуляторах, а именно о полноплатформенной симуляции, с которой чаще всего сталкивается обычный пользователь, а также о потактовой модели и трассах, которые больше распространены в кругах разработчиков.

image

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

Полноплатформенный симулятор (full platform simulator), или Один в поле не воин


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

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

Ниже приведена блок-диаграмма чипсета x58 от компании Intel. В полноплатформенном симуляторе компьютера на этом чипсете необходима реализация большинства перечисленных устройств, в том числе и тех, что находятся внутри IOH (Input/Output Hub) и ICH (Input/Output Controller Hub), не нарисованных детально на блок-диаграмме. Хотя, как показывает практика, не так уж мало устройств, которые не используются тем ПО, которое мы собираемся запускать. Модели таких устройств можно не создавать.

image

Чаще всего полноплатформенные симуляторы реализуются на уровне инструкций процессора (ISA, см. предыдущую статью). Это позволяет относительно быстро и недорого создать сам симулятор. Уровень ISA также хорош тем, что остается более или менее постоянным, в отличие от, например, уровня API/ABI, который меняется чаще. К тому же, реализация на уровне инструкций позволяет запускать так называемое немодифицированное бинарное ПО, то есть запускать уже скомпилированный код без каких-либо изменений, ровно в том виде как он используется на реальном железе. Другими словами, можно сделать копию (дамп) жесткого диска, указать его в качестве образа для модели в полноплатформенном симуляторе и вуаля! ОС и остальные программы загружаются в симуляторе без всяких дополнительных действий.

Производительность симуляторов



image

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

Здесь как раз уместно будет коснуться темы производительности симуляторов. Обычно ее измеряют в IPS (instructions per second), точнее в MIPS (millions IPS), то есть количестве инструкций процессора, выполняемых симулятором за одну секунду. В то же время скорость симуляции зависит и от производительности системы, на которой работает сама симуляция. Поэтому, возможно, правильнее говорить о замедлении (slowdown) симулятора по сравнению с оригинальной системой.

Наиболее распространенные на рынке полноплатформенные симуляторы, те же QEMU, VirtualBox или VmWare Workstation, имеют неплохую производительность. Для пользователя может быть даже не заметно, что работа идет в симуляторе. Так происходит благодаря реализованной в процессорах специальной возможности виртуализации, алгоритмам бинарной трансляции и другим интересным вещам. Это все тема для отдельной статьи, но если совсем коротко, то виртуализация это аппаратная возможность современных процессоров, позволяющая симуляторам не симулировать инструкции, а отдавать на исполнение напрямую в реальный процессор, если, конечно, архитектуры симулятора и процессора похожи. Бинарная трансляция это перевод гостевого машинного кода в хостовый и последующее исполнение на реальном процессоре. В результате симуляция лишь ненамного медленнее, раз в 5-10, а часто вообще работает с той же скоростью, что и реальная система. Хотя на это влияет очень много факторов. Например, если мы хотим симулировать систему с несколькими десятками процессоров, то скорость тут же упадет в эти несколько десятков раз. С другой стороны, симуляторы типа Simics в последних версиях поддерживают многопроцессорное хостовое железо и эффективно распараллеливают симулируемые ядра на ядра реального процессора.

Если говорить про скорость микроархитектурной симуляции, то это обычно на несколько порядков, примерно в 1000-10000 раз, медленнее выполнения на обычном компьютере, без симуляции. А реализации на уровне логических элементов медленнее еще на несколько порядков. Поэтому в качестве эмулятора на этом уровне используют FPGA, что позволяет существенно увеличить производительность.

График ниже показывает примерную зависимость скорости симуляции от детализации модели.

image

Потактовая симуляция


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

Простейший пример инструкция доступа в память. Если запрашиваемая ячейка памяти доступна в кэше, то время выполнения будет минимально. Если в кэше данной информации нет (промах кэша, cache miss), то это сильно увеличит время выполнения инструкции. Таким образом, для точной симуляции необходима модель кэша. Однако моделью кэша дело не ограничивается. Процессор не будет просто ждать получения данных из памяти при ее отсутствии в кэше. Вместо этого он начнет выполнять следующие инструкции, выбирая такие, которые не зависят от результата чтения из памяти. Это так называемое выполнение не по порядку (OOO, out of order execution), необходимое для минимизации времени простоя процессора. Учесть все это при расчете времени выполнения инструкций поможет моделирование соответствующих блоков процессора. Среди этих инструкций, выполняемых, пока ожидается результат чтения из памяти, может встретится операция условного перехода. Если результат выполнения условия неизвестен на данный момент, то опять-таки процессор не останавливает выполнение, а делает предположение, выполняет соответствующий переход и продолжает превентивно выполнять инструкции с места перехода. Такой блок, называемый branch predictor, также должен быть реализован в микроархитектурном симуляторе.

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

image

Работа всех этих блоков в реальном процессоре синхронизуется специальными тактовыми сигналами, аналогично происходит и в модели. Такой микроархитектурный симулятор называют потактовым (cycle accurate). Основное его назначение точно спрогнозировать производительность разрабатываемого процессора и/или рассчитать время выполнения определенной программы, например, какого-либо бенчмарка. Если значения будут ниже необходимых, то потребуется дорабатывать алгоритмы и блоки процессора или оптимизировать программу.

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

При этом для симуляции остального времени работы программы используется функциональный симулятор. Как такое комбинированное использование происходит в реальности? Сначала запускается функциональный симулятор, на котором загружается ОС и все необходимое для запуска исследуемой программы. Ведь нас не интересует ни сама ОС, ни начальные стадии запуска программы, ее конфигурирование и прочее. Однако и пропустить эти части и сразу перейти к выполнению программы с середины мы тоже не можем. Поэтому все эти предварительные этапы прогоняются на функциональном симуляторе. После того, как программа исполнилась до интересующего нас момента, возможно два варианта. Можно заменить модель на потактовую и продолжить выполнение. Режим симуляции, при котором используется исполняемый код (т.е. обычные скомпилированные файлы программ), называют симуляцией по исполнению (execution driven simulation). Это самый распространенный вариант симуляции. Возможен также и другой подход симуляция на основе трасс (trace driven simulation).

Симуляция на основе трасс


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

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

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

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

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

Из песочницы Про анализ без страшных слов

04.07.2020 16:09:21 | Автор: admin
Приветствую, читатель!

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

image

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

Одна из них: Бизнес-аналитик и системный аналитик в IT. Разбираемся в сортах

Введение


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

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

Чем занимается аналитик?


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

На самом деле, аналитика состоит из следующих шагов:

  1. Получение запроса на доработку системы
  2. Уточнение желаемого результата, получаемого пользователем в конце вашего процесса
  3. Уточнение текущего процесса работы
  4. Предварительная проектировка решения
  5. Согласование с заказчиком дополнительных шагов процесса, если они необходимы для достижения результата,
  6. Корректировка решения
  7. Согласование процесса с заказчиком
  8. Оформление технического задания для разработчика
  9. Тестирование основных сценариев работы функционала
  10. Оформление документации, написание пользовательских инструкций
  11. Передача функционала заказчику

Подробнее о каждом шаге


Получение запроса на доработку


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

Уточнение желаемого результата


Здесь вы должны уточнить, чего конкретно хочет заказчик. Это может быть чем угодно: смена статуса заявки, генерация документа, отправка SMS или E-mail, в общем и целом, все, что может делать IT-система.

Всегда руководствуйтесь следующими принципами на этом этапе:

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

Уточнение текущего процесса


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

image

Предварительная проектировка решения


Этот этап подразумевает под собой определение будущего процесса или, как говорят, процесс TO-BE.

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

image

Руководствуйтесь следующими принципами:

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

Согласование дополнительных шагов


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

Корректировка решения


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

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


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

Оформление технического задания


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

Тестирование функционала


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

Документация


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

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

Передача функционала заказчику


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

Вывод


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

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

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

Категории

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

© 2006-2020, personeltest.ru