Практическое применение графических нотаций в ИТ

Привет всем! Меня зовут Валерий. Я мог бы сочинять музыку, но знаю только три ноты: C, C# и F#, поэтому работаю системным аналитиком в Сбере, а код сочиняют разработчики с ГигаКодом, они знают ещё много разных нот. Мне кажется, что я умею читать и писать, но, когда я начинаю сомневаться в последнем навыке, добавляю в свою писанину диаграммы.

Различия между диаграммой и текстом

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

Текст «одномерен», это упорядоченная последовательность знаков. Чтобы прочитать текст, нужно воспринимать эти знаки последовательно, друг за другом.

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

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

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

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

Подавляющее большинство естественных языков имеет средства для разделения темы (того, что известно читателю или слушателю) и ремы (того, что ещё не известно и надлежит сообщить). На диаграммах почему-то не обозначают разделение на тему и рему. Иногда обозначают границы проектирования (например, архитекторы Сбера на своих диаграммах выделяют знаком «+» АС, функциональные подсистемы, модули и потоки данных, которые должны быть добавлены согласно отражаемым на диаграмме архрешениям), однако границы проектирования отделяют скорее TO BE от AS IS, а не рему от темы.

Считается, что в высказывании, чтобы оно легко воспринималось, должно бытьне более 5—9 самостоятельных слов. В противном случае высказывание оказывается перегруженным, слишком информативным, и его получатель не может поместить его целиком в свою кратковременную память, чтобы усвоить содержащиеся в нём сведения Часто можно встретить аналогичную рекомендацию для составления диаграмм: не размещать на них более 5—9 элементов, основных по семантике.

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

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

Графические нотации

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

ЕСКД — это межгосударственный формат, действует в СНГ. Однако чертёж, выполненный в соответствии с ним, будет понятен инженеру в любой стране, потому что национальные стандарты для чертежей различаются незначительно. При этом ЕСКД стандартизирует не только текстовые и графические документы, но отчасти и управленческие процессы документирования и организации исследований и производства.

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

Особенности графических нотаций в ИТ

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

Наша отрасль особенная, поскольку по сравнению с другими дисциплинами и отраслями часто приходится иметь дело с абстракциями. У нас как у философов много абстрактных понятий без объективных критериев их различения, много различных терминов (и мало специалистов, которые хорошо разбираются в наших абcтрактных вещах; ещё меньше специалистов, готовых разбираться в этих тонкостях, что печально).

Вот несколько кластеров понятий и терминов:

• автоматизированная система, информационная система, подсистема, программный модуль;

• сообщение, уведомление, нотификация, сигнал;

• контроль, мониторинг, наблюдение;

• завести, зарегистрировать, создать, записать, зафиксировать, сохранить;

• информация, данные, факты, сведения, информационные активы, структурированные данные;

• типы фактов, типы данных.

Иногда ИТ-специалисты сидят рядом, читают и даже составляют одни и те же документы с этими словами, но каждый что-то понимает по-своему.

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

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

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

Другой особенностей нашей отрасли является привязка нотаций к методикам или методологиям создания АС.

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

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

В ИТ зачастую не так. Удачная нотация или набор нотаций обрастает методикой анализа, разработки функциональных решений, проектирования и так далее. Или методику привязывают к нотации, или нотацию разрабатывают для самой методики. Например, в Rational Unified Process многие артефакты являются диаграммами в нотациях UML. Да и сам UML — это прежде всего методика моделирования и проектирования, а потом уж графические нотации.

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

Вторая причина — это мода на такие методики. Большинство создателей современных нотаций — специалисты, работающие в западных странах, в основном, в США. Большинство авторов и читателей диаграмм никогда не занималась ни автоматизацией производства в реальном секторе, ни автоматизацией управления промышленным предприятием. Во время создания нотаций происходила деиндустриализация этих стран, превалировало мнение, что успешным странам западной цивилизации следует не заниматься реальным сектором экономики, а развивать финансовые услуги, управленческий консалтинг, растить доткомы и — если немного утрировать — придумывать и продавать различные методики, методологии, подходы, то есть то, что наши технари часто называют болтологией.

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

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

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

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

