Boatman's Home: К вопросу о диаграммах (v1)

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

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

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

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

Передача диаграммы в процессе коммуникации ^

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

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

Есть 2 участника передачи информации: участник 1 и участник 2.

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

При передаче происходит следующее:
1. Часть информации в голове участника 1 перемещается в диаграмму;
2. Информация из диаграммы перемещается в голову участника 2, в результате, в голове участника 2 появляется измененная информация;
3. Если средство и протокол передачи позволяют обратную связь с уточнением, или если кроме диаграммы передаются другие артефакты, то еще одна часть информации из головы участника 1 передается в виде "другой информации" (иногда это происходит и до передачи диаграммы);
4. "Другая информация" воспринимается участником 2. В результате, в голове участника 2 появляется уточненная информация - окончательная картина.

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

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

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

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

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

Таким образом мы имеем следующую ситуацию (см рисунок ниже).

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

для эффективной коммуникации, при разработке диаграммы ВСЕГДА следует учитывать, кто потребитель диаграммы и планировать способ передачи контекста.

Итак, мы пришли к трем ключевым компонентам коммуникации:
1. потребитель,
2. способ передачи,
3. контекст.

Четвертым компонентом коммуникации в нашем случае является сама диаграмма.

Варианты коммуникации с использованием диаграмм ^

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

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

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

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

	Отсутствие передачи контекста	Текстово-табличная информация	Переписка	Телефон	Живое общение
В одном лице	Так как весь контекст хранится в одной голове, то для проектирования и документирования на короткий срок отсутствие дополнительной информации вполне приемлемо	Несмотря на то, что контекст имеется в голове, при документировании на длительный срок (более 2-3х недель) лучше выплеснуть существенные моменты описания контекста в документацию.	Вряд ли имеет смысл.	Вряд ли имеет смысл.	При составлении диаграммы для себя, можно считать, что живое общение с самим собой происходит непрерывно
Коллега из нашего проекта	Если с коллегой налажено достаточно тесное взаимодействие, то контекст есть у него в голове, поэтому чаще всего можно не передавать дополнительную информацию.	Если коллега не работает над той же задачей, что и мы, то, скорее всего, контекст все же придется представить в виде проектной документации.	Если коллега территориально удален, то проектную документацию можно передать ему по почте.	Если что-то непонятно в проектной документации, то детали можно уточнить по телефону.	Бывает так, что единственным способом пояснить документацию является живое общение на совещании.
Коллега из другого проекта	Для коллеги из другого проекта (например, вводимого в наш проект) восстановление контекста играет важнейшую роль, поэтому отсутствие передачи дополнительной информации практически неприемлемо.	Текстово-табличная информация и поясняющие диаграммы - единственный приемлемый вид представления проектной документации практически во всех случаях.	Переписка служит естественным дополнением для уточнения проектной документации в распределенных командах. Недостаток в том, что для составления предельно ясного письма требуются большие усилия, если их не приложить, качество донесения информации страдает.	Телефон может оказать существенную помощь там, где не работает переписка. (После третьего уточняющего письма беритесь за телефон). Недостаток в том, что уточнить или передать большой объем информации по телефону невозможно.	Живое совещание позволяет снять разногласия и недопонимание наиболее эффективно, но для передачи полной информации в большом проекте потребуется слишком много времени.
Представитель пользователей	При общении с представителями пользователей огромную роль играет качество передаваемой информации, так как для ИТ специалистов и пользователей разные сущности и взаимосвязи являются привычными и не требующими объяснения. Поэтому планирование передачи контекста в данном случае требует больших усилий, чем при общении с коллегами. В частности, при передачи диаграмм пользователям следует позаботиться о том, насколько им знакома нотация, используемая в диаграмме. Можно видеть, что отсутствие передачи контекста при общении с пользователями в большинстве случаев неприемлемо.	В живом ИТ проекте есть только 2 способа надежного общения с пользователями и только один из них юридически приемлемый. Один их этих способов - предъявление прототипа, другой - общение через документацию, которая может быть как одинаково прочитана в любой момент, так и заверена подписями и печатями.	Переписка может служить для уточнения деталей в рабочем порядке, однако для нее сохраняется все та же оговорка, что и для документов: существует проблема взаимопонимания, особенно на начальных стадиях проекта.	Телефон может оказать помощь при общении с пользователями, но не может заменить хорошей документации, как и в предыдущих случаях.	Живое общение с пользователями подчиняется общим закономерностям. Учитывая проблему взаимопонимания, подготовка такого общения требует больше времени. Чаще всего информацию доносят на совещаниях, организованных в виде презентации, к которым специально готовятся слайды и тезисы выступления.
Представитель заказчика	Проблема взаимопонимания с бизнесменами и руководителями кроме разного языка (как с пользователями) усугубляется еще и отсутствием времени у руководителей на проникновение в детали и разрешение неясностей. Здесь действует "принцип лифта", согласно которому любую проблему следует уметь изложить в течение 30 секунд (пока вы, случайно встретившись с генеральным директором в лифте, едете с ним с 1го этажа на 11тый). Для текстовых документов это означает не более 2-3 страниц, для диаграмм не более 2-3 слайдов, не более 7-9 объектов на слайде. Отсутствие передачи контекста при общении с руководителем нежелательно, как бы тщательно не готовились слайды презентации.	Руководство редко обращается к дополнительным документам, поэтому уточнение с использованием обширной проектной документации практически не используется при данном виде общения.	Для переписки справедливо то же, что и для предыдущих двух видов передачи информации.	Телефон чаще используется руководством для организации работы и приема отчетов о выполнении, чем для проникновения в суть проблемы.	Живое общение - единственный способ качественно донести свое сообщение руководителю. В данном случае ясность слайдов и четкость тезисов при чтении презентации играют особенную роль.

