Нужна каноническая диаграмма UML, показывающая основной поток информации от источника к получателю (потоковый граф). Вложение 1 - структура системы в виде диаграммы классов, если это так можно назвать Вложение 2 - как хотелось бы представить потоковый граф. Можно так, в виде диаграммы объектов? Поучите новичка, пжл 

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

Надо сказать что практически все UML диаграммы графовые.

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

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

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

В вашем случае показана диаграмма коммуникации, она же диаграмма объектов. Так что думаю можно

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

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

Да, вы правы, что телеметрическая система скорее агрегат, а не композит. Монитор как минимум может быть внешним и стандартным- по сути это же какой-то компьютер с АЦП как понимаю. Тем более в описание говорится об удаленном мониторе

Вторая (или даже первая) диаграмма больше похожа на Диаграмму Компонентов (component diagram) или Диаграмму Внедрения (deployment diagram), но на них изображают статику - из каких элементов состоит система.
Динамику можно показать на Диаграмме коммуникаций (communication diagram), но там нужно показывать Классы или Объекты, не знаю на сколько корректно показывать блоки Системы (хотя я и сам иногда этим балуюсь).
А вообще очень компактно показаны Диаграммы здесь:
http://www.xpdian.biz/TheUML2Diagrams.html

Да, вы правы, что телеметрическая система скорее агрегат, а не композит. Монитор как минимум может быть внешним и стандартным- по сути это же какой-то компьютер с АЦП как понимаю. Тем более в описание говорится об удаленном мониторе

Спасибо, вы оба правы - я поспешил.

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

Моя вторая, или это о принципе DFD?

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

Есть, <<flow>>, пунктирная. Ее и надо применять, пунктиром вместо сплошной? С этим стереотипом?

В вашем случае показана диаграмма коммуникации, она же диаграмма объектов. Так что думаю можно

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

Моя вторая, или это о принципе DFD?

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

Есть, <<flow>>, пунктирная. Ее и надо применять, пунктиром вместо сплошной? С этим стереотипом?

Она самая

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

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

Пожалуйста, проясните еще несколько моментов.
1. На диаграмме классов у меня подразумевается, что между Регистратором и Монитором осуществляется передача данных в одну сторону. Может вместо ассоциации (сплошная) нужно показывать поток информации пунктиром, со стереотипом <<flow>>?
2. Ассоциации классов в нижнем и верхнем ряду на той же диаграмме - сплошные двунаправленные стрелки. В таком контексте это будет пониматься по умолчанию как стереотип <<navigate>>? Какая-то неопределенность тут. Может на диаграмме классов тут вообще ничего не надо показывать?
3. На диаграмме объектов Дисплей в виде граничного элемента "смотрит не в ту сторону". Так можно, или этого нужно избегать?
4. Как изобразить (в ЕА) Источник в виде блока со стереотипом <<system agent>>? Или этого нет в UML 2.x?

Да и все тут ясно, правда почему функциональная схема?

Так называют эти диаграммы в схемотехнике? Модель нужно будет обсуждать с инженерами, привыкшими к таким схемам.

Пожалуйста, проясните еще несколько моментов.
1. На диаграмме классов у меня подразумевается, что между Регистратором и Монитором осуществляется передача данных в одну сторону. Может вместо ассоциации (сплошная) нужно показывать поток информации пунктиром, со стереотипом <<flow>>?

Ни в коем случае. ДК - статическая структура. Она показывает либо реальные объекты их устойчивые отношения, либо программные объекты с аналогичными устойчивыми отношениями либо зависимостями

2. Ассоциации классов в нижнем и верхнем ряду на той же диаграмме - сплошные двунаправленные стрелки. В таком контексте это будет пониматься по умолчанию как стереотип <<navigate>>? Какая-то неопределенность тут. Может на диаграмме классов тут вообще ничего не надо показывать?

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

3. На диаграмме объектов Дисплей в виде граничного элемента "смотрит не в ту сторону". Так можно, или этого нужно избегать?

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

4. Как изобразить (в ЕА) Источник в виде блока со стереотипом <<system agent>>? Или этого нет в UML 2.x?

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

Так называют эти диаграммы в схемотехнике? Модель нужно будет обсуждать с инженерами, привыкшими к таким схемам.

Ну суть не в названии, верно.

Я соглашусь с BAS, что по сути у вас представлена не диаграмма классов, а диаграмма компонетов, модулей системы. Хотя конечно никто не запрещает изображать скажем АЦП, как некоторый класс со своим набором свойств и операций. Однако судя по вашим комментариям и высказываниям действительно можно предположить, что вы смешиваете разные диаграммы в одной и сосбвтенно ДК и диаграмму компонентов.
Кстати в вашем случае может быть более полезна нотация SysML, она доступна в VISIO и стенсилсы к ней можно скачать в интернете. Я прицеплю сюда.

Вообще для чего нужны диаграммы? Может их имеет смылс делать в Visio, WorkBench и т.п. инструментах

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

Вообще для чего нужны диаграммы? Может их имеет смылс делать в Visio, WorkBench и т.п. инструментах

Мы осваиваем ООА/П и начинаем как бы с Reverse Engineering. Сейчас нужен анализ того, что было сделано (и неплохо!) раньше. Сделаем модели тех систем на УМЛ, проанализируем, а потом будем делать по-другому. Скажете, что нужно начинать с контекстной модели, UC-диаграммы. Правильно, мы это делаем, но нужно посмотреть и на основные компоненты (наверное, с этой диаграммы и начали, как заметил BAS). Теперь займемся классами. В общем, для нас важно анализировать и проектировать всю систему в целом, а не только софт.

Спасибо за помощь! Если поделитесь еще какими-то соображениями или ссылками - будем благодарны. (rar, однако, пришел дефектный. Попробую еще).

Попробуйте этот

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

Зип прошел. В двух словах, пожалуйста, напишите про эту нотацию или дайте ссылку. Вообще-то, от УМЛ отступать мы не можем.

Зип прошел. В двух словах, пожалуйста, напишите про эту нотацию или дайте ссылку. Вообще-то, от УМЛ отступать мы не можем.

У вас скорее всего другая версия рар архива, ну да ладно.
Про SYSML я не супер знаток, но это ветвь UML так-что тут все корректно. А ссылка:
всегда пользуйтесь Википедиа http://ru.wikipedia.org/wiki/SysML или http://en.wikipedia.org/wiki/Systems_Modeling_Language

А насчет отступать от UML не можете, что это значит? У вас принят строгий корпоративный стандарт? У вас требуют в вузе только в стиле UML?

Вообще мне кажется основная задача любой графической нотации - это доступность и наглядность восприятия, возможность передать больше информации, чем в тексте.
Однако все-таки картинки не самоцель и там где проще и понятнее нужно использовать текстовое описание.
Используется ли UML или еще что, мне кажется, должно определяться вами и целесообразностью.
UML конечно создавался как некоторй унифицированный т.е. единый язык моделирования, но возможно в его названии было скрыто не всеобъемность языка, а объединяющий момент для обозначения классов и их взаимодействия.
Далее язык стал развиваться и использоваться в разных областях. Некоторые удачные изыскания вылились в ветви языка такие как SysML или профили типа SPEM.
А нотация Эриксона-Пенкера - по сути попытка привязать IDEF0 и UML, на мой взглад, хотя мотивы у них могли быть совершенно иные