Здравствуйте.
Во вложении кусок диаграммы вариантов использования из моей курсовой работы "Терминал по продаже авиабилетов".
Вариант использования - просмотр расписания рейсов. Клиент подходит к терминалу, вводит параметры поиска, терминал обращается к информационной системе аэропорта, в которой хранятся данные по рейсам.
Спецификация варианта использования:
1.Основной поток событий
  1.1.Пользователь выбирает пункт отправления
  1.2.Пользователь выбирает пункт назначения
  1.3.Пользователь выбирает дату рейса
  1.4.Терминал обращается к ИС аэропорта для получения списка рейсов на выбранную дату. Если на выбранную дату рейсов нет, то выполняется альтернативный поток 1
  1.5.Терминал выводит список рейсов на данное число  
  1.6.Пользователь распечатывает список рейсов
2. Альтернативный поток событий 1:
  2.1.Терминал выводит сообщение о том, что рейсов на выбранную дату нет
Корректна ли такая спецификация?

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

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

Я вот кстати подумал, а может быть надо сделать немного иначе: ввести сущность список рейсов (локальная бд), куда помещать результат выборки, а потом отображать на форме данные из этой сущности?

а потом отображать на форме данные из этой сущности?

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

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

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

1. Список рейсов - плохая сущность, либо нужно показать, что это действительно сущность.
2. Нужно показать Актора: ИС аэропорта - это позволит понять и определить системный события и операции при взаимодействии системы с ИС аэропорта
3. Дуг Рознеберг (и я с ним согласен) советую, чтобы избежать ошибок делать так: гранчиные классы и сущностные классы - есть СУЩЕСТВИТЕЛЬНОЕ, управляющие классы - ГЛАГОЛЫ
  Nouns can talk to verbs (and vice versa). - Существительные могут разговаривать с глаголами и наоборот
  Nouns can’t talk to other nouns. - Существительные не могу разговаривать с другими существительными
  Verbs can talk to other verbs. - Глаголы могу разговаривать с другими глаголами
Это конечно не означает, что граничные классы не могу общаться между собой, или сущностные клсассы не могут обмениваться информацией. Например Главное окно может послать сообщение Покажись  - какомо-ту подчиненному окну. А некий сущностный класс Продажа, посылает сообщение Создать новую Строку продажи - например.
Но вот общение граничных классов с сущностными, т.е. классов области границы, логики представления не следует объединять с классами бизнес-логики

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

А, да и еще, тут получается тогда длинная цепочка в получении списка рейсов. Это нормально, нельзя ли ее сократить, как думаете?

Комментарии по поводу последней диаграммы.

Я бы сделал следующее
1) добавил еще одно сообщение от Клиента к Форме (5-ое по счету) - "Выполнить запрос" (кто-то должен дать команду на выполнение), хотя можно считать, как это нарисовано, что все начинается после ввода даты, но для меня это не логично
2) Принтер терминала переделал бы в действующее лицо
3) "Управлять терминалом" переименовал бы в "Контроллер терминала" или "Менеджер терминала".
4) "Интерфейс к ..." выбросил бы
5) не применял бы нотации граничных и прочих классов, а рисовал бы нормальные прямоугольники. Понимаемость диаграммы только увеличится

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

Вам тоже спасибо за комментарий.
1) Сообщение добавлю, действительно не очевидно
2) А почему принтер - действующее лицо? Он же является частью системы.
3) Переименовал
4) А почему интерфейс выбросить? Вадь должны же быть очерчены границы системы, разве нет? То есть у меня же ведь должен быть какой-то класс для связи двух систем. Или для этого спокойно можно использовать управляющий класс?
5) Ну просто задание такое, там все стереотипы надо указывать. Я бы тоже не применял, наверное, если бы опытнее был в этом деле. А пока вот применяю
А диаграмму деятельности я сделаю позже, сейчас хочется разобраться с диаграммой последовательности.
Исправленную диаграмму позже выложу

2) А почему принтер - действующее лицо? Он же является частью системы.

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

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

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

5) Ну просто задание такое, там все стереотипы надо указывать. Я бы тоже не применял, наверное, если бы опытнее был в этом деле. А пока вот применяю

Ну так вы автору этого задания скажите, что таких стереотипов нет в UML. По-моему RUP-овцы их придумали.

Так, кое-что начинаю понимать
1. По поводу принтера: ну допустим, будем писать драйвер, не суть. Все равно программу писать не надо Тогда это будет частью нашей системы, правильно?
2. Видимо, придется добавить драйвер клавиатуры и экрана, как в модели банкомата. А, и еще, нам преподаватель говорил, что должен быть протокол обмена между системами. Ну и, как я понимаю, этот протокол должен быть реализован граничным классом. Или нет? Ну, то есть в граничном классе задать атрибуты типа IP сервера, порт и т.д.

Так, кое-что начинаю понимать
1. По поводу принтера: ну допустим, будем писать драйвер, не суть. Все равно программу писать не надо Тогда это будет частью нашей системы, правильно?

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

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

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

Именно по этой причине я бы выкинул "Интерфейс к ...". Зачем раньше времени предлагать детали реализации?
Детализировать диаграмму всегда успеете.