Вы находитесь на странице: 1из 14

Case-средства.

Лекция №5.
Диаграмма use case.

Авторы:
Добрынин А.С.
2015-2018

Сибирский государственный
индустриальный университет
г. Новокузнецк.
Диаграммы UML
Два типа диаграмм всего.
1) Структурные модели (structured models) – модели,
предназначенные для описания статической структуры
сущностей или элементов некоторой системы, включая их
классы, интерфейсы, атрибуты и отношения.
(диаграмма классов, диаграмма объектов, диаграмма
компонентов, диаграмма пакетов, диаграмма
развертывания, диаграмма композитной структуры)
2) Модели поведения (behavioral models) – модели,
предназначенные для описания процесса
функционирования элементов системы.

(диаграмма вариантов использования, диаграмма


деятельности, диаграмма последовательности, диаграмма
конечного автомата, диаграмма коммуникации)
Назначение диаграммы use case
1) Определить актеров (кто пользователь?) системы.
2) Определить границы системы с точки зрения разных ее
пользователей (актеров).
3) Предоставить концепцию взаимодействия будущего
пользователя (актера) с системой.
4) Описать базовую функциональность системы с точки зрения
актеров.
Главная задача.
Описать работу (взаимодействие) актера (пользователя)
с системой в виде простых для понимания и работы
прецедентов. Чем меньше прецедентов, тем лучше.
Зачем? Пользователь в итоге выберет то, что проще!.
Имеется Windows и 1000+ клонов Unix, Linux и что. Доля рынка
Linux систем по прежнему 1%. Вы сами пользуетесь Linux??
Следствие. Не пудрите пользователю мозги!
4) Делайте меньше прецедентов.
Философские аспекты
1) Не пытайтесь выявить ВСЕ прецеденты. Это невозможно.
2) Смиритесь с тем, что ваше видение будущей системы не
оптимально на текущий момент. Но оно может (и будет)
эволюционировать по мере работы над проектом.
3) Завтра прецеденты изменятся. Придет заказчик или другой
актер и все изменится. Это нормально.
4) Если завтра все изменится, не нужно фиксировать детали.
Прецеденты – это текущие требования к системе.
5) Прецедент описывает видимый пользователю результат!
(какое отношение к этому имеет запись в бд или фиксация
транзакции??)
6) Под видимым событием мы понимаем нечто, что
пользователь может наблюдать глазами (ушами и т.д.).
Прецеденты вообще не описывают скрытое поведение. В них
не обсуждаются скрытые механизмы системы. Пользователя
не интересует, что находится под капотом. Только то, что он
сможет увидеть лично.
4
Обозначения на диаграмме

Отношение типа ассоциации возникает между актером и


прецедентом, таким образом актер создает некий наблюдаемый для
себя результат-прецедент.
Границы системы четко отделяют систему от ее внешнего окружения.
Отношения обобщения возможно между актерами и прецедентами.
Отношения ассоциации со стереотипами «extend» и «include» обычно
указываются между вариантами использования.

5
Вариант использования
1) Вариант использования (или прецедент) – это
описание поведения системы, как его видит актер
(пользователь). Актер просит систему что-то
сделать и наблюдает результат.
2) Представляет собой общую спецификацию
выполняемых системой действий с целью
представления наблюдаемого результата, который
имеет значение для актеров.
3) Проясняет функциональность системы.

6
Актер
1) Расширяет понятие “пользователь”. Актер это не
только человек, актером может быть почтовый
робот или спам-бот.
2) любая внешняя по отношению к проектируемой
системе сущность, которая взаимодействует с
системой и использует ее функциональные
возможности для достижения определенных
целей или решения частных задач.
3) Примеры актеров: менеджер продаж,
администратор, сотовый телефон, скрипт.

