Система, функция, требования, конструкция, архитектура
Система представляет собой единство функции, конструкции, процесса и множества других групп описаний. Фишка в том, чтобы научиться разговаривать в этой терминологии и профессионализироваться в тех или иных системных рассмотрениях. Я рассказывал и писал об этом много раз, этот постинг лишь собирает разные детальки, раскиданные по другим местам. Вполне может быть, что у кого-то чтение этого текста вызовет долгожданное "Ага!" по поводу системной инженерии и системного подхода.
Система всегда в глазах смотрящего: она определяется границей, которую проводит тот, кто определяет (иногда для себя, иногда для других) назначение системы. Назначение -- это те функции, которые система выполняет для объемлющей системы в качестве элемента конструкции объемлющей системы.
Системы именуются по их основному назначению. Стакан ("Стеклянный сосуд цилиндрической формы, без ручки, служащий для питья", как пишется в толковых словарях) остаётся стаканом, даже если мой дитёнка использует его для хранения сломанных карандашей и ручек. Конечно, любое другое назначение задаёт другие свойства. Так, дырочка в боку пластмассового стакана для карандашей, отсутствие стекла и даже мысли о том, чтобы из такого стакана пить, задаёт совсем другую систему. Но основные свойства (узкая цилиндрическая тонкостенная форма, удобная для назначения "хранение чего-то внутри") остаются, и имя это чётко фиксирует. Перевернутый стакан обычно стаканом уже не называют -- это может быть "подставка", "опора". В любом случае, название назначением, а оно обычно не в словарях и таксономиях, а определяется деятелем, который выделяет эту систему из месива самых разных объектов окружающей среды.
Назначение всегда связано с функцией, возможностью выполнять какую-то роль по отношению к объемлющей системе. Начальник -- это тот, кто выполняет распорядительные функции (его назначение -- распоряжаться) с точки зрения окружения -- подчиненных этого начальника. Внутреннее устройство начальника тут неважно, а вот его функция/назначение -- важно. Начальника-как-систему определяет это назначение, а не "коллегиальное устройство" (например, начальник-как-Правление-из-пятерых-избранных) или "реализация одним человеком". Аэропорт имеет функции по обеспечению приёма и отправки самолётов, если рассматривать его в разных обеспечивающих системах. Этот же аэропорт -- это просто какие-то циклопические сооружения, если объемлющая система не интересуется самолётами.
Требования к системе -- это функциональное описание системы, в деонтической модальности. Другими словами, требования -- это описание функций целевой-системы-как-элемента в конструкции имеющей другие элементы-системы объемлющей надсистемы, причем это описание задано в терминах долженствования и дозволения. Инженер по требованиям отвечает за то, чтобы согласовать такое описание у всех тех заинтересованных сторон, надсистемы которых затрагиваются целевой системой. Если одна заинтересованная сторона в моём доме считает функцией музыкальной системы воспроизведение на максимальной громкости хард-рока, то другая заинтересованная сторона требует от этой же системы полной бесшумности воспроизведения чего бы то ни было, а тяжелого рока в особенности. Инженер по требованиям должен разобраться и сформулировать такие функции, которые удовлетворят все заинтересованные стороны (заметим, что это может включать изменение не только самих требований, но и изменение самих заинтересованных сторон!).
Функциональное описание -- это описание "черного ящика". Я не знаю, как устроена моя музыкальная система, но тяжелый рок она играет. Я не знаю, как устроен аэропорт, это для меня "черный ящик", но самолёты улетают и прилетают -- и часто это происходит вОвремя. Описание "черного ящика" крайне важно для тех людей, которые используют систему. Автомобиль содержит в себе следующие "функциональные системы": двигательную, осветительную, климатическую, безопасности при столкновениях. Ремонтнику это описание не поможет: ему нужно описание "белого ящика", в терминах которого можно описать отвинчиваемые и привинчиваемые части -- конструкцию из составляющих систему элементов. Шасси, фара, кабель -- вот описание автомобиля как "белого ящика".
Описание конструкции целевой системы из составляющих ее элементов обязательно, если речь идет об инжиниринге, о создании системы. Стакан может быть из глины, музыкальная система включать не только аппаратуру, но и плотно закрывающуюся дверь в комнату с этой аппаратурой. Система, которая определяется своей функцией, может иметь разные альтернативные конструкции. Стакан может быть складным из пластмассы, музыкальная система реализована как плеер с наушниками. Аэропортом для Руста оказался Васильевский Спуск. Впрочем, и для одной и той же конструкции вполне возможны разные функции. Стакан используется в качестве пресс-папье, чтобы бумаги не унесло ветром. Музыкальная система служит столиком для полупустых после вчерашней пьянки стаканов. Васильевский Спуск служит местом установки музыкальной системы для концерта под открытым небом.
За описание конструкции отвечают инженеры по специальностям: инженеры-механики, инженеры-теплотехники, инженеры-акустики, инженеры-электрики. Они хорошо знают своё дело, конструкция будет великолепна. Проблема в том, насколько конструкция системы позволит реализовать требуемые функции, и как объяснить инженерам по специальностям, что они должны сообща сделать, чтобы собранные вместе результаты их конструкторской работы позволили реализовать оговоренные в требованиях функции.
Функция и конструкция принципиально различны, и не могут быть выражены друг через друга напрямую. Катушка громкоговорителя никак не выражается через музыку, в воспроизведении которой она участвует. И наоборот, музыку нельзя выразить через движение катушки громкоговорителя. Но это не значит, что конструкция не связана с функцией! Связана, конечно -- ибо функция и конструкция представляют собой разные аспекты одной и той же системы. Связь функции и конструкции называется архитектурой. Архитектура у системы есть всегда, ибо функция и конструкция всегда связаны. Правда, архитектура может быть не описана.
Описания функции и конструкции могут быть связаны между собой посредством особого сорта артефакта (рабочего продукта): архитектурного описания. Архитектурное описание представляет собой набор моделей, как раз и описывающих связь функции системы и ее конструкции из составляющих конструктивных элементов. Ответственный за разработку архитектуры и выражение её в архитектурном описании -- системный инженер.
Итого, есть три основных позиции, которые участвуют в определении системы (system definition, нисходящая часть V-диаграммы жизненного цикла: проектирование, вплоть до начала воплощения элементов системы "в металле, коде, бетоне"): две позиции системного инженера (инженер по требованиям согласует функции, архитектор делает архитектурное описание) и множество позиций инженеров по специальностям, занимающихся отдельными элементами конструкции. Целостность элементов конструкции обеспечивает архитектор, целостность функций -- инженер по требованиям.
Одним из ключевых элементов описания конструкции служат интерфейсы: интерфейсы показывают, как функционально связаны между собой элементы конструкции системы (ибо каждый конструктивный элемент целевой системы -- система сама по себе, и в нём тоже можно выделить его функцию-назначение и конструкцию-материал).
Используем "модель гамбургера" из Wim Gielingh et al. (http://15926.info/functional-physical-object/GARM-paper.pdf -- на этой работе основаны и ISO 15926, и Gellish, и BIM) для представления функции и конструкции:
Эта картинка "модели гамбургера" взята из http://15926.info/functional-physical-object/index.htm):
Functional Unit -- это как раз система, как ее назначение, функция в объемлющей надсистеме. Technical Solution -- это ее конструкция, разбиение общего функционального описания на взаимодействующие через интерфейсы элементы.
Такое "гамбургерное" описание задаёт иерархию архитектурной (функционально/конструктивной) декомпозиции, иными словами -- даёт решение модульности (ибо помним: для каждой заданной функции элемента на любом уровне конструктивной иерархии мы можем иметь альтернативные технические решения, альтернативные конструкции).
Для подробного разбирательства с вопросом -- читайте материалы по приведенным ссылкам, имея при этом ввиду:
-- функция и конструкция связываются через модели. Моделеориентированная системная инженерия -- это как раз использование связного набора таких моделей. Архитектурные языки позволяют выражать необходимое разнообразие моделей, и задавать модульность системы.
-- все использованные слова являются омонимами, и легко запутываться, ежели придерживаться жесткой связи между словами и их определениями. Так, слово "функция" в инженерном деле имеет пять разных значений (онтологически слово "функция" используется для обозначения 1. подтипа активности -- процесса или события, 2. какой-то сущности в определенной роли или сделанной для определенной роли, 3. самой роли сущности, обычно в физической вещи, которую эта вещь играет в активности, 4. указания на связь, например корреляция между какими-то аспектами -- ежели высота растёт, то давление падает, 5. математическое отношение между числовыми объектами, определяющее их соотнесение/mapping. Подробнее -- со стр. 79 тут: http://repository.tudelft.nl/assets/uuid:de26132b-6f03-41b9-b882-c74b7e34a07d/its_renssen_20050914.pdf).
Тут очень важно, что "функция" часто связана с какой-то активностью/процессом: описание системы как структуры из конструктивных элементов обычно недостаточно, функциональное описание оказывается тесно связанным с процессными описаниями. Все эти "слова верхнего уровня" крайне абстрактны, поэтому скользки в их употреблении, будьте внимательны!
-- большинство описаний методов системной инженерии не касаются описаний того, что именно делают инженер по требованиям и системный архитектор, и почему они оба -- системные инженеры, а не инженеры по специальности (specialty engineers). Тем не менее, описание метода должно включать и организацию работы (акторов и их инструменты), а не только разбирательство с рабочими продуктами, практиками работы с ними и языками для выражения моделей этих продуктов работы. Можно порекомендовать ознакомиться с MFESA в качестве примеров такого описания: http://www.sei.cmu.edu/library/assets/030509webinar1.pdf (а если заглянуть в library.nu, то можно и всю книжку найти).
-- дискуссия по разделению FunctionalPhysicalObject и PhysicalObject как отражение разницы между "функцией и конструкцией" в сообществе ISO 15926 далеко не закончена. Вы встретитесь с 4D экстенсионализмом во всей его красе и сложности. Отголоски этой дискуссии вы найдёте также в обсуждении "дизайна в классах" (например, http://15926.info/plant-design-using-classes/index.htm). Это связано, в том числе и с тем, что по ходу инженерной разработки функциональные и конструктивные описания, а также связывающие их модели появляются не в строгой последовательности. Более того, "дизайн в классах" сразу предполагает, что "классы могут меняться" по мере продвижения в определении системы, и это даёт дополнительные сложности для онтологического моделирования архитектуры: архитектурное описание само имеет жизненный цикл, как отдельный артефакт, и само устроено сложным образом (у архитектурного описания, как системы, есть свои функция, конструкция, жизненный цикл).
-- про "белый ящик", "черный ящик" и архитектуру хорошо написано в описании DEMO (см. книжку "Enterprise ontology: theory and methodology" by Jan Dietz в той же library.nu). Всё сказанное относится и к организациям, а не только к "железным" или программным системам: организации, как обеспечивающие системы -- это тоже системы, и их нужно как-то определять и воплощать. Тем не менее, при попытках тупо использовать этот архитектурный подход для "систем из человеков", мы немедленно сталкиваемся с подходом "система систем" (http://ailev.livejournal.com/869585.html, http://ailev.livejournal.com/856576.html): люди очень не любят, когда кто-то (а хоть даже и начальство) определяет их функции, а затем вставляет их как элементы в конструкцию системы-организации.
Система всегда в глазах смотрящего: она определяется границей, которую проводит тот, кто определяет (иногда для себя, иногда для других) назначение системы. Назначение -- это те функции, которые система выполняет для объемлющей системы в качестве элемента конструкции объемлющей системы.
Системы именуются по их основному назначению. Стакан ("Стеклянный сосуд цилиндрической формы, без ручки, служащий для питья", как пишется в толковых словарях) остаётся стаканом, даже если мой дитёнка использует его для хранения сломанных карандашей и ручек. Конечно, любое другое назначение задаёт другие свойства. Так, дырочка в боку пластмассового стакана для карандашей, отсутствие стекла и даже мысли о том, чтобы из такого стакана пить, задаёт совсем другую систему. Но основные свойства (узкая цилиндрическая тонкостенная форма, удобная для назначения "хранение чего-то внутри") остаются, и имя это чётко фиксирует. Перевернутый стакан обычно стаканом уже не называют -- это может быть "подставка", "опора". В любом случае, название назначением, а оно обычно не в словарях и таксономиях, а определяется деятелем, который выделяет эту систему из месива самых разных объектов окружающей среды.
Назначение всегда связано с функцией, возможностью выполнять какую-то роль по отношению к объемлющей системе. Начальник -- это тот, кто выполняет распорядительные функции (его назначение -- распоряжаться) с точки зрения окружения -- подчиненных этого начальника. Внутреннее устройство начальника тут неважно, а вот его функция/назначение -- важно. Начальника-как-систему определяет это назначение, а не "коллегиальное устройство" (например, начальник-как-Правление-из-пятерых-избранных) или "реализация одним человеком". Аэропорт имеет функции по обеспечению приёма и отправки самолётов, если рассматривать его в разных обеспечивающих системах. Этот же аэропорт -- это просто какие-то циклопические сооружения, если объемлющая система не интересуется самолётами.
Требования к системе -- это функциональное описание системы, в деонтической модальности. Другими словами, требования -- это описание функций целевой-системы-как-элемента в конструкции имеющей другие элементы-системы объемлющей надсистемы, причем это описание задано в терминах долженствования и дозволения. Инженер по требованиям отвечает за то, чтобы согласовать такое описание у всех тех заинтересованных сторон, надсистемы которых затрагиваются целевой системой. Если одна заинтересованная сторона в моём доме считает функцией музыкальной системы воспроизведение на максимальной громкости хард-рока, то другая заинтересованная сторона требует от этой же системы полной бесшумности воспроизведения чего бы то ни было, а тяжелого рока в особенности. Инженер по требованиям должен разобраться и сформулировать такие функции, которые удовлетворят все заинтересованные стороны (заметим, что это может включать изменение не только самих требований, но и изменение самих заинтересованных сторон!).
Функциональное описание -- это описание "черного ящика". Я не знаю, как устроена моя музыкальная система, но тяжелый рок она играет. Я не знаю, как устроен аэропорт, это для меня "черный ящик", но самолёты улетают и прилетают -- и часто это происходит вОвремя. Описание "черного ящика" крайне важно для тех людей, которые используют систему. Автомобиль содержит в себе следующие "функциональные системы": двигательную, осветительную, климатическую, безопасности при столкновениях. Ремонтнику это описание не поможет: ему нужно описание "белого ящика", в терминах которого можно описать отвинчиваемые и привинчиваемые части -- конструкцию из составляющих систему элементов. Шасси, фара, кабель -- вот описание автомобиля как "белого ящика".
Описание конструкции целевой системы из составляющих ее элементов обязательно, если речь идет об инжиниринге, о создании системы. Стакан может быть из глины, музыкальная система включать не только аппаратуру, но и плотно закрывающуюся дверь в комнату с этой аппаратурой. Система, которая определяется своей функцией, может иметь разные альтернативные конструкции. Стакан может быть складным из пластмассы, музыкальная система реализована как плеер с наушниками. Аэропортом для Руста оказался Васильевский Спуск. Впрочем, и для одной и той же конструкции вполне возможны разные функции. Стакан используется в качестве пресс-папье, чтобы бумаги не унесло ветром. Музыкальная система служит столиком для полупустых после вчерашней пьянки стаканов. Васильевский Спуск служит местом установки музыкальной системы для концерта под открытым небом.
За описание конструкции отвечают инженеры по специальностям: инженеры-механики, инженеры-теплотехники, инженеры-акустики, инженеры-электрики. Они хорошо знают своё дело, конструкция будет великолепна. Проблема в том, насколько конструкция системы позволит реализовать требуемые функции, и как объяснить инженерам по специальностям, что они должны сообща сделать, чтобы собранные вместе результаты их конструкторской работы позволили реализовать оговоренные в требованиях функции.
Функция и конструкция принципиально различны, и не могут быть выражены друг через друга напрямую. Катушка громкоговорителя никак не выражается через музыку, в воспроизведении которой она участвует. И наоборот, музыку нельзя выразить через движение катушки громкоговорителя. Но это не значит, что конструкция не связана с функцией! Связана, конечно -- ибо функция и конструкция представляют собой разные аспекты одной и той же системы. Связь функции и конструкции называется архитектурой. Архитектура у системы есть всегда, ибо функция и конструкция всегда связаны. Правда, архитектура может быть не описана.
Описания функции и конструкции могут быть связаны между собой посредством особого сорта артефакта (рабочего продукта): архитектурного описания. Архитектурное описание представляет собой набор моделей, как раз и описывающих связь функции системы и ее конструкции из составляющих конструктивных элементов. Ответственный за разработку архитектуры и выражение её в архитектурном описании -- системный инженер.
Итого, есть три основных позиции, которые участвуют в определении системы (system definition, нисходящая часть V-диаграммы жизненного цикла: проектирование, вплоть до начала воплощения элементов системы "в металле, коде, бетоне"): две позиции системного инженера (инженер по требованиям согласует функции, архитектор делает архитектурное описание) и множество позиций инженеров по специальностям, занимающихся отдельными элементами конструкции. Целостность элементов конструкции обеспечивает архитектор, целостность функций -- инженер по требованиям.
Одним из ключевых элементов описания конструкции служат интерфейсы: интерфейсы показывают, как функционально связаны между собой элементы конструкции системы (ибо каждый конструктивный элемент целевой системы -- система сама по себе, и в нём тоже можно выделить его функцию-назначение и конструкцию-материал).
Используем "модель гамбургера" из Wim Gielingh et al. (http://15926.info/functional-physical-object/GARM-paper.pdf -- на этой работе основаны и ISO 15926, и Gellish, и BIM) для представления функции и конструкции:
Эта картинка "модели гамбургера" взята из http://15926.info/functional-physical-object/index.htm):
Functional Unit -- это как раз система, как ее назначение, функция в объемлющей надсистеме. Technical Solution -- это ее конструкция, разбиение общего функционального описания на взаимодействующие через интерфейсы элементы.
Такое "гамбургерное" описание задаёт иерархию архитектурной (функционально/конструктивной) декомпозиции, иными словами -- даёт решение модульности (ибо помним: для каждой заданной функции элемента на любом уровне конструктивной иерархии мы можем иметь альтернативные технические решения, альтернативные конструкции).
Для подробного разбирательства с вопросом -- читайте материалы по приведенным ссылкам, имея при этом ввиду:
-- функция и конструкция связываются через модели. Моделеориентированная системная инженерия -- это как раз использование связного набора таких моделей. Архитектурные языки позволяют выражать необходимое разнообразие моделей, и задавать модульность системы.
-- все использованные слова являются омонимами, и легко запутываться, ежели придерживаться жесткой связи между словами и их определениями. Так, слово "функция" в инженерном деле имеет пять разных значений (онтологически слово "функция" используется для обозначения 1. подтипа активности -- процесса или события, 2. какой-то сущности в определенной роли или сделанной для определенной роли, 3. самой роли сущности, обычно в физической вещи, которую эта вещь играет в активности, 4. указания на связь, например корреляция между какими-то аспектами -- ежели высота растёт, то давление падает, 5. математическое отношение между числовыми объектами, определяющее их соотнесение/mapping. Подробнее -- со стр. 79 тут: http://repository.tudelft.nl/assets/uuid:de26132b-6f03-41b9-b882-c74b7e34a07d/its_renssen_20050914.pdf).
Тут очень важно, что "функция" часто связана с какой-то активностью/процессом: описание системы как структуры из конструктивных элементов обычно недостаточно, функциональное описание оказывается тесно связанным с процессными описаниями. Все эти "слова верхнего уровня" крайне абстрактны, поэтому скользки в их употреблении, будьте внимательны!
-- большинство описаний методов системной инженерии не касаются описаний того, что именно делают инженер по требованиям и системный архитектор, и почему они оба -- системные инженеры, а не инженеры по специальности (specialty engineers). Тем не менее, описание метода должно включать и организацию работы (акторов и их инструменты), а не только разбирательство с рабочими продуктами, практиками работы с ними и языками для выражения моделей этих продуктов работы. Можно порекомендовать ознакомиться с MFESA в качестве примеров такого описания: http://www.sei.cmu.edu/library/assets/030509webinar1.pdf (а если заглянуть в library.nu, то можно и всю книжку найти).
-- дискуссия по разделению FunctionalPhysicalObject и PhysicalObject как отражение разницы между "функцией и конструкцией" в сообществе ISO 15926 далеко не закончена. Вы встретитесь с 4D экстенсионализмом во всей его красе и сложности. Отголоски этой дискуссии вы найдёте также в обсуждении "дизайна в классах" (например, http://15926.info/plant-design-using-classes/index.htm). Это связано, в том числе и с тем, что по ходу инженерной разработки функциональные и конструктивные описания, а также связывающие их модели появляются не в строгой последовательности. Более того, "дизайн в классах" сразу предполагает, что "классы могут меняться" по мере продвижения в определении системы, и это даёт дополнительные сложности для онтологического моделирования архитектуры: архитектурное описание само имеет жизненный цикл, как отдельный артефакт, и само устроено сложным образом (у архитектурного описания, как системы, есть свои функция, конструкция, жизненный цикл).
-- про "белый ящик", "черный ящик" и архитектуру хорошо написано в описании DEMO (см. книжку "Enterprise ontology: theory and methodology" by Jan Dietz в той же library.nu). Всё сказанное относится и к организациям, а не только к "железным" или программным системам: организации, как обеспечивающие системы -- это тоже системы, и их нужно как-то определять и воплощать. Тем не менее, при попытках тупо использовать этот архитектурный подход для "систем из человеков", мы немедленно сталкиваемся с подходом "система систем" (http://ailev.livejournal.com/869585.html, http://ailev.livejournal.com/856576.html): люди очень не любят, когда кто-то (а хоть даже и начальство) определяет их функции, а затем вставляет их как элементы в конструкцию системы-организации.