Один прецедент определяет несколько сценариев

Диаграммы прецедентов и их нотация

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

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

Кроме
рамок системы или ее контекста на
диаграмме мы видим еще два вида связанных
с ней сущностей — это действующие
лица(экторы,
actors) и прецеденты.
Начнем с экторов. Довольно часто в
русскоязычной литературе по UML для
обозначения действующих лиц можно
встретить термин «актер«.
В принципе, смысл его более-менее понятен
и оригинальному английскому термину
он созвучен. Более того, есть еще одна
причина такого перевода. Какое слово первым
приходит к вам в голову, когда вы
слышите слово «актер«?
Да, конечно же — слово «роль»!
Именно о ролях мы вскоре и поговорим,
когда будем пытаться разобраться, что
скрывается за понятием «действующее
лицо». А пока, да простит нас читатель,
далее мы все же будем пользоваться
словом «эктор» — транскрипцией
оригинального термина. Помнится, мы уже
как-то писали о нашем отношении к
буквальному переводу терминологии…

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

Возможно,
слова «роли, исполняемые пользователем»
в определении эктора звучат не очень
понятно. Очень забавно это понятие
объясняется в Zicom Mentor:

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

Действительно,
наденьте шляпу пирата — и вы капитан
Джек Воробей, а наденьте цилиндр и вы —
Джек-потрошитель! Шутка…
«Физический» пользователь может
играть роль одного или даже нескольких
экторов, выполняя их функции в ходе
взаимодействия с системой. И наоборот,
роль одного и того же эктора может
выполняться несколькими пользователями.

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

Рис.
6.4.

Несмотря
на «человеческий» вид этого
обозначения, не следует забывать, что
экторы — это не обязательно люди. Эктором,
как мы уже говорили ранее, может быть
внешняя система, подсистема, класс и
т. д. Кстати, человечек ( «stick-person» )
— это не единственное обозначение эктора,
используемое в UML.
На диаграммах прецедентов обычно
применяется именно «человекоподобная»
форма эктора, но на других диаграммах,
и особенно в
случаях, когда эктор имеет атрибуты,
которые важно показать, используется
изображение эктора как класса со
стереотипом <<actor>> (рис.
6.5):

Рис.
6.5.

С
системой экторы, как мы уже сказали,
общаются через сообщения, но если
говорить на более высоком уровне
абстракции, в терминах модели прецедентов,
то взаимодействуют они с системой через
прецеденты. Один и тот же эктор может
быть связан с несколькими прецедентами,
и наоборот, один прецедент может
быть связан с несколькими разными
экторами. Ассоциации между эктором и
прецедентом всегда бинарные — т. е.
представляют отношения типа «один к
одному», использование кратности
недопустимо. Это не противоречит
сказанному выше: действительно, один
эктор может быть связан с несколькими
прецедентами, но только с помощью
отдельных ассоциаций — по одной
на каждый прецедент.
Мы видели это в нашем примере. Кстати,
там мы видели ассоциации, изображенные
не просто в виде линий, а стрелками.
Думаем, смысл этого обозначения вполне
понятен: этонаправленная
ассоциация и
стрелка (как и на других диаграммах)
всегда направлена в сторону той сущности,
от которой что-то требуют, чьим сервисом
пользуются и т. д.

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

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

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

Рис.
6.6.

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

Внимательный
читатель, возможно, отметил то, как
незаметно мы ввели в
употребление слово » сценарий «.
Что же такоесценарий и
как понятие сценария связано с понятием
прецедента? На первый вопрос хорошо
отвечают классики (Г. Буч):

Сценарий
— это конкретная последовательность
действий, иллюстрирующая поведение.

Сценарий —
это повествовательный рассказ о
совершаемых эктором действиях, история,
эпизод, происходящий в данных временных
рамках и данном контексте взаимодействия.
Сценарии (в различных формах представления)
широко применяются в процессе разработки
программного обеспечения. Как мы уже
только что отметили, написание сценария
напоминает написание художественного
рассказа, и этим объясняется тот факт,
что использование сценариев широко
распространено среди аналитиков, которые
часто обладают художественными или
литературными способностями. Несмотря
на непрерывный повествовательный
характер, сценарии можно рассматривать
как последовательности действий
(делать раскадровку ).
При разработке пользовательского
интерфейса сценарии описывают
взаимодействие между пользователем
(или категорией пользователей, например,
администраторами системы, конечными
пользователями) и системой.
Такой сценарий состоит
из последовательного описания комбинаций
отдельных действий и задач (например,
нажатий клавиш, щелчков по элементам
управления, ввода данных в соответствующие
поля и т. д.). Вспомните, к примеру, описания
последовательностей действий пользователя
(предназначенных для достижения
определенных результатов, решения
определенных задач), которые вы находите
в справке к малознакомой программе. То
же самое можно сказать о модных сейчас
«how-to videos», в которых такие
последовательности отображаются
визуально, на конкретных примерах. В
любом случае, цель подобных справочных
материалов — предоставить описание
типичных сценариев использования
системы, сценариев взаимодействия между
пользователем и системой.

Сценарии
также иногда можно увидеть на диаграмме
прецедентов. Иногда их изображают в
виде » листа
бумаги «,
на котором написано имя
файла,
— прямоугольника с загнутым нижним левым
уголком. В этом случае указанный файл содержит
в себе описание данного сценария. А
иногда сценарий записывается
в комментарий. Как вы, наверное, помните,
комментарии (ноутсы, notes) изображаются
прямоугольниками с загнутым верхним
правым углом и соединяются с элементом,
который они поясняют, пунктирной линией
(рис.
6.7).

Рис.
6.7.

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

Вот
пример простого (неформализованного)
текстового описания сценария.

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

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

А
вот тот же сценарий в
табличном представлении:

Действия пользователя	Реакция системы
Ввод логина, пароля, адреса электронной почты и нажатие кнопки «Далее»	Запрос ввода проверочного кода
Ввод проверочного кода и нажатие кнопки «Далее»	Проверка кода на соответствие изображенному на картинке

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

А
пока попробуем ответить на второй
вопрос, а именно: как
связаны понятия сценария и прецедента.
Прецеденты, как мы уже говорили, рождаются
из требований к системе. Но говорят они
о том, что делает система. Как система
это делает, говорят сценарии. Таким
образом, прецедент можно
специфицировать путем описания потока
действий или событий в текстовой форме
— в виде, понятном для «постороннего»
(не занятого в непосредственной разработке
системы) читателя. А ведь такое описание
— это и есть сценарий!
Таким образом, сценарии
специфицируют прецеденты.
И еще. Поскольку сценарии — это, по сути,
рассказы, они являются весьма эффективным
средством извлечения информации из
бесед с заказчиком и предоставляют
превосходное, понятное непрофессионалу
описание создаваемого приложения.
Сценарии, да и вообще диаграммы
прецедентов (дополненные
сценариями) являются отличным средством
общения между разработчиками и заказчиком,
причем, в силу простоты нотации, —
средством, понятным обеим сторонам. В
конечном итоге, взаимосвязь между
требованиями, прецедентами и сценариями
можно изобразить такой «псевдодиаграммой»
(рис.
6.8).

Рис.
6.8.

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

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

«Хватит
ходить вокруг да около!» — воскликнет
нетерпеливый читатель. Уже заканчиваем.
Мы просто хотели мягко подвести читателя
к вопросу об отношениях между прецедентами.
А отношения эти весьма многообразны.
Начнем со старого знакомого — отношения
обобщения (наследования, генерализации).
О генерализации мы уже говорили не раз,
когда рассматривали диаграммы
классов.
Но все же напомним суть этого понятия.
Как говорят классики, обобщение —
это отношение специализации
(обобщения), в котором объекты
специализированного элемента (потомка)
могут быть подставлены вместо объектов
обобщенного элемента (родителя, или
предка).

Точно
так же, как мы обычно поступаем с классами,
после того как мы выделили и описали
каждый прецедент,
мы должны просмотреть их все на предмет
наличия одинаковых действий — поискать,
а не выполняются ли (используются)
некоторые действия совместно несколькими
вариантами использования. Этот совместно
используемый фрагмент лучше описать в
отдельном прецеденте. Таким образом мы
уменьшим избыточность модели
за счет применения обобщения прецедентов
(иногда, правда, говорят не об обобщении,
а об использовании прецедентов;
почему — сейчас поймете). Как это и
«положено» при наследовании,
экземпляры обобщенных прецедентов
(потомков) сохраняют поведение, присущее
обобщающему прецеденту (предку). Другими
словами, наличие (использование) в
варианте использования X обобщенного
варианта использования Y говорит
нам о том, что экземпляр прецедента X включает
в себя поведение
прецедента Y.
Обобщения применяются, чтобы упростить
понимание модели вариантов использования
за счет многократного задействования
«заготовок» прецедентов для создания
прецедентов, необходимых заказчику
(помните, как мы рассматривали вопрос
о том, всегда ли необходимо создавать
новый класс,
или лучше воспользоваться готовым
решением, чувствуете аналогию?). Такие
«полные» прецеденты называются конкретными
прецедентами.
«Заготовки» прецедентов, созданные
лишь для многократного использования
в других прецедентах, называют абстрактными
прецедентами. Абстрактный прецедент (как
и абстрактный
класс)
не существует сам по себе,
но экземпляр конкретного прецедента
демонстрирует поведение, описываемое
абстрактными прецедентами, которые он
(повторно) использует. Прецедент,
который экторы наблюдают при взаимодействии
с системой («полный» прецедент,
как мы называли его ранее), часто называют
еще » реальным »
прецедентом.

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

Изображается обобщение,
как, конечно, помнит внимательный
читатель, линией с «незакрашенной»
треугольной стрелкой на конце. Обобщение —
это отношение между
предком и потомком, и стрелка всегда
указывает на предка. Если вспомнить,
что потомки наследуют (используют)
свойства предка, то вполне логично
вспоминается наше утверждение о том,
что стрелки в UMLвсегда
направлены в сторону того, от кого что-то
требуют, чьими сервисами пользуются
(рис.
6.9):

Рис.
6.9.

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

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

А
как же изображается включение? Да очень
просто — как зависимость (пунктирная
линия со стрелкой, помните?) со
стереотипом<<include>>.
При этом стрелка направлена, естественно,
в сторону включаемого прецедента. Этот
факт легко объяснить, если вспомнить
утверждение, которое мы уже несколько
раз использовали в этом курсе: стрелка
всегда направлена в сторону того
элемента, от которого что-то требуется,
чьими сервисами пользуются. А если
считать, что объемлющий прецедент включает
в себя, заимствует (использует) поведение
включаемых прецедентов, становится
ясно, что стрелка может быть направлена
только таким образом. А вот и диаграмма,
иллюстрирующая вышесказанное, которую
мы позаимствовали из Zicom Mentor (рис.
6.10):

увеличить
изображение
Рис.
6.10.

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

На
очереди — отношение расширения.
Чтобы уяснить себе смысл расширения,
представим себе, что мы говорим об оплате
некоторого купленного нами товара. Мы
можем оплатить товар наличными,
если сумма не превышает $ 100. Или оплатить
кредитной картой, если сумма находится
в пределах от $ 100 до $ 1000. Если же сумма
превышает $ 1000, нам придется братькредит.
Таким образом мы расширили
понимание операции оплаты
купленного товара и на случаи, когда
используются другие средства оплаты,
нежели наличные. Но сами эти случаи
возникают только при строго определенных
условиях: когда цена
товарапопадает
в определенные рамки.

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

Рис.
6.11.

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

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

Рис.
6.12.