Можно видеть, что при общении с любым потребителем информации важно учитывать следующие параметры, образующие в совокупности коммуникационный барьер:
-- насколько близок <язык общения> (языковой барьер): с коллегами язык одинаковый, с пользователями ‑ разный, с руководством - еще более разный.
-- дефицит времени и внимания у принимающей стороны (барьер внимания): коллеги чаще всего полностью в вашем распоряжении, пользователи могут быть заняты другими делами, руководство всегда торопится.
-- насколько далеко находятся оппоненты (физическое расстояние): иногда можно организовать живое общение, иногда доступна только переписка и передача документов.
-- каково расстояние во времени между передающей и принимающей стороной: иногда срок жизни диаграммы - несколько дней, иногда - годы.
-- какова численность и разнородность потребителей документации (барьер усреднения).

Общее правило таково:

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

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

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

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

Что несет диаграмма ^

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

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

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

На простой диаграмме в нотации IDEF1 приведены следующие факты:

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

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

Таблица 1 Перечень сущностей

№	Название сущности
1	Подразделение
2	Позиция
3	Сотрудник
4	Назначение на позицию

Таблица 2 Перечень характеристик

№	Название сущности	Название характеристики	Уникально идентифицирующая характеристика
1	Подразделение	Код подразделения	+
2	Подразделение	Название	-
3	Позиция	Код подразделения	+
4	Позиция	Код специальности	+
5	Позиция	Название позиции	-
6	Сотрудник	Табельный номер	+
7	Сотрудник	Фамилия	-
8	Сотрудник	Имя	-
9	Сотрудник	Отчество	-
10	Назначение на позицию	Табельный номер	+
11	Назначение на позицию	Код подразделения	+
12	Назначение на позицию	Номер специальности	+
13	Назначение на позицию	Количество часов в неделю	-

Таблица 3 Перечень связей

№	Сущность 1	Сущность 2	Характеристики связи 1	Характеристики связи 2	Множественность	Название
1	Подразделение	Позиция	Код подразделения	Код подразделения	1:много	Подразделение имеет позицию
2	Позиция	Назначение на позицию	Код подразделения, Код специальности	Код подразделения, Код специальности	1:много	Назначение соответствует позиции
3	Сотрудник	Назначение на позицию	Табельный номер	Табельный номер	1:много	Сотрудник имеет назначение на позицию

Посмотрим, что дает диаграмма читающему ее.

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

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

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

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

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

Рассмотрим теперь текстовое представление.

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

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

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

Теперь рассмотрим, что может табличная форма.

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

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

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

Если сказать другими словами,

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

Как правильно передать контекст ^

Наконец, мы можем исследовать роль контекста по отношению к диаграмме.

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

