Системное мышление

Стандарт ISO 42010 даёт рекомендации о том, как думать о (полном) описании системы. Сам стандарт говорит только об архитектурном описании, но его положения вполне применимы к любым описаниям. Вот задающее мышление об описаниях системы диаграмма из этого стандарта, модифицированная с использованием положений OMG Essence (Рис. 3).

Диаграмма начинается с уже знакомого нам различения воплощения (realization) и определения (definition) системы.

Каждая связь между объектами этой диаграммы может быть прочтена в двух направлениях: «воплощение системы удовлетворяет определению системы», «определение системы характеризует определение системы». «Определение системы выражается описанием системы», «описание системы документирует определение системы».

Для простоты диаграммы многие связи приведены только с одним наименованием связи, но это не значит, что не существует обратного отношения. Это общее свойство всех подобных схем: даже отношение «часть-целое» в одном направлении читается «включает_в_себя», в другом направлении читается «является_частью».

Вот схема на английском языке:

(Полное) описание системы (system description) состоит из частных описаний системы (view) – рабочих продуктов, которые отражают частные определения системы (на диаграмме не показаны).

Частные определения системы – это как раз требования, архитектура, неархитектурные части дизайна, данные об эксплуатации: всё что угодно, что определяет интересные для стейкхолдера ипостаси/аспекты системы. Определения системы – функциональные объекты, описания системы – рабочие продукты.

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

На диаграмме чётко видно, что частное описание отвечает на вопросы стейкхолдера, а именно на вопросы какого-то стейкхолдерского интереса. Помним, что интерес – это та тема, которая интересна стейкхолдеру для его деятельности, стейкхолдер может иметь и несколько интересов. Частное описание системы позволяет описать систему так, чтобы поддержать разговор со стейкхолдером на тему его интереса, ответить на интересующие его вопросы.

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

В английском тексте view означает как частное (то есть удовлетворяющее один или несколько, но не все стейкхолдерские интересы) определение системы, так и частное описание системы, воплощающее в рабочем продукте это частное определение. По-русски это тоже путается в переводе: «частное описание системы» или «частное определение системы» используется в обоих значениях. Предполагается, что читатель сам разберётся в каждом конкретном случае, идёт ли речь о рабочем продукте или об альфе. В ISO 42010, например, view – это именно рабочие продукты (какие-то документы, возможно электронные).

Более того, полное описание системы встречается в жизни довольно редко, много чаще встречаются частные описания системы. Поэтому view обычно переводится как «описание» – и при этом подразумевается его частичность, отражаемая на диаграмме стрелочкой с ромбиком на конце полного описания.

Какие бывают описания (view)? Прежде всего, можно выделить функциональные/компонентные описания, конструктивные/модульные описания, описания размещения. Но кроме этого может быть огромное количество описаний, интересующих самых разных стейкхолдеров: например, финансовое, синхронизации во времени, структуры владения, информационных потоков и т. д. Чем сложней система, тем бо́льшего количества (частных, на какую-то одну тему) описаний можно ожидать.

Модели и виды моделей