Слон -- сложная система (напомню, что "сложная" система это не такая, в которой всё от всего зависит, а такая, в которой все эти зависимости заведомо не помещаются в человеческую голову и нужно придумывать разные способы описания, удерживающие работоспособное целое). Слона создают по интересу (concern) за раз -- это принцип разделения интересов (separation of concerns), сформулированный Dijkstra (http://en.wikipedia.org/wiki/Separation_of_concerns). Краткая суть этого принципа: обо всём нужно думать по отдельности, сразу обо всём думать не получится. Чтобы властвовать над определением системы, надо его разделять.
Все определения системы (альфы -- требования, архитектура и т.д.) и связанные с этими определениями описания (спецификации требований, архитектурные диаграммы и т.д.) как раз отражают этот принцип. Каждое действующее лицо (stakeholder) имеет какой-то интерес к системе, и его поэтому интересует про систему не всё, что можно, а только то, что ему нужно. По одному интересу за раз, и так пока не удовлетворим всех стейкхолдеров.
Это суть системного подхода, системноинженерного мышления:
-- системные холархии (матрёшки из холонов -- части и целые). Нет целого без частей, нет частей без целого.
-- каждое действующее лицо интересуется чем-то своим, что важно для его действия. "Система в глазах смотрящего" (вернее, действующего): деятельностный подход.
-- определение системы множественно по своей природе, его составляющие необходимы для удовлетворения разных интересов разных действующих лиц.
-- описаний системы ещё больше (в какой-то презентации по OMG Essence указывается, что сжатие информации при переходе к обсуждению в "альфах" по сравнению с обсуждением в "рабочих продуктах" составляет 1:10 -- о состоянии альфы мы узнаём подробности по десятку рабочих продуктов).
-- все эти определения и описания создаются (изменяются, эволюционируют) в ходе жизненного цикла системы.
Похоже, что минимальный набор более-менее концептуально совместимых международных стандартов современного системноинженерного мышления таков:
-- обобщенный с архитектурного описания до описания определения системы ISO 42010: множественность описаний и деятельностный подход. Это "поворот мозгов" от редукционистского подхода одного всеохватного описания к системному подходу, подразумевающему множественность связанных описаний.
-- обобщенный с программной до системной инженерии OMG Essence: описание жизненного цикла (системноинженерный менеджмент). Метод контрольных вопросов в управлении жизненным циклом.
-- ISO 81346 для минималистичного описания и именований. Это фундамент для управления конфигурацией системы.
-- ISO 15926 для моделирования данных развёрнутых описаний. Обеспечивает федерирование развёрнутых описаний.
Этот небольшой набор стандартов и нужно гармонизировать, на этой основе и нужно создавать учебные курсы, на этой основе и нужно консультировать предприятия. Забавно, что тусовки (community of practice) вокруг этих стандартов очень мало знают друг о друге -- несмотря на всю идейную их близость.
Я писал тут про все эти стандарты, кроме ISO 81346. Это относительно свежий стандарт, 2009 года.
Стандарт ISO 81346 претендует на роль самого минималистичного метода описания системы. В нём определены принципы создания системы справочных обозначений (reference designation system, RDS -- слово "система" тут означает "систематичность", а не целевую систему) целевой системы. Эта система справочных обозначений отражает самое существенное в основных трёх стилях (function, product, location): имена объектов и их место в холархии (разбиения, т.е. отношения "композиции" или "часть-целое"). Функция, конструкция и размещение (модули, компоненты и места; функции, продукты и места: эта основная троица в разных школах обсуждается под разными именами) отражают основные, хотя и не все, стили определения инженерной системы. Подробно этот вопрос разбирается в программной инженерии (например, я упоминал книжку http://libgen.org/get?nametype=orig&md5=abb4676b7b1ddfa74e33b7799ebbb61a -- на неё, в частности, ссылается ISO 42010). Но ISO 81346 в минималистичном варианте проводит эту мысль и для "железных" систем. Неправильно понимать этот стандарт как "принципы создания кодировок", не в кодировке/именовании дело. Это именно стандарт принципов минималистичного описания инженерной системы.
Главное достоинство этого стандарта в том, что в предлагаемых им описаниях выкидывается 99.9% информации о системе, но оставшиеся 0.1% (только имена объектов и отношения "часть-целое") оказываются крайне полезны. Вот тут можно почитать об этом стандарте подробнее: http://81346.com/english/?page_id=117.
Схема метро приводится в объяснительных материалах к этому стандарту как пример того, как радикальное упрощение описания системы резко повышает его полезность. Всем знакомая "схема метро" впервые была придумана в 1931 году (http://en.wikipedia.org/wiki/Tube_map, http://en.wikipedia.org/wiki/Harry_Beck и чудесные фильмы краткий http://www.youtube.com/watch?v=Bg3pfUqdLp4 и длинный http://www.youtube.com/watch?v=1xmOpyv5NuI). Автор схемы метро заметил: расстояния и длины не важны (по большей части), направления неважны (по большей части), пересадки важны. Один аспект, один интерес, одно описание за раз. Схема московского метро отражает сегодня те же принципы (http://metro.yandex.ru/moscow/). Вот краткое видео, подчёркивающее ту же мысль: важность бедных информацией представлений -- http://www.youtube.com/watch?v=W4A1Dnlv8h0