КАКОЕ-ТО Подразделение, которое характеризуется НЕКИМ кодом подразделения и НЕКИМ названием (при этом уникальный идентификатор - код подразделения), может КАК-ТО иметь несколько КАКИХ-ТО позиций, которые уникально характеризуются кодом подразделения и КАКИМ-ТО кодом специальности, а дополнительно характеризуются НЕКИМ названием позиции. НЕКИЕ Сотрудники, которые уникально характеризуются КАКИМ-ТО табельным номером и дополнительно характеризуются фамилией, именем и отчеством, НЕКОТОРЫМ ОБРАЗОМ имеют НЕКИЕ назначения на позиции. Каждое назначение на позицию КАК-ТО соответствует сотруднику и позиции, уникально характеризуется табельным номером (сотрудника), кодом специальности и номером подразделения. Для каждого назначения указывается КАКОЕ-ТО количество часов в неделю.

Каждое "КАКОЙ-ТО" и "НЕКИЙ" будут додуманы читающим в соответствии с тем, что было передано в качестве контекста и какой предыдущий жизненный опыт он имеет.

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

Термин	Рисующий	Читающий
Подразделение	Структурное подразделение ЗАО "Рога и копыта", находящееся в составе департамента, находящегося в составе ЗАО "Рога и копыта". На данный момент имеется 5 департаментов и 26 подразделений.	Подразделение некоторой организации. При этом организация делится на подразделения, которые могут так же делиться на подразделения.
Код подразделения	Числовой трехзначный код подразделения, указанный в документе "Положение об организационной структуре ЗАО Рога и копыта" для каждого подразделения. Код подразделения имеет первой цифрой номер департамента (номера департаментов указаны в том же документе).	Некий буквенно-числовой код.
Название (подразделения)	Привязка названия к коду содержится в документе "Положение об организационной структуре ЗАО Рога и копыта".	Некая строка.
Подразделение имеет позицию	Для каждого подразделения указывается список позиций (штатных рабочих мест), который содержится в документе "штатное расписание ЗАО Рога и копыта". На данный момент в подразделениях от 3х до 20 позиций.	Подразделению соответствует несколько позиций.
Код специальности	шестизначный код специальности по классификатору специальностей из "ТАКОГО-ТО всероссийского документа"	Некий буквенно-цифровой код
Название позиции	Название позиций указано в документе "штатное расписание ЗАО Рога и копыта"	Некая строка.
Сотрудники	Штатные сотрудники (люди) ЗАО "Рога и копыта" в отличие от внештатных сотрудников, работающие по контракту.	Все работники (люди) ЗАО "Рога и копыта"
Табельный номер	Табельный номер сотрудника, присвоенный отделом кадров и хранящийся в личном деле сотрудника.	Некое число.
Фамилия, имя, отчество	Фамилия, имя, отчество - те же, что и в паспорте сотрудника	Фамилия, имя, отчество - те же, что и в паспорте сотрудника
Назначение на позицию	Назначение на позицию осуществляется приказом по предприятию ЗАО "Рога и копыта" (шаблон №П123) с указанием перечня позиций и сотрудников, назначенных на позицию, а также датой начала выполнения работы. Сотрудник, назначенный на позицию выполняет работы, указанные в положении о подразделении в которое он назначен. Освобождение сотрудника от исполнения работ на данной позиции осуществляется приказом по ЗАО Рога и копыта (шаблон №П123) с указанием перечня сотрудников и позиций и даты прекращения выполнения работ.	Сотрудник, имеющий назначение на позицию, работает на этой позиции в подразделении.
Сотрудник имеет назначение на позицию	После ознакомления с приказом о назначении на (освобождении от) позицию сотрудник обязан приступить к выполнению работ (прекратить выполнение работ), указанных в положении о подразделении, куда он назначен с указанной даты или с момента ознакомления (если указанная дата прошла на момент ознакомления).	Сотрудник, имеющий назначение на позицию работает на этой позиции в подразделении.
Назначение на позицию соответствует сотруднику и позиции	Соответствие указано в приказе (шаблон П123).	Назначение указывает какой сотрудник на какой позиции работает.
Количество часов в неделю	Каждая позиция может быть заполнена несколькими сотрудниками. Количество часов в неделю указывает, сколько часов сотрудник должен тратить на выполнение работ на данной позиции в одну рабочую неделю. Некоторые позиции могут быть заполнены только одним сотрудником. Возможно ли разделение позиции и насколько указывается в Штатном расписании ЗАО Рога и копыта. Для всех позиций и сотрудников не допускается заполнение позиции более, чем на 40 часов в неделю (сумма часов всех назначенных на позицию сотрудников <=40). Для всех сотрудников не допускается назначение на позиции с превышением 40часовой рабочей недели (сумма часов по всем назначениям сотрудника <=40).	Некое число

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