7
Идентификация актеров в системе
Для идентификации актеров (кто пользователь)
отвечайте на вопросы:
• Какие организации или лица будут использовать
систему?
• Кто будет получать пользу от использования
системы?
• Кто будет использовать информацию от системы?
• Будет ли использовать система внешние ресурсы?
• Может ли один пользователь играть несколько
ролей при взаимодействии с системой?
• Могут ли различные пользователи играть одну роль
при взаимодействии с системой?
• Будет ли система взаимодействовать с
законодательными, исполнительными, налоговыми
или другими органами? 8
Отношение ассоциации
1) Является важнейшим и фундаментальным
в ООП и UML. Самое распространенное
на диаграммах UML (более 50% связей).
2) Ассоциация с мощностью – то что
используется в РСУБД всегда и ERD в
частности.
3) Используется на диаграмме use case для
описания взаимодействия актера и
варианта использования. Никак иначе!

9
Расширение и включение
1) Отношение ассоциации со стереотипами «extend» и «include» - это
зависимые отношения между прецедентами, которые можно указать
явно.
2) Отношение включения (include) специфицирует тот факт, что некоторый
прецедент (всегда) содержит поведение другого прецедента.
3) Отношение расширения (extend) определяет прецедент,
функциональность которого (иногда) задействуется только при
определенных условиях по отношению к заданному.

О ф орм л ение З аказа в < < in c lu d e > > Р еги стр ац и я


И н те р н е т-м а га з и н е п о ку п ател я

вариант использования А вариант использования Б

< < e x te n d > > П р ед о став л ен и е б о н у сн о й


О ф о рм л ение З аказа в
ски д ки п о сто я н н о м у
И н те р н е т-м а га з и н е
п о ку п ател ю

вариант использования А вариант использования Б


10
Практические рекомендации.
1) Делайте диаграммы use case максимально простыми.
3-4 прецедента на начальном этапе вполне
достаточно.
2) Не превращайте диаграмму прецедентов в диаграмму
деятельности.
3) Диаграммы прецедентов могут делаться для
заказчиков.
4) Избегайте отношений между прецедентами,
предоставьте разработчику свободу в реализации.
5) Отношения между прецедентами лучше избегать, они
не добавляют ничего нового ни прецедентам, ни
пониманию системы, а приводят к бесконечным
спорам по поводу того, что имеет место
«расширение» и «обобщение».
6) Диаграмма use case должна акцентировать внимание
команды разработчиков на функциональности,
которая должна быть реализована в первую
очередь. Она сфокусирована на быстрое получение
конкретного результата – ожидаемого пользователем
поведения.
11
Практические задания.
Постройте use case диаграммы для с использованием
case – инструментария (Software Architect, Visual UML,
Rational Rose и т.д.). Загрузите диаграммы в систему
MOODLE. Варианты заданий – в соответствии с номером
по списку в группе.
1) Требуется разработать систему мониторинга
технологического оборудования производственного
предприятия. Постройте use case диаграмму.
2) Требуется разработать систему управления
обслуживанием и ремонтами технологического
оборудования. Постройте use case диаграмму.
3) Требуется разработать систему номенклатурного
учета основных средств на предприятии. Постройте
use case диаграмму.
4) Требуется разработать систему управления
учебным процессом образовательного учреждения.
Постройте use case диаграмму.
5) Требуется разработать систему управления
заявками на обслуживание пользователей
компьютерного оборудования. Постройте use case
диаграмму. 12
Практические задания.
Продолжение.
6) Требуется разработать систему «Банкомат».
Постройте use case диаграмму.
7) Требуется разработать банковскую систему
кредитования клиентов и учета просроченной
задолженности. Постройте use case диаграмму.
8) Требуется разработать Web-систему продажи
текстов через Internet “text sale”. Постройте use case
диаграмму.
9) Требуется разработать Web-систему обучения и
сертификации специалистов “tech monkeys”.
Постройте use case диаграмму.
10) Требуется разработать Web-систему online-
заказов для ресторана. Постройте use case диаграмму.
11) Требуется разработать Web-систему подсчета
голосов избирателей на выборах. Постройте use case
диаграмму.
12) Требуется разработать Web-систему online-
бронирования номеров в отеле. Постройте use case
диаграмму.
13
Спасибо за
внимание!

14