Вступление

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

Но всё это будет возможно в полной мере только при условии, что сначала был сделан правильный выбор, а потом мы не остановились на полпути.

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

Кейс 1. Диаграмма состояний: достаточно одной таблетки

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

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

Так вот. В ходе обсуждения задачи вырабатывается подход, согласно которому информационные системы, вовлечённые в обработку, будут отправлять сообщения проектируемой системе мониторинга, а она уже будет «понимать» текущее состояние. Но тут вскрываются особенности:

1. процесс оформления может проходить через несколько подразделений (в том числе с подключением специалистов);

2. процесс оформления может проходить через 2 разные компании (случай, когда одна компания у себя в приложении или на сайте предлагает продукты другой компании, входящей в ту же экосистему);

3. специалисты разных компаний и применяемые в них информационные системы могут оперировать разными понятиями и сущностями, требующими свои этапы обработки.

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

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

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

При таком варианте решения потребуется разработать 2 статусные модели в виде отдельных диаграмм состояния UML (она же — диаграмма конечных автоматов, Statechart Diagram), которые будут описывать стадии жизненного цикла для сущностей «Заявка» и «Договор». Также понадобится сформировать таблицу соответствий: статус заявки такой-то соответствует статусу договора такому-то.

При этом, наверняка так случится, что одному статусу сущности «Заявка» будет соответствовать сразу несколько статусов сущности «Договор». К примеру, для состояния «Заявка доставлена» будет подходить длинный перечень состояний «Договора»: «Договор создан», «Договор оплачен», «Договор открыт» и т.д. Более того, состояние «Заявка доставлена» вообще не гарантирует того, что сущность «Договор» была создана (вторая компания могла принять запрос на открытие договора, но по какому-то трагическому стечению обстоятельств так этого и не сделала).

Кажется, что описанный подход не выглядит удачным. Причина в том, что поддержание в проектируемой системе одновременно 2-х статусных моделей из внешних систем и правил соответствий между ними приводит к потере наглядности модели в целом и потенциально может повлечь ошибки.

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

В силу указанных недостатков был выбран иной подход. Было решено разработать для системы мониторинга свою собственную статусную модель. Для этих целей была проработана диаграмма состояний, на базе которой будет реализовываться вся дальнейшая логика. Фактически эта модель получается синтезом из 2-х моделей таким образом, чтобы каждое её состояние имело однозначное отображение в реальное состояние хотя бы одной из исходных моделей.

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

Что мы сделали необычного? Если почитать определения, которые даются различными авторами диаграмме состояний, то везде будет сказано примерно одно и то же: что эта диаграмма представляет динамическое поведение индивидуальной сущности, системы или элементов системы; что эта диаграмма позволяет описать состояния объекта и переходы между ними. В нашем же случае мы применили эту диаграмму для описания сразу двух сущностей…

Нарушили ли мы принципы, заложенные авторами UML? Уверен, что нет. Наши действия формально равносильны тому, что мы для проектируемой системы ввели в рассмотрение некую свою сущность «Процесс» (хотя и представляющую одновременно несколько логически связанных сущностей реального мира), и с помощью диаграммы состояний смоделировали её поведение.

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

Кейс 2. Диаграмма коммуникации и вариантов использования: вам курицу или рыбу?

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

Далее вы выясняете, что бухгалтерский учёт всех сделок и операций по счетам должен вестись в единой системе — АБС. И сделки из используемой трейдерами системы (назовём её «Торговая система А») загружаются в АБС, используя промежуточное звено в виде некоторого хранилища. Через некоторое время вы узнаёте ви́дение бизнеса — притом высокоуровневое! — относительно того, что́ такое лимит на операции. И из этого ви́дения и полученных вводных проистекает необходимость проработать комплексное интеграционное решение, а не отдельный изолированный модуль.

Итого, мы до конца не понимаем ситуацию «как есть», то есть то, как и из каких систем складывается текущая схема автоматизации. А ведь нам нужно в этот зоопарк подселить ещё одну «зверушку» (назовём её «Торговая система Б»). Из этих соображений следует необходимость повнимательнее разобраться с архитектурой. А раз так, то выберем для этого подходящее средство визуализации.

Чтобы не утонуть во всём многообразии выбора и заодно проиллюстрировать метод, воспользуемся метадеревом, описанным в ранее опубликованной статье.

Что рассматриваем? Информационную систему. Что именно? Архитектуру. Какая точка зрения нам нужна? Это точно не отдельная система, т.к. в текущей ситуации у нас нет явной «точки притяжения» (более того, мы даже пока не можем сделать осознанного выбора, где физически и в каком виде будет реализовываться управление лимитами).

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

Исходя из личных предпочтений остановимся на диаграмме коммуникации UML (Communication Diagram).

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

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

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

В последней представленной версии, как можно видеть, был изменён принцип загрузки сделок из Торговой системы Б, а также появились новые детали.

На этом моменте процесс уточнения диаграммы предлагаю остановить и сосредоточиться на значимых для работы аналитика фактах.

