- •Учебный курс
- •Канонические диаграммы языка UML 1.х
- •Классификация моделей в языке UML
- •Канонические диаграммы языка UML 2.х
- •Взаимосвязь представлений сложной системы
- •Рекомендации по изображению диаграмм в нотации языка UML
- •Механизмы расширения языка UML
- •Механизмы расширения языка UML
- •Стереотипы в языке UML
- •Графические стереотипы компонентов в IBM Rational Rose
- •Ограничения в языке UML
- •Помеченные значения в языке UML
- •Диаграмма вариантов использования (use case diagram)
- •Диаграмма вариантов использования
- •Назначение диаграммы вариантов использования
- •Проектируемая система и ее окружение
- •Основные обозначения на диаграмме вариантов использования
- •Вариант использования (use case)
- •Актер (actor)
- •Вопросы для идентификации актеров в системе
- •Отношения на диаграмме вариантов использования
- •Отношение ассоциации
- •Отношение включения
- •Отношение расширения
- •Изображение отношения расширения с условием выполнения
- •Отношение обобщения
- •Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине
- •Формализация функциональных требований с помощью диаграммы ВИ
- •Functionality – функциональные требования
- •Спецификация ВИ с помощью текстовых сценариев
- •Показатели качества для модели вариантов использования
- •Последовательность разработки вариантов использования
- •Типичные ошибки при разработке диаграмм вариантов использования
- •Сценарий №1
- •Раздел Типичный ход событий
- •Раздел Типичный ход событий
- •Раздел Исключений
- •Сценарий №2 "Получение справки о состоянии счета"
- •Типичный ход событий
- •Типичный ход событий
- •Раздел Исключений
- •Раздел Исключений
Отношения на диаграмме вариантов использования
Отношение ассоциации
Ассоциация (association) является одним из фундаментальных понятий в языке UML 2.х и может использоваться на различных канонических диаграммах при построении визуальных моделей
Применительно к диаграммам вариантов использования отношение ассоциации может служить только для обозначения взаимодействия актера с вариантом использования.
П р о с м о т р с п и с к а п р е д с т а в л е н н ы х т о в а р о в
П о с е т и т е л ь И н т е р н е т - м а г а з и н а
Отношение включения
Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя элементами модели, предназначенная для спецификации того обстоятельства, что изменение одного элемента модели приводит к изменению некоторого другого элемента
Отношение включения (include) специфицирует тот факт, что некоторый вариант использования содержит поведение, определенное в другом варианте использования
О ф о р м л е н и е З а к а з а в |
< < in c lu d e > > |
Р е г и с т р а ц и я |
И н т е р н е т - м а г а з и н е |
|
п о к у п а т е л я |
в а р и а н т и с п о л ь з о в а н и я А |
в а р и а н т и с п о л ь з о в а н и я Б |
Отношение расширения
Отношение расширения (extend) определяет взаимосвязь одного варианта использования с некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.
О ф о р м л е н и е З а к а з а в |
< < e x t e n d > > |
П р е д о с т а в л е н и е б о н у с н о й |
|
с к и д к и п о с т о я н н о м у |
|||
И н т е р н е т - м а г а з и н е |
|
||
|
п о к у п а т е л ю |
||
|
|
в а р и а н т и с п о л ь з о в а н и я А |
в а р и а н т и с п о л ь з о в а н и я Б |
Изображение отношения расширения с условием выполнения
|
|
|
У с л о в и е |
: { к л и е н т и м е е т б о н у с н у ю к а р т о ч к у } |
|
e x t e n t io n |
p o in t : С к и д к а |
|
|
|
|
О ф о р м л е н и е З а к а з а в |
|
|
|
И н т е р н е т - м |
а г а з и н е |
< < e x t e n d > > |
П р е д о с т а в л е н и е б о н у с н о й |
|
|
||
e x t e n t io n |
p o in t |
|
с к и д к и п о с т о я н н о м у |
|
п о к у п а т е л ю |
||
С к и д к а |
|
|
Отношение обобщения
Отношение обобщения (generalization relationship)
предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели
О п л а т а в ы б р а н н о г о в |
|
О п л а т а т о в а р а п о |
И н т е р н е т - м а г а з и н е т о в а р а |
|
к р е д и т н о й к а р т о ч к е |
|
||
в а р и а н т и с п о л ь з о в а н и я А |
|
в а р и а н т и с п о л ь з о в а н и я Б |
П о с е т и т е л ь |
П |
о к у п а т е л ь |
|
И н т е р н е т - м а г а з и н а |
|||
|
|
||
( а к т е р А ) |
|
( а к т е р Б ) |
Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине
|
|
|
С и с т е м а п р о д а ж и т о в а р о в в И н т е р н е т - м а г а з и н е |
|
|
|
|
|||
|
|
|
|
П р о с м о т р с п и с к а |
|
|
|
|
|
|
|
|
|
|
т о в а р о в |
|
|
|
|
|
|
|
|
|
|
|
И з м е н е н и е с п и с к а |
|
|
|
|
|
|
|
|
|
|
т о в |
а р о в |
|
|
|
|
П о с е т и т е л ь |
И з м е н е н и е с о д е р ж а н и я |
|
|
|
|
|
||||
|
И н т е р н е т - |
|
к о р з и н ы |
|
|
|
|
|
||
|
м |
а г а з и н а |
|
|
|
|
|
|
|
|
|
|
|
|
О ф о р м л е н и е З а к а з а |
|
|
|
|
|
|
|
|
|
|
н а п о к у п к у т о в а р о в |
|
|
|
|
|
|
|
|
|
< < in c lu d e > > |
< < |
e x t e n d > > |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
Р е г и с т р а ц и я |
|
|
М |
е н е д ж |
е р |
||
|
|
|
|
|
|
|
|
|||
|
|
|
п |
о к у п а т е л |
я |
|
|
|
|
|
|
|
|
|
|
П р е д о с т а в л е н и е |
|
|
|
|
|
|
|
|
|
|
б о н у с н о й с к и д к и |
|
|
|
|
|
П |
о |
к у п а т е л |
ь |
|
|
|
|
|
|
|
|
|
|
|
О п л а т а в ы б р а н н о г о |
|
|
|
|
|
|
|
|
|
|
|
т о в а р а |
|
|
|
|
|
|
|
|
|
|
|
Б |
у |
х г а л т е р |
|
|
|
|
|
О п л а т а т о в а р а |
О п л а т а т о в а р а п о |
|
|
|
|
||
|
|
|
н а л и ч н ы м и |
к р е д и т н о й к а р т о ч к е |
|
|
|
|
Формализация функциональных требований с помощью диаграммы ВИ
Требование (requirement) – желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации
Требование к ПО – некоторое свойство ПО, которым должна обладать система или ее компонент, чтобы удовлетворять условиям контракта, положениям стандартов, формальной спецификации или технической документации
Управление требованиями – это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и разработчиком по поводу меняющихся требований к системе
Классификация требований – модель FURPS+
Functionality
функциональные требования
|
Usability |
(требования практичности) |
|
Reliability |
(требования надежности) |
Performance (требования производительности)
Supportability (требования обслуживания и сопровождения)
Дополнительно + IEEE 610.12.1990
Проектные ограничения
Требования выполнения
Требования к GUI Физические требования
Functionality – функциональные требования
Функциональные требования определяют действия, которые должна быть способна выполнить система, без рассмотрения физических особенностей их реализации
Тем самым функциональные требования определяют внешнее поведение системы
Лучше всего они описываются в форме модели вариантов использования
Каждому функциональному требованию в этом случае будет соответствовать отдельный вариант использования