Так чего же не хватает на диаграмме?

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

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

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

И теперь перед нами встает вопрос: как обеспечить такое понимание диаграммы читающим.

Так как же использовать диаграммы ^

Надеюсь, читатель уже понял, что я пытаюсь донести следующую мысль:

диаграмма не первичный и не самодостаточный артефакт.

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

Рассмотрим несколько вариантов.

Описание бизнес-процессов с целью автоматизации (использование диаграмм) ^

Бизнес-процессы "как есть" с целью автоматизации могут появляться в рамках обследования. По итогам обследования я мог бы получить следующую диаграмму.

Прочесть (и использовать) эту диаграмму правильно можно только зная контекст моделирования и использования. Если мы видим только диаграмму, вопросов возникает больше, чем ответов.

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

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

Зададим контекст моделирования.

Концепция Системы

В рамках проекта "АБВ" решается проблема регламентации и автоматизации проектного управления в компании "ЭЮЯ" путем
1. создания пакета регламентов проектного управления с целью автоматизации (см п.2);
2. внедрения системы автоматизации проектного управления со следующими возможностями:
   2.1. для руководителей -
    а) предоставление отчетов о состоянии выполнения задач в текущих проектах;
    б) предоставление отчетов о затраченной трудоемкости в текущих и закрытых проектах;
    в) постановка задач и получение еженедельного отчета о выполнении;
   2.2. для исполнителей -
    а) предоставление информации о текущих задачах исполнителя;
    б) отчет о выполнении задач.
........

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

Описание бизнес-процессов проектного управления компании "ЭЮЯ"

1. Данный документ отражает процессы проектного управления компании "ЭЮЯ".
2. Данный документ будет использоваться совместно с концепцией Системы (ссылка на документ) командой проекта "АБВ".
а) для разработки проекта регламента автоматизированного процесса проектного управления компании "ЭЮЯ";
б) в качестве исходного материала для извлечения функциональных требований и разработки ТЗ на систему автоматизации, поддерживающую регламент.
......

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

Документ, содержащий исследуемую диаграмму имеет введение, еще более уточняющее, какую информацию читающий может в нем найти (а автор должен отразить).

Приведем дальнейший текст документа:

.......
3. Структура процесса проектного управления показана на диаграмме (ссылка на нашу диаграмму).
4. Описание подпроцессов, показанных на диаграмме, представлено в таблице 1.
5. Описание ресурсов, показанных на диаграмме, представлено в таблице 2.
.......

Пункты 4 и 5 ссылаются на таблицы, дающие сущностям с диаграммы привязку к реалиям компании "ЭЮЯ", приведем эти таблицы.

Таблица 1 Описание подпроцессов процесса проектного управления

Код	Название	Описание
А1	Разработка первой версии рабочего плана	Цель: формирование проектной команды, ознакомление ее членов с целями проекта и их ролью в проекте. Основной результат - рабочий план версии 0 (см приложение 1).
А2	Выполнение работ	Цель - приближение проекта к завершению. Основной результат - отчет о выполнении работ, подписанный со стороны заказчика (см приложение 3).
А3	Оперативное управление	Цель: координация работ по проекту. Сценарий выполнения: 1. Руководитель проекта проводит еженедельные совещания с проектной командой и представителями заказчика по статусу проекта, на которых принимаются решения о необходимости выпуска новой редакции плана проекта (см п.1а). Решения совещания фиксируются протоколом совещания по статусу проекта (см приложение 4). 2. Руководитель проекта ежедневно принимает отчеты о выполнении работ от консультантов и а) принимает решения о постановке новых задач исполнителям на основании текущей версии рабочего плана; б) проставляет отметки об исполнении в соответствующем разделе рабочего плана проекта. 3. Директор в произвольный момент (или на основании обращения представителя заказчика) выясняет состояние проекта у руководителя проекта и принимает решение о внеочередном совещании по статусу проекта (см п.1). 1а. На основании протокола совещания по статусу проекта руководитель проекта выпускает редакцию плана следующей версии и согласует ее с проектной командой и представителем заказчика.
А4	Согласование рабочего плана	Цель: резервирование ресурсов, согласование с заказчиком сроков выполнения конкретных работ. Основной результат - рабочий план версии 1 (см приложение 2).

Таблица 2 Описание ресурсов процесса проектного управления