Во-первых, связи и сообщения на диаграмме коммуникации крайне полезны; они, как пункты чек-листа, помогают в выявлении функциональных требований. Объясняется это тем, что каждое сообщение на схеме визуализирует существование функциональной зависимости, а значит добавление на схему нового объекта, сообщения или связи потенциально может повлиять на все ранее сложившиеся зависимости.

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

В-третьих, несмотря на то, что на последней диаграмме были пронумерованы сообщения, надо понимать, что чёткой хронологии здесь нет. И это обстоятельство является достоинством, а не недостатком. В отличие от диаграммы последовательности, которая в общем случае предполагает строгую очерёдность выполнения шагов, в рассматриваемом кейсе многие события развиваются во времени независимо и параллельно. Соответственно, если бы мы пытались это визуализировать с помощью диаграммы последовательности, то получился бы либо набор из нескольких диаграмм, описывающих отдельные цепочки взаимодействия, существующие в рамках схемы автоматизации (а значит увидеть картину целиком было бы затруднительно), либо, в худшем случае, у нас появилась бы единая диаграмма с «мешаниной», которая привела бы к неправильному представлению ситуации в целом, что в конечном итоге могло бы привести к ошибкам в проектировании.

А что если?..

Давайте теперь зададимся вопросом: что было бы, если бы мы при выборе средства визуализации пошли по иному пути? Так как границы применимости диаграмм последовательности мы уже рассмотрели чуть ранее, выберем другой вариант. Пусть это будет диаграмма вариантов использования UML (она же — диаграмма прецедентов, Use Case Diagram).

Для такого выбора у нас даже будет обоснование. Как отмечается в довольно популярной книге по UML, «исходной моделью, с которой начинается процесс моделирования в нотации UML, является модель или диаграмма вариантов использования» (Леоненков А.В. Самоучитель UML 2 СПб.: БХВ-Петербург, 2007).

Утверждение звучит разумно, однако для нашей задачи данный вид диаграмм, если бы мы на нём реально остановили свой выбор, мог бы не показать себя с лучшей стороны. Причина в том, что был бы высок риск того, что мы бы сместили акцент на функциональные требования и на проектирование конкретного функционала по управления лимитами; у нас был бы эктор и основной вариант использования отвечал бы за установку лимита.

В таком случае мы бы вовремя не увидели систем, которые влияют на разрабатываемый функционал управления лимитами; мы были бы в неведении относительно того, что за границами системы у нас существуют две другие, причём со своими пользователями, а также хранилище и обусловленные законодательством взаимодействия. Мы бы потеряли довольно широкий системный контекст.

Но, может, если бы мы увеличили число деталей на диаграмме вариантов использования, то это бы повысило полезность? Коль скоро лимиты должны влиять на возможность заключения сделок клиентов, давайте попробуем добавить на диаграмму Торговую систему Б в качестве ещё одного эктора.

Что видим? Такое добавление может только запутать, так как для многих читающих диаграмму эктор — это, прежде всего, человек (да он и выглядит соответствующе!). А значит, в какой момент мы бы реально смогли перекинуть мост через пропасть, отделяющую немногословную диаграмму вариантов использования от разумного решения, сказать трудно.

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

Но что если бы мы оставили одну диаграмму, но попытались поместить на неё действия, выполняемые в различных системах, не взирая на то, что так, вообще говоря, обычно никто не делает? Быть может, это бы помогло увидеть картину в целом? Давайте проверять.

Для начала попробуем разместить все варианты использования внутри единых границ системы (прямоугольника на схеме), притворившись, что вся схема автоматизация воспринимается нами как единая система. В результате получим диаграмму, которая уже начинает проливать свет на выполняемые операции, участников и на то, как в этот процесс будет встраиваться проектируемый функционал.

Но что если пойти ещё дальше и разместить на диаграмме границы участвующих в автоматизации систем, а потом локализовать варианты использования (овалы на схеме) внутри реально существующих систем? Должно получиться что-то такое.

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

1. Для повышения полезности диаграммы вариантов использования пришлось прибегнуть к ряду действий, которые могут показаться спорными, а именно:

   • сначала мы включили в границы «системы» весь задействованный функционал;

   • далее мы вообще изобразили сразу несколько систем на одной диаграмме, показали отношения между вариантами использования, относящимися к разным системам,

   • а также ввели эктора Time, который почему-то до сих пор не снискал всеобщего признания среди аналитиков.

2. В отличие от канонической диаграммы вариантов использования с полученной нами диаграммой уже можно работать, т.к. она содержит множество полезных деталей о контексте.

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

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

Заключение

Давайте кратко зафиксируем основные выводы.

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

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

3. Иногда бывает полезным отходить от шаблонных практик и подходов, если это помогает стимулировать поиски более эффективного решения, а также позволяет разрабатывать более прозрачные модели и более надёжные информационные системы. В данной статье мы видели реальные кейсы, когда это действительно имело смысл.