В ИТ превалируют дискретные вычисления, вот и наши диаграммы представляют не аналоговые данные, а дискретные. Причём используют «дискретные» приёмы для представления. Например, если на диаграмме есть шкала времени, то она обычно лишь порядковая, а не интервальная (без соблюдения масштаба), потому что задаёт последовательность событий, но не отражает, как соотносятся между собой временные интервалы между этими событиями. Если на диаграмме символ одного сервера в два раза больше символа другого сервера, то это не означает, что первый в два раза мощнее, просто автору пришлось поместить больше объектов в область первого сервера.

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

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

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

(Разработку метамодели для моделирования АС и её окружения в этой статье рассматривать не будем, но они важнее самих графических нотаций.)

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

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

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

Абстракции в составе метамодели зависят от точек зрения, используемых для моделирования на её основе объекта автоматизации и АС, или от аспектов, для которых метамодель предназначена. Например, если метамодель предназначена для технического описания инфраструктуры АС, то среди её абстракций окажутся каналы передачи данных, линии связи, сетевые протоколы, кластеры серверов, транспортное ПО и так далее. Если же метамодель предназначена для отражения деловых процессов, то в ней окажутся роли участников, действия, артефакты, события, бизнес-правила. Одна и та же метамодель может предназначаться для моделирования с нескольких точек зрения.

В силу дискретности модель удобно рассматривать как математический граф. Действительно, большинство разрабатываемых моделей АС, её окружения и объекта автоматизации математически представляют собой граф. Его вершины могут представлять модули ПО АС, организационные единицы, пользователей и смежные системы, шаги процессов, функции и состояния, а рёбра – отношения между подразделениями, зависимости между модулями, переходы между состояниями и шагами процессов. Поэтому многие нотации предназначены для изображения графа. Точнее, фрагмента графа, где согласно правилам моделирования вершины и рёбра отнесены к нескольким типам, а также снабжены атрибутами.

Графическая нотация и даже система графических нотаций может охватывать метамодель не полностью. Например, реляционная СУБД поддерживает индексы и хранимые процедуры, внешние ключи и многое другое, но на диаграмме таблиц отражаются только таблицы, их поля и связи через внешние ключи.

У нас мало стандартов в части графических нотаций

Кто виноват?

Дело не только в молодости отрасли и обилии абстрактных понятий (ГОСТ 34 и ГОСТ 19 с ними прекрасно справились). Пожалуй, основная причина — частая смена модных технологий. Каждая из них призвана управлять сложностью, упростить работу инженера и уменьшить вероятность ошибок. Разработка технологии в нашей отрасли не столь ресурсоёмкое предприятие как в других отраслях: не нужно строить ракетный двигатель, ракету-носитель, космический корабль и космодром, поэтому многие технологии живут чуть дольше очередного попсового шлягера.

Что делать?

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

Как рисовать понятные диаграммы?

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

Выделять узлы

Посмотрите на эту диаграмму:

Она кажется чертежом ромба, вершины которого скрыты прямоугольниками и ромбами поменьше. Но из семантики надписей можно сделать вывод, что это ER‑диаграмма. Если бы надписи были сделаны на китайском языке, то мы не смогли бы прийти к такому заключению.

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

Закруглять изломы соединительных линий

Что не так с этой диаграммой?

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

Мы видим, что соединительные линии образуют Т-образные пересечения. Вероятно, в них они сливаются или разветвляются. Ведь имеются же нотации, где соединительные линии обозначают потоки данных. В них несколько потоков могут сливаться в один, и, наоборот, поток может разветвляться на несколько. Вот только в таких пересечениях читателю совсем не понятно, что с чем сливается или что из чего ответвляется. Например, куда идёт линия от вершины с надписью «Клямсы сопритюкноты»? Как обозначить её направление, чтобы читателю не пришлось это вычислять? Пририсовать на каждом сегменте стрелку, указывающую направление? Но допускает ли это нотация?

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

Теперь в каждом Т-образном пересечении стало понятно, которая из линий является «главной», то есть которая из линий разветвляется на две или, наоборот, является результатом слияния других линий.

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

