Лабораторный журнал
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 20 most recent journal entries recorded in Anatoly Levenchuk's LiveJournal:

    [ << Previous 20 ]
    Sunday, July 27th, 2014
    5:48 pm
    Полиполиглотность
    Я что-то задумался над обилием языков, которые неплохо бы знать образованному человеку. На сегодня можно выделить несколько классов таких языков:
    -- естественные (английский, русский, немецкий, японский и т.д.)
    -- схемные/структурные (радиосхемы, P&ID, SysML, Modelica, AADL, ArchiMate)
    -- программистские (математическая нотация, C++, Python, Java, SQL, SPARQL, Haskell)

    Полиглот знает несколько языков одного класса, а если речь идёт о нескольких классах полиглотства, то я назову это полиполиглотностью.

    Несмотря на всю их разницу (наличие или отсутствие под ними каких-то предметных областей, формализмов и т.д.), это всё языки. Задача: получить полиполиглота. При этом есть обширные исследования по обучению естественным языкам, кое-какие исследования по обучению программистским языкам и практически ноль по обучению схемным языкам. На примере исследований по обучению естественным языкам показывается, что в этой области мифов более чем хватает, а учителя-практики серьезно расходятся с исследователями в своих оценках (вот, например: http://www.govtilr.org/Publications/TESOL03ReadingFull.htm).

    Но значительная часть оценок совпадает: главный критерий -- это время, потраченное на занятие языком. Это примерно год на язык "с нуля до мастерства" (по ссылке выше приводят с английского на испанский 600 аудиторных часов, на русский 1100 часов, на японский 2200 часов. Плюс ещё примерно треть от аудиторного времени на домашнюю работу. Сравнение: магистерская программа обычно 1800 аудиторных часов плюс столько же домашняя работа. Для языков программирования примерно то же самое -- три дня на первый hello world! и год плюс минус вчетверо от этого на овладение в совершенстве. C, Python, Haskell в этом плане отличаться в плане освоения будут не меньше, чем испанский, русский и японский для англоговорящих. Haskell не трудный язык, как и японский. В японии даже кухарки свободно говорят на японском. Но кто из пишущих на Си готов потратить вчетверо больше времени для его совершенного освоения? То есть четыре года вместо года для Си? Для схемных языков то же самое, плюс сюда нужно добавить и изучение предметной области схемного языка: если не знаешь, что записывать, то никакое знание иероглифов и правил из сочетания не поможет).

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

    Как учить языки? Методы изучения естественных языков (типа shadowing -- http://learnanylanguage.wikia.com/wiki/Shadowing, повторение синхронно за диктором) для программистских языков не работают. Программистские методы (упражнения с автоматическим контролем типа курса алгоритмики на Python http://informatics.mccme.ru/course/view.php?id=156) не работают для схемных языков -- хотя при соединении схемных языков и языков запросов, может, и удастся сформулировать что-то похожее на такие последовательности упражнений.

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

    Этот пост можно воспринимать по-разному -- от прикидок "что лучше, потратить время на изучение испанского или Хаскеля?" до прикидок к обсуждению достоинств от перехода к одному SysMoLan по сравнению с парой Modelica и SysML (две части SysMoLan выучить будет быстрее, чем два разных языка -- типа как испанский к английскому вместо японского к английскому: все подъязыки SysMoLan должны по определению быть "одной природы"). Ну, или попыток ставить правильные оценки сроков перехода к моделеориентированной системной инженерии в консалтинговых проектах и попыток впихнуть невпихуемое в соответствующие учебные курсы. Так, в 32 аудиторных часа "Практик моделеориентированной системной инженерии" сколько можно воткнуть языков? То-то же.

    Но жизнь полиполиглотов ценит. Никуда не деться, учиться языкам нужно до самой старости -- естественным, схемным, программирования. Интересно только, откуда на это брать время.
    9:55 am
    О философах как властителях душ
    Вот тут разгорелась дискуссия о роли философов на примере цитаты из "Раннего Хайдеггера" В.В.Бибихина, в которой поминается равномощность Хайдеггера Гитлеру -- https://www.facebook.com/elashkina/posts/776511779037319. Ну, я ввязался и сказал свою точку зрения:
    Боюсь, что из этих рассуждений только захочется найти современного философа -- "ту же масть, ту же мощь, он был может быть единственным равновесием Путина, равномощным". Ну ищите, ищите. Жизнь государства или одного государственного лидера может быть устроена на любом отражённом в письменности наборе идей: религиозной книжке, философской книжке, художественной книжке, экономической книжке и т.д.. Выпячивать философов из тучи других профессий я бы не стал. Хотя их удобно потом находить задним числом и считать, что все идеи от них. Нет, от них не такое большое количество идей. Но в терминах их построений удобно всё обосновывать и объяснять (впрочем, мне знакомые психологи демонстрировали равномощность таких объяснений с объяснениями астрологическими, проективных тестов и т.д.. Любая более-менее богатая знаковая система позволяет найти тыщу и одну параллель и закономерность между собой и жизнью). Соревнование между попами, политиками, философами, писателями за право быть властителем дум, хе-хе. Шовинисты гуманитарных профессий. На броневичках из бумаги, с небумажными последствиями от хождений во власть (независимо от того, кто в эту власть попадёт -- поп или философ, писатель или экономист).
    Моя точка зрения на философию -- она бытует ещё на алхимическом уровне, выражая какие-то мысли красивыми метафорами и мыслительными нечёткими эвристиками. Ван Ренссен правильно замечает в своей диссертации, что философы недорабатывают. Как химики начали дорабатывать алхимическое знание про вещества (но тоже не дошли до нормального верифицируемого знания -- это сделали только физики, заодно выкинув надежды по химической трансмутации свинца в золото), так дорабатывать философское знание получается только у философских логиков.

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

    Философских же логиков, т.е. настоящих философов, которые пытаются как-то мыслительно связать абстрактный мир стройных логических (но обычно это не аристотелева логика) рассуждений с конкретным окружающим нас физическим миром, знают только в узких кругах специалистов. Они, как и физики, не претендуют на роль властителей душ. И о них не пишут восторженных книжек. И их изучают только на спецкурсах, а не в порядке получения общего высшего образования, как философов.
    Saturday, July 26th, 2014
    12:20 pm
    Социализм как рассадник вранья
    Меня давно интересует тема официального вранья -- начиная ещё с корейского боинга, кто помнит. Но официальное враньё питается враньём народным. "Близнецовое исследование" на странах http://www.economist.com/news/finance-and-economics/21607830-more-people-are-exposed-socialism-worse-they-behave-lying-commies показывает в эксперименте, что пожившие при социализме немцы более склонны врать, чем немцы чисто капиталистические -- "The longer the participants had been exposed to socialism, the greater the likelihood that they would claim improbable numbers of high rolls".
    Sunday, July 20th, 2014
    1:27 am
    lytdybr
    Жена сегодня обманным путём вытащила в RollHall на Тульской, где заставила купить новый самокат. Отрок раздолбал на самокатных горках в парке Горького сначала свой самокат, а затем и мой. Так что пришлось потратить 5тыс. рублей на новое средство каботажного передвижения. Увы, повторить модель не удалось. Она у меня не менялась с сентября 2006 года (http://ailev.livejournal.com/417218.html), а с тех пор рынок поменялся в корне и на нём либо совсем детские модели, либо совсем недетские. В итоге самокат стал сантиметров на 10 побольше в каждом измерении, и я об него пока спотыкаюсь при смене ног. Весит килограмма на полтора больше. В метро уже не так свободно его протащишь: прошлый я протаскивал в сложенном вертикальном положении, "к ноге". Колёса теперь не 120, а аж 145 -- "накат должен быть лучше", неубедительно утешаю себя этим. Ничего, привыкну.

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

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

    Пятницкая поражает: тротуары на ней становятся широченные, а проезжая часть стала двухполосная (проект реконструкции: http://probok.net/blog/1089/). Пятницкая всегда была улицей, по которой ходят от Третьяковки к центру, но вот от Третьяковки до Садового там пустыня, пешеходов никогда не было. Что, тротуары расширят, и пешеходы появятся в количестве? Или пешеходы туда приедут по велосипедным дорожкам? Или направят всех прибывающих туристов именно по "пешеходному маршруту"? И чем там будут туристов развлекать? Даже интересно, как всё будет происходить, это ведь всё буквально рядом с моим домом.

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

    Курс "Практики моделеориентированной системной инженерии" начну читать в здании МФТИ на Клементовском переулке по субботам с 13 сентября 2014, группа студентов будет та же, режим такой же закрытый. А перед этим в начале сентября проведу курс "Системноинженерное мышление в управлении жизненным циклом" для студентов и преподавателей высшей инженерной школы УрФУ (http://hse.edu.urfu.ru/ingener2/).

    Чикагские учёные (ах, где в этот момент были британские учёные?!) научились отличать любовь от похоти по движению глаз -- http://news.uchicago.edu/article/2014/07/17/eye-movements-reveal-difference-between-love-and-lust. Сначала наберёт популярность приложение AR, отслеживающее глаза окружающих, и выводящее на лоб каждому встречному маркер по шкале "любит-хочет". Потом его заметят депутаты, и во все "гугль глассы" и прочие подобные девайсы вставят аппаратную неотключаемую функцию: если в кадре появились дети, то включается подозрение на педофилию, и прибор должен отсканировать движение глаз носящего эти AR-очки, определить значение по шкале "любит-хочет", и при превышении порога "хочет" немедленно сообщить в компетентные органы, передав в том числе и GPS-координаты для немедленной поимки человека с преступными мыслями. Продвинутые модели будут передавать в компетентные органы и фотографию носящего очки, полученные из отражения в глазах невинного ребёнка, которого не "любят", а "хотят". Всё строго по науке! Ибо нефиг!
    Saturday, July 19th, 2014
    2:11 am
    lytdybr
    Сегодня купил ещё три килограмма мороженого. Прошлые три кило сожраны за пять дней. Продавщица подсунула вместо одного белорусского шоколадного эскимо челябинское с утверждением "всё то же самое, попробуйте". Нет, у челябинского шоколад с каким-то другим привкусом, а палочка более короткая, пальцы в результате шоколадом измазались. Так что буду теперь говорить "белорусское качество".

    Задумался над таблицей распространённости языков: http://www.ethnologue.com/statistics/size (испанский в ней второй, арабский пятый). Вот ещё одна: http://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D1%8F%D0%B7%D1%8B%D0%BA%D0%BE%D0%B2_%D0%BF%D0%BE_%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D1%8F%D1%89%D0%B8%D1%85 (испанский в ней пятый, арабский второй). Из неанглийских языков техническая литература, похоже, производится [русский не обсуждаем] главным образом на японском и немецком (ибо сама Испания 42млн. человек -- и из них для 30% населения испанский язык является вторым после каталонского, галийского и прочих баскских. Остальные 30 испаноговорящих стран как-то не кажутся особо технически продвинутыми. Из португалоязчных под вопросом Бразилия, но она мне не кажется технически круче а хоть и крошечной по масштабам всех предыдущих Италии. Поэтому тоже вычёркиваем). Далее с некоторым отрывом корейский и французский, но цифры уже существенно поменьше. Если ориентироваться на Европу (то есть не брать японский), то получается в качестве третьего языка немецкий неплохой выбор. INCOSE German chapter организована по тому же принципу, что и INCOSE Russian chapter -- не по государству, а по языку. Ибо там и Германия, и Австрия, и много чего совсем маленького.

    Три дня назад вышла книжка с обсуждением в том числе и Essence: "Fundamentals for Higher Performance in Software Development: Includes discussions on CMMI, Lean Six Sigma, Agile and SEMAT's Essence Framework" http://www.amazon.com/Fundamentals-Higher-Performance-Software-Development-ebook/dp/B00LU8OM0U/15.

    Чтобы ссылка была под рукой (каждый раз надоедает её искать): как онтологии применяют в IBM Watson, рассказ Chris Welty из IBM Research -- http://ontolog.cim3.net/file/work/OntologySummit2014/2014-01-30_OntologySummit2014_Using-Ontology-Tools-Services-Techniques-1/OntologySummit2014_SemanticWeb-In-Watson_v2-short--ChrisWelty_20140130.pdf (аудиозапись http://ontolog.cim3.net/file/work/OntologySummit2014/2014-01-30_OntologySummit2014_Using-Ontology-Tools-Services-Techniques-1/OntologySummit2014-s03_20140130b.mp3, общее расписание всех докладов на странице http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2014_01_30).

    Вышло программистское расширение PMBoK пятого издания: http://www.infoq.com/news/2014/06/pmbok-guide-fifth-edition

    Обзорчик масштабирования Agile: http://www.infoq.com/news/2014/07/compare-agile-scaling. Модная тема. Кстати, свежевышедший INCOSE INSIGHT имеет тему "Agile Systems-Engineering AND Agile-Systems Engineering"

    Этот INCOSE INSIGHT довольно популярное чтиво. Я вот там опубликовался в 2009г. и получил два академических цитирования: http://ailev.livejournal.com/1127145.html?thread=11834089#t11834089
    Friday, July 18th, 2014
    7:58 pm
    Видео моего выступления "Система в глазах смотрящего"на TEDxSadovoeRing
    Видео моего 18-минутного выступления "Система в глазах смотрящего" 2 июля 2014 на TEDxSadovoeRing (http://www.ted.com/tedx/events/12440, http://tedxsadovoering.com) в музее Скрябина на Арбате (http://youtu.be/obbNe1-JZBo):



    Вот тут ещё несколько моих фотографий с того мероприятия, которые собрал для меня Фейсбук (хотя я не понимаю, как из них отобрать только те, что относятся к TEDxSadovoeRing): https://www.facebook.com/ailevenchuk/photos
    7:16 pm
    SysMoLan (system modeling language): зачем мы это делаем и почему у нас это получится
    Зачем нужен ещё один системноинженерный язык, когда у нас есть SysML, Modelica, AADL, P&ID диаграммы, ArchiMate, GSN и множество других чудесных инструментов моделирования для инженера по требованиям и системного архитектора?

    Да и перечисленные чудесные инструменты сегодня используются отнюдь не всеми, и явно не распространяются как пожар ("Заметки по трудностям верхнеуровневого моделирования", 2013, http://ailev.livejournal.com/1056723.html -- в качестве причин медленного перехода к MBSE приводятся неочевидность полезности моделирования, отрыв моделирования от принятого в инженерии системного подхода, отсутствие дешёвых и удобных моделеров, непонятность создаваемых моделей ключевым участникам моделирования, модели не учитывают нужды коллективной разработки, модели не рассчитаны на накопление знаний).

    Какие плюшки мы должны предложить инженерам, чтобы они выбрали моделирование на Сисмолане? Вот несколько из них (и мы постараемся собрать этих плюшек побольше -- мы честно выучили несколько уроков за прошедших несколько лет):

    1. Разные инженеры привыкли работать в различных САПР, в различных моделерах. Дальше проблема не столько в отсутствии мэппинга между моделерами (это не проблема обычно), сколько в невозможности устроить полноценную коммуникацию между людьми, работающими с разными моделями. ISO 42010 предложил различать
    -- синтетический подход, при котором отдельные модели-документы независимы и готовятся в разных САПР (authoring tool), а потом мы их объединяем, как-то указывая на соответствие элементов моделей друг другу и храня эти соответствия где-нибудь ещё (например, система registry позволяет обозначить компонент, а потом мы этот компонент указываем в самых разных документах, используя именно это обозначение и добавляя разную информацию про этот компонент -- скажем, глядя глазами на одну диаграмму, и вбивая нужное имя в нужную табличку другого документа).
    -- прожекторный подход (у театрального прожектора белая лампочка, но мы можем получить любой цвет, поставив светофильтр), когда есть одна база данных описания системы, а отдельные модели мы получаем фильтрацией этой базы данных -- читая или записывая только элементы, нужные для этой модели.

    Исторически, конечно, развивался синтетический подход: много разных САПР поддерживали много разных моделирований. Все эти САПРы втыкались в какую-то PLM. В части PLM мы уже понимаем, куда идёт развитие: в сторону прожекторного подхода (подробней рассказано в "Четыре поколения информационных систем для инженерных проектов", 2011, http://ailev.livejournal.com/965124.html -- там мы это называли датацентричными системами в противовес документоцентричным).

    В реалии языков моделирования именно такой "датацентрический" (прожекторный) подход показал Архимейт: дизайн-цель там была обеспечить коммуникацию между разработчиками моделей деятельности (какими-нибудь службами качества), моделями софта (какими-нибудь "службами САПР" или "службами ERP") и моделями оборудования и связи (какими-нибудь "службами IT). Решение было простым: иметь возможность нарисовать одну диаграмму с элементами разных моделей, нужных этим разным службам. А если эти службы хотят увидеть информацию только для них -- фильтровать, механизм view (тематических для каких-то стейкхолдеров групп описания). Но можно фильтровать и так, что диаграммки будут отражать именно связи между обычно разными моделями, позволяя разным группам отмоделировать и обсудить эти связи.

    Это был успех, Архимейт достиг заявленных целей и стал одним из самых быстро развивающихся архитектурных языков (сейчас интерес к нему, определяемый по Google Trends уже догнал появившиеся чуть пораньше SysML и Modelica и обогнал ISO 15926, хотя некоторое время и был на одном уровне: http://www.google.com/trends/explore#q=archimate%2C%20sysml%2C%20ISO%2015926%2C%20modelica&cmpt=q

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

    Зачем мы делаем проективный язык? Почему бы не продолжать использовать букет из сегодняшних языков системного моделирования -- SysML+AADL+Modelica+Essence+ArchiMate? Все эти языки (хотя и каждый по-своему) описывают какой-то кусочек проблемы, остаётся лишь собрать воедино все описания, плюс из бонусов никого не нужно переучивать и весь инструментарий уже есть. Зачем нам нужен новый язык?

    Непрерывно пухнущее и разбухающее знание системноинженерного мышления, практик системной инженерии и системноинженерного менеджмента нужно время от времени компактифицировать, а иногда и со сменой репрезентаций. Так прирастает человеческое знание в любой сфере. SysMoLan делает именно это: компактифицирует сегодняшнее знание о системноинженерном мышлении (см. подробней пункт 6 в "Компактификация методического знания и сопутствующие гносеологические проблемы", 2010, http://ailev.livejournal.com/872954.html, а в других пунктах аргументы в пользу работы по компактификации).

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

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

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

    Выходом из этого является переход к факт-ориентированному от объект-ориентированного описания (и не будем называть это "семантикой", это слово сейчас чаще всего означает Semantic Web, а нам это лишнее). Всё больше и больше людей хочет держать данные в "графовых базах данных" (трипл-сторах, "безсхемных базах данных"), подробней в "Про ECM и PLM, а также пятое поколение инженерных информационных систем", 2011, http://ailev.livejournal.com/965564.html

    Про факт-ориентированность (достоинства графовых баз данных, семантической обработки данных) написаны горы литературы, семантик-вебовцы постарались. Но нам не нужен семантик веб, мы за модой не гонимся. Рекомендую первую половину книжки Chris Partridge “Business Objects: Re-Engineering for Re-Use” http://www.borosolutions.co.uk/research/content/files/books/BusObj-Printed-20050531-with-watermark.pdf/at_download/file, я называю это "антиаристотелевщина" (Витгенштейн сказал, что мир дан нам не в объектах со свойствами первичными и вторичными, как говорил Аристотель, а в фактах о том, как относятся между собой объекты. Мы про объекты можем сказать только то, как они относятся к другим объектам, и ничего -- никаких атрибутов -- про сам объект).

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

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

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

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

    3. Люди, которые были недовольны объект-ориентированной природой стандартов STEP (ISO 10303) для инженерной информации, поняли, что стандарт не решит поставленной задачи: не позволит создавать "интеллектуальную модель изделия", "цифровой макет", "информационную модель сложного инженерного объекта" и т.д., причём не только потому что STEP был объект-ориентированным, и не получилось складывать вместе в одну базу данных проектные данные, созданные в соответствии с его разными схемами данных. Нет, факт-ориентированного описания для сборки нескольких разных моделей в одно связное описание системы оказалось мало. Нужно было понять, как сопоставлять разные объекты на разных моделях -- и для этого пришлось обратиться к онтологии.

    Онтология (по Тому Груберу) это формализованная концептуализация, общая для многих (shared). Онтология отвечает на вопрос "какие концепты -- т.е. объекты и отношения между ними -- есть в этом мире (включая воображаемые, прошлые, будущие, потенциально возможные, информационные, физические и т.д.)?". Ответ при этом требуется формальный и согласованный с каким-то сообществом, солипсизм какого-то отдельного человека в качестве онтологии не подходит -- онтология выполняет коммуникационную функцию тоже. Онтология оказалась нужна инженерам для формальной записи информации различных моделей системы, в которой как-то бы гарантировалось, что эти модели описывают одно и то же устройство мира -- и обмена информацией между моделями. Если грубо, то есть много разных способов записать смену насоса на насосной станции (на принципиальной схеме остаётся один и тот же насос, но вот насос с серийным номером меняется -- иногда на насос совсем другой модели другого производителя), и нужно договориться как объединить модели закупщиков и проектантов (часто разрабатываемые разными людьми в разном софте) так, чтобы компьютер не запутался при их объединении. Многие из этих способов плохи, некоторые хороши. Нужно было договориться так описать мир, поделенный на объекты и отношения, чтобы компьютер не запутался, и можно было бы выражать такие типовые ситуации инженерной работы. И инженеры договорились, создав справочные данных ISO 15926 -- инженерную онтологию.

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

    К примерно таким же онтологическим выводам пришли и многие другие стандарты:
    -- ISO 42010 рассказал, что не бывает одного описания системы, но только множество этих описаний, ибо есть много разных стейкхолдеров. Для каждого тематического вида описаний -- view (состоящего из моделей) стандарт потребовал указать метод описаний -- viewpoint (дисциплину, раскрывающую часть онтологии: какие виды объектов записывать)
    -- ISO 81346 указал, как обозначать элементы системы, существующие во многих ипостасях -- и декларировал минимальное число этих ипостасей. Плюс он рассказал, как "разбирать систему на части" с учётом различных ипостасей.
    -- ISO 42010 и OMG Essence указали на показал различие дисциплины (как думаем о системе в терминах идеальных объектово), позволяющей определять систему и практики, позволяющей описывать систему (документировать систему в виде рабочих продуктов)
    -- ISO 15288, OMG Essence показали важность описания системы деятельности (обеспечивающей системы, enabling system в ISO 15288, client и endeavour domain of interest в OMG Essence), обеспечивающей жизненный цикл целевой системы. Нужно уметь описывать не только саму систему, но и практики её жизненного цикла, и вид жизненного цикла.

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

    Слово "системный" в словосочетаниях system thinking, system approach, systems engineering означает мышление в рамках онтологии систем. SysMoLan -- System Modeling Language, язык системного моделирования -- содержит слово System именно в этом смысле, он поддерживает онтологию систем, системный подход, системное мышление, системное моделирования прямо "из коробки". Заметим, что в SysML и Modelica это не присутствует.

    Как и ArchiMate оказывается не только архитектурным языком, но и архитектурным подходом (framework: он диктует не только как записывать архитектуру, но и как думать об архитектуре и как делать архитектурные описания), так и SysMoLan более полно можно назвать -- язык и подход системного моделирования. SysMoLan служит не только для записей различных моделей системы, но и воплощает в себе системный подход (в данном случае не только aproach, но и framework).

    4. ISO 15926 не только предложил онтологические решения (идеи о том, как устроен мир с точки зрения системного подхода -- прежде всего 201 тип сущности, которые позволяют описать невероятно большое количество инженерных моделей), но и способ документирования моделей системы. Но в этом месте разработчики сделали ошибку: они пошли вслед за модой семантического веба и создали чересчур сложный формат записи этой онтологии. Мало того, что этот формат вообще не был приспособлен для чтения человеком (а только для чтения программами), так он оказался крайне сложен для освоения любыми программистами. Конкретно, в этом стандарте в основе лежат нечитабельные URI (программисты давно забыли, как выглядят адреса в оперативной памяти -- но спокойно пишут свои программы. А ведь эти URI имеют именно такой смысл! Почему кто-то должен смотреть на эти адреса без крайней на это необходимости?!). Также они реифицировали отношения (показали, что само отношение состоит из нескольких объектов), что само по себе хорошо. Но это оказалось и очень плохо: вместо желаемого инженером отношения нужно каждый раз придумывать и записывать множество разных объектов со своими именами, это огромный накладной расход. Реификация должна быть только тогда, когда она действительно уместна.

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

    John Sowa сформулировал свой "закон стандартизации", аргументирующий важность недоспецификации предметной области: если и разработан какой-то стандарт, то результатом будет распространение упрощённой версии этого стандарта (http://en.wikipedia.org/wiki/John_F._Sowa#Sowa.27s_law_of_standards).

    SysMoLan не будет отражать всё то, что в состоянии отразить все перечисленные стандарты, в особенности ISO 15926. Нет, он отразит только самое важное и намеренно будет простым (как и Архимейт, который "опишет 20% ситуаций, встречающихся в 80% случаев"). С другой стороны, SyMoLan будет снабжён достаточными средствами для расширения языка.

    Что же будет отражать SysMoLan? В Shell были исследования, показавшие, что в ходе всего жизненного цикла для какого-то сложно устроенного насоса нужно хранить лишь 20 единиц данных, хотя в ходе разработки о нём используется до 1500 данных. Мы постараемся сделать так, чтобы в SysMoLan попали все эти 20 единиц "из коробки" (а остальные 1500 единиц данных можно было бы представить расширениями языка -- "профилями" как в UML, "библиотеками справочных данных" как в ISO 15926, дополнениями как в Archimate и т.д.).

    SysMoLan не будет использовать идеи семантического веба, но обопрётся на аналогичные идеи моделирования данных, хорошо отработанные в мире традиционного программирования (даже не в мире баз данных!). Это позволит в разы и разы упростить работу с языком. Никакого OWL/RDF/XML стека, онтологии всегда можно было записывать по-другому. Это не значит, что моделям системы и их элементам нельзя будет давать адреса в интернете! Но их никто не увидит, как никто не увидит в текстах программ адресов оперативной памяти. Забота о URL должна лечь на что-то типа "компилятора" и "линкера/мейкера", сам язык в этих URL не нуждается (хотя они и могут быть из него доступны).

    5. Логические языки представления факт-ориентированной информации не получили большого распространения, ибо в них трудно соединить ход вычислений с внешним миром -- что-то запросить у пользователя в ходе обработки или подождать ответа от далёкого сервера. Совсем недаром про успешный Prolog шутят, что у него половина от фортрана! В этом плане функциональные языки оказались лучше (в том числе для связи функционального и логического миров всегда можно вспомнить о Curry-Howard, или подключить логический ризонер в виде внешней "библиотеки" -- по специально организованному запросу).

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

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

    Паттернирование даёт систематический способ расширять язык, охватывать новые и новые предметные области. По сути дела, это концепция встроенных в базовый SysMoLan DSL (подробней на эту тему, а также объяснение почему это невозможно сделать в SysML: http://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/).

    Тем самым SysMoLan представляет собой нечно среднее между "псевдокодом" (записями моделей, не имеющими документированную в формальном логическом языке семантику -- то есть не подлежащими компьютерной обработке иной, нежели хранение и выдача хранимых единиц по запросу, таким языком является, например ArchiMate) и "кодом" (записями моделей, имеющими формальную семантику -- то есть такими моделями, на который можно напустить солвер, таким языком является опирающийся на MOF SysML и Modelica). Это будет и язык представления моделей/данных, и язык запросов к моделям/данным, и язык трансляции/конверсии/трансформации данных.

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

    6. Опыт любых языков описания показывает, что к этим описаниям нужны язык запросов и язык конверсии в другие представления (трансформации, мэппинга). Для каждого OWL нужно договориться о его SPARQL, для каждого XML нужно договориться о его XSLT.

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

    Эти сервера будут работать сразу не в программистских терминах, а в терминах системного подхода. Вся "программистская часть" будет спрятана в них "под капотом". SysMoLan это не только язык системного моделирования, это и язык запросов к системным моделям (типа SQL, SPARQL), и язык преобразования (мэппинга) системных моделей (типа XSLT, QVT, ATL).

    В отличие от ISO 15926, в котором до сих пор не нашлось места для описания ограничений (хотя и предложено делать это на Plan9) и SysML, в котором ограничения можно описывать на отдельном языке OCL, SysMoLan будет поддерживать ограничения "из коробки", так что вполне можно думать и о contract-based design.

    7. Современные языки описания систем имеют сразу два представления: текстовое и графическое. Текстовое представление позволяет легко программно генерировать записи на этих языках, а также читать их не только человеку, но и компьютеру. Текстовое представление в разы и разы удобней, когда описания на этом языке большие по объему (помним, как вымерли блок-схемы компьютерных программ и до сих пор не могут прижиться визуальные языки программирования: просто программы стали большие!). Графические описания важны, когда человеку нужно представить наглядно топологию: что там с чем связано в небольшом описании. Два вида представления моделей имеет OMG Essence, два вида представления моделей имеет Modelica.

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

    В инженерии это общепринято: например, так устроена Modelica.

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

    Лозунг: SysMoLan не воюет с естественным языком, он вместе с ним!

    Вообще, SysMoLan по возможности ориентирован на гибридные вычисления:
    -- логический (функциональный) вывод/reasoninc для информации о структуре, контрактах модулей (contract design)
    -- численные вычисления для мультифизики (как в Modelica)
    -- текстовые вычисления (a la IBM Watson -- ответы на вопросы. Или извлечение информации, "понимани", a la CYC)
    -- в принципе, сюда же может быть добавлена и геометрическая информация, для геометрических солверов

    В этом смысле SysMoLan нацеливается поучаствовать в движении поиск-ориентированной системной инженерии и другой пост-моделеориентированной жизни: http://ailev.livejournal.com/1122876.html

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

    Наша цель тут -- чтобы SysMoLan стал не менее популярным языком MBSE инициативы INCOSE, чем SysML, AADL, Modelica. Так что вокруг SysMoLan мы планируем некоторую формальную организацию стандартизации (и для поддержки этой организации мы зарегистрировали http://sysmolan.org). Но, как водится в этой стандартизации, на вход стандартизации должен поступить какой-то проект стандарта, коллективная разработка "с белого листа" оказывается неэффективной, проще обсуждать "по тексту" и модельной реализации, если они есть.

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

    10. SysMoLan служит для накопления знаний. Это означает, что на нём легко подготовить:
    -- типовые требования (например, содержащиеся в стандартах)
    -- типовые высокоуровневые архитектуры (например, содержащиеся в учебниках)
    -- типовые запросы для какого-то сорта комбинированных моделей

    Эти знания будут накапливаться в библиотеках справочных системных моделей (по аналогии с библиотеками справочных данных ISO 15926 и библиотеками Modelica).

    В этом плане SysMoLan -- это язык представления и накопления инженерных знаний.

    11. Какие области применения SysMoLan будут первоочередными?

    11.1. Инженерия: "ранние стадии жизненного цикла" (несмотря на то, что эти практики выполняются в ходе всего жизненного цикла, а часто их и вовсе называют "системная инженерия") -- инженерия архитектурных требований и системной архитектуры. "Архитектурный" тут -- это те самые 20% требований и отвечающих им инженерных решений, которые определяют 80% устройства системы. То есть в этом плане SysMoLan -- это язык целеориентированной инженерии требований (типа GSN или i*) и системной архитектуры (типа SysML, AADL, Modelica -- да, мы считаем Modelica и архитектурным языком, а не только языком мультифизического моделирования), а также описания вида жизненного цикла (типа OMG SPEM 2.0 и OMG Essence) и даже организации разработки (ArchiMate) -- и дикий зоопарк продуктов.

    11.2. Образование: поскольку SysMoLan поддерживает "из коробки" основные инженерные концепты в рамках системного подхода, он становится идеальным для обучения студентов видеть мир в терминах систем, начальная стадия обучения системного инженера. Это означает, что в дополнение к языку должен быть разработан курс системноинженерного мышления. По факту, такой курс уже разработан, но он пока никак не использует язык моделирования -- http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf. После появления хотя бы первых версий языка и моделера этот курс будет существенно переработан не столько в части его содержания, сколько в части упражнений: понимание будет тренироваться и проверяться на решении задач системного моделирования. Для моделе-ориентированной (model-based, model-driven) системной инженерии нужно моделеориентированное системное мышление.

    11.3. Интеграция данных (федерирование инженерных информационных систем): поскольку SysMoLan является наследником ISO 15926, то все его достижения и наработки по федерированию данных жизненного цикла, находящихся в разных инженерных системах, вполне приложимы к SysMoLan. Это будет даже лучше, ибо язык стандартизует не только онтологию ("справочные данные") и средства её пополнения, но и как запрашивать данные жизненного цикла, и как преобразовывать их в/из альтернативных представлений в разных инженерных информационных системах. Редактор/моделер SysMoLan должен быть дополнен сервером (поддерживающим язык запросов) и адаптором (обеспечивающим экспорт-импорт в/из разных форматов данных). В этом плане SysMoLan поддерживает пункт 13 из http://ailev.livejournal.com/872954.html -- он предлагает компактное представление нового знания, а для уже имеющегося знания в старых форматах он предлагает мэппинг.
    * * *
    Этот текст представляет собой обновление и расширение предыдущих двух текстов с постановкой задачи: февральского http://ailev.livejournal.com/1061167.html и июньского http://ailev.livejournal.com/1122497.html. Он рассчитан на тех, кто знаком с упомянутыми в нём языками, стандартами и идеями (сейчас ситуация чуть полегче: для начального знакомства теперь можно прочитать книжку "Системноинженерное мышление в управлении жизненным циклом", 306 страниц по-русски -- . Теперь "для маркетинга" нужно бы переписать его "на чистых идеях", чтобы не поминать ненужных имён стандартов, но я бы перед этим хотя бы чуть-чуть спрототипировал язык. нулевая версия могла бы использовать паттернированую запись триплов для архимейт-подобных диаграмм, плюс многоипостасийные структурные имена, почёрпнутые из ISO 81346. Для детекторного приёмника запись выбора оборудования при этом может быть чем-то вроде =детектор1((реализован((-диод Д 161-320-18 ((имеет((ударный прямой ток((7500@А

    На конкретный синтаксис в деталях (обработка пробелов и т.д.) пока внимания не обращаем, а вот как компактненько показать паттерн из нескольких триплов про одно и то же -- вот это да, этим как раз и занимаемся. Так, префикс = из ISO 81346 для =детектор1 означает для , что детектор1((тип((компонент, т.е. функциональный объект с принципиальной схемы. Префикс - в -диод Д 161-320-18 по ISO 81346 означает, что диод Д 161-320-18((типа((модуль, то есть "продукт" из каталога. Всё это "дизайн в классах", что делать с классификаторами и индивидами придумаем чуть позже. А когда отмоделируем детекторный приёмник, то начнём работать с подуровнями системы. Потом добавим описания (ибо на SysMoLan нужно описавать не только саму систему, но и её модели -- это язык мегамоделирования!).

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

    =детектор1((реализован((-диод Д 161-320-18 ((имеет((

       ударный прямой ток((7500@А
       частота максимальная((500@Гц
    * * *
    Проблемы для постепенного решения:
    -- киберфизические системы (попытки решения в AADL: стык оборудования и софта)
    -- какая-то более-менее развитая онтология информатики (software engineering)
    -- акаузальное мультифизическое моделирование (Modelica)
    -- требования и motivation (хотя бы как в i* или лучше)
    -- модуляризация
    -- графический синтаксис
    -- обоснования по ISO 15026 и так далее (http://ailev.livejournal.com/811715.html)
    -- как делать model cheсking (верификация)
    * * *
    Отдельный вопрос -- это прототипная реализация (сервер, моделер, адаптеры). К этому уже приступили. Не забываем про чеклист для современного моделера -- http://ailev.livejournal.com/1041274.html
    Thursday, July 17th, 2014
    1:05 am
    Мозг-на-выносе
    Майкрософт гордо заявляет, что её алгоритмы deep learning в Project Adam в 50 раз быстрее и в 2 раза точнее двухлетней давности гуглевских, называемых в ролике скромно current state of the art: http://youtu.be/S4ZgfYoeyCo. Это означает, что они теперь не просто собачку могут на фото определить, но и сказать породу этой собачки.

    Подробности в http://research.microsoft.com/en-us/news/features/dnnvision-071414.aspx

    И тут интересный вопрос: а во сколько раз круче двухлетней давности гуглевских алгоритмов сейчас алгоритмы самого гугля? И что в этот момент делают другие крупные игроки этого рынка? А они ведь точно что-то делают: всяким Yahoo! и Facebook тоже очень хочется в искуственноинтеллектуальный (или статистический, уж как кому) рай.

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

    Распределённые вычисления, распределённое существование. Киборги, говорите? Где?

    Футбольные матчи-на-вынос чемпионата мира 2014 майкрософтовская Cortana предсказала все 14 из 14 -- http://www.cmswire.com/cms/big-data/why-microsofts-cortana-is-14-for-14-calling-world-cup-matches-025853.php

    Сценарии про хакеров, шпионов, государство, перехват управления всеми этими глазами и мозгами на выносе, а также прочую традиционную чернуху придумайте, плиз сами. Впрочем, её и без вас придумают.
    Wednesday, July 16th, 2014
    2:41 pm
    Инженерный спорт
    Я писал о спорте данных (http://ailev.livejournal.com/1047765.html), а вот пара примеров инженерного спорта в России:
    -- робокросс (автомобили без водителя): http://community.sk.ru/news/b/articles/archive/2014/07/15/ispytaniya-robomobiley-reportazh-skru.aspx (был 7-11 июля 2014, вот победитель: http://www.venture-news.ru/news/52501-komanda-kb-avrora-stala-absolyutnym-pobeditelem-robokross-2014.html)
    -- гонки солнечных яхт (на солнечных батареях): http://www.skolkovo.ru/public/ru/press/news/item/4154-2014-07-14-regata/ (будут 26 июля 2014)
    12:35 pm
    Вольфрам разбушевался
    За последний месяц Wolfram выдал много чего новенького и интересного (http://blog.wolfram.com/):
    -- подхакан Wolfram Language, и сразу попал в ThoughtWorks Radar July 2014 на assess (http://www.infoq.com/news/2014/07/thoughtworks-radar-july-2014). Чтобы было понятно: на том же статусе, что и Python 3
    -- поставка языка Wolfram на Raspberry Pi демонстрирует, что речь не идёт о чём-то неэффективном и монстрообразном и специализированном, но о вполне эффективном просто ещё одном языке программирования (http://blog.wolfram.com/2014/07/02/hungry-for-more-pi/)
    -- запущено в эксплуатацию вольфрамовское облако (http://blog.wolfram.com/2014/06/23/wolfram-programming-cloud-is-live/)
    -- Вышла Mathematica 10 (причём скоро обещают выход её и в онлайн варианте тоже), http://blog.wolfram.com/2014/07/09/launching-mathematica-10-with-700-new-functions-and-a-crazy-amount-of-rd/

    Тамошние языковые концепции, безусловно, спорны. Но как когда-то CISC архитектура процессоров победила RISC, так и CISC язык (в котором есть всё и ещё чуть-чуть, и который теперь можно ещё и размазывать по облакам -- то есть реализовывать и programming-in-the-large, а также иметь такие фичи как smart fields -- попытки делать парсинг естественного языка) может думать о том, что по факту есть шанс победить RISC-языки с чётко очерченным крохотным теоретически обоснованным ядром и благими пожеланиями всё остальное иметь дописанным кем-то и когда-то на этом ядре.

    И там явно обращают внимание на инженеров. Вот, например, расчёт надёжности изделия в Mathematica: http://blog.wolfram.com/2013/09/30/reliability-mathematics-in-mathematica/

    Конкуренты срочно отстраиваются, иначе им рядом не выжить. Так, MapleSoft практически полностью перешёл в поддержку образования по математике, добровольно загнали себя главным образом в нишу "студенческого софта" и "софта для учителей математики" -- http://maplesoft.com/. Посчитайте, сколько раз там на первых страницах поминаются "ученики", students, в том числе в описании функций их главного пакета Maple. У них там и Modelica поддержана (http://maplesoft.com/products/maplesim/, и в Mathematica это есть (http://www.wolfram.com/system-modeler/features/). Отличие именно в том, что Maple решает узкие задачи (и этим гордится: какие-то функции там работают быстрее, чем в той же Mathematica), а Mathematica намеренно прихватывает самые разные типы экспортов-импортов, самые разные типы данных, самые разные базы данных (Wolfram Alpha), самые разные опции ввода-вывода -- и все они "из коробки", а не "можно будет легко сделать, если потребуется". Ну, и всё это оказывается доступно как на рабочем столе, так и из облака, что немаловажно.

    Вообще-то "большие и развесистые" инфраструктуры программирования оказываются удивительно выживающими. С одной стороны, тот же Eclipse не ругает только ленивый, но и сделанные на нём разные моделеры "из коробки" обладают свойствами, добиться которых разработкой "с нуля" очень трудно. Если выкинуть специфически математическую начинку, то из ползущих медленно в реализуемом Вольфрамом направлении open source фреймворков создания приложений можно указать именно Eclipse (хотя всякие Ipython тоже думают в этом направлении, учитывая обилие доступных библиотек). Wolfram теперь предлагает не просто как-то координируемые язык и обширную библиотеку функций, он предлагает также и обширную инфраструктуру разработки и разворачивания готового кода, которая будет доступна для использования даже отдельным крошечным приложеням, которые будут написаны на его языке. И эта штука масштабируется от Raspberry Pi через инженерную рабочую станцию (по нынешним временам это просто десктоп) к облаку, плюс поддерживает какой-то интеллект в полях ввода.

    Смотрите на Wolfram и чешите затылки. Software engineering делает ещё один шаг от поддержки в софте решения олимпиадных алгоритмических задачек из учебников computer science к решению реальных прикладных задач из жизни.

    У Вольфрама много чего ещё анонсировано. Вот, например, Wolfram Discovery Platform http://www.wolfram.com/discovery-platform/, Wolfram Data Science Platform http://www.wolfram.com/data-science-platform/. У него сейчас 700 человек в фирме работают, и не все из них сейлзы и уборщицы.
    Tuesday, July 15th, 2014
    7:28 pm
    Вышел релиз .15926 Editor версии 1.5beta
    Ура, мы выпустили бету версии 1.5 нашего онтологического редактора! Можно качать: http://techinvestlab.ru/files/dot15926Editor15beta/dot15926Editor15beta.rar

    В этой версии мы, наконец, достигли плановой функциональности в полном объёме:
    -- взять какие-то сложные данные (например, из инженерных САПР, или развесистых баз данных каких-то "отчётностей", или набор из стопиццот различных форм эксельных табличек одна другой кривей, или даже онлайн-базы данных с выдачей в XML -- в примере мы взяли Google Maps API),
    -- совместно перевести всё это кучерявие в формат ISO 15926 (по пути почистив, преобразовав и проверив по потребности). Это "резиновый" формат, поэтому туда всё упакуется.
    -- и при этом поддерживать какую-то нейтральную по отношению ко всем этим данным разных стейкхолдеров модель предметной области (модель данных, онтологию), чтобы хоть как-то гарантировать совместимость этих данных
    -- затем конвертировать эти данные в какие-то другие целевые форматы ("отчётность", "публикация", "рендеринг") -- в том числе семантические, онтологические, реляционные, объектные, вордовый текст или таблички экселя и т.д.

    Основная фишка версии 1.5 в том, что эти все преобразования делаются с использованием паттернов данных, которые позволяют повысить уровень описания данных по сравнению с ранее использовавшимися в инструментах ISO 15926 низкоуровневыми описаниями "семантических сетей" или даже "шаблонов". Прощай, ассемблер данных (хотя особенности части 8 ISO 15926 и не дают забыть об этой низкоуровневости окончательно, но это уже "ужас", а не "ужас-ужас-ужас"). Пруф оф концепт достигнут, всё работает. Визуальный редактор паттернов с автокомплитом, подсветки ролей, драг-н-дроп и прочие вкусности IDE. А хранятся паттерны в JSON, но этого уже никто не видит, руками туда залезать уже не нужно.

    В принципе, ежели хочется поисследовать какие-то структуры данных (не поисследовать сами данные -- т.е. не поразвлекаться статистикой), то инструмент получился вполне удачный. Пара дней на то, чтобы распарсить P&ID экспорт из мейнстримного САПР и отконвертировать его в формат, читаемый yEd. Хо-хо-хо! Генератор адаптеров у нас в кармане! Кстати, этот пример включён в дистрибутив и отдокументирован.

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

    Ещё одна крутая фишка, это включение веб-фреймворка и веб-сервера прямо в комплект поставки. Если очень хочется наверстать крутой отчёт, то почему не верстать сразу в виде интерактивной веб-страницы? С включением карт, полей ввода и прочих прелестей веб-разработки. Вытащил откуда-то данные, а дальше можно их как-то перетасовать и опубликовать в Сети -- и не на чистом HTML, а с использованием шаблонов веб-фреймворка, с последующей генерацией отдаваемых страниц. Мы теперь и Open Linked Data умеем!

    На этом фоне полноценная (чтение и запись) поддержка Turtle формата для данных ISO 15926 кажется мелочью, но многие её ждали.

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

    Что дальше в планах?

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

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

    3. Продолжать исследования: отказаться от рыхлого и неподъемного тщательно реализованного в версии 1.5 стека стандартов семантического веба и сделать паттерны основным механизмом выражения семантики. Это будет .15926 Modeler, он же версия 2.0. Ибо цели версии 1.x достигнуты, и от совершенствования нужно переходить к развитию. Об этом нужно говорить много и отдельно (в частности, мы уже сегодня часа три подряд обсуждали, как может выглядеть язык паттернов и ставили задачу на прототипирование. Но об этом нужно писать отдельно).

    В любом случае, я считаю выпуск полноценного релиза 1.5 только "заглянцовкой" в этом проекте, а настоящее событие как раз сегодня: программа есть, программой можно пользоваться, цели всего исследовательского проекта .15926 первой стадии достигнуты -- инструмент поддерживает полный цикл работы с данными в технологии ISO 15926.
    Monday, July 14th, 2014
    11:53 pm
    День взятия Бастилии
    Ну что, будем всю ночь плясать? Здесь танцуют?
    2:37 pm
    Обозвать язык системного моделирования
    Все нужные слова для языка системного моделирования уже заняты, начиная с SysML (system modeling language). Поскольку я хочу, чтобы этот язык был больше похож на ArchiMate и на Essence, то проверил самые разные сочетания sys, archi, essence: занято. Sysperanto, syssense, sysarchi, archiessence и т.д., в количестве. В интернетах уже есть всё. Ontology я в название всовывать не хочу, это должно быть под капотом, а не снаружи. Игры с semantic (sysmantic) тоже оказались заняты.

    Тест на новизну прошeл только systemese, естественно используемый для ссылки на "системный жаргон" -- то есть слово встречается, но пока это непохоже на трейдмарк или название чего-то другого. Дьявол, даже Systemease занято! Более наворочены sysarchese и разные варианты типа sysarchiese, sysarchease, но они явно получаются непопсовые.

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

    UPDATE: в фейсбуке на эту тему тоже несколько комментов появилось -- https://www.facebook.com/ailevenchuk/posts/10202796591369917

    UPDATE2: всем спасибо, реализовал рекомендацию boldachev, язык будет Sysmolan (или SysMoLan, это уж без разницы и расшифровываться так же, как и SysML -- System Modeling Language. Пусть таких языков системного моделирования, как и языков программирования будет много. Да, в этом действии какой-то элемент агрессии против SysML есть, но это конструктивная энергичность, а не агрессия. Так сказать, творческая конкуренция).
    Sunday, July 13th, 2014
    11:07 pm
    Страны, рейтинги и decision analysis.
    Многокритериальное сравнение для меня загадочно. Вот, например, удобная интерактивная смотрелка показателей "странового развития" -- http://www.socialprogressimperative.org/data/spi#performance/countries/spi/dim1,dim2,dim3

    Ну, и что можно сказать про то, жизнь в каких странах круче других, сравнивая приводимые там характеристики "в попугаях"? Фишка в том, что все эти рейтинги-на-весах не позволяют надёжно принимать решения выбора объекта из нескольких возможных (но хорошо позволяют принимать решения получения высокорейтинговых объектов -- достаточно в эти объекты добавить нужные для рейтинга фичи и плюнуть на всё остальное!):

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

    2. В аниме и мангах я не люблю, когда много стреляют. Но люблю многое другое. Ни один рейтинг не учитывает этих моих предпочтений. Рейтинги рассчитаны на "среднего человека", но кто из нас оказывается средним в предпочтениях?! Что для одного "десяточка" (по совокупности разных характеристик!), то для другого "троечка" (тоже по совокупности!).

    3. Высокий рейтинг из многих компонент часто означает "второй по многим позициям", то есть "никому не нужный" (важна часто одна характеристика, и берут её максимизацию -- компромиссы jack of all trades, master of none не так популярны, как кажется устроителям рейтингов).

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

    Decision analysis (http://en.wikipedia.org/wiki/Decision_analysis, https://www.informs.org/Community/DAS, http://www.usc.edu/dept/create/assets/001/50843.pdf) -- надо бы им поплотней позаниматься. Наверняка в этой области много нового за последние годы придумали, хотя происхождение этой дисциплины от довольно древнего системного подхода с сильным привкусом кибернетики. А уже от decision analysis можно выйти на множество других смежных проблем -- измерения, рейтинги, KPI и сбалансированные показатели и т.д. и т.п..
    6:44 pm
    Висцеральная теория сна и иглорефлексотерапия
    Самое внятное объяснение механизма действия иглорефлексотерапии я встретил в висцеральной теории сна (http://sukhov.com/blog/ivan-pigaryov-vo-sne-udivitelno-vse/):
    Когда мы на экспериментах продемонстрировали ответы коры мозга на стимуляцию внутренних органов, возник следующий вопрос: "Каким образом весь объем висцеральной информации приходит в кору?" Анатомия проводящих путей от сенсорных каналов к тому времени была хорошо известна. Были так же исследования, касающиеся блуждающего нерва. Но мы четко понимали, что одного блуждающего нерва для передачи всего массива информации от внутренних органов не достаточно. Этот нерв слишком маленький. Мы начали искать другие объяснения.

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

    Теперь вернемся к акупунктуре. Если у человека есть патология в каких-то внутренних органах, то организм делает все для ускорения передачи информации от них в спинной и головной мозг. Он снижает пороги чувствительности соответствующих нейронов, чтобы улучшить проведение сигналов. Как еще можно побудить организм снизить эти пороги? Мы знаем, что на те же самые нейроны приходят сигналы от кожи. Значит, если начать раздражать соответствующие участки кожи, то мы получим нужную нам реакцию нейронов. Именно этим и занимается акупунктура.
    Подробней про висцеральную теорию сна, но без рефлексотерапии тут: http://www.polit.ru/article/2014/05/04/pigarev/.
    Saturday, July 12th, 2014
    9:32 pm
    lytdybr
    Притащил домой три килограмма мороженого. Интересно, насколько его хватит?

    Верить никому нельзя. Про то же мороженое пишут, что в США едят его 30кг в год (http://www.extra-n.ru/text/potrebitel/morozhenoe_i_eto_vse_o_nem/), 20кг в год (http://investtalk.ru/biznes-idei/biznes-ideya-otkry-vaem-kafe-morozhenoe), 6.3кг в год (http://doslovno.info/articles/320-sladkaya-pravda-o-morozhenom). Это Биг Дата, сынок! Прикинем, сколько будет осмысленная цифра: лето напролёт (100 дней) по одной эскимошке (70г, специально поглядел на упаковку), если не пропускать ни дня. Итого: 7кг.

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

    Отрок закончил решать контрольные задачи заочной физматшколы МИФИ по шестому классу. Но неугомонная жена нашла учебник 6-го класса уровня физматшколы от МГУ (Потапов, Шевкин), в котором акцент делается на физику: единицы измерения, графики и т.д.. Так что что он до алгебры ещё месяц не дойдёт, а математика по факту у него случится трёхфизматшкольная. Наследственность: жена тоже формально закончила три физматшколы. Один я в семье "обычный ребёнок".

    Довольно большой разговор про медитацию, инженерию психики, "управлению усилием мысли" (то бишь руление через электроэнцефалограмму -- brain driving) случился в сообществе нейронета: https://www.facebook.com/groups/nevronet/331243420375319/ (и ещё я дал кратенькую заметочку на эту тему тут: http://openmeta.livejournal.com/228156.html).

    Очень хорошая картинка про разницу науки и инженерии:
    scienceandengineering

    Cycorp выступил с заявлением, что у них всё хорошо: http://www.businessinsider.com/cycorp-ai-2014-7. Из этого заявления ничего не понять, но не сомневаюсь, что у них действительно всё хорошо. Мне во время хакатона одна бывшая работница Cycorp сказала, что там хватает идей на самые крутые работы в мире, просто у Doug Lenat очень жёсткий способ руководства. Поэтому многие не выдерживают, и уходят. Если собрать по миру бывших работников Cycorp, то это был бы самый сильный в мире стартап в области искусственного интеллекта. И никаких бы IBM Watson там и рядом бы не стояло. Ибо эти люди владеют по-настоящему интересными технологиями (главной из которых является работа с микротеориями).

    Вчера меня спрашивали про то, как я бы мыслил краткосрочные курсы повышения квалификации для гуманитариев. Я бы давал мета-дисциплины, чтобы каждый гуманитарий смог поработать со своей дисциплиной специализации и соотнести её с другими дисциплинами: философская логика (аналитическая философия, с ней тут мало кто вообще знаком), системное мышление и выход в деятельностный подход, методология и "что такое наука, что такое история", презентационная работа (они ж гуманитарии вроде как, но их никто никогда не учил рассказывать -- в этом они все самоучки). "Краткосрочность" заставляет на этом закончить дозволенные речи, сюда ведь ещё много чего можно приписать. Хотя гуманитариям лучше поднимать квалификацию до их гуманитарного образования. Из физиков лириков ведь можно сделать, а вот из лириков физиков уже нет. Так что физики потенциально могут понять больше разных идей, чем лирики. Дальше я лучше прервусь, а то набегут из интернетов поругаться тут за лирическую справедливость.
    Wednesday, July 9th, 2014
    12:56 am
    Об талант и 10000 часов практики
    Всё-таки талант имеет значение: исследование на близнецах показало, что музыкальные способности существенно зависят от таланта, а не от усидчивости (и заодно зависимость самой усидчивости от таланта): http://www.economist.com/news/science-and-technology/21606259-musical-ability-dna-practice-may-not-make-perfect?fsrc=scn/tw/te/pe/practicemanynotmakeperfect

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

    Эх, знать бы, к чему у меня талант...
    Tuesday, July 8th, 2014
    10:06 pm
    Как стать Шивой восьмируким? Купить дополнительные руки у робототехников!
    Шивой восьмируким (или доктором октопусом) робототехники сделать человека ещё не могут, а вот четырехруким уже (http://youtu.be/LkXpldrhRm4):


    Подробней об этом: http://spectrum.ieee.org/automaton/robotics/industrial-robots/heres-that-extra-pair-of-robot-arms-youve-always-wanted (сайт лаборатории: http://darbelofflab.mit.edu/?q=node/22).

    А вот дополнительные пальцы для руки: http://newsoffice.mit.edu/2014/getting-grip-robotic-grasp-0718

    Понятие "робот" уже и так размыто до безобразия, а дальше будет размыто ещё больше. Экзотело (ибо это уже далеко выходит за рамки экзоскелета) в данном случае более подходящий термин, чем "робот".
    Sunday, July 6th, 2014
    9:04 pm
    Ноты
    Огромное количество самых разных нот (главным образом в .pdf):
    -- http://tgv777.free.fr/Sheetmusic/SongBooks/
    -- http://www.jososoft.dk/yamaha/sheetsites.htm
    -- http://www.jososoft.dk/yamaha/sheets.htm
    -- https://app.box.com/s/h4a8x8w01e70grijkaw0 (там они же и в .mxl для нотных редакторов типа http://musescore.org/ -- чтобы транспонировать и т.д.).

    Интересно, что по нынешним временам дольше: запрограммировать компьютер так, чтобы он сносно всё это играл по нотам -- или натренироваться самому? Напомню, что соревнование компьютерных пианистов тут: http://renconmusic.org/ (в этом году, похоже, пауза. Но результаты прошлого года вполне убедительны). Сейчас эта дилемма будет по многим и многим занятиям: научить робота танцевать, петь, играть на пианино или саксофоне, сочинять стихи и рассказы будет занимать примерно столько же времени, как научить человека. Уже почти.

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

    1. Сапдейтили понятие нейронета: раньше был "эпоснет", когда знание передавалось в устной традиции, потом "букнет" для письменной традиции, потом "интернет" с его гуглём, поиском, социальными сетями, а уже потом будет "нейронет", когда "нейро" переместится в саму сеть и "нечеловеческие и/или сверхвалидные узлы" станут активными переустроителями как себя, так и самой сети ("САПР переместится в систему", как я это называю). Техническая реализация интерфейса непосредственно от нейронов к сети тут не самый важный и интересный момент, как не самый важный момент в развитии самого интернета переход от интерфейса интернета от толстеньких CRT-дисплеев к дисплеям на смартфонах и планшетах и прохождения самого интернета не по проводам, а через WiFi или LTE. Как говорится, в играх побеждает лучший геймплей, а не техническая реализация полигонов: кто и в какую игру играет важней, чем на каком движке оно сделано (но разные движки позволяют при этом делать разные игры, это тоже забывать нельзя).

    Тут есть три времени рассмотрения: операции (run-time), жизненный цикл одной системы (например, интернета) и "управление технологиями" (смена технологий, перескок с одной s-образной кривой развития на другую, переход с одного типа платформ на другую). Нейронет в этом плане имеет жизненный цикл как система (нейронет ведь индивид, физический объект, существует в пространстве-времени! Как интернет всепланетный и один, так и нейронет), но само его появление рассматривается именно в плане "управления технологиями". Что будет после нейронета пока не рассматриваем, не будем строить из себя Нострадамусов (сингулярность она такая сингулярность!).

    2. Для того, чтобы сделать шаг от "форсайтно-предсказательной" деятельности к "инженерно-проектной" деятельности (т.е. перейти от экспертной группы к рабочей группе по формулированию требований и предложению архитектуры) решили переформатировать материалы прошлых форсайтных сессий в соответствии с принципами системноинженерного подхода:
    -- ввели уровни системного рассмотрения/холархию/zoom-select: мир, сеть (эпос, бук, интер, нейро), узел ("я"), комплектующие узла. Надсистема задаёт функцию целевой системы, функция эмерджентно появляется из взаимодействия подсистем. Мир задаёт функцию нейронета, нейронет появляется во взаимодействии узлов (плюс мы не игнорируем то, что сами узлы нам тоже придётся делать из каких-то комплектующих).
    -- При этом учитываем, что для интернета мир-сеть задаются социотехнически (система систем), а вот узлы и комплектующие инженерно (традиционные системы -- люди пока выводятся за пределы системы). Для нейронета всё не так очевидно, потому что у узлов сети появляется субъектность, они проявляют агентность (в смысле агентского подхода, то есть какая-то автономность в принятии решений). Появляется свойства resilience, адаптации, развития и т.д., привносимые не инженерами снаружи, а самой нейросетью. Что там в узлах (люди, киборги, агенты, датацентры, мыслящие кофеварки и т.д.) это уже содержание, на разных стадиях развития интернета-нейронета там разное будет. Интернет-узел был мини-компьютером когда-то, а сейчас принтером или смартфоном (опять же, приаттаченность человека к принтеру или смартфону можно обсуждать отдельно: к принтеру человек приаттачен меньше, а к смартфону больше. А вот к нейронету так и вообще может быть приаттачен до неразличимости, на эту тему потом порассуждаем).
    -- ввели минимально два стиля определения системы, чтобы запустить архитектурную работу: компонентный (принципиальные схемы -- обсуждаем время работы нейронета) и модульный (набор имеющих интерфейсы модулей -- обсуждаем время строительства нейронета).

    3. По возможности опираемся на международные инженерные стандарты в части формы/схемы. Содержание в рамках этих форм/схем, конечно, полностью новое -- специфически нейронетное. Так, компоненты и модули -- это из ISO 81386, архитектура из ISO 42010, привязка всех логических построений к физической деятельности и физическому миру из ISO 15926, типы инженерного взаимодействия узлов из ISO 11354, разделение идеальных объектов (дисциплины) и рабочих продуктов (конкретных технологий) из OMG Essence и т.д.. В задаваемых этими стандартами схемах ("в системном языке") вполне выразим и особый случай инженерии предпринятия, и особый случай программной инженерии, и особый случай инженерии психики (да, я помню, у меня в планах уже пару лет пост про это в openmeta с выходом на шестичастную архитектуру психики).

    Остальное всё -- по мелочи, по сравнению с этими тремя пунктами.

    "Российская группа нейронета" тусуется главным образом в фейсбуке: https://www.facebook.com/groups/nevronet/

    Основные употреблённые в этом посте термины системноинженерного мышления разъясняются в http://techinvestlab.ru/files/systems_engineering_thinking/systems_engineering_thinking--TechInvestLab_2014.pdf , там же даются краткие характеристики упомянутых международных стандартов. Но по этой ссылке непопса и многабукофф (306 страниц с картинками).
[ << Previous 20 ]
About LiveJournal.com