Анатолий Левенчук - Системное мышление

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

Термин «определение системы» (system definition) тут нельзя путать со «словарным определением», типа «наша система – это то-то и то-то». Нет, это самая разная информация о воплощении системы, она включает и требования, и архитектуру, и неархитектурную часть проекта/design, так что одной фразой «определения из словаря» её не заменишь, тут совсем другое значение термина.

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

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

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

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

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

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

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

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

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

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

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

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

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

Само описание (view) состоит из множества отдельных моделей(models), которые можно трактовать как разные способы формального или неформального описания, отвечающие на ещё более частные вопросы. Например, полное описание системы включает в себя финансовое описание системы, но в финансовом описании можно выделить разные модели, нужные для ответа на разные вопросы интересующегося финансами стейкхолдера: баланс, отчёт о прибылях и убытках (profit and loss, P&L) и денежный поток (cash flow). Если у вас есть только баланс, то вы не ответите на вопрос о безубыточности работы предприятия, а если у вас отчёт о прибылях и убытках и даже баланс, то вы не сможете обсудить кассовый разрыв без наличия документов по денежному потоку. Одно описание, три разные модели.