семантическим и онтологическим описаниям

(http://en.wikipedia.org/wiki/Open_world_assumption — и обратите там внимание, что наш “стейкхолдер” заменён философским словом агент/agent — http://en.wikipedia.org/wiki/Agency_%28philosophy%29. Это не “наблюдатель”, а “деятель”, хотя предметом обсуждения и является тут “рассмотрение”, “наблюдение”, “описание”.

Два типа “целого”

Про то, как описывать систему, много подробней будет в следующем разделе. Сейчас нас волнует только то, как описывается воплощение системы как целое — но с учётом того факта, что разные люди видят даже это “целое” как ипостаси!

И тут нужно не путать два использования слово “целое” (единое, совокупное, целокупное и т.д.):

●По отношениям часть-целое (разбиения) — это когда система представляется состоящей из частей и сама является частью другой системы. Холархии, “зум” и “уровни рассмотрения” как уровни разбиения системы на части, эмерджентность от взаимодействия частей. Когда говорят о частях и целом, обычно имеют в виду воплощение системы.

●Целое, проявляющее себя в разных ипостасях, рассматриваемое разными стейкхолдерами по-разному — в системном подходе это “мультидисциплинарность”, объединение описаний, отсутствие редукционизма (сведения к одной дисциплине), холизм (та же “целостность”, но не про части! Про “разносторонность”!). Когда говорят о частных и целостных описаниях, то обычно имеют в виду определение системы (разные описания системы).

Не путайте эти две разных “целостности” системы.

Конечно, сам разговор о воплощении системы подразумевает какое-то описание этого воплощения — как минимум, описание самого воплощения: называние его по имени, учитывая какой-то аспект/ипостась. Именно поэтому, говоря в этом разделе про воплощение системы мы вынужденно касаемся и определения системы, её частей-подсистем и элементов, надсистемы, использующей системы, систем в операционном окружении, обеспечивающей системы и т.д. — как минимум, называние их с учётом аспекта/ипостаси.

Компоненты, модули, размещения

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

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

Теперь нужно разобраться, что такое компоненты, модули, размещения — типовые именно для инженерии ипостаси системы.

Компоненты

В современном русском языке компонента/компонент примерно одинаково по частоте употребляется как в женском роде, так и в мужском. Никакой нормы тут нет, так что не нужно обращать на это внимания: как привыкли писать и произносить, так и продолжайте. Вас поймут и не поругают.

Компоненты — это ипостаси системы, в которых она выполняет какую-то функцию (имеет какое-то назначение, предназначение) в составе надсистемы/использующей системы. Помним, о том, что слово “функция” имеет множество самых разных значений! Но чаще всего функция — это поведение (т.е. описывается глаголами или отглагольными существительными — “переноска”, “охлаждение”, “освещение”).

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

функционирования (run-time, operation).

Компоненты часто называют “компонеты и соединения” (components and connectors), ибо для показа связи компонент между собой используются соединения между портами (ports) компонент — и не путайте “соединения” с “интерфейсами” модулей. Диаграммы, показывающие соединения компонент друг с другом и удобные для объяснения принципа функционирования системы (”как работает система”), чаще всего называют “принципиальными схемами”:

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

Важно, что все эти "схемы" часто не предполагают какого-то сорта физического (продуктного, модульного) воплощения в материальном мире, это остаётся для

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

По принципиальным схемам чаще всего проводится мультифизическое моделирование: рассчитываются режимы работы, оптимальные характеристики отдельных компонентов и т.д.

Философски очень похоже, что компонента это “действующее лицо” в системе, а модули назначаются на соответствующие роли в качестве “исполнителей”. Поэтому замена какого-нибудь компонента-насоса на атомной станции, представленного модулем одного производителя на модуль другого производителя описыватся практически идентично замене президента Клинтона на Буша. Также принято говорить о компонентах не как о ролях, а как о реальных физических объектах.

В стандарте IEC 81346 принято давать обозначения компонентам (определяемым там как функциональный аспект объекта), начинающиеся с префикса = (таким образом сопротивление на радиосхеме может быть обозначено =R1).

Конечно, нужно помнить, что разные описания “гибридны” — люди на схемах вполне могут уточнить, что функция повышения давления жидкости реализуется модулем-насосом, а не перепадом высот и модулем-жёлобом, или даже явно указать марку и технические характеристики оборудования, которое нужно закупить!

Модули

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

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

Модули связываются друг с другом через “интерфейсы”, которые прежде всего рассматриваются с точки зрения их “видимости” (доступности для подключения модулей друг к другу). Зависимый модуль имеет слот для подключения того “низкоуровневого” модуля, от которого он зависит.