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

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

Ну, на текущий момент я для себя понимаю так: моделировать можно в любой нотации и в любом количестве вариантов. Главное, чтобы у каждой диаграммы была цель, которой она удовлетворяет, и чтоб нотация диаграммы была понятна и удобна всем ее пользователям. А уж стандарты и прочие строгости - это не must have, а best practice.
После того, как я определилась с этим, при моделировании появилась такая легкость!
На всякий случай повторяю: это мое мнение, может не совпадать с гуру и классиками :-)

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

Комментарии к диаграммам.

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

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

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

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

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

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

Понимаете для того, чтобы задать контекст и понять его, следует:
1. определить цель данного контекста или моделируемого аспекта
2. определить точку зрения или точки зрения
3. четко определить границу - т.е. что вне, а что внутри системы.

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

Так же советую посмотреть одну из ранее понимаемых тем Задачи на построение диаграммы вариантов использование, и конкретно советы Boatmana, начиная отсюда

** Я бы не стал на первом этапе заострять внимание на кратности связей, это уже не будет контекстом. **
Согласен.

** Что касается первой диаграммы - ... главное тут - получить медицинское амбулаторное обслуживание, частью которого должен быть телемедицинский сервис. ... сразу обозначить границу - Получить телемедицинское амбулаторное обслуживание. ... Где происходит данный процесс? **
Чтобы сразу ответить на этот вопрос, я даю более общий контекст в 1-й д. и стараюсь раскрыть его во 2й, которую также отношу к контекстной модели. Если нет противоречий между 1й и 2й диаграммами, то учитывая Вашу, Galogen, оценку второй д. "в целом", считаю, такой подход удачным. Дальше я и хочу дать более узкий контекст в виде еще одной ДВИ, где и обозначить границу "Получить телемедицинское амбулаторное обслуживание", выделяя ИС мобильного сервиса, а также показать внешних по отношению к ней актеров.

** Понимаете для того, чтобы задать контекст и понять его, следует:
1. определить цель данного контекста или моделируемого аспекта
2. определить точку зрения или точки зрения
3. четко определить границу - т.е. что вне, а что внутри системы
**
Понимаю и пытаюсь это сделать. Далее Вы ссылаетесь на ветку с советами Boatmana, которую я изучил вдоль и поперек и считаю классикой (серьезно, без смайла). Так вот там кто-то (не Galogen ли?) предлагал сразу, для ясности, давать диаграмму классов. Я к этому и пришел для обозначения общего контекста, когда получил здесь благословление на использование серии контекстных диаграмм 

В той ветке Boatman показал, какие сложности возникают при вложении контекстов. Решая свою задачу, я не могу сделать на одной диаграмме три (или даже 4) уровня вложения так, чтобы все заинтересованные лица все поняли (а надо, чтобы все и всё). Поэтому пройдя первый круг, я бы перешел, сузив контекст, на второй, и т.д.

Похоже, это все не для этого раздела, не так ли? Однако надеюсь на обратную связь.

Why not? Я думаю мы обсуждаем контекстную диаграмму - значит самое место это сделать тут, хотя ЕА тут явно не причем.

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

Модель предметной области (Domain Model) или концептуальная модель классов, или модель бизнес-объектов из серии  контекстных диаграмм, задающих контекст для дальнейшего обсуждения в рамках ОО подхода (и не только). Т.е. аналитик ,как он это понимает, пытается построить модель объектов реального мира и их устойчивые связи. Рамбо говорит по этому поводу, что модель предметной области должна разрабатываться быстро в течение 2 часов, не более. Она не должна содержать лишних деталей, не должна быть слишком подробной, и не должна быть слишком адекватной. Главная задача тут простота, а не полнота. В рамках данной модели и разворачивается дальнейшее обсуждение. Это словарь между разработчиком и предметниками.

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

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

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

К чему я - если то, что Вы делаете Вам понятно, если это понятно тем заинтересованным лицам, кому вы адресуете эти диаграммы. То пусть так и будет. Соответствует ли это какому-то стандарту или нет, какое это имеет значение?

Замечу только, что в Вашей диаграмме с ВИ виден интерес больного, но не видны остальные участники, не видно интереса самой системы обслуживания

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

Если не очень трудно, дайте ссылку на [Нейбург и Максимчук]

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

Если не очень трудно, дайте ссылку на [Нейбург и Максимчук]

Ссылки не дам. Вряд ли она есть. Проектирование баз данных с помощью UML. Эрик Нейбург, Роберт Максимчук. Вильямс, 2002.

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

Все определяется целесообразностью, я полагаю

Две диаграммы (прилагаются) представляют собой 2 "проекции" модели предметной области - медицинского обслуживания. Прошу покритиковать нотацию и прочее...

Может есть замечания

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

По Д1 - Вы смешиваете бизнес и ИС, а  этого нельзя делать. Либо показываем бизнес (и пофиг как данные передаются, хоть 1000 негров бегают), либо показывает компоненты ИС.

Так это... Ну, как ее?.. Во! Это - контекстная диаграмма. Вся тема про это самое 

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

А я думал, что это нотация Эрикссона-Пенкера (Irr советовала) . Вот английский <<result>> на русский <<результат>>, может, и не стоило менять. Но это я для своих "Заинтересованных лиц". Galogen писал, что можно переопределить.

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

Насчет 1 д. Если ИС уже имеется и внедрена, и используется, то конечно ее нужно построить(включить) в контекст. Если же ИС предполагется сделать - то имхо в контекст ее включать как бы и не надо, хотя если изобразить контекст в стиле Захмана или TOGAF, почему бы и нет:)

Как бы сказал Boatman- а какова цель, кков ожидаемый или идеальный результат.

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

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

Эти события как бы последние звенья в некоторой цепи. Например: Мобильный_персонал Принимает_решение Начать_исследование. Тут "Начать исследование" ПОЛУЧАЕТСЯ в результате решения. Такая логика выбора этого типа события. Ниже используется "Интерпретировать..." в виде посылаемого события, т.к. это уведомление, которое нужно ждать.
 

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

Процесс показан фазами, которые идут слева направо. Сам процесс - последовательность фаз, идет сверху вниз. Показан поток информации (пунктиром) сверху вниз до анализа.

А как показывать, что "выход одной есть вход другой" в этой нотации на диаграмме анализа?

А как показывать, что "выход одной есть вход другой" в этой нотации на диаграмме анализа?

Вообще термин нотация Эрриксона-Пенкера не совсем корректна. Скорее нужно говорить о расширении UML. Просто данные авторы попытались расширить UML средствами моделирования бизнес-процессов.

Отчего они отталкивались мне не совсем ясно, но можно предположить от IDEF0 или SADT в широком смысле слова.
Кроме того, они очень внимательно использует термин БП. А любой БП имеет владельца, который владеет (управляет) БП, есть выходы - т.е. назначение БП, что БП производит, входы - то из чего БП делает выходы, и ресурсы - с помощью чего БП делает выходы, преобразуя входы под управлением. Еще можно добавить, что БП имеет цель. Цель каждого БП, подчинена более общей цели. Эта иерархическая цепочка приводит нас к цели всего бизнеса или дела - который и может быть тем контекстом, который Вы пытаетесь представить.

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

Авторы добавили события, чего нет в IDEF0, и чего нет явно в диаграммах активности прошлых версий UML.

Потому нет ничего сложного в передачи управления с выхода на вход.