Вступление
Обработка доступной информации является неотъемлемой частью процесса проектирования информационных систем. При этом, форма представления информации напрямую влияет на успешность её восприятия и анализа, а значит, сказывается на эффективности процесса в целом.
Из этого тезиса можно было бы сделать очевидный вывод: надо представлять информацию в правильном виде, а в неправильном — не надо. Однако, выбор наиболее подходящего средства визуализации не всегда является простой задачей.
Причина, как мне видится, состоит в том, что уровень интереса к этому вопросу со стороны авторов публикаций продолжает оставаться низким. И, в результате, аналитикам порой приходится действовать методом проб и ошибок.
В данной статье я попытался заполнить этот пробел и предложить своё видение решения.
Как всё начиналось, или деревья растут для всех
Представленная выше характеристика состояния дел с выбором средств визуализации была во многом справедлива и в моём случае, пока я не столкнулся с одной из задач (более подробно — в статье). В ходе её решения оказалось, что ранее успешно применяемый подход к визуализации «захлёбывается», требует всё большего и большего вовлечения умственных усилий экспертов предметной области и других участников процесса.
И вот, некоторое время спустя, я сформировал дерево решений, которое может помочь аналитику с выбором подходящего средства визуализации. Коль скоро получившаяся древовидная модель описывала подход к выбору других моделей, я назвал её метадеревом.
Но это был не финал. Шло время. Периодически появляющиеся соображения заставляли меня возвращаться к, казалось бы, уже проделанной работе, чтобы внести уточнения и дополнения. В процессе этого «тюнинга» какие-то ветки приходилось «обрезать», какие-то — «пересаживать» на новое место, но всякий раз метадерево неизменно становилось больше.
Не исключаю, что развитие продолжится и впредь. Меж тем я посчитал имеющийся на текущий момент результат достаточно «зрелым», чтобы представить его широкой публике.
Знакомьтесь — метадерево!
Вместо сносок
На схеме выше в целях экономии места приводится только по одному варианту названия средств визуализации и, как правило, только на русском языке. При возникновении затруднений с идентификацией рекомендую отыскать в интернете наиболее привычное для себя альтернативное наименование. Пример: диаграмма вариантов использования кому-то больше знакома под названием «Диаграмма прецедентов».
Упоминание нотации (UML, BPMN и пр.) в конце имени диаграммы означает, что данный вид диаграмм относится к данной нотации. Такая отсылка призвана помочь быстрее отыскать релевантное описание.
Для устранения неоднозначности рядом с некоторыми названиями в скобках указаны примечания. Пример: обозначение «Контекстная диаграмма (не IDEF0)» подсказывает, что в данном случае подразумевается контекстная диаграмма в наиболее общем понимании, а не диаграмма A-0 в нотации IDEF0. Если же встречаются квадратные скобки, то внутри них содержится отсылка к их автору.
RML — пожалуй, наименее известная из упомянутых и не очень легко отыскиваемая аббревиатура, поэтому и привёл её отдельно.
RML (Requirements Modeling Language) — это набор типов диаграмм, своего рода нотация, предлагаемая её авторами для использования при разработке программного обеспечения. Более подробно можно ознакомиться в работе: Joy Beatty, Anthony Chen. Visual Models for Software Requirements. Microsoft Press, 2012.
Глядя на представленную схему, кто-то может задаться вопросом: как с этим работать? На самом деле, алгоритм обхода метадерева довольно простой.
Сперва надо встать на корень (то есть узел, расположенный вначале диаграммы) и прочитать сформулированный на нём вопрос.
После этого следует просмотреть ближайшие узлы, соединённые дугами (ветками) с корнем, и выбрать среди них один, на котором представлен текст, наиболее точно по своему смыслу отвечающий на вопрос.
Далее нужно передвинуться на узел, следующий за выбранным (он также содержит свой вопрос).
И весь процесс повторяется.
Так, двигаясь от корня дерева и отвечая на вопросы, вы, в конечном счёте, дойдёте до листового узла, содержащего название предпочтительного, на мой взгляд, средства визуализации.
Важно отметить, что представленное дерево не претендует на полноту, универсальность и медицинскую точность, а лишь отражает мой личный опыт и понимание.
Возможно, у вас появятся доводы в пользу того, чтобы где-то появились ещё ветви, листья или даже будут веские основания для того, чтобы что-то убрать с моей схемы. Я предлагаю не дискутировать на этот счёт в попытках добиться недостижимого идеала, а попробовать воспользоваться этим деревом и при необходимости адаптировать его на своё усмотрение, убрав или добавив что-то ценное для сферы своих профессиональных интересов.
Более того, я не буду скрывать, что довольно большу́ю долю представленных средств визуализации я применял на практике в очень ограниченном объёме, а, например, с С4 имел дело только в теории. Но коль скоро эта нотация занимает умы всё большего числа архитекторов и авторов статей в интернете, добавил и её.
И ещё пара важных замечаний.
Двигаясь от корня дерева, можно оказаться в ситуации, когда ответу на последний вопрос будет соответствовать сразу более одного листового элемента. Это следует воспринимать так, что окончательный выбор остаётся за вами. И здесь можно руководствоваться имеющимися у вас соображениями или личными предпочтениями.
Не всегда следует буквально воспринимать предложенные варианты. Всегда есть место творчеству, плюс в вашей компании или команде могут существовать внутренние правила и свои нотации. В таком случае, найдя лист на дереве, вы без труда сможете выбрать наиболее близкий аналог из доступного вам инструментария.