Внимательный читатель заметит, что на последнем рисунке разъединили две соединительные линии.

Отступы между соединительными линиями и узлами

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

Отступы поддерживает инструмент draw.io, но не поддерживает MS Visio.

Структурирование диаграммы путём размещения её элементов

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

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

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

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

Рекомендации по разработке оригинальной нотации

Проверьте целесообразность разработки оригинальной нотации

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

• С какими существующими нотациями знакомы ваши читатели?

• Освоили ли вы эти нотации достаточно хорошо, чтобы утверждать, что ни одна из них не подходит для ваших задач?

• Допускают ли эти нотации расширения?

И ещё один важный вопрос: Как вы доведёте свою нотацию до читателей? Достаточно ли для неё поместить в документ легенду или дополнить раздел «Обозначения»?

Проработайте метамодель

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

• отличный опытный дизайнер, который для всех ваших типов фактов с ходу предлагает более выразительные для читателей и компактные обозначения, чем вы ему показали, и готовый документировать эти обозначения;

• бригада разработчиков с Гигачатом, способная за вечер реализовать любые идеи этого дизайнера;

и не думайте над графической нотацией, пока не разработаете для них модель данных. Не тревожьтесь о том, что затем вам лично придётся придумывать графические обозначения и разрабатывать уж если не рисовалку, то набор элементов в Visio или draw.io как минимум.

Определите правила полноты для графической нотации

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

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

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

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

Правила должны содержать ответ на этот вопрос.

Анатомия графических (и не только) обозначений, используемых в ИТ-нотациях

На разработку собственной нотации может вдохновить багаж графических обозначений и правил (соглашений) составления диаграмм, которые уже используются в различных ИТ‑нотациях. Ниже — мой обзор этих обозначений и правил. Разумеется, я его составил только по тем нотациям, которые знаю, поэтому приглашаю дополнять в комментариях.

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

• фрагмент диаграммы;

• вся диаграмма целиком;

• совокупность всех диаграмм модели.

Локализация на фрагменте диаграммы

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

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

Ограниченная область диаграммы

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

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

Надписи

Редкая графическая нотация обходится без надписей на естественном языке, и ИТ-нотации не исключение. Надпись может располагаться в ограниченной области, на соединительной линии, являться частью рамки диаграммы (колонтитулов).

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

Текстовые нотации в надписях

Графическую нотацию можно дополнить текстовой нотацией для формирования некоторых надписей:

Текстовая нотация может быть довольно сложной, включать в себя ключевые лексемы. Хороший пример такой текстовой нотации — текстовый язык объектных ограничений (OCL), являющийся частью UML.

Соединительные линии

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

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

Стиль соединительной линии также может нести семантику.

Порты

Это символы, обозначающие соединения узлов графа и соединительных линий.

Иногда порт не обозначают отдельным символом, для этого служат естественные направления: верх, низ, лево, право — такая методика используется в нотации SADT:

Локализация на всей диаграмме

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

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

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

Локализация на совокупности диаграмм модели

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

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

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

Это достаточно большой граф для представления на одной диаграмме, в нём сложно ориентироваться.

Выделим в нём подграфы, чтобы между ними было поменьше рёбер. Например, вот так:

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

Теперь каждый подграф представим на отдельной диаграмме:

Сделаем верхнеуровневую диаграмму, её вершинами будут выделенные нами подграфы, а рёбрами — совокупность рёбер между вершинами разных подграфов:

Получилось, что мы декомпозировали этот граф.

Замечу, что на этой диаграмме одному ребру соответствует несколько рёбер исходного графа.

Разумеется, такое упражнение можно проделать при двух условиях:

1. В метамодели предусмотрены сущности для этих подграфов (например, метамодель допускает компоновать шаги процесса в подпроцессы или объединять состояния объекта в группы).

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

Что не принято использовать в графических нотациях?

• Цвета. Не все их различают одинаково.

• Фоновые рисунки.

• Штриховки ограниченных областей.

• Стили текста в текстовых надписях.

• Интервальные шкалы.

• Составные соединительные линии, например, двойную линию. Вероятно, из-за проблем в поддержке таких линий в ПО для составления диаграмм.