March 13th, 2009

2019

Требовательный инжиниринг

Начал отвечать на коммент (http://ailev.livejournal.com/667768.html?thread=5692024#t5692024) и решил вынести отдельным постом. В комменте vit_r приводит фрагмент картинки из реальной requirement diagram, выполненной по современной моде системной инженерии, в SysML:


vit_r пишет: "это элементарный случай дюжина на дюжину. У меня во многих случаях идёт сто на сто. Так что графическое решение многих задач красиво только на элементарных (рекламных) примерах".

ППКС! Полностью согласен с приведенным примером. Хотя из этого не следует, что язык можно сразу выкинуть: можно сохранить его онтологию и семантику, но поменять нотацию. Так, схемами IDEF0 (даже в более расширенном их варианте, так называемом eIDEF0) в графическом виде пользоваться нельзя, но их великолепно подшивать к отчетам по договору: очень умно выглядят и занимают много-много листов бумаги. А вот пользоваться ими удобно только в виде их табличного представления. Хорошенькая такая табличка, с парой дюжиной полей и мнооооожеством строчек, готовится в Exel (например, программой ОргМастер), свободно читается топ-менеджерами без айтишного образования...

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

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

Я думаю, наш самый большой вклад в INCOSE может быть в том, что мы будем усомневать SysML в качестве единственного языка системной инженерии. Мне кажется, что будущее тут не за "один язык для всех и обо всем", а за набором DSL для разных групп описаний. Ход на стыковку Modelica с SysML мне не представляется самым удачным (хотя Modelica и имеет текстовое и графическое представление одновременно. Кто знает, вдруг редакторы для Modelica станут средством массового применения SysML для больших систем?).

Если вернуться от общего обсуждения недостатков графических языков для описания больших систем к представлению требований, то
а) с онтологией требований все пока очень плохо:
-- понятие "трассировка" совершенно неоперационально (протрассируйте-ка требования ilities! Как раз про это assurance case, и нужно как-то требования привязывать к claims и далее к тестированию и обоснованиям, что в системах управления требованиями не слишком-то поддерживается, равно как в системах оценки: нет того места, где claims сопоставлялись бы с требованиями, или генерировались из них);
-- верификацию от валидации отличить зачастую затруднительно. Тут вся эта дискуссия про intents, различие "духа" требований и их "буквы", что очень трудно отразить в языке. Различение превращается в игру слов и выпячивание должностей участвующих;
-- иерархичность требований непонятно по каким типам отношений проходит -- понятно только что по разным (в мереологии обсуждается, что иерархии требований-подтребований могут строиться по разным основаниям);
-- разница между функциональными/черного ящика и конструкторскими/белого ящика требованиями размыта;
-- привязка требований к стейкхолдерам, и далее различные view и viewpoints для их выражения отнюдь не способствует единообразному их представлению. Требование "чтобы 2*2 было =4" лучше представлять в формате выражения, а вот требование "на самом видном месте должен быть налеплен логотип" даже не сразу понятно, в каком формате представлять, кроме текстового (хотя я верю, что "самое видное место" вполне можно формализовать и затем проверять выполнение этого требования приборно -- распознаванием сцен).
Этот список можно продолжать и продолжать. Сведение всего этого списка к "требование -- это текстовая строка, не более" сводит системы управления требованиями к простому блокноту, т.е. явно не дает особого выигрыша по сравнению с любой неспециализированной базой данных "текстовых строк". А как только мы пытаемся выскочить за пределы такого упрощения, тут же получаем все непонятки с требованительной онтологией.

б) с DSL (domain specific language) требований тоже плохо: язык должен выражать какую-то определенную онтологию, нотация должна быть компактна для этой онтологии. Ежели у нас нет онтологии, то мы не можем представить компактный язык для ее описания. Так, сначала можно поверить в SysML как адекватный язык представления требований, затем предложить альтернативную нотацию. Но вот что-то не кажется, что язык (его семантика) адекватен. Далее см. пункт 1 -- нелепо переходить к оптимизации нотации без уверенности в выразительной силе подлежащей семантики.
2019

Фрайди найт

