December 1st, 2013

2021 год

Функция, конструкция, место. Модули, компоненты, размещения.

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

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

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

Определяется каждая система через её функцию по отношению к надсистеме времени эксплуатации (operation). Эти функции определяются компонентами системы, которые связаны друг с другом. Поэтому иногда компонентный стиль называют "компоненты и связи" (component and connectors).

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

Важно, что все эти "схемы" часто не предполагают какого-то сорта физического (продуктного, модульного) воплощения в материальном мире, это остаётся для других описаний, более удобных для этого. Так, для каждого резистора на принципиальной схеме продуктное описание можно найти где-то в спецификации, на монтажных чертежах (печатной платы, например). Для каждого насоса в P&ID диаграммах про "физические" насосы-как-продукты больше можно узнать из закупочных спецификаций или 3D-модели. На самих же диаграммах приведены "функциональные" объекты (компоненты) и связи между ними. Компонентные диаграммы можно также найти в современных средствах мультифизического моделирования (Modelica). Все эти "клиент-серверные", "клиент-middleware-сервер" подстили описаний софтовых систем -- это примеры компонентного стиля описаний, "как оно работает".

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

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

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

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

В большинстве случаев невозможно найти описательный стиль в чистом виде, используются гибридные стили. Кроме того, описания обычно используются совместно. Чаще всего это совместное использование происходит в рамках двух подходов:
-- синтетического: когда несколько абсолютно разных описаний связываются между собой через понимание, какие элементы в них являются общими. Например, какие модули одного описания соответстствуют каким компонентам другого описания.
-- проективного: когда из одного супер-комбинированного описания (чаще всего хранящегося в виде какой-то базы данных) нужное описание как бы "проецируется", давая только нужное для того или иного стейкхолдера описание.
Оба эти подхода логически эквивалентны (хотя проективный вариант с его базой данных/репозиторием представляется мне более современным, а синтетический вариант исторически ему предшествует как "одно описание -- один файл". Ср. с поколениями PLM, ибо PDM в PLM как раз и занимается объединением разнородных описаний, обеспечивая контроль конфигурации: http://ailev.livejournal.com/965124.html. Конечно, мы тут говорим о машинообрабатываемых описаниях, а не просто "машиночитаемых" типа .pdf файлов с диаграммами класса "псевдокодов", http://ailev.livejournal.com/965564.html).

Все элементы системы в этих описаниях должны быть поименованы. Имя элемента зависит от описания. Имя модуля будет, скорее всего, именем продукта. Имя компонента -- функциональным именем. Имя какой-нибудь "площадки" -- именем места. Тем самым один и тот же элемент может иметь много самых разных имён. Помним, что минимальное число имён -- три:
-- компоненты,
-- модуля,
-- места.
Стандарт ISO 81346 предлагает различать эти имена префиксами: = для функционального имени, - для продуктового, + для места.

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

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

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

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

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

Практики описания системы -- это просто практики записи, они не подразумевают какого-то выдумывания описываемой системы. Практики описания включают в себя знания по языку описания, используемым нотациям, описательным идиомам, редакторам. Эти практики описания не нужно путать с практиками инженерии (инженерии требований, инженерии системной архитектуры, системного конструирования/проектирования/design). Практики инженерии учат тому, как придумать соответствующие определения системы (альфы). А практики описания -- как создать рабочие продукты, документирующие принятые при определении системы инженерные решения. То, что вы знаете, как поименовать какой-нибудь модуль и как его описать в разных видах моделей, используемых в инженерном проекте, ещё не означает, что вы можете этот модуль для системы предложить и правильно определить его интерфейсы, минимизировав связи с другими модулями. Умение нарисовать правильным значком компоненту на принципиальной схеме вовсе не означает, что вы понимаете, как создать эту принципиальную схему так, чтобы результирующая система была успешной.
* * *
Этот текст получился из соединения нескольких идей:
-- генерализации идеи разделения архитектуры и архитектурного описания (и доработки терминологии) в ISO 42010 до идеи разделения определения и описания системы. Там очень много всего, в том числе определения синтетического (synthetic) и проективного (projective) подходов к описанию.
-- генерализация идеи архитектурных стилей до стилей описания из книжки Garlan et al. (http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a) и адаптация для "железных" систем;
-- развитие идеи холархии: минимально три холархии (соответствие стилям описания) по отношению часть-целое для одной системы, это из ISO 81346. Отсюда же дисциплина "холархических имён" (с учётом их множественности).

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

И ещё нужно подумать, как это всё совместить 4D extensionalism из ISO 15926 (где компоненты и модули/продукты отождествляются друг с другом через отношения WholeTemporalPart). Я бы всё-таки модулем считал "тип изделия", а продуктом именно продукт (т.е. что-то произведённое) с серийным номером. Но это может быть и лишним.

Я понимаю, что в литературе полный бардак по поводу всех этих "функций", "конструкций", "модулей", "продуктов" и т.д. (вот, например, кратенький обзор на тему "функций" -- http://ailev.livejournal.com/938820.html. В принципе, этот текст по ссылке в какой-то мере предшественник настоящего поста). Так что меня волнует создание более-менее связного по терминологии обзора всех этих разных полезных идей, появляющихся в самой разной терминологии в самых разных практиках.

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

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

lytdybr

Отрок вернулся к зергам, зерглингам и саранчидам (http://ru.wikipedia.org/wiki/%D0%97%D0%B5%D1%80%D0%B3%D0%B8). Остальные игры и мультфильмы уже несколько дней побоку.

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

Калькулятор для пикселей -- http://members.ping.de/~sven/dpi.html. У меня сейчас 92 PPI (1080p на 24"), и это для моего нынешнего зрения очень комфортно. Если я хочу 4K такой же степени комфортности, это должно быть 48" (калькулятора тут не нужно, 4К это же Quad HD -- просто удваиваем диагональ). Так что нужно ждать какого-нибудь приличного 50" монитора. Который потребует правильной видеокарты и портов, которые потребуют поменять ноутбук, который потребует переустанавливать весь софт. Ох...

6Tb гелиевые 3.5" HDD с 2млн. часов наработки на отказ -- http://www.hgst.com/hard-drives/enterprise-hard-drives/enterprise-sas-drives/ultrastar-he6. Меня тут меньше интересует гелиевая компонента (хотя там много неожиданных бонусов: например, эти диски герметичны, поэтому из можно заливать непроводящей жидкостью для более эффективного охлаждения). Больше меня интересует 6Tb в одном диске при 2млн. часов наработки на отказ. Пока эти диски отгружаются избранным клиентам, но скоро это будет у всех.

General Electric будет печатать 85тыс. форсунок для своего нового реактивного двигателя Leap (вместо сборки форсунки из двадцати мелких деталей): http://www.bloomberg.com/news/2013-11-12/ge-printing-engine-fuel-nozzles-propels-6-billion-market.html. Как я понимаю, дороговизна и малая скорость печати с лихвой компенсируются сложностью и продолжительностью сборки двадцати деталей. Но даже это не главная причина: собранные из деталей компоненты менее надёжны. А работать форсункам нужно при высокой температуре, им нужно выдерживать 1315 °С. Стратегия GE в том, чтобы получить новое поколение принтеров, поэтому у них тесное сотрудничество с поставщиками этих новых "станков". Изготовители потирают ладошки: в отрасль потихоньку начинают приходить настоящие (для основного производства), а не "пилотные" (для экспериментов деньги.

Продолжая тему "долой процессный подход" можно зацепить и смежную тему "долой проектный подход" -- http://www.infoq.com/news/2013/11/get-rid-of-projects. Есть примеры организаций без проектов и проектных менеджеров (хотя там есть и команды, и менеджеры). Просто неиспользование слова "проектный менеджер" ведёт к неиспользованию практик "проектного управления", что сегодня может быть рассмотрено не только как вред, но и как благо. Заодно по ссылке поднимается и тема вреда годичного цикла бюджетирования (а противовесом видится подход beyond budgeting, http://ailev.livejournal.com/331549.html -- в 2005 году я писал "работа с проектами в мультипроектной организации требует много более гибкого бюджетирования, нежели типовое сегодняшнее". Прошло восемь лет, и "работа с проектами в мультипроектной организации" тоже начинает быть подозрительной. Управление кейсами (ведение дел), предпринятия как общее слово для каких-то организационных начинаний -- жизнь не стоит на месте). Вдогонку сюда же -- Management 3.0 про новые практики agile leadership (http://www.management30.com/, перевод тамошней книжки на русский -- http://www.books.ru/books/kak-izmenit-mir-yurgen-appelo-21577/?customer_product=1). Давненько я не занимался сдвигами в практиках leadership, а ведь это крайне важно при реорганизациях. Нужно навёрстывать.

Программа конференции с использованием в этой программке метода персонажей (кратко помянул его тут: http://ailev.livejournal.com/511947.html) для участников конференции -- http://www.xpdays.net/Xpday2013/XPDays/Program.html. Такое впечатление, что эти персонажи больше помогали создавать программу, но как маркетинговый ход это тоже неплохо получилось.

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

Жизнь в лице сразу нескольких клиентов заставляет меня заниматься учебнопрограммописательством. Ох, трудное это дело! Впрочем, а что у меня дело лёгкое?!

Зима наступила, Дед Лайны уже недалеко, поэтому существенно искажают пространство-время. Нам бы ещё ночь простоять, да день продержаться. Слушаю джингл беллз на радио Пандора. Там уже давно праздник.