Название	Описание
Договор	Договор - обязательное основание старта проекта; Договор фиксирует цели проекта, критерии достижения цели, назначение представителя заказчика, а так же сроки начала и завершения этапов проекта.
Рабочий план проекта версии 0	Рабочий план версии 0 фиксирует уточненные цели, критерии достижения, предварительный состав работ и состав проектной команды. (см приложение 1)
Рабочий план проекта версии 1	Рабочий план версии 2 в дополнение к версии 0 содержит утвержденное расписание работ и контрольный список проекта. (см приложение 2)
Отчет о выполнении	Технический протокол, содержащий подтверждение со стороны заказчика факта выполнения работ, а также перечень замечаний по выполнению работ. (см приложение 3)
Текущий рабочий план	Текущий рабочий план в дополнение к первой версии содержит уточненное расписание и частично заполненный пометками об исполнении контрольный список проекта (см приложение 6).
Текущие задачи	Текущие задачи - это задание на выполнение работ в письменном виде (см приложение 5), выдаваемое на основании рабочего плана проекта.
Результаты работ	Здесь не описаны.
Протокол совещания по статусу проекта.	Протокол, содержащий перечень задач, завершенных и поставленных с момента прошлого совещания по статусу, с отметками о состоянии выполнения, а также принятые решения о выпуске новой версии рабочего плана. (см приложение 4)
Консультант	Член проектной команды, отвечающий за выполнение работ. Назначение консультанта на проект отражается в рабочем плане проекта.
Руководитель проекта	Член проектной команды, отвечающий за координацию работ по проекту. Назначение руководителя на проект отражается в рабочем плане проекта.
Директор	Директор проекта фиксируется в договоре. Его задача - решение конфликтных и исключительных ситуаций, выделение ресурсов на проект, принятие решения о старте, приостановке и завершении проекта.

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

Приложение 1. Инструкция по заполнению рабочего плана версии 0.
Приложение 2. Инструкция по заполнению рабочего плана версии 1.
Приложение 3. Инструкция о заполнении шаблона отчета о выполнении работ.
Приложение 4. Инструкция по заполнению протокола совещания по статусу проекта.
Приложение 5. Инструкция по постановке текущих задач.
Приложение 6. Инструкция по заполнению контрольного списка проекта.
Приложение 7. Шаблон плана проекта.
Приложение 8. Шаблон отчета о выполнении работ.
Приложение 9. Шаблон протокола совещания по статусу проекта.
Приложение 10. Шаблон отчета о выполнении работ.
Приложение 11. Шаблон постановки текущих задач.

В нашем примере в приложениях к документу даны описания ресурсов. Детальные описания процессов отдельно не даны.

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

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

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

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

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

Использование диаграмм при сборе функциональных требований ^

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

На основании концепции системы мы можем перечислить основные возможности, предоставляемые системой пользователям:

ВИ1 получить отчет о состоянии выполнения задач в текущем проекте,
ВИ2 получить отчет о затраченной трудоемкости в текущем или закрытом проекте,
ВИ3 поставить задачу,
ВИ4 получить еженедельный отчет о выполнении,
ВИ5 получить информацию о текущих задачах (для исполнителя),
ВИ6 отчитаться о выполнении задач (для исполнителя).

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

Предметом выяснения на интервью будут являться конкретные формы отчетов и как поступает информация (ВИ1, ВИ2, ВИ4, ВИ6), что входит в информацию о текущих задачах и в постановку задачи (ВИ5 и ВИ3).

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

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

ВИ\Процесс	А1 Разработка первой версии рабочего плана	А2 Выполнение работ	А3 Оперативное управление	А4 Согласование рабочего плана
ВИ1 получить отчет о состоянии выполнения задач в текущем проекте	-	-	х	-
ВИ2 получить отчет о затраченной трудоемкости в текущем или закрытом проекте	х	-	х	-
ВИ3 поставить задачу	-	-	х	-
ВИ4 получить еженедельный отчет о выполнении	-	-	х	-
ВИ5 получить информацию о текущих задачах	-	х	-	-
ВИ6 отчитаться о выполнении задач	-	х	-	-
ВИ7 ввести версию плана	х	-	х	х
ВИ8 ввести данные о человеке	х	-	х	х

Как уже было сказано, диаграмма ВИ показывает связь между сценариями использования системы. Сами сценарии - это текст, описывающий взаимодействие между системой и пользователями. Пример сценария показан ниже.

