Практика системной информатики
Если кратко и без нюансов, то системная информатика -- это практика (наука/дисциплина и технологии/софт) многоуровнего множественного описания системы. Я писал о ней подробней тут: http://ailev.livejournal.com/1272169.html
Многоуровневого -- это уровни абстракции, "мета", описания описаний (методы описаний), описания описаний описаний (описания методов описаний), описания описаний описаний (описания языков описания методов описаний). В случае коннекционистского моделирования, это уровни абстракции, "глубина". Про важность "глубины" и обоснование многоуровневости в описаниях (речь идёт прежде всего о краткости выражения пути между разнородными далёкими описаниями) см. http://ailev.livejournal.com/1274014.html
Множественного -- это на всех уровнях системы * для удовлетворения всех интересов стейкхолдеров. Это азы системного мышления: поддержка понятия "холон" и междисциплинарности на каждом уровне холона (различная междисциплинарность, ибо на каждом уровне холона мы имеем дело с эмерджентностью: нужно моделировать какие-то иные свойства системы, не сводящиеся к свойствам частей этой системы).
Дисциплина -- это какой-то теоретический аппарат, набор основных понятий, опирающийся на понятия системного подхода в части описаний систем (если грубо, то дисциплина работы с альфой определения системы из Systems Engineering Essence -- см. системную схему проекта, например, в варианте http://ic.pics.livejournal.com/ailev/696279/103958/103958_original.png). Основная диаграмма тут -- модифицированная для всех видов описаний (а не только архитектурное) из ISO 42010 -- http://ic.pics.livejournal.com/ailev/696279/104932/104932_original.png
Основная технология -- это мегамоделирование, поддерживаемое мегамоделерами, многоязычными групповыми IDE (http://ailev.livejournal.com/1273208.html). Сами мегамоделеры базируются на инфраструктуре, поддерживающей множество viewpoints и view (алгоритмическими, данными в XML или JSON, онтологическими, текстовыми-с-синтаксисом, фото-видео-адио, 3D-модели и т.д.) и мэппинги между различными форматами данных. Базовый софт для мегамоделеров (так сказать, "мегамоделер без моделей") -- systems framework, по аналогии с language workbench, которые должны были стать инструментами для создания IDE для разных DSL, а сейчас называются language frameworks, например Xtext -- http://www.eclipse.org/Xtext/. Так и тут: systems frameworks должны стать инструментами для создания мегамоделеров (см. дискуссию к посту по ссылке в этом абзаце), удобных для различного рода систем: инструментами комплексирования множества реализаций viewpoints для документирования описания какого-то класса систем. Типа как игровые движки/фреймворки, которые инструменты для создания игр и модов, моделирующих различные игровые миры.
По системной информатике пока нет специального образования (information systems тут не в счёт, ибо это подходит больше для узкого класса корпоративных менеджерских систем). Учат computer science (алгоритмы и структуры данных), учат архитектурам софта, учат многоуровневости определений данных и программ (формальным спецификациям) в ООП, кое-где учат онтологиям и моделированию данных, даже учат DDD (domain driven design). Нигде не учат многоуровневым многоаспектным описаниям и работе с ними под контролем конфигурации -- немного касаются этого в курсах системной инженерии, но и там для программистов больше делают акцент на практики системной инженерии для "железных" систем, а не на системное мышление. Для разворачивания образования нужно:
-- формулирование профиля компетенций (что-то типа GRCASE для системной инженерии -- см. ).
-- формулирование предмета/дисциплины (серии моих постов тут явно маловато. Нужно делать какой-то учебник).
-- разворачивание какой-то учебной технологии, system workbench (ибо побеждает не дисциплина, а практика: обёрнутая в удачную технологию дисциплина. Плохая технология предаёт дисциплину забвению, идеи умирают легче, чем хорошо работающий софт).
-- подготовка набора задач и проведение практических работ по а) разработке/доработке мегамоделеров, methodology realm и б) работе с ними в условиях целевых рабочих проектов, endeavor realm.
-- дидактика: как и в каком порядке всё это воплощать в учебных курсах?
-- сообщество системных информатиков, рефлексирующих практиков. Если не будет практикующих, то всё это ненастоящее. Тут нужно учесть, что NCOSE появилось только в 1990, хотя практика системной инженерии много раньше. Но тогда ещё не было ни web 1.0, ни тем более web 2.0, всё было в социальном плане медленно.
Это всё легко написать, но очень трудно сделать -- возможно, это займёт несколько лет.
Нужно показать систему разделения труда в системной информатике, её подпрактики. Где кончается системная информатика и начинается просто программная инженерия (как в системной инженерии на V-диаграмме показывают, где начинаются и где заканчиваются системноинженерные практики). Лет тридцать назад (в конце 80-х) в СССР было некоторое неформальное обсуждение вопросов "системного программирования", которое понималось как строительство прежде всего компиляторов, баз данных и прочего "системного софта" (и системных компонент, например тех же баз данных и компиляторов в прикладном софте: все же помнят, что "любая достаточно развитая программная система с какого-то момента начинает включать в себя кривой и неразвитый Common Lisp").
Но это "системное программирование" в те времена дико путалось ещё с "системным администрированием". На одной из тусовок "системных программистов" в Киеве где-то году так в 1989 родилось определение "системный программист -- это тот, кто всё время дискетки копирует", и это было правдой: системные администраторы и системные программисты в те поры практически не отличались, но точно занимались не тем, чем прикладные программисты с их вгрызанием в прикладную предметную область. Системные программисты вгрызались именно в computer science, а не прикладные предметы, но вот что все свои инструментальные системы они потихоньку ведут к мегамоделеру -- это явно не отслеживалось. А инструментарий для построения инструментария, все эти YACC и СУБД в целокупности состявляющие systems frameworks -- это даже не обсуждалось. Всё было ad hoc, и слипалось потом причудливо в самые разные "системы", общность функционала и архитектуры в которых было уж не разглядеть.
То, что "системный софт" как-то отличается от "прикладного софта", отражается даже в ArchiMate -- он моделируется в "оборудовании", а не "софте" (ибо он не прямо поддерживает деятельность людей, а поддерживает работу прикладного софта) -- http://pubs.opengroup.org/architecture/archimate3-doc/chap10.html#_Toc451758049. "This can be, for example, an operating system, a JEE application server, a database system, or a workflow engine. Also, system software can be used to represent, for example, communication middleware".
Инженерия систем машинного обучения, вероятно, тоже должна пройти подобный путь развития. Одни (системные машинообучатели) лепят всяческие "фреймворки" и "библиотеки" (типа TensorFlow) и думают, как бы их интегрировать в объемлющие когнитивные архитектуры и поудобней включить в состав мегамоделеров, а другие делают прикладные системы -- занимаются моделированием языков, анализируют изображения, изготавливают корпуса текстов и устанавливают к ним baseline.
Что же касается моделирования и онтологизирования, то computer science (за исключением странных эпизодов типа Simula 67) и software engineering вообще их не считают "своими" -- и те болтаются практически бесхозными. А уж комплексное моделирование-онтологизирование будущей системы (т.е. конструирование-проектирование) так вообще "чужое", а ведь это всё про одно и то же -- создание многоуровнего множественного описания системы различными средствами. Сборка всех частных описаний (view, каждый под своим viewpoint) в общий system description -- этим ни одна из дисциплин не озабочена. Так, modeling-in-the-large вообще не обсуждается (иногда как "коллаборативное проектирование"), и эта дискуссия совершенно отдельна от очень редких обсуждений programming-in-the-large -- http://www.cs.umd.edu/class/spring2005/cmsc838p/General/pitl.pdf, https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small, пункт 2 в http://ailev.livejournal.com/1122126.html про "птолемеевкую модель кода", и много чего ещё из этой серии. Всё это появляется в силу наличия многих стейкхолдеров со многими интересами, плюс необходимости сочетать работу над целевой системой с жизненным циклом (т.е. заниматься работой обеспечивающей системы), т.е. это всё системная информатика.
Все отдельные дисциплины плывут к пониманию необходимости множества "veiw" как бы "в бессознанке" -- и поэтому главная сейчас задача это внесение осознанности. Нужно построить основные понятия системной информатики и предложить терминологию, в которых консистентно и компактно можно обсуждать единство программирования, моделирования, онтологизирования, проектирования. Тут явно не пустое место, но сборку разбежавшегося по разным дисциплинам и технологиям, сборку по редко встрачающимся в жизни друг с другом практикам -- эту сборку сделать нужно.
Многоуровневого -- это уровни абстракции, "мета", описания описаний (методы описаний), описания описаний описаний (описания методов описаний), описания описаний описаний (описания языков описания методов описаний). В случае коннекционистского моделирования, это уровни абстракции, "глубина". Про важность "глубины" и обоснование многоуровневости в описаниях (речь идёт прежде всего о краткости выражения пути между разнородными далёкими описаниями) см. http://ailev.livejournal.com/1274014.html
Множественного -- это на всех уровнях системы * для удовлетворения всех интересов стейкхолдеров. Это азы системного мышления: поддержка понятия "холон" и междисциплинарности на каждом уровне холона (различная междисциплинарность, ибо на каждом уровне холона мы имеем дело с эмерджентностью: нужно моделировать какие-то иные свойства системы, не сводящиеся к свойствам частей этой системы).
Дисциплина -- это какой-то теоретический аппарат, набор основных понятий, опирающийся на понятия системного подхода в части описаний систем (если грубо, то дисциплина работы с альфой определения системы из Systems Engineering Essence -- см. системную схему проекта, например, в варианте http://ic.pics.livejournal.com/ailev/696279/103958/103958_original.png). Основная диаграмма тут -- модифицированная для всех видов описаний (а не только архитектурное) из ISO 42010 -- http://ic.pics.livejournal.com/ailev/696279/104932/104932_original.png
Основная технология -- это мегамоделирование, поддерживаемое мегамоделерами, многоязычными групповыми IDE (http://ailev.livejournal.com/1273208.html). Сами мегамоделеры базируются на инфраструктуре, поддерживающей множество viewpoints и view (алгоритмическими, данными в XML или JSON, онтологическими, текстовыми-с-синтаксисом, фото-видео-адио, 3D-модели и т.д.) и мэппинги между различными форматами данных. Базовый софт для мегамоделеров (так сказать, "мегамоделер без моделей") -- systems framework, по аналогии с language workbench, которые должны были стать инструментами для создания IDE для разных DSL, а сейчас называются language frameworks, например Xtext -- http://www.eclipse.org/Xtext/. Так и тут: systems frameworks должны стать инструментами для создания мегамоделеров (см. дискуссию к посту по ссылке в этом абзаце), удобных для различного рода систем: инструментами комплексирования множества реализаций viewpoints для документирования описания какого-то класса систем. Типа как игровые движки/фреймворки, которые инструменты для создания игр и модов, моделирующих различные игровые миры.
По системной информатике пока нет специального образования (information systems тут не в счёт, ибо это подходит больше для узкого класса корпоративных менеджерских систем). Учат computer science (алгоритмы и структуры данных), учат архитектурам софта, учат многоуровневости определений данных и программ (формальным спецификациям) в ООП, кое-где учат онтологиям и моделированию данных, даже учат DDD (domain driven design). Нигде не учат многоуровневым многоаспектным описаниям и работе с ними под контролем конфигурации -- немного касаются этого в курсах системной инженерии, но и там для программистов больше делают акцент на практики системной инженерии для "железных" систем, а не на системное мышление. Для разворачивания образования нужно:
-- формулирование профиля компетенций (что-то типа GRCASE для системной инженерии -- см. ).
-- формулирование предмета/дисциплины (серии моих постов тут явно маловато. Нужно делать какой-то учебник).
-- разворачивание какой-то учебной технологии, system workbench (ибо побеждает не дисциплина, а практика: обёрнутая в удачную технологию дисциплина. Плохая технология предаёт дисциплину забвению, идеи умирают легче, чем хорошо работающий софт).
-- подготовка набора задач и проведение практических работ по а) разработке/доработке мегамоделеров, methodology realm и б) работе с ними в условиях целевых рабочих проектов, endeavor realm.
-- дидактика: как и в каком порядке всё это воплощать в учебных курсах?
-- сообщество системных информатиков, рефлексирующих практиков. Если не будет практикующих, то всё это ненастоящее. Тут нужно учесть, что NCOSE появилось только в 1990, хотя практика системной инженерии много раньше. Но тогда ещё не было ни web 1.0, ни тем более web 2.0, всё было в социальном плане медленно.
Это всё легко написать, но очень трудно сделать -- возможно, это займёт несколько лет.
Нужно показать систему разделения труда в системной информатике, её подпрактики. Где кончается системная информатика и начинается просто программная инженерия (как в системной инженерии на V-диаграмме показывают, где начинаются и где заканчиваются системноинженерные практики). Лет тридцать назад (в конце 80-х) в СССР было некоторое неформальное обсуждение вопросов "системного программирования", которое понималось как строительство прежде всего компиляторов, баз данных и прочего "системного софта" (и системных компонент, например тех же баз данных и компиляторов в прикладном софте: все же помнят, что "любая достаточно развитая программная система с какого-то момента начинает включать в себя кривой и неразвитый Common Lisp").
Но это "системное программирование" в те времена дико путалось ещё с "системным администрированием". На одной из тусовок "системных программистов" в Киеве где-то году так в 1989 родилось определение "системный программист -- это тот, кто всё время дискетки копирует", и это было правдой: системные администраторы и системные программисты в те поры практически не отличались, но точно занимались не тем, чем прикладные программисты с их вгрызанием в прикладную предметную область. Системные программисты вгрызались именно в computer science, а не прикладные предметы, но вот что все свои инструментальные системы они потихоньку ведут к мегамоделеру -- это явно не отслеживалось. А инструментарий для построения инструментария, все эти YACC и СУБД в целокупности состявляющие systems frameworks -- это даже не обсуждалось. Всё было ad hoc, и слипалось потом причудливо в самые разные "системы", общность функционала и архитектуры в которых было уж не разглядеть.
То, что "системный софт" как-то отличается от "прикладного софта", отражается даже в ArchiMate -- он моделируется в "оборудовании", а не "софте" (ибо он не прямо поддерживает деятельность людей, а поддерживает работу прикладного софта) -- http://pubs.opengroup.org/architecture/archimate3-doc/chap10.html#_Toc451758049. "This can be, for example, an operating system, a JEE application server, a database system, or a workflow engine. Also, system software can be used to represent, for example, communication middleware".
Инженерия систем машинного обучения, вероятно, тоже должна пройти подобный путь развития. Одни (системные машинообучатели) лепят всяческие "фреймворки" и "библиотеки" (типа TensorFlow) и думают, как бы их интегрировать в объемлющие когнитивные архитектуры и поудобней включить в состав мегамоделеров, а другие делают прикладные системы -- занимаются моделированием языков, анализируют изображения, изготавливают корпуса текстов и устанавливают к ним baseline.
Что же касается моделирования и онтологизирования, то computer science (за исключением странных эпизодов типа Simula 67) и software engineering вообще их не считают "своими" -- и те болтаются практически бесхозными. А уж комплексное моделирование-онтологизирование будущей системы (т.е. конструирование-проектирование) так вообще "чужое", а ведь это всё про одно и то же -- создание многоуровнего множественного описания системы различными средствами. Сборка всех частных описаний (view, каждый под своим viewpoint) в общий system description -- этим ни одна из дисциплин не озабочена. Так, modeling-in-the-large вообще не обсуждается (иногда как "коллаборативное проектирование"), и эта дискуссия совершенно отдельна от очень редких обсуждений programming-in-the-large -- http://www.cs.umd.edu/class/spring2005/cmsc838p/General/pitl.pdf, https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small, пункт 2 в http://ailev.livejournal.com/1122126.html про "птолемеевкую модель кода", и много чего ещё из этой серии. Всё это появляется в силу наличия многих стейкхолдеров со многими интересами, плюс необходимости сочетать работу над целевой системой с жизненным циклом (т.е. заниматься работой обеспечивающей системы), т.е. это всё системная информатика.
Все отдельные дисциплины плывут к пониманию необходимости множества "veiw" как бы "в бессознанке" -- и поэтому главная сейчас задача это внесение осознанности. Нужно построить основные понятия системной информатики и предложить терминологию, в которых консистентно и компактно можно обсуждать единство программирования, моделирования, онтологизирования, проектирования. Тут явно не пустое место, но сборку разбежавшегося по разным дисциплинам и технологиям, сборку по редко встрачающимся в жизни друг с другом практикам -- эту сборку сделать нужно.