В
этом примере регистрация пассажиров
авиарейса включает в себя контроль службы
безопасности, а при условии (указанном
в примечании после служебного слова
«Condition:»),
что человек часто летает и салон
переполнен (обратите внимание на
операторAND,
говорящий об одновременности выполнения
условий), класс билета
может быть повышен, например, с «эконом»
до «бизнес-класса». Причем такой
апгрейд может произойти только после
того, как билет предъявлен на стойку
регистрации — это и есть точка расширения.
Она описана (ее имя указано) в дополнительном
разделе прецедента
после служебной фразы «Extensionpoints:».
Предваряя вопрос читателя, скажем,
что прецедент может
иметь сколь угодно много точек расширения.
А сопоставить конкретный
расширяющий прецедент с
определенной точкой расширения можно,
прочитав условия расширения, указанные
в комментариях, — само условие записывается
после служебного слова «Condition:»
в фигурных скобках, за которыми идет
служебная фраза «Extension point:»,
и после нее указывается имя точки
расширения. Посмотрите еще раз на наш
пример с регистрацией пассажиров в
аэропорту и убедитесь сами, что все это
очень просто!

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

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

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

На
этом разговор о нотации диаграмм
прецедентов можно было бы и завершить.
Хотелось бы только сказать еще пару
слов о соотношении между понятиями
прецедента и кооперации.
О кооперации мы уже говорили ранее
(помните диаграммы
взаимодействия?)
как о множестве ролей, работающих вместе,
чтобы обеспечить некоторое поведение
системы. Мы также упоминали о том, что
прецеденты отвечают на вопрос «что
делает система?», но не говорят, как
именно она это делает. На этапе анализа
понимать, как именно система реализует
свое поведение, действительно не нужно.
Но при переходе к реализации неплохо
бы знать, какие
именно классы (или другие элементы
модели), совместно работая, обеспечивают
нужное поведение.
То есть мы логично перешли от разговора
о прецедентах к разговору о кооперации!
Недаром обозначения кооперации и
прецедента очень похожи (читатель,
конечно, помнит, что кооперация обозначается
пунктирным эллипсом) (рис.
6.13).

Рис.
6.13.

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

Источник

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

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

«Хватит ходить вокруг да около!» — воскликнет нетерпеливый читатель. Уже заканчиваем. Мы просто хотели мягко подвести читателя к вопросу об отношениях между прецедентами. А отношения эти весьма многообразны. Начнем со старого знакомого — отношения обобщения (наследования, генерализации). О генерализации мы уже говорили не раз, когда рассматривали диаграммы классов. Но все же напомним суть этого понятия. Как говорят классики, обобщение — это отношение специализации (обобщения), в котором объекты специализированного элемента (потомка) могут быть подставлены вместо объектов обобщенного элемента (родителя, или предка).

Точно так же, как мы обычно поступаем с классами, после того как мы выделили и описали каждый прецедент, мы должны просмотреть их все на предмет наличия одинаковых действий — поискать, а не выполняются ли (используются) некоторые действия совместно несколькими вариантами использования. Этот совместно используемый фрагмент лучше описать в отдельном прецеденте. Таким образом мы уменьшим избыточность модели за счет применения обобщения прецедентов (иногда, правда, говорят не об обобщении, а об использовании прецедентов; почему — сейчас поймете). Как это и «положено» при наследовании, экземпляры обобщенных прецедентов (потомков) сохраняют поведение, присущее обобщающему прецеденту (предку). Другими словами, наличие (использование) в варианте использования X обобщенного варианта использования Y говорит нам о том, что экземпляр прецедента X включает в себя поведение прецедента Y.
Обобщения применяются, чтобы упростить понимание модели вариантов использования за счет многократного задействования «заготовок» прецедентов для создания прецедентов, необходимых заказчику (помните, как мы рассматривали вопрос о том, всегда ли необходимо создавать новый класс, или лучше воспользоваться готовым решением, чувствуете аналогию?). Такие «полные» прецеденты называются конкретными прецедентами. «Заготовки» прецедентов, созданные лишь для многократного использования в других прецедентах, называют абстрактными прецедентами. Абстрактный прецедент (как и абстрактный класс) не существует сам по себе, но экземпляр конкретного прецедента демонстрирует поведение, описываемое абстрактными прецедентами, которые он (повторно) использует. Прецедент, который экторы наблюдают при взаимодействии с системой («полный» прецедент, как мы называли его ранее), часто называют еще » реальным » прецедентом.

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

Изображается обобщение, как, конечно, помнит внимательный читатель, линией с «незакрашенной» треугольной стрелкой на конце. Обобщение — это отношение между предком и потомком, и стрелка всегда указывает на предка. Если вспомнить, что потомки наследуют (используют) свойства предка, то вполне логично вспоминается наше утверждение о том, что стрелки в UML всегда направлены в сторону того, от кого что-то требуют, чьими сервисами пользуются (рис. 6.9):

Рис.
6.9.

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

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

А как же изображается включение? Да очень просто — как зависимость (пунктирная линия со стрелкой, помните?) со стереотипом <<include>>. При этом стрелка направлена, естественно, в сторону включаемого прецедента. Этот факт легко объяснить, если вспомнить утверждение, которое мы уже несколько раз использовали в этом курсе: стрелка всегда направлена в сторону того элемента, от которого что-то требуется, чьими сервисами пользуются. А если считать, что объемлющий прецедент включает в себя, заимствует (использует) поведение включаемых прецедентов, становится ясно, что стрелка может быть направлена только таким образом. А вот и диаграмма, иллюстрирующая вышесказанное, которую мы позаимствовали из Zicom Mentor (рис. 6.10):

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

На очереди — отношение расширения. Чтобы уяснить себе смысл расширения, представим себе, что мы говорим об оплате некоторого купленного нами товара. Мы можем оплатить товар наличными, если сумма не превышает $ 100. Или оплатить кредитной картой, если сумма находится в пределах от $ 100 до $ 1000. Если же сумма превышает $ 1000, нам придется брать кредит. Таким образом мы расширили понимание операции оплаты купленного товара и на случаи, когда используются другие средства оплаты, нежели наличные. Но сами эти случаи возникают только при строго определенных условиях: когда цена товара попадает в определенные рамки.

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

Рис.
6.11.

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

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

Рис.
6.12.

В этом примере регистрация пассажиров авиарейса включает в себя контроль службы безопасности, а при условии (указанном в примечании после служебного слова «Condition:»), что человек часто летает и салон переполнен (обратите внимание на оператор AND, говорящий об одновременности выполнения условий), класс билета может быть повышен, например, с «эконом» до «бизнес-класса». Причем такой апгрейд может произойти только после того, как билет предъявлен на стойку регистрации — это и есть точка расширения. Она описана (ее имя указано) в дополнительном разделе прецедента после служебной фразы «Extension points:». Предваряя вопрос читателя, скажем, что прецедент может иметь сколь угодно много точек расширения. А сопоставить конкретный расширяющий прецедент с определенной точкой расширения можно, прочитав условия расширения, указанные в комментариях, — само условие записывается после служебного слова «Condition:» в фигурных скобках, за которыми идет служебная фраза
«Extension point:», и после нее указывается имя точки расширения. Посмотрите еще раз на наш пример с регистрацией пассажиров в аэропорту и убедитесь сами, что все это очень просто!

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

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

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

На этом разговор о нотации диаграмм прецедентов можно было бы и завершить. Хотелось бы только сказать еще пару слов о соотношении между понятиями прецедента и кооперации. О кооперации мы уже говорили ранее (помните диаграммы взаимодействия?) как о множестве ролей, работающих вместе, чтобы обеспечить некоторое поведение системы. Мы также упоминали о том, что прецеденты отвечают на вопрос «что делает система?», но не говорят, как именно она это делает. На этапе анализа понимать, как именно система реализует свое поведение, действительно не нужно. Но при переходе к реализации неплохо бы знать, какие именно классы (или другие элементы модели), совместно работая, обеспечивают нужное поведение. То есть мы логично перешли от разговора о прецедентах к разговору о кооперации! Недаром обозначения кооперации и прецедента очень похожи (читатель, конечно, помнит, что кооперация обозначается пунктирным эллипсом) (рис. 6.13).

Рис.
6.13.

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

Источник

Лекция 6:

Диаграммы прецедентов: крупным планом

Несколько слов о требованиях

Итак, поговорим о требованиях. Что это такое, мы, в общем, понимаем — когда заказчик описывает нам, чего же именно он хочет, мы всегда слышим фразы типа «хотелось бы, чтобы проверка обновлений проводилась автоматически, как в антивирусах», «хочу большую зеленую кнопку в центре окна, которая начинает процесс», «программа должна позволять просматривать и печатать отчеты», «и чтоб красивенько все было, с полупрозрачностями, как в Висте», «при выходе должно выводиться подтверждение» и т. д. и т. п. Конечно, как настоящие разработчики, мы понимаем и то, что заказчик никогда не знает, что именно ему нужно, а если понимает, то объяснить не может. Но ведь фразы-то всегда, по сути, одинаковы! Они описывают, как заказчик представляет себе систему, чего заказчик хочет от системы, функциональность, которой он от нее ожидает, требования, которые к ней предъявляет.

Если обратиться к классикам, например, к той же «банде трех» (Якобсон, Буч, Рамбо), мы узнаем, что требование — это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс разработки ПО в виде » черного ящика » (уверены, читатель знает, что это такое, если нет — «Википедия» к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого «черного ящика» будет подаваться именно набор требований к программному продукту (рис. 6.1)!

Рис. 6.1.

Кстати, какую диаграмму напоминает этот рисунок? Правильно, диаграмму активностей. И выбор именно этой диаграммы тут абсолютно оправдан — помните, мы говорили, что диаграммы активностей часто используют для описания бизнес-процессов? Единственный нюанс: обычно процесс разработки не заканчивается с выпуском программного продукта — грядет новая итерация, новые, уточненные требования, новая версия и т. д.

Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего «черного ящика» подается набор требований. Но в какой форме? Как их документируют, эти требования? Думаю, большинство читателей помнит, что такое техническое задание — основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, посути, не что иное, как требования к создаваемой системе!

Рекомендуемые материалы

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

· диаграммы прецедентов;

· нефункциональные требования.

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

Нефункциональные требования — это описание таких свойств системы, как особенности среды и реализации, производительность,расширяемость, надежность и т. д. Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный список дополнительных требований к системе (рис. 6.2).

Рис. 6.2.

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

· четко разграничить систему и ее окружение;

· определить, какие действующие лица и как именно взаимодействуют с системой, какой функционал (варианты использования) ожидается от системы;

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

Подобный вид деятельности обычно выполняется в такой последовательности:

1. Определение действующих лиц.

2. Определение прецедентов.

3. Составление описания каждого прецедента.

4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).

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

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

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

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

Здесь нигде не сказано о том, что система должна быть написана на ASP.NET. Почему — понятно: это ведь нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. Читатель, внимательно прочитавший предыдущие лекции, заподозрит, что в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно бы применить генерализацию. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис. 6.3):

Рис. 6.3.

Диаграммы прецедентов и их нотация

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

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

Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей — это действующие лица(экторы, actors) и прецеденты. Начнем с экторов. Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин «актер«. В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово «актер«? Да, конечно же — слово «роль»! Именно о ролях мы вскоре и поговорим, когда будем пытаться разобраться, что скрывается за понятием «действующее лицо». А пока, да простит нас читатель, далее мы все же будем пользоваться словом «эктор» — транскрипцией оригинального термина. Помнится, мы уже как-то писали о нашем отношении к буквальному переводу терминологии…

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

Возможно, слова «роли, исполняемые пользователем» в определении эктора звучат не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor:

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

Действительно, наденьте шляпу пирата — и вы капитан Джек Воробей, а наденьте цилиндр и вы — Джек-потрошитель! Шутка… «Физический» пользователь может играть роль одного или даже нескольких экторов, выполняя их функции в ходе взаимодействия с системой. И наоборот, роль одного и того же эктора может выполняться несколькими пользователями.

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

Рис. 6.4.

Несмотря на «человеческий» вид этого обозначения, не следует забывать, что экторы — это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д. Кстати, человечек ( «stick-person» ) — это не единственное обозначение эктора, используемое в UML. На диаграммах прецедентов обычно применяется именно «человекоподобная» форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом <<actor>> (рис. 6.5):