ВИ3 Поставить задачу
Предусловие: Текущая версия плана данного проекта введена в Систему (ВИ7), руководитель данного проекта принял решение о постановке задачи по данной работе, выполнен вход в Систему с учетной записью пользователя, являющегося руководителем данного проекта.
Участники: руководитель данного проекта (инициатор).
Условия успешного завершения: Задача, поставленная в ходе сценария отображается в отчете из ВИ1, все исполнители по поставленной задаче получают по ней информацию в ходе ВИ5, все исполнители по поставленной задаче имеют возможность отчитаться в ходе ВИ6 (при этом для задачи заданы: даты начала и планового завершения, полный список исполнителей и текст задания), все исполнители по задаче выбраны из консультантов данного проекта.
Основной сценарий
1. Руководитель проекта выбирает проект из списка своих проектов и работу из плана проекта.
2. Система сообщает версию плана, номер и дату протокола-основания для плана и предлагает ввести данные задачи.
3. Руководитель проекта вводит:
- дату планового завершения;
- текст задания;
- выбирает исполнителей из консультантов данного проекта.
4. Система производит проверку данных:
- дата планового завершения должна быть не меньше текущей даты;
- дата планового завершения должна быть не больше даты планового завершения выбранной работы;
- текст задания не может быть пустым;
- список исполнителей не может быть пустым;
При успешной проверке Система запоминает текущую дату в качестве даты начала выполнения задачи и введенные данные, выполняет действия для реализации условий успешного завершения, сценарий заканчивается успешно.
Альтернативные шаги
1а. Если проект или текущая версия плана не введены, сценарий заканчивается неуспешно.
1б См 2а.
2а1. Руководитель проекта принимает решение об отмене постановки задачи.
2а2. Система отменяет ввод, сценарий заканчивается неуспешно.
3а. См 2а.
4а. Если проверка по одному из критериев не успешна, Система сообщает об этом и переходит к шагу 3 (корректно введенные данные не должны вводиться повторно).
.......

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

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

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

Сущность\ВИ	ВИ1	ВИ2	ВИ3	ВИ4	ВИ5	ВИ6	ВИ7	ВИ8
Информация о человеке в Системе	-	-	-	-	-	-	-	i
Учетная запись	-	-	s	o	s	s	-	i
Проект	s	s	s	s	o	s	i	-
Этап в Системе	o	o	s	o	o	s	i	-
Версия плана в Системе	o	o	o	o	o	o	i	-
Работа в Системе	o	o	s	o	o	o	i	-
Задача в Системе	o	o	i	o	o	s	-	-
Отчет о выполнении в Системе	o	o	-	o	-	i	-	-

Примечание
i - информация сущности вводится в сценарии;
s - информация сущности используется для организации выбора в сценарии;
o - информация сущности выводится в сценарии;

Столбец матрицы дает представление о том, какая информация вводится и выводится в ходе исполнения сценария. Строка матрицы дает информацию о том, в каких сценариях вводится и выводится информация сущности.

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

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

Естественным будет вопрос: "При чем тут матрица?". Дело в том, что на сегодняшний день большинство диаграмм строится с использованием CASE средств, позволяющих отражать связи между элементами модели не только на диаграмме, но и в виде матрицы смежности. Связи, изображенные на любой диаграмме, можно изобразить в матрице. Обратное верно лишь отчасти, так как удобочитаемые диаграммы обычно имеют "разреженную" матрицу смежности элементов, в которой заполнены далеко не все ячейки. Так, данную матрицу сущность-ВИ можно было бы визуализировать серией диаграмм activity, поясняющих сценарии. Одна из них (приблизительно соответствующая столбцу ВИ3 нашей матрицы) показана ниже.

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

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

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

Применение диаграмм при проектировании приложения ^

Рассмотрим применение диаграмм в процессе проектирования на примере схемы базы данных.

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

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

Что является контекстом в этом случае? Если не брать в рассмотрение текст хранимых процедур, триггеров и ограничений целостности, не отображаемых на диаграмме, контекстом будет являться конкретная РСУБД и CASE средство, в котором будет создаваться диаграмма и преобразовываться в DDL. Если учесть полные спецификации этих программных продуктов, можно видеть, что контекст по-прежнему имеет значительный объем. Отличие в том, что в этом случае контекст наиболее строго описан.

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

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

Заключение ^

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

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

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

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

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

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

^ О сайте Главная Новости Карта

К вопросу о диаграммах (v1)

Введение ^

Мифы о диаграммах ^