vit_r опять сделал коммент с очень точным наблюдением (http://ailev.livejournal.com/667930.html?thread=5693210#t5693210): "чем больше формализация, тем меньше люди обращают внимание на смысл". И ведь это крайне точно, замечал много раз: чем больше формализация, чем больше математики, тем мощнее решения и тем меньше вероятность доведения решений до какой-то практики. maksimotstavnov как-то заметил мне, что раньше считал объективных идеалистов не существующими в природе. А потом понял: неуемные формализаторы как раз и есть эти объективные идеалисты -- они свои идеальные построения считают связанными с реальностью (имеющими смысл) уже в силу того, что эти идеальные построения сделаны. То, что такие построения (даже очень сложные, даже очень красивые) могут быть бессмысленными по отношению к практике, этим людям в голову не приходит.

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

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

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

Самые интересные формализмы -- это отсекающие несущественное (иначе -- не формализм), но затем автообращающие внимание на смысл, заставляющие думать не только о том, что тебе сказали, но и зачем сказали, и что из этого следует. Не только лестница в теоретическое небо, но и гарантии возврата на практическую землю.
* * *
Огромное спасибо vit_r за наводку на стандарт обмена требованиями (Requirements Interchange Format, RIF), который был инициирован автостроителями еще в 1999г. и ныне используется во многих системах требовательного инжиниринга -- http://www.prostep.org/fileadmin/freie_downloads/Empfehlungen-Standards/ProSTEP_iViP/PSI6_RIF_1.2_Mapping-Table.pdf

А вот про интеграцию RIF и SysML -- http://www.omg.org/docs/syseng/08-06-07.pdf

Дальше можно было бы обсудить этот тренд: Modelica пытается интегрироваться в SysML, RIF пытается интегрироваться в SysML, все DSL пытаются интегрироваться в SysML -- почему мне так не нравится этот джаггернаут? Почему мне не хочется вскочить на подножку этого моднейшего поезда, почему мне кажется, что этот поезд полным ходом несется в тупик? Ведь успех UML абсолютно очевиден, SysML не менее успешен, но почему мне кажется, что это не лучший способ интегрировать различные группы описаний?

Мне почему-то кажется, что Священный Грааль объединения самых разных DSL лежит там, где изучают эти DSL. Ну, и там, где делают инструментарий для ISO 42010 (про архитектурные описания). Вот взялся бы кто-нибудь на эти темки рефератик написать, а потом доложился бы на каком-нибудь собрании российской группы INCOSE (думаю, что до официальной регистрации отделения-chapter можно именоваться группой).
* * *
Месяц назад я написал "неожиданно быстро может появиться новое поколение хардвера на вероятностной логике" (http://ailev.livejournal.com/660537.html), и вот оно -- первым устройством на вероятностной логике будет грифельная доска (тачскрин со стилусом) на солнечных батарейках, которая сможет учить деток математике сама, без учителя -- концепция learning by doing (http://www.media.rice.edu/media/NewsBot.asp?MODE=VIEW&ID=12267&SnID=2). Не сотовые телефоны, не криптография, как было ранее объявлено, а учебные эээ... пособия.

Солнечных батареек будет хватать потому, что вероятностные чипы потребляют в тридцать раз меньше электричества и работают в семь раз быстрее, чем сегодняшние лучшие технологии (http://www.rice.edu/nationalmedia/news2009-02-08-pcmos.shtml).
* * *
Тем временем OLPC объявляет о возможном переходе на ARM для новенького XO-2 (http://www.pcworld.com/article/161112/olpc_set_to_dump_x86_for_arm_chips_in_xo2.html) -- прощай, x86. Ключевой вопрос все тот же: потребление энергии. Ну, и свободный дизайн хардвера XO-2 опять подтвержден -- с ARM это еще более интересно, ибо для ARM есть много конкурирующих производителей.
* * *
С батарейками тоже начинают разбираться -- нашли способ зарядки обычных аккумуляторов за секунды вместо десятков минут: http://web.mit.edu/newsoffice/2009/battery-material-0311.html. Обещают коммерциализировать за пару лет.
* * *
Но гонка за самый дешевый (т.е. самый медленный и убогий) учебный компьютер продолжается: вот еще один проект на процессоре 6502 (дико успешный проект 1975г. -- http://en.wikipedia.org/wiki/MOS_Technology_6502 -- я и не знал, что он продолжает выпускаться тридцать лет спустя, до сих пор!): http://techon.nikkeibp.co.jp/english/NEWS_EN/20090312/167076/. Этот компьютер должен подключаться к телевизору, производится он в Китае и стоит как раз $10 -- он сделан по образу и подобию старинной игровой консоли NES (Nintendo Entertainment System). Эта "игровая консоль" и планируется к начинке учебным софтом для развивающихся стран.
* * *
Качественную графику будут считать в 20 раз быстрее: один из стартапов, наконец, выпустил графический ускоритель трассировки лучей: http://www.caustic.com/caustic-rt_intro.php
* * *
Так и представляю себе, как начинают комплексировать все эти технологии через пару лет -- графический ускоритель, который пересаживают на вероятностную логику и засовывают в похожую на XO-2 машинку, в которой есть мощная мгновенно перезаряжаемая батарея...
* * *
Книжка про машинную этику Moral Machines -- http://book.pdfchm.net/Moral-Machines-Teaching-Robots-Right-from-Wrong/9780195374049/ (не забывайте регистрироваться на этом сайте!).