Лекция 6: Диаграммы прецедентов: крупным планом Несколько слов о требованиях Итак, поговорим о требованиях. Что это такое, мы, в общем, понимаем — когда заказчик описывает нам, чего же именно он хочет, мы всегда слышим фразы типа «хотелось бы, чтобы проверка обновлений проводилась автоматически, как в антивирусах», «хочу большую зеленую кнопку в центре окна, которая начинает процесс», «программа должна позволять просматривать и печатать отчеты», «и чтоб красивенько все было, с полупрозрачностями, как в Висте», «при выходе должно выводиться подтверждение» и т. д. и т. п. Конечно, как настоящие разработчики, мы понимаем и то, что заказчик никогда не знает, что именно ему нужно, а если понимает, то объяснить не может.
Но ведь фразы-то всегда, по сути, одинаковы! Они описывают, как заказчик представляет себе систему, чего заказчик хочет от системы, функциональность, которой он от нее ожидает, требования, которые к ней предъявляет.
Диаграмма Use Case
Если обратиться к классикам, например, к той же «банде трех» (Якобсон, Буч, Рамбо), мы узнаем, что требование — это желаемая функциональность, свойство или поведение системы. Именно со сбора требований начинается процесс разработки ПО. Если изобразить процесс разработки ПО в виде » черного ящика » (уверены, читатель знает, что это такое, если нет — «Википедия» к вашим услугам), на выходе которого мы получаем программный продукт, то на вход этого «черного ящика» будет подаваться именно набор требований к программному продукту (рис. 6.1)!
Рис. 6.1. Кстати, какую диаграмму напоминает этот рисунок? Правильно, диаграмму активностей. И выбор именно этой диаграммы тут абсолютно оправдан — помните, мы говорили, что диаграммы активностей часто используют для описания бизнес-процессов?
Единственный нюанс: обычно процесс разработки не заканчивается с выпуском программного продукта — грядет новая итерация, новые, уточненные требования, новая версия и т. д. Кстати, вернемся к требованиям. Да, мы сказали, что на вход нашего «черного ящика» подается набор требований. Но в какой форме? Как их документируют, эти требования?
Думаю, большинство читателей помнит, что такое техническое задание — основной документ, без составления которого не начинался в советские времена ни один проект. Документ это был большой, многостраничный, с четкой структурой, определяемой ГОСТами (государственными отраслевыми стандартами). И описывал он, посути, не что иное, как требования к создаваемой системе!
Рекомендуемые материалы
Домашнее задание №2 (Вариант E16)
Объектно-ориентированное программирование (ООП)
Лабораторная работа №8(7) (Вариант F16)
Объектно-ориентированное программирование (ООП)
Проектно-технологическая практика ООП №3 Вариант 16 (оцененная на максимум) Проект+отчет Кафедра ИУ6
Объектно-ориентированное программирование (ООП)
Практика ООП 2 семестр РК6
Объектно-ориентированное программирование (ООП)
Объектно-ориентированное программирование (ООП)
Объектно-ориентированное программирование (ООП)
UML Диаграмма Прецедентов (UML Use Case Diagrams)
Техническое задание — вещь по-своему хорошая. Но время шло, менялись стандарты, нотации, способы описания требований. И вот постепенно техническое задание уступило место набору артефактов, состоящему из документов двух видов: · диаграммы прецедентов; · нефункциональные требования.
Диаграммы прецедентов составляют модель прецедентов (вариантов использования, 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. На диаграммах прецедентов обычно применяется именно «человекоподобная» форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом > (рис. 6.5):
Рис. 6.5. С системой экторы, как мы уже сказали, общаются через сообщения, но если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты. Один и тот же эктор может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными экторами.
Ассоциации между эктором и прецедентом всегда бинарные — т. е. представляют отношения типа «один к одному», использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один эктор может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций — по одной на каждый прецедент. Мы видели это в нашем примере.
Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого обозначения вполне понятен: этонаправленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д. И еще — экторы не могут быть связаны друг с другом.
Единственное допустимое отношение между экторами — генерализация (наследование ). Опять-таки, в нашем примере с заказом обедов в офис, вы могли увидеть именно такой вид отношений между экторами. Это не значит, что в реальной жизни офис-менеджер и секретарь (да и вообще любые два сотрудника) не могут общаться: просто при создании модели прецедентов такое общение не попадает в область наших интересов, считается несущественным.
Еще один тип элементов, встречающийся на диаграммах прецедентов, более того, давший им название, — это собственнопрецеденты, или варианты использования. Прецедент — это описание набора последовательных событий (включая возможные варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату.
Прецеденты описывают сервисы, предоставляемые системой экторам, с которыми она взаимодействует. Причем прецедент никогда не объясняет, «как» работает сервис, а только описывает, «что» делается. Изображаются прецеденты в виде эллипса, внутрь контура которого помещается имя (описание) прецедента. Имя прецедента обычно намного длиннее имен других элементов модели.
Почему это так, в принципе, понятно: имя прецедента описывает взаимодействие эктора с системой, говорит о том, какими сообщениями они обмениваются между собой. В нашем примере с заказом обедов мы видели несколько прецедентов и наверняка читатель заметил, что имя прецедента — это, скорее, название сценария, воспроизводящегося в ходе взаимодействия эктора с системой. Причем это всегда описание с точки зрения эктора, описание услуг, предоставляемых системой пользователю. Приведем пример простейшей диаграммы, иллюстрирующей сказанное нами об обозначениях прецедента (рис. 6.6).
Рис. 6.6. В этом примере пассажир может купить в сервисной кассе билет на некоторый вид транспорта. Покупка билета — это название сценария, по которому эктор (пассажир) может взаимодействовать с системой (кассой). Заметьте, это не описание сценария, а именно название — оно говорит нам, что делает эктор в процессе взаимодействия, но не говорит, как именно!
И еще — прецеденты определяют непересекающиеся сценарии поведения. Выполнение одного прецедента не может быть прервано в результате работы другого прецедента. Другими словами, выполнение одного прецедента не может быть прервано в результате событий или действий, вызванных выполнением другого прецедента.
Прецеденты выступают как атомарные транзакции, выполнение которых не может быть прервано. Внимательный читатель, возможно, отметил то, как незаметно мы ввели в употребление слово » сценарий «. Что же такоесценарий и как понятие сценария связано с понятием прецедента? На первый вопрос хорошо отвечают классики (Г.
Буч): Сценарий — это конкретная последовательность действий, иллюстрирующая поведение. Сценарий — это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия. Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения.
Как мы уже только что отметили, написание сценария напоминает написание художественного рассказа, и этим объясняется тот факт, что использование сценариев широко распространено среди аналитиков, которые часто обладают художественными или литературными способностями. Несмотря на непрерывный повествовательный характер, сценарии можно рассматривать как последовательности действий (делать раскадровку ). При разработке пользовательского интерфейса сценарии описывают взаимодействие между пользователем (или категорией пользователей, например, администраторами системы, конечными пользователями) и системой.
Такой сценарий состоит из последовательного описания комбинаций отдельных действий и задач (например, нажатий клавиш, щелчков по элементам управления, ввода данных в соответствующие поля и т. д.). Вспомните, к примеру, описания последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе.
То же самое можно сказать о модных сейчас «how-to videos», в которых такие последовательности отображаются визуально, на конкретных примерах. В любом случае, цель подобных справочных материалов — предоставить описание типичных сценариев использования системы, сценариев взаимодействия между пользователем и системой. Сценарии также иногда можно увидеть на диаграмме прецедентов.
Иногда их изображают в виде » листа бумаги «, на котором написано имя файла, — прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 6.7).
Рис. 6.7. Как мы уже упоминали, сценарии могут быть записаны в различных формах. Это может быть структурированный, но неформализованный текст, формализованный структурированный текст, псевдокод, таблица, диаграмма активностей, наконец!
Каждый сценарий описывает в повествовательной форме завершенное, конкретное взаимодействие, имеющее с точки зрения пользователя определенную цель. Если рассматривать табличную форму представления сценария, то линия, разделяющая левый и правый столбцы таблицы, символизируют собой границу, отделяющую действия пользователя от ответных действий системы.
Табличная форма особо подчеркивает участие пользователя, что является очень важным аспектом при разработке пользовательского интерфейса. Вот пример простого (неформализованного) текстового описания сценария. Пользователь вводит логин, пароль, адрес электронной почты и код подтверждения и нажимает кнопку «Далее». Система запрашивает ввод проверочного кода.
Пользователь вводит код и нажимает кнопку «Далее». Система проверяет соответствие кода изображенному на картинке. Не правда ли, знакомая процедура? Да, это описание регистрации пользователя на некотором сайте.
Правда, не совсем полное: не рассмотрены случаи, когда выбранный пользователем логин уже занят, адрес электронной почты введен неправильно, парольне удовлетворяет требованиям или код не соответствует изображенному на картинке. О таких случаях — альтернативных сценариях — мы поговорим чуть позже. А вот тот же сценарий в табличном представлении:
| Действия пользователя | Реакция системы |
| Ввод логина, пароля, адреса электронной почты и нажатие кнопки «Далее» | Запрос ввода проверочного кода |
| Ввод проверочного кода и нажатие кнопки «Далее» | Проверка кода на соответствие изображенному на картинке |
Источник: studizba.com
Варианты Использования «Включить» И «Расширить»
Вариант использования описывает, как пользователь использует систему для достижения определенной цели. Диаграмма вариантов использования состоит из системы, связанных вариантов использования и действующих лиц и связывает их друг с другом для визуализации: что описывается? ( система ), кто использует систему? ( актеры ) и чего хотят добиться актеры? ( прецеденты использования ), таким образом, прецеденты помогают обеспечить разработку правильной системы, фиксируя требования с точки зрения пользователя.
Структурирование вариантов использования
Отношения вариантов использования моделируют зависимости между вариантами использования в модели взаимодействия системы. Хотя независимые варианты использования могут адекватно представлять более простые системы. Однако для представления сложных или больших систем нам может потребоваться построить сложные варианты использования с помощью зависимостей между вариантами использования. Установление взаимосвязей между вариантами использования позволяет повторно использовать те варианты использования, которые необходимо определять снова и снова, что снижает усилия разработчиков.
UML определяет три стереотипа для структурирования ассоциаций вариантов использования.
Что такое вариант использования >?
Расширенный вариант использования фактически является альтернативой базовому варианту использования. Вариант использования «расширить» выполняет это, концептуально вставляя дополнительные последовательности действий в последовательность базового варианта использования.
Время для использования отношения > наступает после того, как вы завершили первое описание всех ваших основных вариантов использования. Теперь вы можете просмотреть варианты использования и определить общие последовательности взаимодействия пользователя с системой.
- Когда вариант использования изображается как использующий функциональность другого варианта использования, отношение между вариантами использования называется отношением включения или использования.
- Вариант использования включает функциональные возможности, описанные в другом варианте использования, как часть его бизнес-процесса.
- Отношение «использует» от базового варианта использования к дочернему варианту использования указывает, что экземпляр базового варианта использования будет включать поведение, указанное в дочернем варианте использования.
- Отношение включения изображается направленной стрелкой, имеющей пунктирную линию. Кончик стрелки указывает на дочерний вариант использования и родительский вариант использования, соединенные в основании стрелки.
- Стереотип «>» идентифицирует отношение как отношение включения.
Пример использования — включение связи
Отношение включения добавляет дополнительную функциональность, не указанную в базовом варианте использования. Отношение > используется для включения общего поведения из включенного варианта использования в базовый вариант использования, чтобы поддерживать повторное использование общего поведения.
Что такое вариант использования >?
- Указывает, что вариант использования «Неверный пароль» может включать (с учетом указанного в расширении) поведение, заданное базовым вариантом использования «Вход в учетную запись» .
- Изобразить направленной стрелкой, имеющей пунктирную линию. Кончик стрелки указывает на базовый вариант использования, а дочерний вариант использования соединяется с основанием стрелки.
- Стереотип «>» идентифицируется как отношение расширения.
Расширить отношения
Отношения расширения важны, потому что они показывают дополнительную функциональность или поведение системы. Отношение > используется для включения необязательного поведения из расширенного варианта использования в расширенный вариант использования. В приведенном выше примере есть соединитель расширения с точкой расширения «Неверный пароль».
Абстрактный и обобщенный вариант использования
Общий вариант использования является абстрактным. Его нельзя создать, так как он содержит неполную информацию. Название абстрактного варианта использования выделено курсивом.
Пример диаграммы варианта использования
Этот пример диаграммы прецедентов изображает модель нескольких бизнес-прецедентов (целей), которые представляют собой взаимодействие между рестораном (бизнес-системой) и его ключевыми заинтересованными сторонами (участниками бизнеса и работниками бизнеса). Определив основные варианты использования в первом раунде сокращений, мы, возможно, сможем дополнительно построить эти варианты использования с «расширением» и «включением» вариантов использования во втором раунде изменений.
Источник: blog.visual-paradigm.com
Бизнес-моделирование в UML (диаграмма прецедентов).
Назначение модуля: определение ускоренной оценки возможности реализации проекта разрабатываемой ИС в соответствии с выбранными требованиями.
Для проекта ИС этот модуль является первым шагом перед детальным исследованием ОУ, подразумевающим требования, СТ и СЛС.
При реализации модуля исследуется существующая ИС, которая позволила бы оценить вариант ИС по соответствующим ограничениям.
Входы модуля: — входные данные, определяющие цель;
— выбранный вариант ИС для анализа реализуемости;
— договор об объеме исследований;
— документы, инициирующие проект;
— ссылки: ОС, ФС, ОУ.
— цели(предусматривает определение возможности удовлетворения коммерческих требований заказчика разрабатываемой ИС);
— установление соответствия между планируемыми ресурсами и предполагаемыми расходами;
— оценка возможности создания логической и физической БД по исходным данным;
— обеспечить менеджеру проекта возможность выбора рационального проекта системы;
— в группу участников включаются опытные пользователи, разработчики-аналитики, обладающие способностями к анализу и управлению проектом;
— отчет по анализу реализуемости;
— описание действий по анализу реализуемости.
Выходы: — анализ реализуемости (ТЭО ИС).
UML Назначение. Свойства
UML является унифицированным стандартом для создания чертежей ПО.
С помощью UML можно:
— документировать артефакты программных систем;
Артефакт- исскуственные технические объекты(документ).
UML пригоден для моделирования ИС, WEB-приложений, систем реального времени.
3-и основных элемента:
1.Базовые строительные блоки
2.правила определяющие как эти блоки могут взаимодействовать между собой.
3.Общие механизмы языка.