Рис. 6.5.

С системой экторы, как мы уже сказали, общаются через сообщения, но если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты. Один и тот же эктор может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными экторами. Ассоциации между эктором и прецедентом всегда бинарные — т. е. представляют отношения типа «один к одному», использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один эктор может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций — по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого обозначения вполне понятен: этонаправленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д.

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

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

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

Рис. 6.6.

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

Внимательный читатель, возможно, отметил то, как незаметно мы ввели в употребление слово » сценарий «. Что же такоесценарий и как понятие сценария связано с понятием прецедента? На первый вопрос хорошо отвечают классики (Г. Буч):

Сценарий — это конкретная последовательность действий, иллюстрирующая поведение.

Сценарий — это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия. Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения. Как мы уже только что отметили, написание сценария напоминает написание художественного рассказа, и этим объясняется тот факт, что использование сценариев широко распространено среди аналитиков, которые часто обладают художественными или литературными способностями. Несмотря на непрерывный повествовательный характер, сценарии можно рассматривать как последовательности действий (делать раскадровку ). При разработке пользовательского интерфейса сценарии описывают взаимодействие между пользователем (или категорией пользователей, например, администраторами системы, конечными пользователями) и системой. Такой сценарий состоит из последовательного описания комбинаций отдельных действий и задач (например, нажатий клавиш, щелчков по элементам управления, ввода данных в соответствующие поля и т. д.). Вспомните, к примеру, описания последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе. То же самое можно сказать о модных сейчас «how-to videos», в которых такие последовательности отображаются визуально, на конкретных примерах. В любом случае, цель подобных справочных материалов — предоставить описание типичных сценариев использования системы, сценариев взаимодействия между пользователем и системой.

Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их изображают в виде » листа бумаги «, на котором написано имя файла, — прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 6.7).

Рис. 6.7.

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

Вот пример простого (неформализованного) текстового описания сценария.

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

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

А вот тот же сценарий в табличном представлении:

Действия пользователя	Реакция системы
Ввод логина, пароля, адреса электронной почты и нажатие кнопки «Далее»	Запрос ввода проверочного кода
Ввод проверочного кода и нажатие кнопки «Далее»	Проверка кода на соответствие изображенному на картинке

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

А пока попробуем ответить на второй вопрос, а именно: как связаны понятия сценария и прецедента. Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать путем описания потока действий или событий в текстовой форме — в виде, понятном для «постороннего» (не занятого в непосредственной разработке системы) читателя. А ведь такое описание — это и есть сценарий! Таким образом, сценарии специфицируют прецеденты. И еще. Поскольку сценарии — это, по сути, рассказы, они являются весьма эффективным средством извлечения информации из бесед с заказчиком и предоставляют превосходное, понятное непрофессионалу описание создаваемого приложения. Сценарии, да и вообще диаграммы прецедентов (дополненные сценариями) являются отличным средством общения между разработчиками и заказчиком, причем, в силу простоты нотации, — средством, понятным обеим сторонам. В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой «псевдодиаграммой» (рис. 6.8).

Рис. 6.8.

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

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

«Хватит ходить вокруг да около!» — воскликнет нетерпеливый читатель. Уже заканчиваем. Мы просто хотели мягко подвести читателя к вопросу об отношениях между прецедентами. А отношения эти весьма многообразны. Начнем со старого знакомого — отношения обобщения (наследования, генерализации). О генерализации мы уже говорили не раз, когда рассматривали диаграммы классов. Но все же напомним суть этого понятия. Как говорят классики, обобщение — это отношение специализации (обобщения), в котором объекты специализированного элемента (потомка) могут быть подставлены вместо объектов обобщенного элемента (родителя, или предка).

Точно так же, как мы обычно поступаем с классами, после того как мы выделили и описали каждый прецедент, мы должны просмотреть их все на предмет наличия одинаковых действий — поискать, а не выполняются ли (используются) некоторые действия совместно несколькими вариантами использования. Этот совместно используемый фрагмент лучше описать в отдельном прецеденте. Таким образом мы уменьшим избыточность модели за счет применения обобщения прецедентов (иногда, правда, говорят не об обобщении, а об использовании прецедентов; почему — сейчас поймете). Как это и «положено» при наследовании, экземпляры обобщенных прецедентов (потомков) сохраняют поведение, присущее обобщающему прецеденту (предку). Другими словами, наличие (использование) в варианте использования X обобщенного варианта использования Y говорит нам о том, что экземпляр прецедента X включает в себя поведение прецедента Y. Обобщения применяются, чтобы упростить понимание модели вариантов использования за счет многократного задействования «заготовок» прецедентов для создания прецедентов, необходимых заказчику (помните, как мы рассматривали вопрос о том, всегда ли необходимо создавать новый класс, или лучше воспользоваться готовым решением, чувствуете аналогию?). Такие «полные» прецеденты называются конкретными прецедентами. «Заготовки» прецедентов, созданные лишь для многократного использования в других прецедентах, называют абстрактными прецедентами. Абстрактный прецедент (как и абстрактный класс) не существует сам по себе, но экземпляр конкретного прецедента демонстрирует поведение, описываемое абстрактными прецедентами, которые он (повторно) использует. Прецедент, который экторы наблюдают при взаимодействии с системой («полный» прецедент, как мы называли его ранее), часто называют еще » реальным » прецедентом.

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

Изображается обобщение, как, конечно, помнит внимательный читатель, линией с «незакрашенной» треугольной стрелкой на конце. Обобщение — это отношение между предком и потомком, и стрелка всегда указывает на предка. Если вспомнить, что потомки наследуют (используют) свойства предка, то вполне логично вспоминается наше утверждение о том, что стрелки в UMLвсегда направлены в сторону того, от кого что-то требуют, чьими сервисами пользуются (рис. 6.9):

Рис. 6.9.

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

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

А как же изображается включение? Да очень просто — как зависимость (пунктирная линия со стрелкой, помните?) со стереотипом<<include>>. При этом стрелка направлена, естественно, в сторону включаемого прецедента. Этот факт легко объяснить, если вспомнить утверждение, которое мы уже несколько раз использовали в этом курсе: стрелка всегда направлена в сторону того элемента, от которого что-то требуется, чьими сервисами пользуются. А если считать, что объемлющий прецедент включает в себя, заимствует (использует) поведение включаемых прецедентов, становится ясно, что стрелка может быть направлена только таким образом. А вот и диаграмма, иллюстрирующая вышесказанное, которую мы позаимствовали из Zicom Mentor (рис. 6.10):

увеличить изображение
Рис. 6.10.

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

На очереди — отношение расширения. Чтобы уяснить себе смысл расширения, представим себе, что мы говорим об оплате некоторого купленного нами товара. Мы можем оплатить товар наличными, если сумма не превышает $ 100. Или оплатить кредитной картой, если сумма находится в пределах от $ 100 до $ 1000. Если же сумма превышает $ 1000, нам придется братькредит. Таким образом мы расширили понимание операции оплаты купленного товара и на случаи, когда используются другие средства оплаты, нежели наличные. Но сами эти случаи возникают только при строго определенных условиях: когда цена товарапопадает в определенные рамки.

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

Рис. 6.11.

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

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

Рис. 6.12.

В этом примере регистрация пассажиров авиарейса включает в себя контроль службы безопасности, а при условии (указанном в примечании после служебного слова «Condition:»), что человек часто летает и салон переполнен (обратите внимание на операторAND, говорящий об одновременности выполнения условий), класс билета может быть повышен, например, с «эконом» до «бизнес-класса». Причем такой апгрейд может произойти только после того, как билет предъявлен на стойку регистрации — это и есть точка расширения. Она описана (ее имя указано) в дополнительном разделе прецедента после служебной фразы «Extensionpoints:». Предваряя вопрос читателя, скажем, что прецедент может иметь сколь угодно много точек расширения. А сопоставить конкретный расширяющий прецедент с определенной точкой расширения можно, прочитав условия расширения, указанные в комментариях, — само условие записывается после служебного слова «Condition:» в фигурных скобках, за которыми идет служебная фраза «Extension point:», и после нее указывается имя точки расширения. Посмотрите еще раз на наш пример с регистрацией пассажиров в аэропорту и убедитесь сами, что все это очень просто!

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

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

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

На этом разговор о нотации диаграмм прецедентов можно было бы и завершить. Хотелось бы только сказать еще пару слов о соотношении между понятиями прецедента и кооперации. О кооперации мы уже говорили ранее (помните диаграммы взаимодействия?) как о множестве ролей, работающих вместе, чтобы обеспечить некоторое поведение системы. Мы также упоминали о том, что прецеденты отвечают на вопрос «что делает система?», но не говорят, как именно она это делает. На этапе анализа понимать, как именно система реализует свое поведение, действительно не нужно. Но при переходе к реализации неплохо бы знать, какие именно классы (или другие элементы модели), совместно работая, обеспечивают нужное поведение. То есть мы логично перешли от разговора о прецедентах к разговору о кооперации! Недаром обозначения кооперации и прецедента очень похожи (читатель, конечно, помнит, что кооперация обозначается пунктирным эллипсом) (рис. 6.13).

Рис. 6.13.

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

Моделирование при помощи диаграмм прецедентов

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

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

· Прецеденты дают возможность аналитикам, пользователям и разработчикам говорить на одном языке: используя прецеденты, аналитики (эксперты в предметной области) могут на основе пожеланий заказчика описать поведение системы с точки зрения пользователя с такой степенью детализации, что разработчики смогут без труда сконструировать «внутренности» системы. В то же время, нотация диаграмм прецедентов настолько проста, что даже неподготовленный пользователь (заказчик) способен понять их смысл и помочь в их уточнении — ведь картинки (а тем более комиксы, каковыми, по сути, являются диаграммы UML) воспринимаются намного легче, чем текст!

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

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

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

· С целью поиска ошибок и чтобы убедиться в адекватности дизайна:

отличная идея после первого перевода с UML на язык программирования сделать обратный перевод и сравнить исходные и восстановленные UML-модели (желательно, чтобы эти переводы выполнялись разными командами). Это позволит убедиться в том, что дизайн системы соответствует модели, никакая информация в ходе перевода не была утеряна, да и попросту выловить некоторые «баги». Такой подход называется обратной семантической трассировкой (или RST — Reverse SemanticTraceability) и разрабатывается компанией INTSPEI (http://www.intspei.com) как одна из базовых техник методологии INTSPEI P-Modeling Framework, краткие сведения о которой вы можете найти в приложении к этому курсу.

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

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

Рис. 6.14.

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

Рис. 6.15.

Следующие три примера уже по традиции мы позаимствовали с сайта шуток на UML (http://www.umljokes.com), продолжая доказывать, что на UML можно шутить — это полноценный язык общения, который можно применять так же, как и любой другой. Первый из примеров — это часть всем известной сказки о «Курочке Рябе», которую автор очень красочно оформил (рис. 6.16).

Рис. 6.16.

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

Рис. 6.17.

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

И наконец, третья картинка, которая не является хорошим примером диаграммы прецедентов, но просто забавна. Это рассказ о способах поведения, позволяющих гарантированно (!) провалить любой экзамен (рис. 6.18):

Рис. 6.18.

Выводы

· Модель прецедентов позволяет описать систему на концептуальном уровне.

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

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

· Эктор — это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью.

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

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

· Каждый прецедент реализуется одной или несколькими кооперациями.

· Сценарии специфицируют прецеденты, а диаграммы взаимодействий визуализируют сценарии.

Контрольные вопросы

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

Если Вам понравилась эта лекция, то понравится и эта — 1.14 Построение частотных характеристик.

· Какие способы изображения экторов вы знаете?

· В какие отношения могут вступать экторы между собой?

· В чем состоит смысл отношений включения и расширения?

· Что такое точка расширения?

· Перечислите известные вам причины использования прецедентов.

· Как прецеденты применяют в прямом и обратном проектировании?

Источник

Каким символом изображается конечное состояние потока?

E
D
B
A
(Правильный ответ) C

Какой элемент диаграмм кооперации изображен на рисунке?

композитный объект
часть композитного объекта
(Правильный ответ) мультиобъект
порт
активный объект

Что означает аббревиатура OMG?

Object Modeling Group
(Правильный ответ) Object Management Group
Object Method Group
Object Markup Group
Object Methodology Group

В каком количественном отношении находятся сценарии и прецеденты?

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

Каким символом в диаграммах активностей изображается конструкция выбора?

D
(Правильный ответ) B
A
C
E

прецеденты
(Правильный ответ) экторы
классы
состояния
активности

Обязательно ли изображение фокуса управления на диаграммах последовательностей?

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

Начало какого этапа жизненного цикла ПО знаменует собой создание диаграммы классов?

внедрения
анализа
тестирования
(Правильный ответ) проектирования
разработки

Как на диаграммах кооперации обозначаются параллельные потоки сообщений?

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

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

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

Что такое композитный объект?

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

Что такое найденные сообщения?

сообщения, отправленные объектом самому себе
сообщения, для которых известен отправитель, но неизвестен получатель
сообщения, в результате получения которых не было отправлено ответное сообщение
(Правильный ответ) сообщения, для которых известен адресат, но неизвестен отправитель
сообщения, в результате которых не было получено некоторое значение

Что такое требование к ПО?

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

Какое место диаграммы взаимодействия занимают в жизненном цикле разработки ПО?

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

В чем состоит смысл операции расширения прецедента?

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

Какие артефакты пришли на смену техническому заданию?

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

Выберите из списка истинные утверждения, касающиеся понятия эктора

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

Чем конечное состояние потока отличается от конечного состояния?

конечное состояние потока означает завершение текущей деятельности, а конечное состояние говорит о завершении всех потоков управления внутри деятельности
(Правильный ответ) конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении всех потоков управления внутри деятельности
конечное состояние потока означает завершение одного потока внутри деятельности, а конечное состояние говорит о завершении всех потоков управления, не относящихся к текущей деятельности
конечное состояние потока означает завершение всех потоков управления внутри деятельности, а конечное состояние говорит о завершении одного потока управления
конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении текущей деятельности

В каком отношении находятся понятия прецедента и кооперации?

ассоциации
генерализации
включения
зависимости
(Правильный ответ) реализации

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

таким образом обозначаются синхронные сообщения
(Правильный ответ) таким образом обозначаются ответные сообщения
таким образом обозначаются рефлексивные сообщения
таким образом обозначаются потерянные сообщения
таким образом обозначаются асинхронные сообщения

Сколько конечных состояний может содержать диаграмма активностей?

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

Как на диаграммах прецедентов изображается включение прецедентов?

(Правильный ответ) в виде зависимости со стереотипом <<include>>
в виде зависимости со стереотипом <<switch on>>
в виде зависимости со стереотипом <<within>>
в виде зависимости со стереотипом <<contain>>
в виде зависимости со стереотипом <<inside>>

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

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

Какие из фрагментов диаграмм последовательностей НЕ противоречат нотации UML?

E
D
(Правильный ответ) B
A
(Правильный ответ) C

Какой смысл вкладывается в понятие плавательных дорожек (swimlanes)?

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

В чем состоит различие между диаграммой последовательностей и диаграммой кооперации?

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

Какие экторы вовлечены в выполнение прецедента Use Case E?

Actor A, Actor B и Actor C
Actor B и Actor C
Actor A
Actor C
(Правильный ответ) Actor A и Actor C

Какие из перечисленных представлений системы могут содержать диаграммы деятельностей?

(Правильный ответ) вид с точки зрения проектирования
(Правильный ответ) вид с точки зрения развертывания
(Правильный ответ) вид системы с точки зрения прецедентов
(Правильный ответ) вид с точки зрения процессов
(Правильный ответ) вид с точки зрения реализации

Что такое асинхронное сообщение?

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

Что такое диаграмма взаимодействия?

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

Разновидностью какой диаграммы UML являются диаграммы активностей?

диаграммы классов
(Правильный ответ) диаграммы состояний
диаграммы последовательностей
диаграммы развертывания
диаграммы прецедентов

Выберите из списка истинные утверждения

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

C построения какой диаграммы должен начинаться процесс проектирования в соответствии с Objectory?

диаграммы состояний
диаграммы активностей
(Правильный ответ) диаграммы прецедентов
диаграммы последовательностей
диаграммы классов

Какой смысл вкладывают в понятие эктора?

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

Частным случаем какой диаграммы является диаграмма деятельностей?

диаграммы кооперации
диаграммы последовательностей
(Правильный ответ) диаграммы состояний
диаграммы объектов
диаграммы прецедентов

Элементы нотации каких видов используются в UML?

(Правильный ответ) фигуры
(Правильный ответ) линии
(Правильный ответ) значки
(Правильный ответ) надписи
операторы

Какие конструкции чаще всего используют при моделировании операций с помощью диаграмм активностей?

траектория объектов
(Правильный ответ) синхронизация
плавательные дорожки
(Правильный ответ) принятие решения
конечное состояние потока

Каким образом объекты соотносятся с деятельностями при изображении траектории объекта?

с помощью композиции
с помощью ассоциации
с помощью генерализации
с помощью агрегации
(Правильный ответ) с помощью зависимости

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

варианты детализации состояния
иерархию состояний
состояния, активные в данный момент
альтернативные подсостояния
(Правильный ответ) параллельные подсостояния

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

E
D
C
(Правильный ответ) B
A

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

(Правильный ответ) семантика
(Правильный ответ) синтаксис
морфология
орфография
(Правильный ответ) прагматика

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

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

Для чего используется обратное проектирование?

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

Что такое синхронное сообщение?

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

Для чего диаграммы деятельности чаще всего используются на практике?

(Правильный ответ) для моделирования процессов
(Правильный ответ) для моделирования операций
для моделирования интерфейсов
для моделирования взаимодействий
для моделирования структуры

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

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

Выберите из списка ЛОЖНЫЕ утверждения относительно текстовых комментариев в UML-моделях

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

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

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

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

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

Источник

Главная / Программирование /
Введение в UML / Тест 6

Упражнение 1:

Номер 1

Что такое требование к ПО?

Ответ:

(1) желаемая функциональность, свойство или поведение системы

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

(3) формальные критерии соответствия системы желаниям заказчика

(4) подробное описание структуры и функционала будущей системы

(5) формальное описание внутреннего устройства будущей системы

Номер 2

Какие артефакты пришли на смену техническому заданию?

Ответ:

(1) диаграммы прецедентов

(2) нефункциональные требования

(3) диаграммы классов

(4) диаграммы развертывания

(5) диаграммы компонентов

Номер 3

Что такое прецедент?

Ответ:

(1) функциональность, уже однажды реализованная в некоторой системе, на которую можно ссылаться при разработке

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

(3) функциональность системы, стандартная «де-факто» для всех систем подобного класса

(4) функциональность системы, стандартная для всех систем подобного класса, реализованная в стандартных библиотеках

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

Упражнение 2:

Номер 1

Какие цели преследует аналитик при идентификации прецедентов?

Ответ:

(1) четко разграничить систему и ее окружение

(2) выделить нефункциональные требования

(3) описать структуру и внутреннее устройство будущей системы

(4) определить, какие действующие лица и как именно взаимодействуют с системой

(5) определить и описать в словаре предметной области общие понятия, описывающие функционал системы

Номер 2

Какие шаги обычно выделяют в процессе идентификации прецедентов?

Ответ:

(1) определение действующих лиц

(2) определение прецедентов

(3) описание модели прецедентов в целом

(4) описание структуры системы

Номер 3

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

Ответ:

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

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

(3) нефункциональные требования часто выносятся в отдельный список дополнительных требований к системе

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

Упражнение 3:

Номер 1

Какой смысл вкладывают в понятие эктора?

Ответ:

(1) набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью

(2) набор пользователей, взаимодействующих с некоторой сущностью

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

(4) обобщенный пользователь системы, взаимодействующий с ней

(5) усредненный пользователь системы, взаимодействующий с ней

Номер 2

Какие из представленных на рисунке символов являются стандартными обозначениями эктора?

Ответ:

(1) A

(2) B

(3) C

(4) D

(5) E

Номер 3

Какое значение имеет стрелка, изображенная на линии, связывающей эктора и прецедент?

Ответ:

(1) она указывает последовательность вызова функционала системы

(2) она указывает на последовательность использования прецедентов

(3) она указывает на главный прецедент, расширяемый остальными прецедентами

(4) она указывает на сущность, от которой что-то требуют, чьим сервисом пользуются

(5) она указывает на сущность, которая чего-то требует, пользуется чужими сервисами

Упражнение 4:

Номер 1

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

Ответ:

(1) экторы всегда располагаются вне контекста моделируемой системы

(2) единственный допустимый вид связи между экторами — наследование

(3) экторы могут быть связаны между собой с помощью ассоциации

(4) диаграмма прецедентов является представлением совокупности сервисов, предоставляемых системой

(5) для связи более чем одного актера с прецедентом допускается использование n-арной ассоциации

Номер 2

Какие экторы вовлечены в выполнение прецедента Use Case E?

Ответ:

(1) Actor A

(2) Actor A и Actor C

(3) Actor B и Actor C

(4) Actor C

(5) Actor A, Actor B и Actor C

Номер 3

Каким термином можно описать человека, покупающего книгу в онлайновом магазине?

Ответ:

(1) клиент

(2) внешняя система

(3) эктор

(4) субъект

(5) компонент

Упражнение 5:

Номер 1

Выберите из списка справедливые утверждения, касающиеся прецедентов

Ответ:

(1) прецедент — это описание набора последовательных событий, выполняемых системой, которые приводят к наблюдаемому эктором результату

(2) прецеденты описывают сервисы, предоставляемые системой экторам, с которыми она взаимодействует

(3) прецедент никогда не объясняет, «как» работает сервис, а только описывает, «что» делается

(4) прецеденты изображают в виде класса со стереотипом <<use case>>

(5) имя прецедента обычно намного длиннее имен других элементов модели

Номер 2

Что такое сценарий?

Ответ:

(1) это конкретная последовательность действий, иллюстрирующая поведение

(2) это повествовательный рассказ о совершаемых эктором действиях

(3) полное описание желаемого функционала системы

(4) желаемая функциональность, свойство или поведение системы

(5) полное описание сервисов, предоставляемых системой

Номер 3

Какие из представленных на рисунке символов являются стандартными обозначениями сценария?

Ответ:

(1) A

(2) B

(3) C

(4) D

(5) E

Упражнение 6:

Номер 1

В каком количественном отношении находятся сценарии и прецеденты?

Ответ:

(1) каждый прецедент соответствует одному сценарию

(2) между сценариями и прецедентами существует связь типа «многие ко многим»

(3) один прецедент определяет несколько сценариев

(4) один сценарий определяет несколько прецедентов

(5) обычно сценарии и прецеденты не связаны друг с другом

Номер 2

Какие прецеденты называют "полными прецедентами"?

Ответ:

(1) прецедент, который экторы наблюдают при взаимодействии с системой

(2) действия, выполняемые совместно несколькими вариантами использования

(3) поведение, включаемое в некоторый вариант использования

(4) поведение, расширяющее функционал, предоставляемый вариантом использования

(5) альтернативные варианты поведения системы, определяемые некоторым условием

Номер 3

Как на диаграммах прецедентов изображается включение прецедентов?

Ответ:

(1) в виде зависимости со стереотипом <<inside>>

(2) в виде зависимости со стереотипом <<include>>

(3) в виде зависимости со стереотипом <<within>>

(4) в виде зависимости со стереотипом <<contain>>

(5) в виде зависимости со стереотипом <<switch on>>

Упражнение 7:

Номер 1

В чем состоит смысл операции расширения прецедента?

Ответ:

(1) прецедент дополняется другими прецедентами, поведение которых включается в общую последовательность

(2) прецедент дополняется другими прецедентами, замещающими оригинальное поведение

(3) прецедент дополняется другими прецедентами, «срабатывающими» при некоторых условиях

(4) прецедент дополняется другими прецедентами, замещающими оригинальное поведение при некоторых условиях

(5) прецедент дополняется другими прецедентами, при вызове определенным эктором

Номер 2

Что описывается в дополнительном разделе прецедента, отделенном от его названия горизонтальной линией?

Ответ:

(1) точка расширения

(2) сценарий поведения

(3) дополнительные атрибуты

(4) включаемые прецеденты

(5) альтернативное поведение

Номер 3

В каком отношении находятся понятия прецедента и кооперации?

Ответ:

(1) зависимости

(2) ассоциации

(3) реализации

(4) генерализации

(5) включения

Упражнение 8:

Номер 1

Какими способами можно использовать прецеденты?

Ответ:

(1) для общения между пользователями, аналитиками и разработчиками

(2) как основу для написания подробного руководства пользователя

(3) чтобы пояснить разработчикам назначение элемента

(4) как основу для тестирования элемента в процессе его разработки

(5) как полное описание структуры будущей системы и ее функционала

Номер 2

Для чего используется обратное проектирование?

Ответ:

(1) чтобы четко разграничить систему и ее окружение

(2) с целью поиска ошибок

(3) чтобы убедиться в адекватности дизайна

(4) чтобы выделить нефункциональные требования

(5) чтобы понять назначение системы, для которой отсутствует документация

Номер 3

В каких отношениях могут состоять прецеденты?

Ответ:

(1) ассоциация

(2) наследование

(3) композиция

(4) включение

(5) расширение

Источник

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

Выберите из списка слова, которые могут быть помещены вместо многоточия. The UML — это … язык.

(1) искусственный

(2) естественный

(3) формальный

(4) алгоритмический

Какие виды моделей существуют?

(1) искусственные

(2) естественные

(3) материальные

(4) математические

(5) декоративные

Что такое инкапсуляция?

(1) сокрытие от пользователя внутреннего устройства объектов

(2) организация системы в виде совокупности взаимозаменяемых объектов — капсул

(3) использование классов, содержащих вложенные классы

(4) защита от пользователя вложенных классов

(5) защита отдельных элементов объекта, не затрагивающих существенных характеристик его как целого

Какие представления системы (виды) предлагает нотация UML?

(1) Вид системы с точки зрения прецедентов

(2) Вид с точки зрения проектирования

(3) Вид с точки зрения процессов

(4) Вид с точки зрения развертывания

(5) Вид с точки зрения реализации

Что такое диаграмма взаимодействия?

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

(2) диаграмма, на которой представлено взаимодействие, состоящее из множества объектов и отношений между ними

(3) диаграмма, на которой представлено взаимодействие, состоящее из сообщений, которыми обмениваются элементы модели

(4) диаграмма, на которой представлено взаимодействие, состоящее из множества объектов одного класса и сообщений, которыми они обмениваются

(5) диаграмма, на которой представлено взаимодействие, состоящее из множества объектов одного класса и его подклассов и сообщений, которыми они обмениваются

Что такое требование к ПО?

(1) желаемая функциональность, свойство или поведение системы

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

(3) формальные критерии соответствия системы желаниям заказчика

(4) подробное описание структуры и функционала будущей системы

(5) формальное описание внутреннего устройства будущей системы

The UML предназначен для…

(1) спецификации

(2) визуализации

(3) симуляции

(4) проектирования

(5) документирования

Выберите из списка истинные утверждения, касающиеся понятия эктора

(1) эктор — это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами

(2) экторами могут быть пользователи, внешние системы или внутренние БД

(3) экторами могут быть пользователи системы

(4) каждый эктор может взаимодействовать только с одним прецедентом

Что такое интерфейс?

(1) графическое представление класса

(2) логическая группа элементов управления для работы с объектом

(3) логическая группа открытых (public) операций объекта

(4) механизм, на котором основаны многие современные технологий программирования

Что такое деятельность?

(1) протяженный во времени составное вычисление (действия, action) и перехода как передачи контроля

(2) протяженная во времени составная передача контроля от объекта к объекту

(3) протяженный во времени составной поток управления

(4) протяженное во времени составное поведение

(5) протяженная во времени составная последовательность деятельностей

Какое место диаграммы взаимодействия занимают в жизненном цикле разработки ПО?

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

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

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

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

Какие цели преследует аналитик при идентификации прецедентов?

(1) четко разграничить систему и ее окружение

(2) выделить нефункциональные требования

(3) описать структуру и внутреннее устройство будущей системы

(4) определить, какие действующие лица и как именно взаимодействуют с системой

(5) определить и описать в словаре предметной области общие понятия, описывающие функционал системы

Что такое метамодель?

(1) описание способа построения модели

(2) концептуальная модель

(3) описание данных

(4) модель, построенная с высоким уровнем абстракции

(5) обобщенная модель

Каким символом изображается прецедент? files

(1) A

(2) B

(3) C

(4) D

(5) E

(6) F

Почему стоит использовать уже существующие классы?

(1) это позволяет не решать задачу заново, а использовать готовые решения

(2) это делает решение мобильным и расширяемым

(3) это позволяет не тратить время на отладку и тестирование

(4) все возможные классы уже созданы, можно всегда подобрать готовый компонент

Какие из изображений символа синхронизации противоречат нотации UML? files

(1) A

(2) B

(3) C

(4) D

(5) E

Каким образом отображается на диаграмме последовательностей порядок отправки и приема сообщений?

(1) место сообщения в последовательности определяется его положением на шкале времени, роль которой играют линии жизни

(2) место сообщения в последовательности определяется его номером, все они пронумерованы в порядке отправки

(3) место сообщения в последовательности определяется его положением, все они продолжают друг друга в логичном порядке

(4) место сообщения в последовательности определяется его составным номером, первая часть которого обозначает объект-отправитель

(5) место сообщения в последовательности определяется его составным номером, первая часть которого обозначает поток, а вторая — номер сообщения

Какой смысл вкладывают в понятие эктора?

(1) набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью

(2) набор пользователей, взаимодействующих с некоторой сущностью

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

(4) обобщенный пользователь системы, взаимодействующий с ней

(5) усредненный пользователь системы, взаимодействующий с ней

Какая характеристика текста является значимой в UML-диаграммах?

(1) цвет

(2) начертание

(3) размер

(4) междустрочный интервал

Выберите из списка истинные утверждения, касающиеся классов

(1) классы — это строительные блоки любой объектно-ориентированной системы

(2) класс — это категория вещей, которые имеют общие атрибуты и операции

(3) в ходе проектирования без диаграммы классов вполне можно обойтись

Что такое полиморфизм?

(1) принцип, позволяющий разным объектам, выполняя одни и те же операции, вести себя по-разному

(2) принцип, позволяющий разным объектам, выполняя одни и те же операции, вести себя одинаково

(3) принцип, основанный на совпадении сигнатуры метода и сигнатуре, описанной в интерфейсе

(4) один из базовых принципов ООП, наряду с наследованием и инкапсуляцией

(5) один из базовых принципов ООП, наряду с наследованием и генерализацией

Сколько конечных состояний может содержать диаграмма активностей?

(1) только одно

(2) больше одного

(3) не больше двух

(4) столько же, сколько на диаграмме начальных состояний

Что означает символ выделенный на рисунке? files

(1) уничтожение объекта

(2) отсутствие фокуса управления

(3) прекращение посылки сообщений

(4) исключение из взаимодействия

(5) прекращения приема сообщений

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

(1) экторы всегда располагаются вне контекста моделируемой системы

(2) единственный допустимый вид связи между экторами — наследование

(3) экторы могут быть связаны между собой с помощью ассоциации

(4) диаграмма прецедентов является представлением совокупности сервисов, предоставляемых системой

(5) для связи более чем одного актера с прецедентом допускается использование n-арной ассоциации

Как расшифровывается аббревиатура UML?

(1) Unified Modeling Language

(2) Unified Markup Language

(3) Unified Methodology Language

(4) Unified Method Language

(5) Universal Modeling Language

Выберите из списка истинные утверждения, касающиеся объектов

(1) объект — это конкретная материализация абстракции

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

(3) объект — экземпляр класса

(4) понятия «объект» и «класс» является синонимами

(5) объекты различимы по значениям атрибутов

В каком случае говорят о зависимости между классами?

(1) когда реализация класса одного объекта зависит от спецификации операций класса другого объекта

(2) когда реализация класса одного объекта зависит от спецификации операций суперкласса этого объекта

(3) когда реализация класса одного объекта зависит от спецификации операций объекта того же класса

(4) когда реализация класса одного объекта зависит от спецификации операций суперкласса другого объекта

(5) когда реализация класса одного объекта зависит от спецификации операций подкласса другого объекта

Для чего диаграммы деятельности чаще всего используются на практике?

(1) для моделирования операций

(2) для моделирования взаимодействий

(3) для моделирования процессов

(4) для моделирования структуры

(5) для моделирования интерфейсов

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

(1) таким образом обозначаются рефлексивные сообщения

(2) таким образом обозначаются синхронные сообщения

(3) таким образом обозначаются асинхронные сообщения

(4) таким образом обозначаются ответные сообщения

(5) таким образом обозначаются потерянные сообщения

Выберите из списка справедливые утверждения, касающиеся прецедентов

(1) прецедент — это описание набора последовательных событий, выполняемых системой, которые приводят к наблюдаемому эктором результату

(2) прецеденты описывают сервисы, предоставляемые системой экторам, с которыми она взаимодействует

(3) прецедент никогда не объясняет, «как» работает сервис, а только описывает, «что» делается

(4) прецеденты изображают в виде класса со стереотипом <<use case>>

(5) имя прецедента обычно намного длиннее имен других элементов модели

При использовании какого подхода UML предоставляет максимум преимуществ?

(1) процедурное программирование

(2) объектно-ориентированное проектирование

(3) функциональное программирование

(4) программирование по контракту

(5) концептуальное проектирование

Каким образом объекты внутри системы взаимодействуют между собой?

(1) путем отправки и приема сообщений

(2) путем прямого вызова операций друг друга

(3) путем обмена информацией через буфер обмена

(4) путем использования интерфейсов родительских классов

(5) путем прямой записи в память

Что означает кратность 3..11, указанная рядом с одним из концов ассоциации?

(1) от 3 до 11 классов ассоциировано с другим классом

(2) от 3 до 11 включительно объектов одного класса ассоциировано с одним объектом другого класса

(3) 4,5,6,7,8,9 или 10 объектов одного класса ассоциировано с одним объектом другого класса

(4) 3 или 11 объектов одного класса ассоциировано с одним объектом другого класса

(5) менее 3 или более 11 объектов одного класса ассоциировано с одним объектом другого класса

Какие еще виды диаграмм, кроме диаграмм активностей, можно использовать для моделирования динамических аспектов систем?

(1) диаграммы прецедентов

(2) диаграммы последовательностей

(3) диаграммы объектов

(4) диаграммы кооперации

(5) диаграммы состояний

Что такое найденные сообщения?

(1) сообщения, для которых известен адресат, но неизвестен отправитель

(2) сообщения, для которых известен отправитель, но неизвестен получатель

(3) сообщения, в результате получения которых не было отправлено ответное сообщение

(4) сообщения, отправленные объектом самому себе

(5) сообщения, в результате которых не было получено некоторое значение

В каком количественном отношении находятся сценарии и прецеденты?

(1) каждый прецедент соответствует одному сценарию

(2) между сценариями и прецедентами существует связь типа «многие ко многим»

(3) один прецедент определяет несколько сценариев

(4) один сценарий определяет несколько прецедентов

(5) обычно сценарии и прецеденты не связаны друг с другом

Выберите из списка истинные утверждения, касающиеся UML-моделей

(1) UML-модели являются XML-документами

(2) UML имеет ограничения по природе моделируемой предметной области

(3) CASE-средства могут генерировать текстовые спецификации из UML-моделей

(4) создавая UML-модель, вы тем самым документируете систему

(5) UML-модель жестко привязана к конкретной методологии разработки ПО

Аналогом какой диаграммы является диаграмма кооперации?

(1) диаграммы прецедентов

(2) диаграммы классов

(3) диаграммы объектов

(4) диаграммы последовательностей

(5) диаграммы деятельностей

Как соотносятся между собой понятия агрегации и композиции?

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

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

(3) композиция — это более строгая разновидность агрегации

(4) композиция — это менее строгая разновидность агрегации

(5) агрегация и композиция — это виды ассоциации, описывающие отношения между классами типа «часть-целое»

Какой отрывок псевдокода соответствует диаграмме, изображенной на рисунке? files

(1)

If (ok) then
do First and Second
else
do Third
do Fourth

(2)

If (ok) then
do First
do Second
else
do Third
do Fourth

(3)

do First and Second
do Third
do Fourth

(4)

If (ok) then
do First
do Second
else
do Third and Fourth

Для чего на практике обычно применяют диаграммы кооперации?

(1) чтобы показать набор взаимодействующих объектов в реальном окружении

(2) чтобы распределить функциональность между классами

(3) чтобы описать взаимодействие системы с окружающим миром

(4) чтобы описать логику выполнения сложных операций

(5) чтобы изучить роли, выполняемые объектами внутри системы

В чем состоит смысл операции расширения прецедента?

(1) прецедент дополняется другими прецедентами, поведение которых включается в общую последовательность

(2) прецедент дополняется другими прецедентами, замещающими оригинальное поведение

(3) прецедент дополняется другими прецедентами, «срабатывающими» при некоторых условиях

(4) прецедент дополняется другими прецедентами, замещающими оригинальное поведение при некоторых условиях

(5) прецедент дополняется другими прецедентами, при вызове определенным эктором

Что такое реверс-инжиниринг приментительно к UML?

(1) создание UML-модели из существующего кода

(2) декомпиляция выполняемых файлов

(3) анализ и улучшение построенной модели

(4) восстановление требований из существующей модели

(5) обратная семантическая трассировка существующего кода

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

(1) диаграммы состояний применяются для того, чтобы объяснить, каким образом работают сложные объекты

(2) диаграмма состояний является альтернативной формой диаграммы объектов

(3) диаграммы состояний служат для моделирования динамических аспектов системы

(4) диаграмма состояний показывает автомат

(5) диаграмма состояний описывает процесс изменения состояний определенного объекта

Какие три принципа лежат в основе ООП?

(1) наследование

(2) инкапсуляция

(3) полиморфизм

(4) ассоциация

(5) зависимость

Символ синхронизации используется на диаграмме активностей в случаях, когда …

(1) нужно изобразить два или более одновременных потока

(2) нужно изобразить ситуацию выбора одного из двух потоков

(3) нужно изобразить слияние в один поток нескольких входящих потоков

(4) нужно сделать диаграмму максимально компактной

(5) нужно изобразить несколько входящих потоков, сливающихся в меньшее число исходящих потоков

Что такое кооперация?

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

(2) набор взаимодействующих классов и их объектов, используемых вместе, чтобы показать некую функциональность

(3) статическая конструкция для моделирования набора сущностей, взаимодействующих друг с другом

(4) статическая конструкция для моделирования набора сущностей, взаимодействующих с системой

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

Какими способами можно использовать прецеденты?

(1) для общения между пользователями, аналитиками и разработчиками

(2) как основу для написания подробного руководства пользователя

(3) чтобы пояснить разработчикам назначение элемента

(4) как основу для тестирования элемента в процессе его разработки

(5) как полное описание структуры будущей системы и ее функционала

Частным случаем какой диаграммы является диаграмма деятельностей?

(1) диаграммы прецедентов

(2) диаграммы кооперации

(3) диаграммы объектов

(4) диаграммы последовательностей

(5) диаграммы состояний

Какой элемент диаграмм кооперации изображен на рисунке? files

(1) композитный объект

(2) часть композитного объекта

(3) порт

(4) мультиобъект

(5) активный объект

Выберите из списка истинные утверждения, касающиеся диаграмм развертывания

(1) диаграммы развертывания — необходимая часть любой UML-модели

(2) диаграммы развертывания — это графическое представление инфраструктуры, на которую будет развернуто приложение

(3) диаграммы развертывания есть смысл строить только для аппаратно-программных систем

(4) диаграммы развертывания могут помочь более рационально распределить компоненты системы по узлам сети

(5) диаграммы развертывания могут помочь решить множество задач, связанных, например, с обеспечением безопасности

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

(1) синтаксис

(2) орфография

(3) морфология

(4) семантика

(5) прагматика

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

(1) диаграммы — средство визуализации модели

(2) это понятия являются синонимами

(3) набор диаграмм составляет модель

(4) любая отдельно взятая диаграмма может рассматриваться, как модель

(5) эти понятия являются антонимами

В чем разница между модификаторами видимости public и protected?

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

(2) public определяет доступ из любой части программы, а protected — только из операций этого же класса

(3) public определяет доступ из операций этого же класса и классов, создаваемых на его основе, а protected — только из операций этого же класса

(4) public определяет доступ из операций этого же класса, а protected — только из операций классов, создаваемых на основе этого класса

Какие элементы модели могут быть уточнены с помощью диаграмм активностей?

(1) только прецеденты

(2) только состояния

(3) только последовательности

(4) только сценарии

(5) любые элементы модели, имеющие динамическое поведение

В чем состоит различие между диаграммой последовательностей и диаграммой кооперации?

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

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

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

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

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

Какие артефакты пришли на смену техническому заданию?

(1) диаграммы прецедентов

(2) нефункциональные требования

(3) диаграммы классов

(4) диаграммы развертывания

(5) диаграммы компонентов

Какие виды спецификаций различают?

(1) словесные

(2) модельные

(3) формальные

(4) предикативные

(5) концептуальные

Какие символы являются стандартными представлениями эктора? files

(1) A

(2) B

(3) C

(4) D

(5) E

(6) F

Какие символы являются стандартными представлениями интерфейса? files

(1) A

(2) B

(3) C

(4) D

(5) E

В чем отличие диаграмм деятельности от диаграмм взаимодействия?

(1) диаграммы деятельности описывают переход от одного состояния к другому, а диаграммы взаимодействия — переход потока управления от объекта к объекту

(2) диаграммы деятельности описывают переход потока управления от объекта к объекту, а диаграммы взаимодействия — от одного эктора к другому

(3) диаграммы деятельности описывают переход от одной деятельности к другой, а диаграммы взаимодействия — переход потока управления от объекта к объекту

(4) диаграммы деятельности описывают переход потока управления от объекта к объекту, а диаграммы взаимодействия — от одной деятельности к другой

(5) диаграммы деятельности описывают переход от одной деятельности к другой, а диаграммы взаимодействия — переход потока управления от эктора к другому

На каком этапе жизненного цикла разработки ПО обычно строят диаграммы взаимодействия?

(1) сбор требований

(2) анализ

(3) проектирование

(4) разработка

(5) внедрение

Какие шаги обычно выделяют в процессе идентификации прецедентов?

(1) определение действующих лиц

(2) определение прецедентов

(3) описание модели прецедентов в целом

(4) описание структуры системы

Элементы нотации каких видов используются в UML?

(1) фигуры

(2) линии

(3) значки

(4) надписи

(5) операторы

В каких отношениях могут состоять прецеденты между собой?

(1) включение

(2) расширение

(3) агрегация

Что такое суперкласс?

(1) класс, обладающий большим количеством методов и свойств

(2) класс, который существует лишь в голове проектировщика

(3) идеализация класса

(4) более общий класс, конкретным воплощением которого является подкласс

Какой смысл вкладывается в понятие плавательных дорожек (swimlanes)?

(1) это часть области диаграммы деятельности, на которой отображаются только те деятельности, за которые отвечает конкретный объект

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

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

(4) это часть области диаграммы деятельности, на которой отображаются объекты, участвующие во взаимодействии

(5) это часть области диаграммы деятельности, на которой отображается поток деятельностей, соответствующий сообщениям, передаваемым между объектами

Какой буквой на рисунке обозначена линия жизни объекта? files

(1) A

(2) B

(3) C

(4) D

(5) E

Какие из представленных на рисунке символов являются стандартными обозначениями эктора? files

(1) A

(2) B

(3) C

(4) D

(5) E

Какие виды линий используются в UML-диаграммах?

(1) сплошная

(2) пунктирная

(3) штрихпунктирная

(4) волнистая

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

(1) абстрактные понятия предметной области

(2) пользователи, взаимодействующие с системой

(3) внешние, по отношению к системе, сущности

(4) программные или аппаратные сущности, составляющие систему

(5) операции, выполняемые системой в процессе ее работы

Каким образом на диаграммах UML изображается наследование?

(1) не закрашенной треугольной стрелкой, направленной в сторону подкласса

(2) не закрашенной треугольной стрелкой, направленной в сторону суперкласса

(3) не закрашенной ромбической стрелкой, направленной в сторону подкласса

(4) не закрашенной ромбической стрелкой, направленной в сторону суперкласса

(5) не закрашенной двунаправленной треугольной стрелкой

Чем конечное состояние потока отличается от конечного состояния?

(1) конечное состояние потока означает завершение всех потоков управления внутри деятельности, а конечное состояние говорит о завершении одного потока управления

(2) конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении всех потоков управления внутри деятельности

(3) конечное состояние потока означает завершение одного потока управления, а конечное состояние говорит о завершении текущей деятельности

(4) конечное состояние потока означает завершение текущей деятельности, а конечное состояние говорит о завершении всех потоков управления внутри деятельности

(5) конечное состояние потока означает завершение одного потока внутри деятельности, а конечное состояние говорит о завершении всех потоков управления, не относящихся к текущей деятельности

Использование каких элементов UML, кроме объектов, допускается на диаграмме последовательностей?

(1) прецеденты

(2) экторы

(3) активности

(4) состояния

(5) классы

Какие экторы вовлечены в выполнение прецедента Use Case E? files

(1) Actor A

(2) Actor A и Actor C

(3) Actor B и Actor C

(4) Actor C

(5) Actor A, Actor B и Actor C

Что означает аббревиатура OMG?

(1) Object Modeling Group

(2) Object Methodology Group

(3) Object Management Group

(4) Object Method Group

(5) Object Markup Group

Какие символы являются стандартными представлениями объекта? files

(1) A

(2) B

(3) C

(4) D

(5) E

(6) F

Какими способами может изображаться однонаправленная ассоциация на диаграммах UML? files

(1) A

(2) B

(3) C

(4) D

(5) E

Какую особенность нотации диаграмм активностей активно используют для описания бизнес-процессов?

(1) траектория объектов

(2) плавательные дорожки

(3) принятие решения

(4) синхронизация

(5) конечное состояние потока

Что такое синхронное сообщение?

(1) сообщение, которое не ждет ответа, и сразу после их посылки происходит переход к следующему шагу последовательности

(2) сообщение, которое приостанавливает поток выполнения до тех пор, пока не будет получен ответ

(3) сообщение, которое отправлено одновременно с сообщениями от других объектов, участвующих во взаимодействии

(4) сообщение, которое отправлено объектом самому себе и переводящее объект в другое состояние

(5) сообщение, которое отправлено объектом в ответ на полученное сообщение

Что такое сценарий?

(1) это конкретная последовательность действий, иллюстрирующая поведение

(2) это повествовательный рассказ о совершаемых эктором действиях

(3) полное описание желаемого функционала системы

(4) желаемая функциональность, свойство или поведение системы

(5) полное описание сервисов, предоставляемых системой

Какие нотации послужили основой при создании UML?

(1) Booch

(2) OMT

(3) Objectory

(4) ER

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

(1) диаграмма последовательностей показывает взаимодействие объектов во времени

(2) диаграмма последовательностей отображает последовательность передачи и приема сообщений объектами

(3) диаграммы последовательностей — это просто другая форма диаграмм прецедентов

(4) диаграммы последовательностей используются для уточнения диаграмм прецедентов

(5) диаграмма последовательностей описывает статические аспекты системы

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

(1) A

(2) B

(3) C

(4) D

(5) E

Какие новые элементы нотации привносят диаграммы деятельностей в блок-схемы?

(1) синхронизация потоков управления

(2) плавательные дорожки

(3) беговые дорожки

(4) траектория объекта

(5) различные виды конечных состояний

Как называется тип сообщения, пример которого изображен на рисунке ? files

(1) рефлексивные сообщения

(2) синхронные сообщения

(3) асинхронные сообщения

(4) ответные сообщения

(5) потерянные сообщения

Какие прецеденты называют «полными прецедентами»?

(1) прецедент, который экторы наблюдают при взаимодействии с системой

(2) действия, выполняемые совместно несколькими вариантами использования

(3) поведение, включаемое в некоторый вариант использования

(4) поведение, расширяющее функционал, предоставляемый вариантом использования

(5) альтернативные варианты поведения системы, определяемые некоторым условием

Выберите из списка ЛОЖНЫЕ утверждения относительно текстовых комментариев в UML-моделях

(1) в UML нельзя использовать текстовые комментарии

(2) комментарии могут содержать только формальные ограничения

(3) некоторые элементы диаграмм не могут быть снабжены комментарием

(4) комментарии могут состоять из нескольких строк

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

(1) нумерация используется по той причине, что время на диаграмме взаимодействия не показывается в виде отдельного измерения

(2) номера задают последовательность передачи сообщений

(3) номера показывают важность сообщений

Каким символом на диаграммах UML изображается композиция? files

(1) A

(2) B

(3) C

(4) D

(5) E

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

(1) для моделирования выполнения операций

(2) для отслеживания изменения состояния объекта в течение его жизненного цикла

(3) для отображения последовательности сообщений, которыми обмениваются объекты

(4) для моделирования одновременного выполнения приложений

(5) для уточнения прецедентов

Для чего в первую очередь применяются диаграммы кооперации уровня экземпляров?

(1) чтобы показать набор взаимодействующих объектов в реальном окружении

(2) чтобы распределить функциональность между классами

(3) чтобы описать взаимодействие системы с окружающим миром

(4) чтобы описать логику выполнения сложных операций

(5) чтобы изучить роли, выполняемые объектами внутри системы

Что описывается в дополнительном разделе прецедента, отделенном от его названия горизонтальной линией? files

(1) точка расширения

(2) сценарий поведения

(3) дополнительные атрибуты

(4) включаемые прецеденты

(5) альтернативное поведение

Что такое кодогенерация?

(1) генерация текстовой спецификации из существующего кода

(2) генерация кода из существующей UML-модели

(3) генерация кода на основе спецификации

(4) генерация исполняемых файлов из существующей UML-модели

(5) генерация UML-модели из исполняемого файла

Что означает символ «кошачий глаз» на диаграмме состояний? files

(1) слияние потоков управления

(2) принятие решения

(3) конечное состояние

(4) начальное состояние

(5) конец потока управления

Начало какого этапа жизненного цикла ПО знаменует собой создание диаграммы классов?

(1) анализа

(2) проектирования

(3) разработки

(4) тестирования

(5) внедрения

Какие из перечисленных представлений системы могут содержать диаграммы деятельностей?

(1) вид системы с точки зрения прецедентов

(2) вид с точки зрения проектирования

(3) вид с точки зрения процессов

(4) вид с точки зрения развертывания

(5) вид с точки зрения реализации

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

(1) сообщения на диаграмме кооперации пронумерованы в порядке отправки

(2) сообщения на диаграмме кооперации продолжают друг друга в логичном порядке

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

(4) сообщения на диаграмме кооперации распределены вдоль отдельной оси времени

(5) сообщения на диаграмме кооперации являются синхронными и отправляются одновременно

Для чего используется обратное проектирование?

(1) чтобы четко разграничить систему и ее окружение

(2) с целью поиска ошибок

(3) чтобы убедиться в адекватности дизайна

(4) чтобы выделить нефункциональные требования

(5) чтобы понять назначение системы, для которой отсутствует документация

Какие преимущества диаграмма деятельностей имеет перед блок-схемой?

(1) позволяет показать последовательность выполнения операций

(2) позволяет изобразить параллельные потоки деятельностей

(3) позволяет изобразить альтернативы потока деятельностей

(4) позволяет изобразить вложенные деятельности

(5) позволяет описать алгоритм решения некоторой задачи

Что такое композитный объект?

(1) набор объектов одного класса

(2) высокоуровневый объект, состоящий из нескольких частей-объектов

(3) объект, которые владеет собственным потоком управления и может инициировать выполнение действий

(4) объект, который содержит данные, но не может инициировать выполнение

(5) экземпляр класса, являющегося агрегатом объектов других классов

Чем нотация диаграмм развертывания отличается от нотации других диаграмм UML?

(1) использованием «трехмерных» фигур

(2) использованием только сплошных линий

(3) использованием стереотипов

(4) запретом использования ноутсов

(5) отсутствием рамок системы

Как соотносятся понятия Modeling и Simulation?

(1) modeling означает создание описательной модели объекта, а simulation предполагает получение с помощью созданной модели дополнительной информации

(2) simulation означает создание описательной модели объекта, а modeling предполагает получение с помощью созданной модели дополнительной информации

(3) эти понятия идентичны по смыслу

(4) оба понятия по смыслу соответствуют русскоязычному термину «моделирование»

Что такое диаграмма с математической точки зрения?

(1) граф

(2) функция

(3) группа

(4) утверждение

Какой из модификаторов видимости изображается в UML с помощью символа # (шарп, диез)?

(1) public

(2) private

(3) protected

(4) restricted

(5) allowed

Разновидностью какой диаграммы UML являются диаграммы активностей?

(1) диаграммы прецедентов

(2) диаграммы классов

(3) диаграммы состояний

(4) диаграммы последовательностей

(5) диаграммы развертывания

На чем акцентирует внимание диаграмма кооперации?

(1) на сообщениях, которыми обмениваются объекты в ходе взаимодействия

(2) на ролях, которые объекты играют во взаимодействии

(3) на последовательности сообщений, которыми обмениваются объекты

(4) на объектах, которые участвуют во взаимодействии

(5) на отношениях между объектами, которые участвуют во взаимодействии

Что такое прецедент?

(1) функциональность, уже однажды реализованная в некоторой системе, на которую можно ссылаться при разработке

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

(3) функциональность системы, стандартная «де-факто» для всех систем подобного класса

(4) функциональность системы, стандартная для всех систем подобного класса, реализованная в стандартных библиотеках

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

Чем The UML НЕ является?

(1) средством коммуникации в команде

(2) языком программирования

(3) спецификацией CASE-средства

(4) моделью процесса разработки

(5) средством документирования повторно используемых решений

Какие из перечисленных технологий программирования основаны на механизме интерфейсов?

(1) COM

(2) MSF

(3) CORBA

(4) Fortran

(5) Java Beans

Каково значение символа, изображенного на рисунке? files

(1) начальное состояние

(2) конечное состояние

(3) начальное состояние потока

(4) конечное состояние потока

(5) разрыв потока

Аналогом какой диаграммы является диаграмма кооперации?

(1) последовательностей

(2) деятельности

(3) состояний

(4) объектов

(5) прецедентов

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

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

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

(3) нефункциональные требования часто выносятся в отдельный список дополнительных требований к системе

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

Используются ли в UML трехмерные фигуры?

(1) да, на диаграмме развертывания

(2) да, на диаграмме классов

(3) да, на диаграмме прецедентов

(4) да, на диаграмме деятельностей

(5) нет

Что означает стрелка, изображенная на одном из концов линии, соединяющей эктора и прецедент?

(1) она направлена к тому, чьими услугами пользуются

(2) она показывает порядок выполнения прецедентов

(3) она указывает на подчиненный элемент

(4) она направлена к тому, кто пользуется услугами другого

(5) она задает порядок чтения диаграммы

Что такое генерализация?

(1) отношение между объектами внутри класса

(2) то же самое, что и наследование

(3) то же самое, что и ассоциация

(4) отношение между суперклассом и подклассом

Каким образом объекты соотносятся с деятельностями при изображении траектории объекта?

(1) с помощью ассоциации

(2) с помощью зависимости

(3) с помощью генерализации

(4) с помощью агрегации

(5) с помощью композиции

Обязательно ли изображение фокуса управления на диаграммах последовательностей?

(1) да, без фокуса управления диаграмма считается неполной

(2) да, без фокуса управления диаграмма становится неоднозначной

(3) да, без фокуса управления диаграмма становится нечитаемой

(4) нет, это зависит от личного стиля проектировщика

Какое значение имеет стрелка, изображенная на линии, связывающей эктора и прецедент?

(1) она указывает последовательность вызова функционала системы

(2) она указывает на последовательность использования прецедентов

(3) она указывает на главный прецедент, расширяемый остальными прецедентами

(4) она указывает на сущность, от которой что-то требуют, чьим сервисом пользуются

(5) она указывает на сущность, которая чего-то требует, пользуется чужими сервисами

По какому принципу выбирались элементы нотации The UML?

(1) ассоциативность

(2) привычность очертаний

(3) простота изображения

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

(1) прямого проектирования

(2) описания способов взаимодействия с системой

(3) описания динамических аспектов системы

(4) описания статических аспектов системы

Что является основой для реализации механизма интерфейсов в языках программирования?

(1) наследование

(2) инкапсуляция

(3) полиморфизм

(4) генерализация

(5) обобщение

Каким символом изображается конечное состояние потока? files

(1) A

(2) B

(3) C

(4) D

(5) E

Что такое рефлексивное сообщение?

(1) сообщение, предусматривающее ответное сообщение

(2) сообщение, предусматривающее получение некоторого значения

(3) сообщение, отправленное в ответ на полученное сообщение

(4) сообщение, не предусматривающее ответного сообщения

(5) сообщение, отправленное объектом самому себе

Каким термином можно описать человека, покупающего книгу в онлайновом магазине?

(1) клиент

(2) внешняя система

(3) эктор

(4) субъект

(5) компонент

Что такое профайл UML?

(1) пакет расширений для моделирования систем из специфической предметной области

(2) подробное описание структуры и синтаксиса UML, его связей с другими языками

(3) пользовательские настройки, учитывающие конкретный стиль проектирования

(4) UML-модель, сохраненная в специальном формате для переноса на другой ПК

(5) описание конкретного стиля проектирования средствами UML

Выберите из списка истинные утверждения, касающиеся диаграммы объектов

(1) диаграмма объектов — необходимая часть каждой UML-модели

(2) диаграммы объектов показывают множество объектов и отношений между ними в некоторый момент времени

(3) диаграмма объектов — это снимок состояния системы в определенный момент времени

(4) диаграммы объектов представляют статический вид системы с точки зрения проектирования и процессов

(5) диаграмма объектов используется для пояснения и детализации диаграмм взаимодействия

Какой тип ассоциации называется n-арной ассоциацией?

(1) это ассоциация, объединяющая три и более класса

(2) это ассоциация, объединяющая более одного класса

(3) это ассоциация с указанием кратности на ее концах

(4) это ассоциация, в которой объекты играют некие роли

(5) это ассоциация между объектом и его суперклассом

Какие конструкции чаще всего используют при моделировании операций с помощью диаграмм активностей?

(1) траектория объектов

(2) плавательные дорожки

(3) принятие решения

(4) синхронизация

(5) конечное состояние потока

Что такое асинхронное сообщение?

(2) сообщение, которое приостанавливает поток выполнения до тех пор, пока не будет получен ответ

(4) сообщение, которое отправлено объектом самому себе и переводящее объект в другое состояние

(5) сообщение, которое отправлено объектом в ответ на полученное сообщение

Какие из представленных на рисунке символов являются стандартными обозначениями сценария? files

(1) A

(2) B

(3) C

(4) D

(5) E

C построения какой диаграммы должен начинаться процесс проектирования в соответствии с Objectory?

(1) диаграммы классов

(2) диаграммы прецедентов

(3) диаграммы активностей

(4) диаграммы состояний

(5) диаграммы последовательностей

Что означают прямоугольники на вертикальных линиях под каждым из объектов на диаграммах последовательностей? files

(1) фокус управления

(2) создание и уничтожение объектов

(3) время жизни (фокус) объектов

(4) получение информации из буфера обмена

Какой символ используется для изображения n-арной ассоциации на диаграммах UML? files

(1) A

(2) B

(3) C

(4) D

(5) E

Каким символом в диаграммах активностей изображается конструкция выбора? files

(1) A

(2) B

(3) C

(4) D

(5) E

Какие из фрагментов диаграмм последовательностей НЕ противоречат нотации UML? files

(1) A

(2) B

(3) C

(4) D

(5) E

Как на диаграммах прецедентов изображается включение прецедентов?

(1) в виде зависимости со стереотипом <<inside>>

(2) в виде зависимости со стереотипом <<include>>

(3) в виде зависимости со стереотипом <<within>>

(4) в виде зависимости со стереотипом <<contain>>

(5) в виде зависимости со стереотипом <<switch on>>

Выберите из списка истинные утверждения

(1) применение UML гарантирует построение разумных и понятных моделей

(2) нотация UML жестко фиксирована

(3) разработчик средства UML-моделирования может модифицировать нотацию по своему желанию

(4) UML может быть использован для реверс-инжиниринга

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

(1) диаграмма объектов показывает статику, а диаграмма взаимодействия описывает динамические аспекты системы

(2) диаграмма объектов и диаграмма кооперации полностью взаимозаменяемы

(3) диаграмма объектов и диаграмма кооперации отличаются лишь нотацией

(4) использование диаграммы кооперации или диаграммы объектов зависит только от особенностей стиля проектировщика

(5) UML-модель не может содержать диаграммы кооперации и диаграммы объектов одновременно

Что такое класс ассоциации?

(1) представление в виде класса ассоциации, имеющей свойства

(2) представление в виде класса ассоциации, имеющей операции

(3) представление в виде суперкласса всех видов связей между объектами

(4) представление в виде подкласса вариантов связей между объектами

Могут ли диаграммы деятельностей быть вложенными?

(1) да, при моделирования составных деятельностей

(2) да, при моделировании траектории объекта

(3) да, при моделировании с использованием плавательных дорожек

(4) да, при моделировании параллельно выполняющихся действий

(5) нет, вложенными диаграммы деятельностей быть не могут

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

(1) чтобы показать набор взаимодействующих объектов в реальном окружении

(2) чтобы распределить функциональность между классами

(3) чтобы описать взаимодействие системы с окружающим миром

(4) чтобы описать логику выполнения сложных операций

(5) чтобы изучить роли, выполняемые классами внутри системы

В каком отношении находятся понятия прецедента и кооперации?

(1) зависимости

(2) ассоциации

(3) реализации

(4) генерализации

(5) включения

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

(1) формальная спецификация может быть составлена для чисто вычислительных задач

(2) формализация некоторых задач может оказаться сложнее, чем сама разработка

(3) формальная спецификация позволяет однозначно описать любую задачу

(4) термины «формальная спецификация» и «математическая модель» являются синонимами

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

(1) параллельные подсостояния

(2) состояния, активные в данный момент

(3) альтернативные подсостояния

(4) варианты детализации состояния

(5) иерархию состояний

Какие разделы могут использоваться в символе класса на UML-диаграмме?

(1) раздел стереотипа

(2) раздел названия

(3) раздел атрибутов

(4) раздел операций

(5) раздел ассоциаций

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

(1) нет, только для описания жизненного цикла одного объекта

(2) нет, только для детализации одной конкретной операции

(3) да, это одно из применений диаграмм деятельностей

(4) да, но это должны быть объекты одного класса

(5) да, но это должны быть объекты одного класса или его подклассов

Как на диаграммах кооперации обозначаются параллельные потоки сообщений?

(1) номера одновременных сообщений предваряют номером потока

(2) номера одновременных сообщений предваряют заглавными буквами

(3) номера одновременных сообщений предваряют названием потока

(4) номера одновременных сообщений заканчивают точкой и номером потока

(5) номера одновременных сообщений заканчивают точкой и номером сообщения в потоке

В каких отношениях могут состоять прецеденты?

(1) ассоциация

(2) наследование

(3) композиция

(4) включение

(5) расширение

Что означает символ «бриллианта» на диаграмме деятельностей? files

(1) слияние потоков деятельностей

(2) принятие решения

(3) распараллеливание потоков деятельностей

(4) конечное состояние

(5) начальное состояние

Чем активные объекты отличаются от пассивных?

(1) активный объект владеет собственным потоком управления и может инициировать выполнение действий, а пассивный объект содержит данные, но не может инициировать выполнение

(2) активный объект содержит данные, но не может инициировать выполнение, а пассивный объект владеет собственным потоком управления и может инициировать выполнение действий

(3) активный объект содержит данные и может инициировать выполнение действий, а пассивный объект владеет собственным потоком управления , но не может инициировать выполнение

(4) активный объект владеет собственным потоком управления, но не может инициировать выполнение, а пассивный объект содержит данные и может инициировать выполнение действий

Что означают надписи под обозначением узла? files

(1) компоненты системы, устанавливаемые на этот узел

(2) папки, открытые на этом узле для сетевого доступа

(3) программное обеспечение, установленное на этом узле

(4) требования к узлу по аппаратному и программному обеспечению

(5) любые примечания, касающиеся назначения этого узла

Источник

Диаграмма прецедентов или диаграмма вариантов использования (англ. (b) use case diagram) в UML (b) — диаграмма, отражающая отношения между акторами (b) и прецедентами (b) и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне^[1].

Прецедент — возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований (b) к системе^[1].

Назначение

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

При моделировании системы с помощью диаграммы прецедентов системный аналитик (b) стремится:

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

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

Элементы

Для отражения модели прецедентов на диаграмме используются^[1]:

рамки системы (англ. (b) system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации,
актор (b) (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующий с некоторой сущностью (системой, подсистемой, классом). Акторы не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),
прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым акторами результатам. Надпись может быть именем или описанием (с точки зрения актора) того, «что» делает система (а не «как»). Имя прецедента связано с непрерывным (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение^[2]. В ходе сценария акторы обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев^[1].

Отношения между прецедентами

Часть дублирующейся информации в модели прецедентов можно устранить указанием связей между прецедентами^[1]:

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

Правила

При работе с вариантами использования важно помнить несколько простых правил:

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

Примечания

1 2 3 4 5 6 Бабич А. В. Введение в UML. ISBN 978-5-94774-878-9, 6. Лекция: Диаграммы прецедентов: крупным планом. Дата обращения: 26 января 2015. Архивировано 2 июля 2015 года.
↑ Г. Буч. Объектно-ориентированное программирование.

Источник

Для чего используется техника креативности

Определить функциональные требования к системе.

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

План действий

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

После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм прецедентов.

Замечания (описание)

Здесь представлен основной набор символов диаграммы вариантов использования (прецедентов) , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы вариантов использования системы (ВИС) самостоятельно!

Термин	Изображение	Описание
Сценарий	Вся диаграмма вариантов использования (ВИС)	Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.
Актер		Актер (actor) представляет собой некую роль, которую пользователь играет по отношению к системе.
Прецедент		Обозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам.
include (включает)		Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй.
Граница системы		Позволяет обозначить границы систем или подсистем.

Как применять технику креативности

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

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

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

Как научиться

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

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

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

Пример использования

Прецеденты – это технология определения функциональных требований к системе. Работа прецедентов заключается в описании типичных взаимодействий между пользователями системы и самой системой и предоставлении описания процесса ее функционирования. Вместо того чтобы описывать прецеденты в лоб, я предпочитаю подкрасться к ним сзади и начать с описания сценариев. Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы. Поэтому при наличии онлайнового магазина, основанного на веб-сайте, мы можем использовать сценарий «Покупка товара» (Buy a Product), в котором происходит следующее.

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

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

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

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

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

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

Содержимое прецедентов

Не существует стандартного способа описания содержимого прецедента; в разных случаях применяются различные форматы. На рис. 9.1 показан общий стиль использования. Вы начинаете с выбора одного из сценариев в качестве главного успешного сценария (main success scenario). Сначала вы описываете тело прецедента, в котором главный успешный сценарий представлен последовательностью нумерованных шагов. Затем берете другой сценарий и вставляете его в виде расширения (extension), описывая его в терминах изменений главного успешного сценария. Расширения могут быть успешными – пользователь достиг своей цели, как в варианте 3a, или неудачными, как в варианте 6a.

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

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

Расширение внутри прецедента указывает условие, которое приводит к взаимодействиям, отличным от описанных в главном успешном сценарии (main success scenario, MSS), и устанавливает, в чем состоят эти отличия. Расширение начинается с имени шага, на котором определяется это условие, и предоставляет краткое описание этого условия.
Следуйте этому условию, нумеруя шаги таким же образом, что и в главном успешном сценарии. Заканчивайте эти шаги описанием точки возврата в главный успешный сценарий, если это необходимо.

Структура прецедента – это отличный инструмент для поиска альтернатив главного успешного сценария. На каждом шаге спрашивайте:
«Что может еще произойти?» и в частности «Что может пойти не так?»

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

Сложный шаг в прецеденте можно представить другим прецедентом. В терминах языка UML мы говорим, что первый прецедент включает (includes) второй. Не существует стандартного способа показать в тексте включение прецедента, но я думаю, что подчеркивание, которое предполагает гиперссылку, работает прекрасно, а во многих инструментах действительно будет гиперссылкой. Так, на рис. 9.1 первый шаг включает шаблон «просматривает каталог и выбирает товары для покупки».

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

Наряду с шагами сценария можно вставить в прецедент дополнительную общую информацию.
• Предусловие (pre-condition) описывает действия, обязательно выполняемые системой перед тем, как она разрешит начать работу прецедента. Это полезная информация, позволяющая разработчикам не проверять некоторые условия в их программе.
• Гарантия (guarantee) описывает обязательные действия системы по окончании работы шаблона ответа. Успешные гарантии выполняются после успешного сценария; минимальные гарантии выполняются после любого сценария.
• Триггер (trigger) определяет событие, инициирующее выполнение прецедента.

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

Диаграммы прецедентов

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

Лучше всего обдумывать диаграмму прецедентов с помощью графической таблицы, показывающей их содержимое. Она напоминает диаграмму контекста, используемую в структурных методах, поскольку она показывает границы системы и ее взаимодействие с внешним миром. Диаграмма прецедентов показывает актеров, прецеденты и отношения между ними:
• Какие актеры выполняют тот или иной прецедент
• Какие прецеденты включают другие прецеденты
В языке UML помимо отношения «include» (включает) есть и другие типы отношений между прецедентами, например отношение «extend» (расширяет). Настоятельно рекомендуем его избегать. Слишком часто разработчики целыми командами надолго погружались в рассмотрение различных отношений между прецедентами, понапрасну растрачивая силы. Лучше уделяйте больше внимания текстовому описанию прецедента; именно в этом заключается истинная ценность этой технологии.

Прецеденты и возможности (или пожелания)

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

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

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

Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.

Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».

Перейти на страницу курса

Источник