Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

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

Существует бесчисленное множество разных видов описаний системы, которые нужны стейкхолдерам для удовлетворения их весьма и весьма разнообразных интересов к системе. Все эти описания порождаются (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. В принципе, этот текст по ссылке в какой-то мере предшественник настоящего поста). Так что меня волнует создание более-менее связного по терминологии обзора всех этих разных полезных идей, появляющихся в самой разной терминологии в самых разных практиках.

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

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

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 3 comments