Автор: Галиаскаров Э.Г.   Воробьев А.С.  

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

ISBN: 978-5-534-14903-6

Год: 2024

Похожие

Разработка Windows-приложений на основе Visual C#: учебное пособие

Современные операционные системы

Теоретический минимум по Computer Science. Все, что нужно программисту и разработчику

Современный JavaScript для нетерпеливых

Текст 
                    УМО

80
1

РЕКОМЕНДУЕТ


Э. Г. Галиаскаров, А. С. Воробьев

АНАЛИЗ И ПРОЕКТИРОВАНИЕ
СИСТЕМ С ИСПОЛЬЗОВАНИЕМ
UML
УЧЕБНОЕ ПОСОБИЕ ДЛЯ ВУЗОВ

Рекомендовано Учебно-методическим отделом высшего образования
в качестве учебного пособия для студентов высших учебных заведений,

обучающихся по ит направлениям

Курс с практическими заданиями и дополнительными материалами
доступен на образовательной платформе «Юрайт»,
а также в мобильном приложении «Юрайт.Библиотека»
Москва«Юрайт • 2024


УДК 004.45(075.8)
ББК 32.972я73
Г15

Авторы:
Галиаскаров Эдуард Геннадьевич — кандидат химических наук,
доцент кафедры информационных технологий и цифровой экономики
факультета
техники,
управления
и цифровой
инфраструктуры
Ивановского государственного химико-технологического университета;
Воробьев Алексей Сергеевич — заместитель директора ООО
«Интерсофт» (г. Иваново).
Рецензенты:
Малышко В. В. — кандидат физико-математических наук, доцент
кафедры системного программирования факультета вычислительной
математики и кибернетика Московского государственного университета
имени М. В. Ломоносова;
Видении А. С. — кандидат педагогических наук, доцент, заведующий
кафедрой
информационных
систем
Института
космических
и информационных технологий Сибирского федерального университета.
П5

Галиаскаров, Э. Г.
Анализ и проектирование систем с использованием UML : учебное
пособие для вузов / Э. Г. Галиаскаров, А. С. Воробьев.— Москва:
Издательство Юрайт, 2024.— 125с.— (Высшее образование).— Текст:
непосредственный.
ISBN 978-5-534-14903-6
Данное пособие представляет собой практическое руководство
по использованию UML для разработки программных систем. Оно
позволит научиться выявлять основные понятия предметной области
и разрабатывать
красивые
диаграммы
классов,
описывать
функциональные
требования
в виде
спецификаций
вариантов
использования и превращать их в правильные проектные решения.
Дополнительно в пособии рассмотрена работа с замечательным CASEсредством Visual Paradigm и средой разработки MDriven.
Соответствует
актуальным
требованиям
федерального
государственного стандарта высшего образования.
Для
студентов
высших
учебных
заведений,
обучающихся по ИТ-направлениям, а также преподавателей и всех
интересующихся.
УДК 004.45(075.8)
ББК 32.972я73

Все права защищены. Никакая частъ данной книги не может бытъ воспроизведена
в какой бы то ни было форме без письменного разрешения владельцев авторских
прав.

ISBN 978-5-534-14903-6

© Галиаскаров Э. Г., Воробьев А. С., 2021
© ООО «Издательство Юрайт», 2024


Оглавление
Введение.................................................................................... 5

Описание учебной задачи........................................................ 8

Предварительная настройка Visual Paradigm...................... 11
Лабораторная работа № 1. Разработка
концептуальной модели классов......................................... 13
1.1. Введение........................................................................................ 13
1.2. Текстуальный анализ................................................................... 14
1.3. Анализ списка классов-кандидатов........................................... 23
1.4. Определение ассоциаций между классами.............................. 27
1.5. Глоссарий....................................................................................... 29
1.6. Начальная модель классов.......................................................... 32
1.7. Диаграммы объектов................................................................... 36
Чек-лист............................................................................................... 40
Вопросы для самоконтроля............................................................... 41

Лабораторная работа № 2. Разработка модели
вариантов использования..................................................... 42
2.1. Введение........................................................................................ 42
2.2. Текстуальный анализ.................................................................. 43
2.3. Список действующих лиц и их задач......................................... 47
2.4. Краткое описание вариантов использования.......................... 49
2.5. Диаграмма вариантов использования...................................... 52
Чек-лист............................................................................................... 54
Вопросы для самоконтроля............................................................... 54

Лабораторная работа № 3. Уточнение
концептуальной модели классов......................................... 55
3.1. Введение........................................................................................ 55
3.2. Уточнение концептуальной модели классов............................ 56
3.3. Проверка модели методом OCL-навигации.............................. 59
Чек-лист............................................................................................... 70
Вопросы для самоконтроля............................................................... 71
3

https://urait.ru


Лабораторная работа № 4. Спецификация варианта
использования.............................................................................. 72
4.1. Введение...................................................................................................... 72

4.2. Описание вариантов использования................................................ 74

4.2.1. Вариант использования UC03 «Войти в систему»........... 74

4.2.2. Вариант использования UC15 «Пополнить баланс
карты»....................................................................................................... 78
4.3. Построение диаграмм деятельности вариантов
использования............................................................................... 79

4.3.1. Диаграмма деятельности «Войти в систему»................. 80

4.3.2. Диаграмма деятельности «Пополнить баланс карты»...82
Чек-лист........................................................................................................... 83
Вопросы для самоконтроля...................................................................... 84

Лабораторная работа № 5. Разработка модели
взаимодействия............................................................................85
5.1. Введение...................................................................................................... 85

5.2. Раскадровка варианта использования............................................ 86
5.2.1. Раскадровка варианта использования «Войти
в систему».................................................................................................... 86

5.2.2. Раскадровка варианта использования «Пополнить
баланс карты»............................................................................................ 90

5.3. Выявление системных событий и операций................................. 93
Чек-лист............................................................................................................. 101
Вопросы для самоконтроля........................................................................ 102

Лабораторная работа № 6. Реализация варианта
использования............................................................................103
6.1. Введение.................................................................................................... 103

6.2. Подготовка к работе.............................................................................. 104
6.3. Реализация варианта использования............................................ 105
Чек-лист............................................................................................................. 109
Вопросы для самоконтроля........................................................................ 110

Лабораторная работа № 7. Разработка модели
состояний.....................................................................................111
7.1. Введение.................................................................................................... 111

7.2. Список объектов-кандидатов.............................................................112
7.3. Диаграммы автоматов.......................................................................... 113

7.4. Интерактивная диаграмма автоматов........................................... 116
7.5. Спецификация состояний................................................................... 120
Чек-лист.............................................................................................................122
Вопросы для самоконтроля........................................................................122

Список используемых источников....................................... 124

4

https://urait.ru


Введение
Существует достаточно большое количество методов про­
ектирования и разработки программного обеспечения [1—3].
В данном учебном пособии мы ориентируемся исключительно
на объектно-ориентированные методы. В частности, мы поша­
гово разберем, как проводить объектно-ориентированный ана­
лиз, и затронем ряд моментов, связанных с проектированием.
Мы во многом ориентируемся на положения книги Дж. Рамбо
и М. Блаха «Объектно-ориентированное моделирование и про­
ектирование с иМБ» [4] и предлагаем читателю самостоятель­
но изучить эту замечательную книгу.
Базовый принцип объектно-ориентированного анализа (да­
лее ООА) — это представление предметной области как сово­
купности объектов, которые имеют определенные свойства
и поведение, и взаимодействуют друг с другом, обеспечивая
решения возложенных на них задач. На стадии проектирова­
ния предлагается высокоуровневая стратегия по построению
приложения (архитектуры системы), определяющая, каким
образом модели реального мира, полученные на этапе анали­
за, преобразуются в структуры программных классов и модели
поведения, удовлетворяющие исходным требованиям к систе­
ме. Наконец, на стадии реализации проектные модели преоб­
разуются в программный код и структуры баз данных. Таким
образом, объектно-ориентированный анализ и проектирова­
ние представляют собой описание системы как совокупности
различных моделей, а именно, моделей структуры и моделей
поведения.
Учебное пособие представляет собой последовательное опи­
сание процесса анализа и проектирования приложения по за­
данной предметной области и включает семь практических
упражнений, объединенных единой темой.
Первые две лабораторные работы представляют собой опи­
сание предметной области проектируемой системы с позиции
ее структуры и функционального назначения. Особое вни-

5

https://urait.ru


мание уделяется способам работы с исходной информацией,
ее формализации и преобразования в строгие модели. На этом
этапе формируются навыки проведения текстуального анализа
исходного описания, построения диаграмм классов, объектов
и вариантов использования, и согласования их между собой.
Третья лабораторная работа представляет собой следующую
итерацию построения модели предметной области и посвяще­
на углубленной проработке диаграммы концептуальных клас­
сов и проверке корректности построенной модели с использо­
ванием языка OCL (.Object Constraint Language'). Для реализации
этой задачи используются инструменты, позволяющие полу­
чить исполняемую модель и проверить ее на основе реальных
данных.
Четвертая, пятая и шестая лабораторные работы посвящены
описанию, формализации и реализации вариантов использо­
вания и демонстрируют методику перехода от описания функ­
циональных требований к объектно-ориентированной струк­
туре приложения. Особое внимание уделяется построению
диаграмм деятельности, последовательности и робастности,
а также разработке раскадровки для иллюстрации варианта
использования.
Завершает пособие лабораторная работа, посвященная во­
просам построения диаграмм автоматов с использованием
инструментов, позволяющих имитировать исполнение модели
и проверить правильность предложенного решения.
Учебное пособие предназначено для самостоятельной рабо­
ты студентов, изучающих дисциплину «Основы объектно-ори­
ентированного анализа и проектирования», и призвано позна­
комить с практикой выполнения анализа предметной области
решаемой задачи, привить навыки проектирования на основе
объектно-ориентированного подхода, научить моделированию
с использованием UML.
В результате изучения материалов учебного пособия и сле­
дования практическим советам студент будет:
знать
• принципы объектно-ориентированного подхода;
• синтаксис, семантику и прагматику языка UML;
• правила разработки и построения диаграмм классов, диа­
грамм объектов, диаграмм вариантов использования, диа­
грамм деятельности, диаграмм последовательности и диа­
грамм автоматов (состояний);

б

https://urait.ru


• правила написания спецификаций вариантов использова­
ния;
• правила составления OCL-выражений;
уметь
• разрабатывать объектно-ориентированные модели систе­
мы;
• применять текстуальный анализ для извлечения концеп­
туальных классов предметной области и вариантов использо­
вания;
• использовать UML-модели для анализа и проектирования
систем;
владеть
• языками визуального объектно-ориентированного моде­
лирования;
• методами объектно-ориентированного анализа и проек­
тирования;
• навыками построения моделей в Visual Paradigm и MDriven
Designer;
• навыками составления и использования OCL-выражений
для проверки навигации модели и задания ограничений.
Авторы выражают глубокую признательность и искреннюю
благодарность доценту Московского государственного универ­
ситета Виктору Васильевичу Малышко за поддержку, интерес
и полезные рекомендации в ходе написания этой работы.

https://urait.ru


Описание учебной задачи
В лабораторном практикуме разбирается учебная задача
по моделированию учетной системы по программе лояльности
сети кофеен «Астрокофе»1.
Сеть кофеен «Астрокофе» мотивирует кофеманов програм­
мой лояльности. Программа поддерживается при помощи карт
лояльности и специального сайта. Сайт программы позволяет
посетителю кофейни создать учетную запись. При заведении
учетной записи посетитель сообщает свой e-mail (далее исполь­
зуемый как логин), пароль, ФИО, дату рождения, номер одной
и более карт лояльности «Астрокофе», выданных ему ранее
в кофейнях. Пользователю, создавшему учетную запись, предо­
ставляется возможность «входить» в меню сайта, т. е. иметь до­
ступ к функциям участника программы лояльности. Участник
программы может редактировать сведения в своей учетной
записи, добавлять свои новые карты лояльности (два разных
участника не могут использовать одну и ту же карту с одним
и тем же номером), блокировать свои потерянные карты, по­
полнять баланс своих карт для осуществления покупок в ко­
фейнях «Астрокофе», просматривать операции (пополнения,
покупки) по карте, следить за накопленными в рамках про­
граммы «фишками», просматривать вознаграждения, доступ­
ные ему в зависимости от количества набранных «фишек», рас­
печатывать листовки с вознаграждениями для использования
их в кофейне.
Пополнение карты лояльности производится за счет средств
с банковской карты. Карта лояльности должна быть зареги­
стрирована как принадлежащая участнику и не заблокирова­
на. Баланс средств на ней может быть нулевым или положи­
тельным. Для пополнения пользователь указывает номер своей
банковской карты и код CW2, а также сумму пополнения. Сайт
1 Текст задания любезно предоставлен доцентом Московского государ­
ственного университета Виктором Васильевичем Малышко (http://sp.cs.msu.
ru/staff/mw.html)

8
https://urait.ru


программы лояльности связывается с банковской системой
и запрашивает, можно ли получить средства в пользу «Астро­
кофе». Если всё указано верно, с банковской карты указанная
сумма переводится на счет «Астрокофе», а баланс указанной
карты лояльности пополняется на ту же сумму. В противном
случае сайт сообщает, что пополнение не может быть осущест­
влено, и указывает причину этого.
Накопление «фишек» происходит после покупок в кофейне.
Клиент, приобретая напитки, зерновой или молотый кофе, ак­
сессуары и др., может сделать это за счет средств на карте ло­
яльности. Данные об этом (номер карты, дата и время, сумма
покупки, купленный напиток или товар) фиксируются в базе
данных о продажах и передаются на сайт программы лояльно­
сти. Данные о покупках, совершенных без карты лояльности,
в программе не учитываются. За каждую покупку начисляется
одна «фишка». Если покупка крупная — на сумму более 1500 ру­
блей, то начисляется дополнительная «фишка». Накопленные
«фишки» клиента суммируются по всем его картам лояльно­
сти. Он может ими распоряжаться независимо от того, с помо­
щью какой своей карты лояльности он их накопил. «Фишки»
можно конвертировать в вознаграждения. 10 «фишек» мо­
гут быть обменены на 1 вознаграждение «бесплатный напи­
ток». 20 «фишек» — на 1 вознаграждение «бесплатный стакан
для кофе». 30 «фишек» — на 1 вознаграждение «бесплатный
кофейник». Вознаграждениями клиент может воспользоваться
в кофейне. Для этого ему следует с помощью сайта распечатать
листовку. В листовке содержится штрих-код с данными о воз­
награждении, а также текст с указанием вида вознагражде­
ния. После печати листовки количество накопленных «фишек»
уменьшается соответственно выбранному вознаграждению.
Использованные листовки учитываются в базе данных о про­
дажах. Сведения о них передаются на сайт, который помечает
вознаграждение как использованное. Вознаграждение «бес­
платный напиток» начисляется клиенту ежегодно в его день
рождения. Вознаграждение «бесплатная пачка кофе» начисля­
ется клиенту после каждого пополнения его карты лояльности
на сумму, превышающую 1999 рублей.
Изменение старых правил и заведение новых правил на­
числения фишек/вознаграждений за покупки, пополнения
или в зависимости от дат осуществляется менеджером сайта.
Менеджер сайта поддерживает сайт в актуальном состоянии.

9

https://urait.ru


Он может редактировать сведения и добавлять новые виды
вознаграждений, обмениваемых на «фишки», а также публико­
вать на сайт статьи о напитках, зерновом кофе и аксессуарах,
предлагаемых в кофейнях. Эти статьи доступны любому по­
сетителю сайта программы лояльности. Неактуальные статьи
менеджер может править или удалять с сайта. При выявлении
нарушений менеджер может вносить изменения в данные лю­
бой учетной записи или блокировать учетную запись пользо­
вателя-нарушителя.

https://urait.ru


ПРЕДВАРИТЕЛЬНАЯ НАСТРОЙКА
VISUAL PARADIGM
Учебный проект выполняется в программном средстве
Visual Paradigm версии 16.0 и выше.
Чтобы приводимые в пособии скриншоты и выполняемые
действия совпадали с тем, что вы видите на своем экране, вам
нужно привести настройки программы к следующим:
В разделе Window меню в пункте Application Options /
General / Appearance / User Interface должно быть установле­
но значение Classic:
0

Астрокафе ■ Visual Paradigm Standard

Dash

Project

Agile

ITSM

View

Diagram

Modeling

Team

J

Window

I

Help

E Application Options
Project Opbore

0

New

Window

Start

License

Window

Switcher

Page

Manager

Configuration

Integration

Auto-Hide Tool bar

X

Application Options

sear ch-

General

General

Diagramming

G

tion

Printing

View

Edition

Teamwork

Referenced Project

Uodate

Environment

Appearance

Instant Reverse
ORM

Гі ter face

State Code Engine

© Classic

О Sleek

User Path
Rie Types

Spell Checking
Keys

Import / Export

В разделе Window меню (или в Tools, если вы уже переклю­
чились в режим Classic) в пункте Application Options / Spell
Checking снимите флаг Enable spell checking. К сожалению,
Visual Paradigm не поддерживает проверку орфографии на рус­
ском языке, и если не снять этот флаг, то все слова на русском
языке у вас будут подчеркиваться красным цветом:

и

https://urait.ru


Создайте новый проект «Астрокофе» (Project / New). Запи­
шите детали проекта аналогично тому, как показано на рисун­
ке ниже. Уделите некоторое внимание полю Description, в ко­
тором можно указать причины работы над проектом, кратко
описать назначение и задачи проекта.
& AcrpoKa^e • Visual Paradigm Standard

File

View

Edit

Modeling

ITSM

Paste

Й New

Agile

T

Tools

Undo Redo

UUL

CM-Shift* N

•^ Open...

Orb О

Reopen
I

Manage Referenced Project.

'^ Print

CM* P

Ді Print Active Diagram..
=^ Quick

Pnnt.

Model Element Quality' Checker
•

Project-based Quality Checker.

В панели Model Explorer создайте следующую структуру
проекта. Все создаваемые далее модели и объекты будут раз­
мещаться в пакетах этой структуры.
Model Expbrer

^

•

С

• I*

■

£

Ф [ЗМ^Лмыг требованія

Ѳ

[^одєльиїтзгьіссичія

& {((Варианты использованія

8 |(Дейстеу<хцие лица
• 2И₽еапиаи*я еариамтое иоюльэоеамия
• [^^одспь состояний

Ы р^одель структуры
8 ^Модель гредиетном области

ф СЯДвагрвгмы объектов
Й Р(Обьекты гред нет нои области

~ “"(Модель приложения

Й ГЗрхгэвнчиье классы

12

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 1.
РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ
МОДЕЛИ КЛАССОВ
Что нужно сделать в рамках данной лабораторной работы:
1) провести текстуальный анализ постановки задачи;
2) сформировать список классов-кандидатов;
3) выделить классы предметной области;
4) построить начальную модель классов;
5) определить возможные связи между классами;
6) дать связям подходящие названия;
7) указать кратности концов связи;
8) проиллюстрировать диаграмму классов несколькими диаграм­
мами объектов.

1.1. Введение

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

13

https://urait.ru


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

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

Класс — абстрактное описание множества объектов, которые
обладают одинаковой структурой и поведением [5, 6].
Класс-кандидат (как и класс) формулируется существительным
в единственном числе именительного падежа.

14

https://urait.ru


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

Текстуальный анализ исходного описания можно проводить
без использования каких-либо специализированных средств.
Вполне достаточно обычного текстового редактора и некото­
рых дополнительных приемов.
Вместе с тем, Visual Paradigm имеет в своем арсенале специ­
альный инструмент, который поможет провести текстуальный
анализ и быстро сформировать список классов-кандидатов.
В Diagram Navigator найдите пункт Textual Analysis
(рис. 1.1) и через контекстное меню создайте новый файл для
текстуального анализа, дайте ему приемлемое название, на­
пример: «Список классов-кандидатов», и скопируйте текст за­
дания в появившийся диалог.
Рекомендуем разбить текст на предложения так, чтобы каждое
предложение начиналось с новой строки (абзаца). Если предложе­
ние сложное, его также следует разбить на части. При необходимо­
сти можно пронумеровать каждое предложение.
Это облегчит восприятие информации и поможет выполнить
анализ более эффективно и быстро.

15

https://urait.ru


£ Астрокафе • • Visual Paradigm Standard

File

Modeling

View

Edit

Cut

Save

= ’

Navigator

O-gr

Q

k
o’

9

Tools

Undo Redo

Paste

Copy

^

Й

Agile

ITSM

Teamwork

Window

BuMWSS

UML

Help

SysUL

Requirement

Enterprise

SoaUL

Dagrams

Щ Textuel Analysai

X

3*LiJJ

ц Textual Analysis 1

. Package Diagram
5 IS Object Diagram (7)
Composite Structure Dm-

В

Timing Diagram
Interaction Overview Dia

èâ
: В

Captu'rg
Textual An

явят

$ « oSîaTXr^-^Ncw Textual Analyse
i^TextualAQ

----------

Сетъ кофеен Астрокофе мотивир

NewD

Сайт программы позволяет посев

$ fH Actors an —J
•

a^ Textual A

0

как логин), пароль. Ф. И. О., дату |
Export Visual Paradigm Project...

учетную запись, предоставляется і
A Requiremei ^

Export XML...

Business Co
-CRCCardD. -

₽nnt

карту с одним и тем же номером),

^Android Tat U

Sort Textual Analysis by name

просматривать операции (пополн

Android Phc j\
DO^Wi®

^

□ iPad Wiretap1'

kpand

может редактировать сведения в с

доступные ему в зависимости от >
Пополнение карты лояльности пр

[3 iPhone Wirt

участнику и не заблокирована Ба

банковской карты и код СѴѴ2. а т

Towwort

3 Q Web Wirefr; (J

Visual History-

средства в пользу Астрокофе

Ес

лояльности пополняется на ту же

Рис. 1.1. Диаграмма текстуального анализа

Чтобы в нашем проекте был порядок, сразу разместим создан­
ную диаграмму в Model Explorer в пакете Исходные требова­
ния. Для этого нужно выделить этот пакет и в контекстном меню
выбрать пункт Sub Diagrams / Existing Diagrams. В открывшем­
ся окне выберите ранее созданную диаграмму (рис. 1.2).
0 Астрокафе * - Visual Paradigm Standard

Edit

File

View

ITSM

Modeling

Agile

и .a
Project

Teamwork

Tools

Window

Help

S, El . S .

Save

Paste

Copy

В °—

M..

Undo Redo

4^ Oâ..

UML

Bustles#

SysML

El
Requrcment

«

.13
Enterprise

SoaML

Digrams

Scrum Canvas Large-Scae Scrum

P U>o-| i^ORM

в

Mede: Explorer

«

X

W ’ ^ ’ It
■

І
?■
з
é-

Астсскафе

Aetas

О

te Items

Add Sub Diagrams

Sub ciagram for Исходим требования

' H*d
: H^

Sub Diagrams

IМ

Textual Analysis • классы

Model Element

11Й

Actors and use cases

3 Дитера
орел Исходные требсеамия Specific

3 ^Moaen

Add

Select the (ЯадгатДО to add es sub degram(s).

View by: Model Hierarchy
New Diagram...

■

Preview

Rename-

І^Моаєл

Existing Diagrams...

Ввмоде.1

Show Link. .

(ft

®^.

Show View-.
Stéréotypés

: ЗЪ

Modal Tonsax
^

Transit From

^>

Transit To

ÇJ

Transit to New Modcl Elément...

Manage .

Ѳ Г^Астрокафе
s СГЫСОККЛ

а
і 3|Canddate Items
а ^Glossary
з ^ДИтераим проекта
з ^Модель ИСЛОГЪ-іСв^іЫ
з QiМодель структуры

Analysis..

Meige
Merge from Other Model Elemcnt($).~

3pr°p
Diagram Over

Merge to Model Element...

TfMmACdk
R

Commit...

Рис. 1.2. Добавление ранее созданной диаграммы в пакет
16

https://urait.ru

Pre VC


Теперь приступим непосредственно к выявлению классовкандидатов.
Первое, что нужно сделать — внимательно прочитать все
описание, возможно и не один раз, чтобы получить общее пред­
ставление о предметной области, увидеть картину в целом.
Далее последовательно анализируем каждое предложение
и выделяем в нем существительные, определяющие понятия
предметной области. Рассмотрим несколько примеров исполь­
зования данного подхода.
Начнем, естественно, с первого предложения:
«Сеть кофеен “Астрокофе” мотивирует кофеманов програм­
мой лояльности.»
«Сеть кофеен...» — в описании предметной области сказа­
но, что кофеен много. Можно сразу сделать предположение,
что поскольку кофеен целая сеть, то в проектируемой нами си­
стеме, возможно, должен существовать отдельный класс «Ко­
фейня», чтобы пользователи этой системы могли получать ин­
формацию по каждой из этих кофеен отдельно. Но может быть
это и не так. Поэтому записываем «кофейню» в список классовкандидатов. Позже, в ходе дальнейшего анализа, мы решим,
следует ли включать это класс в модель предметной области.
К сожалению, текущая версия Visual Paradigm не имеет ин­
струментов морфологического анализа слов русского языка,
и маловероятно, что будет иметь в будущем. И если слова ан­
глийского языка практически не меняются в контексте предло­
жения, то для русского языка, как мы знаем, все далеко не так.
Потому необходимо названия классов-кандидатов приводить
к единственному числу именительного падежа. Это правило
здорово поможет нам при анализе классов-кандидатов, по­
скольку Visual Paradigm будет подсчитывать число вхождений
данного слова в анализируемом нами тексте. А чем больше это
число, тем больше вероятность того, что перед нами действи­
тельно важная сущность предметной области, которая станет
частью диаграммы предметной области. Поэтому прямо в фай­
ле текстуального анализа вместо слова «кофеен» введем сло­
во «кофейня», как это сделано на рис. 1.3. Далее выделяем это
слово и через контекстное меню выполняем действие Add text
as Class.
В результате все слова «кофейня» в тексте будут выделены,
а в таблице в нижней части диалога (рис. 1.4) появится запись
с названием класса-кандидата, текста откуда он был получен.

17

https://urait.ru


Н

Исходные трябо^эмия •> Textual Analysis■ «пассы

a 1^1 >^Щ0
Сеть [кофейня]І ен “Астрокофе" мотивирует кофеманов програмі
Программа П|р^
Сайт протрав ? ал»

Рис 1.3. Действие Add text as Class

Следует помнить, что в русском языке одно и тоже слово может
иметь разные окончания. Поэтому чтобы помочь Visual Paradigm
справится с задачей подсчета числа повторений слова в тексте,
найдите их и приведите к единой форме: единственное число име­
нительного падежа.

В столбце Candidate Class нужно отредактировать название
класса так, чтобы оно начиналось с заглавной буквы и находи­
лось в единственном числе именительного падежа. В столбце
Description дайте подробное описание данного класса. Эта ин­
формация может стать впоследствии частью глоссария проекта
и помогать его участникам быстро понимать, о чем идет речь.
ИгмЛЖ» требования ■> Исходныя хреОоязиня Texiual яляЬяія

□ ІХ^ ^^ А ПИ
B-

• F- »• ► ^ +’ ü

^

Сеть кофейня ен “Астрокофе” мотивирует кофеманов программа лояльности.
Программа поддерживается при помощи карта лояльности и специального сайта.
I

кофейня

Туре
ВО»;

Description
(Одно из заведений сети "Астрокофе", в которой применяется программа лояльности клиентов

Рис 1.4. Список классов-кандидатов

Обратите внимание на то, что в Model Explorer автомати­
чески сформировался пакет Candidate Items, в котором будут
храниться все создаваемые классы-кандидаты (рис. 1.5).
^ Diagram Navigator

(^ Model Е>рІогег

о1

Model Бфіогег

9

X

U " t " II " A - ^
^ Астрокафе

A:з-d'date Items

^^—

5 рЯИсходные требования
S {^Модель использования

[^Модель СОСТОЯНИЙ
£ ^Модель структуры

Рис 1.5. Автоматически создаваемый пакет Candidate Items

18

https://urait.ru


Следующее существительное, которое привлекает наш
взгляд в первом предложении — это слово «кофеманов». Оче­
видно, что такая сущность будет в нашей системе. Более того,
исходя из общего контекста, это будет одна из центральных
сущностей, так как именно вокруг нее строится программа ло­
яльности. Единственное, что пока точно неизвестно это, как
именно мы будем называть эту сущность: «кофеман», «участник
программы», «клиент», «посетитель», «пользователь» или както иначе. Поэтому пока выделим это слово как класс-кандидат,
а потом проанализируем частоту использования каждого
из этих слов в тексте и на основе этого примем решение.
4 ИИ

в- г

Сеть кофейня ен ■ Астрокофе' мотивирует кофеман ов программа лояльности.
Программа поддерживается при по
рта лояльности и специального сайта.
Description
Одно из заведений сети "Астрокофе’, в котором применяется программа лояльности клиентов

2_ Кофейня
•

кофеман

кофеман

Посетитель сети кофеен "Астрокофе', потенциальный участи программы лояльности

Рис. 1.6. Обновленный список классов-кандидатов

А вот следующее словосочетание — «программа лояльно­
сти» — не является классом-кандидатом. По сути, это синоним
слова «система» в данном контексте. Также надо помнить, что
каждый класс (по своему определению) в информационной си­
стеме порождает набор объектов этого класса. Очевидно, что
несколько объектов «программы лояльности» не может суще­
ствовать.
Продолжаем анализ и разбираем второе предложение:
«Программа поддерживается при помощи карт лояльности
и специального сайта.»
Здесь бесспорным классом-кандидатом является слово «кар­
та» или «карта лояльности». А вот «сайт» — нет. Как было
отмечено выше, это понятие связано с реализацией системы,
а в данном контексте является синонимом слова «система». По­
этому исключаем это понятие из списка возможных классов.
Переходим к третьему предложению:
«Сайт программы позволяет посетителю кофейни создать
учётную запись.»
Здесь классами-кандидатами являются слова «Посетитель»,
«Кофейня», «Учетная запись». Как вы видите, некоторые слова
встречаются нам уже не в первый раз, поэтому Visual Paradigm

19

https://urait.ru


автоматически выделяет их желтым цветом (если словофор­
ма полностью соответствует), а внизу в таблице в столбце
Occurrence отображается количество упоминаний этих слов
(рис. 1.7). Слова «Посетитель» и «Учетная запись», как и слово
«Кофеман» ранее, указывают на наличие центральной сущно­
сти, вокруг которой будет строиться система лояльности. Но,
как ранее было замечено, пока преждевременно принимать
решение, какое же именно из этих понятий мы будем в итоге
использовать в качестве ключевого класса модели предметной
области. Поэтому добавим слова «Посетитель» и «Учетная за­
пись» к общему списку классов-кандидатов.
□ іі *^ □□
В- = • Е- F * Ж - •» £

Сеть кофейня ен ■ Астрокофе' мотивирует кофеман ов программа лояльности.

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

Ф И. О., дату рождения, номер одной и более карт лояльности "Астрокофе

выданных ему ранее в

кофейнях
Пользователю, создавшему учетную запись, предоставляется возможность "входить" в мег ю сайта, т. е
LJКофейни
кофеман

Поагтитепь

кофеман
■ ч ' ■’
посетите»

Одно из змедмм сети ‘Астрокофе*, • котором примметса программ* ломнссти клиент о*
Посетит Ми сети кофеен ‘Астрокофе*. ПОтекіХА-ЫКИл учКТМ« Программ ПОАПТНОСТИ
Керт* лоапьиости, по которой полъюмтелъ получает доступ к програмне

Рис. 1.7. Поле Occurrence

Анализируем четвертое предложение:
«При заведении учетной записи посетитель сообщает свой
e-mail (далее используемый как логин'), пароль, ФИО, дату рож­
дения, номер одной и более карт лояльности “Астрокофе”, вы­
данных ему ранее в кофейнях.»
Помимо уже известных по предыдущим предложениям слов,
в четвертом нам встречаются такие существительные, как
«email» или «логин», «пароль», «ФИО», «дата рождения» и «но­
мер карты». Следует ли их включать в список классов-канди­
датов? Категорически нет! Во-первых, это понятия, которые
описывают (дополняют, характеризуют) участника программы
лояльности и карту лояльности, сами по себе не имеют смыс­
ла и отвечают на вопрос «Чей». Во-вторых, как было отмечено
выше, эти понятия выражают простые значения: число, дату,
строку символов. Такие слова играют роль признаков, харак­
теристик сущности, и называются атрибутами класса. С ними
мы разберемся позже, а пока просто пропускаем.
Аналогичным образом производится анализ всего остально­
го текста. Каждое предложение задания, конечно, мы не будем

20

https://urait.ru


разбирать, так как в целом принцип рассуждений вам должен
быть уже понятен, и вы можете закончить анализ самостоя­
тельно. Остановимся только на некоторых интересных момен­
тах в тексте:
— «Участник программы может... просматривать опера­
ции (пополнения, покупки') по карте...» — очевидно, что из это­
го предложения можно выделить новый класс-кандидат «опе­
рация». Однако далее в скобках идет уточнение, что возможны
два вида операций: пополнения и покупки. Могут ли при этом
быть другие операции, мы пока точно сказать не можем. Но уже
сейчас мы можем задаться вопросом: сколько в этом описании
новых классов? Один или два? Классом является только «опера­
ция» или также «операция пополнения» и «операция покупки»?
Такая ситуация вполне возможна, когда класс «операция» будет
являться общим классом, а «операция пополнения» и «операция
покупки» — уточнениями, специализацией. Пока сложно дать
однозначный ответ, требуется дальнейший анализ атрибутного
состава этих потенциальных классов и особенностей их отно­
шений с другими классами-кандидатам. Пока выделим только
один класс «операция», но будем иметь в виду, что тут возмож­
на более сложная семантика;
— «Участник программы может... распечатывать листов­
ки с вознаграждениями для использования их в кофейне» —
можно предположить, что слово «листовка» также является
классом-кандидатом, но это не так. «Листовка» — это лишь
печатное отображение информации о количестве «фишек», ко­
торые пользователь хочет потратить на выбранное вознаграж­
дение. Правило тут простое: любые отчеты, печатные формы
не могут быть классами-кандидатами, так как они не могут
являться самостоятельными объектами в системе. Отчеты, пе­
чатные формы формируются только в момент, когда пользова­
тель этого захочет и нужны только для того, чтобы представить
информацию по другим объектам информационной системы
в удобном для пользователя виде;
— «Клиент, приобретая напитки, зерновой или молотый
кофе, аксессуары и др...» — посетитель покупает в кафе различ­
ные товары и в тексте задания перечисляются примеры таких
товаров (их может быть гораздо больше). Но самого слова «то­
вар» в данном предложении нет. При этом никто не запрещает
нам добавить это слово и поместить его в список классов-кан­
дидатов;

21
https://urait.ru


— «Менеджер сайта поддерживает сайт в актуальном со­
стоянии...» — следует ли включать понятие «менеджер» в спи­
сок классов-кандидатов? В тексте много уделено внимания
обязанностям менеджера по отношению к поддержанию сайта
в актуальном состоянии. По сути, менеджер — это персонал
проектируемой системы. Как будет показано дальше, менеджер
важен на этапе понимания того, что должна делать проектиру­
емая система, но непосредственного отношения к программе
лояльности эта сущность не имеет. Поэтому мы не включаем
ее в список классов-кандидатов;
— «Он может... добавлять новые виды вознаграждений, об­
мениваемых на фишки» — выше в тексте также перечисляют­
ся возможные виды вознаграждений: «бесплатный напиток»,
«бесплатный стакан для кофе», «бесплатный кофейник», «бес­
платная пачка кофе». Тот факт, что в системе могут добав­
ляться новые виды вознаграждений, дает нам право включить
в список потенциальных классов понятие «вид вознагражде­
ния» в качестве класса-кандидата;
— «Он может... публиковать на сайт статьи... Эти ста­
тьи доступны любому посетителю сайта... Неактуальные
статьи менеджер может править или удалять...» — сле­
дует ли включать понятие «статья» в список потенциальных
классов? Здесь рассуждения аналогичны предыдущему пункту.
Понятие «статья» относится к сайту и не имеет непосредствен­
ного отношения к программе лояльности. Поэтому также ис­
ключаем его из списка потенциальных классов.
Ниже представлен конечный результат текстуального ана­
лиза (рис. 1.8—1.9).
Ни.

1

СшМіК Сіи»

СхІгиОиІ Тихі

Туре

ОсшЯ*>ші

Ошят-

Вознаг раждемге вознаграждение д с» „ Подарки, которые можно покупать за фишки, в рамках лрегр,

14

г

Карта

карта

Вс-еп- карта лояльности, по которой пользователь получает дзету

14

3

вышка

фишка

■ Ок: внутренняя валюта в рамках программы лояльности, с пома

13

4

Покупка

покупка

Да«м

•скупка в кофейне товара с использованием карты лояльное

9

3

Кофейня

кофейня

Я СІМ! Одно из заведений сети "Астрокофе*, в котором применяется

8

6

Пополнение

пополнение

■ ОМ! Операция пополнения баланса карты лояльности

Учетная запись учетная запись ■ Омі Учетная запись участника программы лояльности
8

Клиент

Клиент

Дам; Посетитель сети кофеен 'Астрокофе", потенциальный умает

7

6
5

участник прогм участник грогргд^.. Зарегистрированный в системе участник программы лояльно
10

Посетитель

посетитель

Д Сім; Посетитель сети кофеен 'Астроксфе", потенциальный участ

3

11

Пользователь

Полозова гель

В ані Зарегистрированный в системе участник программы лояльнс

3

13

Товар

товар

Дам; Товары, которые макет купить посетитель в кафе

2

1*

Правило

правило

|а«< Условие, по которому начисляется фишки

2

13

Вид вознаграждевид вознагражден ом; Виды подарков, которые участник программы макет получа*

1

18

Операция

операция

Дані Действие, выполгаемое с помощью карты лояльности: попа

1

17

Кофеман

кофеман

ДОм; посетитель сети кофеен 'Астроксфе”. потенциальный участ

1

Банковская карт банковская картд^м; банксеэсая карта участника программы

3

Рис. 1.8. Итоговый список классов-кандидатов

22

https://urait.ru

НцМцЫ 1


1 ■ Сеть кофеина ем ‘ Астрокофе.' мотивирует КСф£ШЦ Ой программа ЛОЯЛЬНОСТИ.
2 . Программа поддерживается при помощи карта лояльности и специального сайта.
1 :айт к .; ! ■ ■^звопяет посетитель ю кофейня, йни создать устная затісь ую
4 При заведении уметная запись ей посетитель зябиш свой email (далее используемый как погни), пароль, ф и.
О. Д?ІУ рождения, номер одной и более карта лояльности 'Астрокофе' вьіданньа ему ранее в кофейня х
5 Пользователь ю. сосавшему учётная запись ую. предоставляется возможность "входить" в меню сайта, т е
6

wife доступ к функциям участник программы попиши а
. Участник программы может редактировать, сведения в своей учетная запись ой и, добавлять свои, новью карта
ы лояльности (два разм=іх участник программы а не могут использовать одну и туже карта у с одним и дем же

ИЙМЙЙОМ). ОПОКИР^ІЬСРІМОЙІ^^
карта Ы. пополнят^ Лаланг своих карта для осуществления покупка g
кофейня х Астрокофе' просматривать операция и (пополнение я. покупка и) по карте, следить за наюллежьіми
в рамках программы ’ фишка ми', просматривать вознаграждение ия, доступные ему в зависимости от
™ч8Шй йй&йім " Фишта. W. раякяяіы^Вг оияавки с юзаашааоеиие ими д^ ошдзджв их в
кофейня е.
?. Пополнение карта ы лояльности производится за ggT средств с банковская карта ой
8 Карта. лояльности ДбЕЕЯЙ &ЛЬ зарегистрирована Ш- принадлежащая участник программы у и не заблокирована.
Баланс средств на ней может быть нулевым или прлржщельным
9 Для пополнение я пользователь указывает номер своей банковская карта ой и CW2 код, а также сумму

ИШШЙИИЙ я
. Sail программы лояльности. связывается с банковской системо” И запрашивает. можно, ли получитъ средства в
пользу Астрокофе’.
11 ЄЯ» ЄРІ утазанр верно, с банковская.» «9 указанная дума. переводится на счет ’Астрокофе.'. а бапанс.
10

указанной карта ы пряпьурсп! пополняется на ту же сумму

Рис 1.9. Фрагмент текста описания с разметкой текстуального анализа

1. 3. Анализ списка классов-кандидатов

После формирования начального списка классов-кандида­
тов необходимо внимательно изучить его, убрать все лишнее,
объединить некоторые понятия, заменить на другие или даже
добавить новые, явно или неявно пропущенные в тексте.
В первую очередь нужно выявить все самые важные, ключе­
вые понятия. В этом нам может помочь общий контекст пред­
метной области, а также столбец Occurrence, в котором пока­
зывается, сколько раз выделенное слово встречается в тексте.
Кроме того, при удалении лишних классов можно руковод­
ствоваться следующими критериями:
— избыточные классы — отражают одно и тоже понятие
предметной области;
— несущественные классы для предметной области;
— нечеткие классы — сложно определить границы класса;
— атрибуты — свойства, характеристики, признаки класса;
— операции — действия над классом;
— роли, сравните: Человек и Водитель, Наниматель;
— классы, относящиеся к реализации: сайт, страница, кноп­
ка, форма, учетная запись и т. п.;
— производные классы — классы, которые могут быть вы­
ведены из других классов.
В табл. 1.1 представлен начальный список всех выделенных
в ходе текстуального анализа классов-кандидатов, отсортиро­
ванных в порядке убывания частоты использования их в тек­
сте.

23

https://urait.ru


Таблица 1.1
Список классов-кандидатов

Класскандидат

Частота
вхождения

Описание

Возна­
гражде­
ние

14

Подарки, которые можно покупать за фиш­
ки, в рамках программы лояльности

Карта

14

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

Фишка

13

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

Покупка

9

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

Кофейня

8

Одно из заведений сети «Астрокофе», в ко­
тором применяется программа лояльности
клиентов

Пополне­
ние

7

Операция пополнения баланса карты лояль­
ности

Учётная
запись

6

Учетная запись участника программы лояль­
ности

Клиент

5

Посетитель сети кофеен «Астрокофс», потен­
циальный участник программы лояльности

Участник
програм­
мы

4

Зарегистрированный в системе участник
программы лояльности

Посети­
тель

3

Посетитель сети кофеен «Астрокофе», потен­
циальный участник программы лояльности

Пользо­
ватель

3

Зарегистрированный в системе участник
программы лояльности

Бан­
ковская
карта

3

Банковская карта участника программы

Товар

2

Товары, которые может купить посетитель
в кафе

Правило

2

Правило, по которому начисляются фишки

Кофеман

1

Посетитель сети кофеен «Астрокофе», потен­
циальный участник программы лояльности

24

https://urait.ru


Окончание табл. 1.1
Класскандидат

Частота
вхождения

Операция

1

Действие, выполняемое с помощью карты
лояльности: пополнения счета или покупка

Вид воз­
награж­
дения

1

Виды подарков, которые участник програм­
мы может получать в рамках программы
лояльности

Описание

Для начала давайте определимся, как мы будем называть
центральную сущность, вокруг которой строится система ло­
яльности — посетителя кафе. В таблице для этой сущности
представлены несколько похожих друг на друга понятий (си­
нонимов): «Клиент» (5), «Участник программы» (4), «Посети­
тель» (3), «Пользователь» (3), «Кофеман» (1). Кроме того, «Учет­
ная запись» (6) также явно указывает на участника программы,
определяя это как обязательное условие участия в программе
лояльности. Если прочитать описания каждого потенциального
класса, нетрудно заметить, что «Клиент», «Посетитель», «Кофе­
ман» обозначают одно понятие — посетителя кафе. При этом
«Участник программы» и «Пользователь», по сути, уточняют
статус посетителя кафе: он является участником программы.
Вывод напрашивается очевидный: в качестве ключевого класса
будем использовать понятие «Участник программы».
Между понятиями «Пользователь» и «Учетная запись» тес­
ная семантическая связь: чтобы быть пользователем, нужно
иметь учетную запись. Конечно, «Пользователь» в данном
случае — более предпочтительное наименование для ключе­
вого класса. Однако нужно ли нам добавлять этот класс в мо­
дель предметной области? По нашему мнению, с этой задачей
успешно справится класс «Участник программы», поскольку
каждый участник программы — это и пользователь сайта.
Далее пройдемся по списку:
— вознаграждение — участник программы может приоб­
ретать различные вознаграждения по своему выбору. Менед­
жер может добавлять новые виды вознаграждений. В конце
концов, вознаграждение — это то, ради чего посетитель кафе
становится участником программы лояльности. Включаем эту
сущность в качестве ключевого класса предметной области;
— карта, или карта лояльности, по сути является иденти­
фикатором участника программы. Без карты участники не мо-

25

https://urait.ru


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

26

https://urait.ru


тировать / отменять различные правила, т. е. таких объектов
у нас в системе будет много, и они должны как-то храниться.
Это верный признак класса-кандидата. Включаем эту сущность
в качестве ключевого класса предметной области;
— вид вознаграждения — в описании упоминается не­
сколько видов вознаграждения, кроме того, явно говорится,
что могут появляться новые виды вознаграждений, а некото­
рые виды вознаграждения могут начисляться по разным пра­
вилам. Таким образом, можно сделать вывод, что данная сущ­
ность будет важной для нашей предметной области.
В результате получился следующий список ключевых клас­
сов предметной области (табл. 1.2). Частота вхождения изме­
нена с учетом объединения синонимичных понятий.
Таблица 1.2

Список ключевых классов предметной области
Ключевой класс

Частота вхождения

Вознаграждение

15

Карта (Карта лояльности)

14

Операция (Покупка, Пополнение)

17

Участник программы

22

Правило

2

Вид вознаграждения

1

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

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

27

https://urait.ru


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

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

Выпишем из задания ассоциации-кандидаты, которые обра­
зуют связь между классами. То есть здесь задача следующая:
читаем исходный текст задания, ищем упоминания классов,
которые были выявлены ранее (см. табл. 1.2) и находим между
ними связи. Допускается изменять названия найденных ассо­
циаций при сохранении их исходного смысла.
Таблица 13
Ассоциации-кандидаты
Участник программ может иметь одну или несколько карт лояльности
Участник программы может выполнять операцию пополнения карты

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

Участник программы осуществляет покупку товаров (операцию по­
купки)

Покупка товаров может делаться за счет средств карты лояльности

За каждую покупку начисляются фишки (на карту лояльности)
Участник программы получает вознаграждения
Накопленные фишки конвертируются в вознаграждения

Правила применяются при определении возможности получения воз­
награждений
Вознаграждения начисляются по заданным правилам в соответствии
с имеющимися вида вознаграждения

Сведения о покупках помечают вознаграждение как использованное

28

https://urait.ru


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

1.5. Глоссарий
В ходе анализа предметной области могут встречаться сло­
ва, которые требуют дополнительного объяснения. Глоссарий
содержит в себе определения для специфической терминоло­
гии, которая используется в проекте. Наличие глоссария по­
зволяет команде проекта и заказчику разговаривать на одном
языке, быть однозначно и правильно понятыми. Также наличие
глоссария позволяет новым участникам проекта быстро войти
в него и не испытывать затруднений.
В глоссарии обычно фиксируют:
— названия основных бизнес-процессов и их краткое описа­
ние. Это в первую очередь полезно разработчикам, так как они
начинают понимать, что и как происходит у заказчика;
— названия сущностей предметной области;
— названия и значения ключевых характеристик сущностей
предметной области. Например, для системы кадрового учета
такой характеристикой может быть «заработная плата сотруд­
ника», с описанием, из чего она состоит и как формируется;
— термины предметной области, которым не соответствуют
какие-либо сущности в системе, но которые важны для пони­
мания предметной области;
— синонимы. Важно отразить, что для обозначения одного
и того же понятия могут использоваться разные названия;
— роли пользователей.
Чтобы добавить термин в глоссарий, в Visual paradigm
нужно в окне текстуального анализа выделить нужное слово
и через контекстное меню выполнить действие Add «термин»
as Glossary Term... (рис. 1.10).
Обратите внимание на то, что в Model Explorer автоматиче­
ски сформировался пакет Glossary, в котором будут храниться
все создаваемые термины (рис. 1.11).
В дальнейшем просмотреть содержимое глоссария можно
через Model Explorer — Glossary — Glossary Grid.

29

https://urait.ru


«явят

Сеть кофейня ен ' Астроксфе' мотивирует кофеман ов проп- Add ІМ »
Программа поддерживается при помощи карта лояльности । C»S8
СаЙТ Пр

При зав
рожден и
Пользоб

функция
Участии
(два раз
потерян
операци
вознагр

Ф Add біо.міу Tiim

X

СОЗ ?

св •

Efttf tie dtlMM Of‘n^rpauvâ МАГквйСПҐ

В’ =’ =’ F’ Я- И Я +• а - л

>ОК< "

коипеис мфкетингаоык мероприятий для ромит ля гюетормьа продаж
суц&оврюии-л іллеитзгл ■ Ош.цвц продажи w.i дополнит епм*иа товаров и
гспн продвкнмѵя морсодетиішс клей л ценностей другмі епаос
ПОТекМбЛвНО прибыльного ПОЄЄДЄМНй|

XT

ACfc<
Use Cast

Requirement

Adon

>

More
Candids* Item

:во

Quick Add прогриз юяленсаи* as ЗДздіг/ Tern

тчхгрзи.й лояльної де Glossary Term

ТЬ 1

acc

1 ОС

Ade Ирссраідо лояльмоелґ з» Glossary Term end Trx^t to How Mow ЄЮтМ

Add Ирссраімі лояпмюспґ ав Glossary Ter пі in Mods
Add ттсграіги лояпм*хпГ a: Glossary Term in Model and Tronic io Hew Model Bement

ли»—
—

toteClw

ѵіыя

ВМ

раадение вози
Кліи

ок

ТОВ*

С»лгж

ACC Model Eiemex
acc property

value

acc Diagram

>

acc variable

n зеі1Н»ре< ink

цраг

Open URL

•л^н

Cut

Coo»

Рис 1.10. Добавление термина в глоссарий проекта
(у Model Ex? or er

^ Diagram Nau gator

Model Ex? orer

o’ 9 X

^ Астрокафе

®PjCanddate items
© ^Glossary

I"*) Glossary G nd

логин
© *~| Исходные требования

©

Модель использования
Модель состояний

©

Модель структуры

Рис 1.11. Пакет Glossary

Чтобы ввести синонимы термина, нужно в Glossary Grid еделать двойной щелчок мышью по этому термину и в открывшем­
ся окне рядом с полем Aliases нажать на кнопку Add (рис. 1.12).
Участник программы -> Term Editor - Участник программы
Definition

Stereotypes

Tagged Values

Definition:

В’ =
Посетитель.сети кофеен "Астрокофе'. потенциальный££стикп|>ог2аммылояльности

Синонимы: Кофеман, Клиент'. Посетитель'. Пользователь*

Рис 1.12. Редактор термина глоссария. Добавление синонимов
Глоссарий может пополняться на протяжении всего проекта
(в вашем случае — по ходу выполнения любой из лабораторных
работ).

30

https://urait.ru


На основе описания задачи был составлен глоссарий пред­
метной области.
Таблица 1.4
Глоссарий проекта
Название

Синонимы

Описание

Логин

—

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

Возна­
гражде­
ние

—

Подарки, которые можно покупать
за фишки, в рамках программы лояль­
ности

Карта ло­
яльности

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

Учётная
запись

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

Менеджер

—

Пользователь системы, который осущест­
вляет различные операции в ней

Фишка

—

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

Участник
програм­
мы

e-mail

Програм­
ма лояль­
ности

Кофеман,
Клиент,
Посетитель,
Пользователь

—

Посетитель сети кофеен «Астрокофе»,
который зарегистрирован в программе
лояльности

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

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

31

https://urait.ru


Окончание табл. 1.4
Название

Синонимы

Описание

Код CW2

—

(англ, card verification value 2) — трехзнач­
ный код проверки подлинности карты
платежной системы Visa

Бан­
ковская
система

—

Внешняя система, которая совершает
транзакцию в пользу «Астрокофе», если
это возможно

Система
учета про­
даж

—

Внешняя система, которая сообщает
системе программы лояльности информа­
цию о продаже

1.6. Начальная модель классов
Всю подготовительную работу мы уже выполнили. Мы зна­
ем, какие у нас есть классы, и какие между ними имеются ас­
социации. Осталось только отобразить все это в виде модели.
В Diagram Navigator найдите пункт Class Diagram и через
контекстное меню создайте новый файл с диаграммой классов
(рис. 1.15).
e Dia..

@ Mo..

a' Dia..

^ Cla..

Diagram Kaugator

p Log..
О’

^ ORM
Р

X

^Астрокафе (trunk)

S £jUML Degrams
!
7:

Use Case Diagram

& Mew Class Diagram

|Cla99 Diagram (t)|

Diagram.

-І Объекты предметной обпасти Class Degram

І

kfc Sequence Diagram

І

■ Communication Diagram
Ьй State Machine Diagram

^

Export Visual Paradigm Project ..

jj

Expert XML..

^J

Export as Image...

ià

print..

U

Sort Class Diagram by name

^

Collapse

^

Expand

□

Visual History...

: Activity Diagram

Component Diagram

і

Deployment Diagram
h»Package Diagram
Object Diagram

Composite Structure Diagram
Timing Diagram

к interaction Overview Diagram

Рис 1.15. Создание новой диаграммы классов

Разместите созданную диаграмму в Model Explorer в паке­
те «Объекты предметной области». Для этого выделите этот
пакет и в контекстном меню выберите пункт Sub Diagrams /
Existing Diagrams. В открывшемся окне выберите ранее соз­
данную диаграмму классов.
Далее в Model Explorer в пункте Candidate Items найдите
все классы-кандидаты, выявленные ранее (т. е. не все, а толь-

32

https://urait.ru


ко те, которые мы не зачеркнули), и перетащите их в рабочую
зону.
в

Г

.у®

й

а

а Модель предметной области
1^1 Список классов-кандидатов

Model Explorer

9

X

Модель предметной области -> Модель предметной области

►

« s A|

<default package > |^

^Астрокафе [trunk]

3 [^Candidate Items
І- ЫБанковская карта

И Вознагражденіе

ОКарта
I

^ Magnet

/ Gesture Pen

І- ЭКлиент

Class__________

j- ѲКофейія
І-ЕЗКофеман

і
І

>••• (^начисляется
і- ВОперасия

?•■■ В операция

}

Вознаграждение

I Class
4— Generalcatton

Участник программы

її? Usage
Правило

EJ Покупка
І-СВПользователь

iation

N-aiy Association

ВПополнение

5- ВПосетитель
ВПравило
і

ВСеть кофейня
І-ВТовар

В Участник программы

В Учетная запись
ВФишка

_

Association Class

> Dependency

Операция
Карта

"?£ Abstraction

* Colaboration
^ Model

5 REST Service

В Note

Рис 1.16. Перенос классов-кандидатов на диаграмму классов
Обратите внимание, что некоторые названия классов выделя­
ются синим цветом. Это ссылки на термины, которые мы добавили
в глоссарий. Перейти к описанию термина можно, нажав Ctrl + щел­
чок по ссылке.
По умолчанию Visual Paradigm раскрашивает элементы модели.
Но это не всегда удобно. Часто требуется, чтобы элементы модели
были черно-белыми. Так они лучше «читаются», например, в распе­
чатанных отчетах или при просмотре презентации с моделью через
проектор.
Чтобы привести модель в черно-белое состояние, нужно выде­
лить все элементы модели и в контекстном меню выбрать пункт
Styles and Formatting — Transparent.
Далее все модели приводятся в черно-белом варианте.

Чтобы добавить связь (ассоциацию) между классами нужно:
— выделить исходный класс;
— нажать на появившеюся в правом верхнем углу иконку
Resource Catalog и, не отпуская кнопку мыши, протянуть связь
на второй класс;

33

https://urait.ru


— в результате откроется окно, в котором нужно выбрать
тип связи Association и добавить ее название:

Рекомендации по формированию диаграммы классов:
1. В центре модели размещайте ключевые, наиболее часто
используемые классы. На периферии размещайте второстепен­
ные классы.
2. Чтобы сделать излом в линии связи, нужно потянуть
за линию в том месте, в котором вы хотите сделать излом.
3. Старайтесь размещать классы таким образом, чтобы ли­
нии ассоциаций не пересекались и имели наименьшее количе­
ство изломов. Это улучшит читаемость модели.
4. Связям нужно давать такие названия, чтобы в итоге
можно было составить осмысленные предложения, например:
«Участник программы имеет карту(ы) лояльности», «Правило
применяется к вознаграждению (ям)» и т. п.
Теперь остается только расставить кратности связей. Крат­
ность также определяется исходя из того, что сказано в описа­
нии предметной области, и логических рассуждений.
В центре модели у нас находится класс «Участник програм­
мы», поэтому все связи, которые идут от этого класса, будут
иметь кратность 1.
Чтобы ввести размер кратности, нужно выделить линию
связи и в контекстном меню выбрать пункт Open Specification
(рис. 1.17) или нажать Enter на клавиатуре.
Участии. программы
Open Specification..
Stereotypes

Enter
>

Role А (Участникпрограммы)
Role В (Карта)

Рис. 1.17. Контекстное меню ассоциации

В появившемся окне нужно у класса «Участник про­
граммы» (Association End From) указать значение в поле
Multiplicity = 1 (рис. 1.18).

34

https://urait.ru


Рис. 1.18. Редактор спецификации ассоциации

Какой размер кратности нужно установить в данном приме­
ре на втором конце связи у класса «Карта»? Для ответа на этот
вопрос нужно вспомнить предметную область и, исходя из ло­
гических рассуждений, построить следующее предложение:
«Каждый из участников программы может иметь одну или
много карт лояльности». Значит в поле Multiplicity нужно вы­
брать значение 1..*.
Аналогичным образом определяем кратности и для всех
остальных связей:
Каждый из участников программы может получить ноль,
одно или много вознаграждений — связь 1 — 0..*;
По каждой карте лояльности может быть проведено ноль,
одна или много операций — связь 1 — 0..*;
По одному и тому же правилу можно получить ноль, одно
или много вознаграждений — связь 1 — 0..*;
Один и тот же вид вознаграждения может быть начислен
по одному и более правилу.
Чтобы модель не была перегружена дополнительными индика­
торами, можно в контекстном меню в пункте Presentation Options
снять флаг Always Show Model Indicators.

35

https://urait.ru


01

Show Constraints

Paste Model Element

Always Show Model Element Indicators

-

Paste View

Connector Caption Placement

>

Handi-seiection

Caption Placement

>

Diagram Content

Shape Presentation Option

>

Connectors

Highlight Glossary Terms

Presentation Options
^i

Layers...

Reference Mapping

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

Рис. 1.19. Диаграмма классов предметной области

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

Чтобы проверить верно ли определена структура связей
и расставлены кратности на концах каждой ассоциации, мож­
но использовать диаграммы объектов.

36

https://urait.ru


Диаграмма объектов (Object Diagram) — отдельный экзем­
пляр диаграммы классов; снимок возможного состояния си­
стемы на определенный момент времени, в котором отражены
не сами классы, а их объекты.

В Diagram Navigator найдите пункт Object Diagram и через
контекстное меню выполните New Object Diagram.
Разместите созданную диаграмму в Model Explorer в паке­
те «Объекты диаграммы объектов». Для этого выделите этот
пакет и в контекстном меню выберите пункт Sub Diagrams /
Existing Diagrams. В открывшемся окне выберите ранее соз­
данную диаграмму объектов.
Альтернативный способ: в Model Explorer выделите пакет
«Объекты диаграммы объектов» и в контекстном меню вы­
берите пункт Sub Diagrams / New Diagram. В открывшемся ок­
не выберите из списка Object Diagram, нажмите кнопку Next,
задайте имя для диаграммы или оставьте по умолчанию и на­
жмите кнопку ОК, завершая создание новой диаграммы.
В Model Explorer найдите ранее созданную диаграмму
классов, которая должна быть размещена в пакете «Объекты
предметной области». Здесь вы увидите все ранее созданные
классы. В рабочую зону последовательно перетащите те клас­
сы, которые вы хотите отразить на диаграмме объектов. После
перетаскивания класса в рабочую зону появится всплывающее
окно, в котором нужно выбрать пункт Instance Specification,
который означает, что вы добавляете отдельный экземпляр
данного класса. Таким образом, если вам необходимо отобра­
зить три объекта данного класса, такую процедуру нужно по­
вторить три раза.
М Слисок классов-кандидат
В Карта

▲

^ДМоделэ использования

Ф Йрарианть использования

^joob

:

♦ Point Eraser

Ф- Й| Действующие лида
[^Модель СОСТОЯНІЙ

^Модель структуры
ф- [^Carddate Items

'- Sweeper
O Magnet

/ Gestae Pen

В ИМсдело предметной обла

і ^ Модель предметной о
В (^Объекты диаграт об
В ЙИОбъекть предметной

object________ :
13 Instance Specfaatiil

— link

Shapa ^pe tocKns kx Ctoit

[- ‘Объектъ предмет

I Вознагражденіе

| Class
^ Pat

I Операція
І Правило
В Участие програм

( Операція

(■

Instance Specification

■

Class

— Association
—> Dependency

<— Generalization

■ грввилэ

Рис. 1.20. Создание диаграммы объектов

37

https://urait.ru


В данном случае объект отличается от класса тем, что
он конкретен, т. е. принимает конкретные значения. Так как
мы еще не определили атрибуты классов, то для каждого объ­
екта следует задать конкретное имя, отражающее ту ситуацию
реального мира, которую мы хотим смоделировать.
Далее следует соединить между собой объекты тех клас­
сов, между которыми на диаграмме классов имеется ассоциа­
ция. При этом объекты соединяются не ассоциацией, а связью
(англ, link) (рис. 1.21). Так же, как и объект является экзем­
пляром класса, так и связь между объектами представляет со­
бой экземпляр ассоциации. Естественно, на связи между объ­
ектами не может быть никакой кратности. Каждая конкретная
связь может соединять между собой только два конкретных
объекта. Сколько раз объект одного типа (класса) связыва­
ется с объектами другого типа (класса), определяется крат­
ностью ассоциации. Именно для того чтобы проверить, пра­
вильно ли мы определили кратности на диаграмме классов,
мы и строим диаграммы объектов.

Рис. 1.21. Редактор связей

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

38

https://urait.ru


— диаграмма объектов — это мгновенный снимок диаграм­
мы классов, которая иллюстрирует тот или иной аспект;
— диаграмма объектов помогает проверить корректность
диаграммы классов.
Рассмотрим несколько примеров диаграммы объектов.
«Операции по карте лояльности». Из диаграммы классов
следует, что у каждого участника программы может быть не­
сколько карт лояльности, а по каждой карте лояльности мо­
гут выполняться много операций пополнения и покупки.
На рис. 1.22 представлена диаграмма объектов, отражающая
эту ситуацию. Одному объекту «Иванов Сергей Петрович» при­
надлежат две карты «№ 14125» и «№ 45678». По каждой карте
может выполняться одна или более операций.

Рис. 1.22. Диаграмма объектов «Операции по карте лояльности»

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

39

https://urait.ru


Иванов Иоан Иванович:
У.ча.£т.мик-протам м ы

имеет

№998 : Карта

Рис 1.23. Диаграмма объектов «Карты лояльности участников программы»

Рис 1.24. Диаграмма объектов «Полученные вознаграждения
участника программы»

Чек-лист
□ В Visual Paradigm описаны задачи проекта и назначение
системы.
□ Названием каждого класса-кандидата является существи­
тельное в единственном числе именительного падежа.
□ Для каждого класса-кандидата дано определение.
□ Названием каждой ассоциации-кандидата является гла­
гол или отглагольная фраза.
□ В диаграмме классов нет ни одного класса, кото­
рый бы не был связан хотя бы с одним другим классом.
□ Все связи имеют название.
□ У всех связей расставлены кратности.
□ Составлены диаграммы объектов.
□ Составлен глоссарий проекта.

40

https://urait.ru


Вопросы для самоконтроля
1. Чем отличается класс-кандидат от класса?
2. Чем отличается ассоциация-кандидат от ассоциации?
3. Чем отличается объект от класса?
4. В чем разница между ассоциацией классов и связью объектов?
5. Нужно ли в диаграмме объектов указывать кратности связей?
6. Может ли быть классом «Отчет о прибылях и убытках»? Почему?
7. Для чего необходим глоссарий проекта?
8. Как сделать модель черно-белой?
9. Как скрыть в модели индикаторы?

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 2.
РАЗРАБОТКА МОДЕЛИ ВАРИАНТОВ
ИСПОЛЬЗОВАНИЯ
Что нужно сделать в рамках данной лабораторной работы:
1) провести текстуальный анализ задачи;
2) определить список действующих лиц;
3) определить список задач, решаемых действующими лицами;
4) сформулировать наименование вариантов использования;
5) дать краткое описание вариантов использования;
6) создать диаграмму вариантов использования.

2.1. Введение

Следующим важным шагом на пути построения системы яв­
ляется этап выявления и формирования требований. Требова­
ния делятся на функциональные и нефункциональные. Требова­
ния позволяют понять, что за систему мы собираемся создать.
Первым этапом на этой стадии является определение функ­
циональных требований, а также границ системы. Одним
из методов определения функциональных требований является
построение модели вариантов использования.
Прежде чем приступать к практической работе, советуем
внимательно ознакомиться с материалами соответствующей
лекции и главы 4 книги Арлоу Д., Нейштадт И. «иМЬ 2 и Уни­
фицированный процесс» [7].
Модель вариантов использования (use case model) представ­
ляет собой модель того, как различные типы пользователей вза­
имодействуют с системой для решения своих проблем или задач.

Модель вариантов использования описывает цели пользовате­
лей, взаимодействие между пользователями и системой и тре­
буемое поведение системы для удовлетворения этих целей.

42

https://urait.ru


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

Для построения модели вариантов использования необходимо:
— выявить действующие лица — персоны, организации или
иные системы, использующие нашу систему или используемые
нашей системой для получения какого-либо важного результата;
— определить варианты использования системы, т. е. вы­
явить задачи, которые действующие лица решают, используя
систему.
2.2. Текстуальный анализ

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

43

https://urait.ru


В Visual Paradigm через Diagram Navigator откройте ранее
созданную модель Textual Analysis и, следуя указанным выше
рекомендациям, составьте список кандидатов в акторы и вари­
анты использования.
Для добавления действующего лица нужно выделить под­
ходящее слово и через контекстное меню выполнить действие
Add text as Actor.
ПО nnnrnQMMQ ПГ
Add text as

і карта л< ■ Class
э кофейн_!_*<*"

Аналогично для добавления варианта использования нуж­
но выделить подходящее слово (словосочетание) и через кон­
текстное меню выполнить действие Add text as Use Case.
4и
Add text as

зет свой email (; $ Actor
строкофе ”, выд.і_ Class
едоставляется • Use Case

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

Ніт>ч ІДВ&ЛДМЕІ • ТмЪЛ МЯг и * «эдем

□

12

*=^па

в- ^- =■ F

3- Ь» £ +■ п

ТІ

am

twwpjwws

W

T

После печати листовки количество накопленных " фишка ек‘ уменьшается соответственно выбранному вознаграждение ю.
Использованные листовки учитываются в базе данных о продажах ( покупка I
Сведения о них передаются на сайт, который помечает вознаграждение как использованное Вознаграждение 'бесплатный
напиток* начисляется клиенту ежегодно в его день рождения Вознаграждение 'бесплатная пачка кофе' начисляется
клиенту после каждого пополнение я его карта ы лояльности на сумму, превышающую 1999 рублей.

или 8 зависимости от дат осуществляется менеджер ом сайта
Менеджер сайта поддерживает сайт в актуальном состоянии
Эн может
и
новые
й. обмениваемых на ' фишка и*, а также
и о напитках, зерновом кофе и аксессуарах, предлагаемых в кофейня х Эти статья и доступны
публиковать на сайт
льо
тигель ю сайта программы лояльности.
Неактуальные статья и менеджер может править или удалять с сайта.
При выявлении нарушений менеджер может [носить изменения в данные любой
ІЛ

ГгостмТ»-

Г.егаМЭІвГ.МД

1

ГЛ\Ѵ*.>мН»^ МПМ .

•
J

ПмсфМА

Аглатжш 1

•им Сем

Пр». маллмяучАЧМЫ ѵ

Плбшт. шмую <дрту

ЮвММНЪСРПИ мЛМХ) «pw u

•UwCCM

попиШМ* Лі. мчагт ллАг

1

Шлмроміъ ютрм>іую орту

0ОМф0МЖ CW* ПОѴфЫМ «ртэ

•Uw Сем

R Ге попдеѵипвлі. “ПТГр

1

ПАГКѴШТкЗДіЖ КфЫ

ВДМЯТЪваЛЭмС сеж OFB

•имеем

Попдеигклъ ыгсегт МИК

1

хущктвявмі «окупи

•имеем

Попдеегель аущестдо

1

прамітрютъ ывррціи

•им Сем

lAfW^n-P^**^^ ЛОМ

1

•имеем

Заремс*ром»^й пол*

1

•имеем

Зарыти* рфхььмий -юл*

1

ГТ Осуияств^ть WfHiy
пра потретъ операм па црк

г

і рамотреn>wyw«o<^o в«шс*

•

трѵ потрем гпм<>*мнл'р*«л4мнй граіытримп. пміггекдсм*

1 11

Tin*

ГЛѴѴГкуМіМ шмеь

ледіиъ * МЙКОАПевемМ • РОМІА* ЛрОГрвММЫ

’апиотго литовку

рос ги*атымтъ мс томі

•имеем

ЗАрИИСТГироа*^- W

1

3»«^і новые тома

эеммние «ОМ Прмил

•имеем

меищнер момат >жс ти

•

Ml

Рис. 2.1. Фрагмент текстуального анализа

Последовательно читаем каждое предложение, анализиру­
ем и выделяем слова или словосочетания, которые указывают
44

https://urait.ru


на действующие лица и возможные задачи, которые они вы­
полняют, используя сайт программы лояльности.
«Сайт программы позволяет посетителю кофейни создать
учетную запись»:
— действующее лицо — «посетитель кофейни»;
— задача / действие — «создать учетную запись», чтобы
стать пользователем сайта и участником программы лояльно­
сти.
«Пользователю, создавшему учетную запись, предоставля­
ется возможность “входить” в меню сайта»:
— действующее лицо — «пользователь»;
— задача / действие — «войти в меню сайта». Стоит за­
метить, что посетитель кофейни, создав учетную запись, ста­
новится пользователем и приобретает возможность входить
в меню сайта.
«Участник программы (новое действующее лицо, являю­
щееся пользователем сайта) может (выполнять задачи / дей­
ствия, позволяющие добиться определенной цели, получить
важный результат):
— редактировать сведения в своей учетной записи,
— добавлять свои новые карты лояльности,
— блокировать свои потерянные карты,
— пополнять баланс своих карт для осуществления покупок,
— просматривать операции (пополнения, покупки) по карте,
— следить за накопленными в рамках программы «фишками»,
— просматривать вознаграждения,
— распечатывать листовки с вознаграждениями для ис­
пользования их в кофейне.
«Пополнение карты лояльности производится за счет
средств с банковской карты... Сайт программы лояльности
связывается с банковской системой и запрашивает, мож­
но ли получитъ средства»:
— действующее лицо — «банковская система»;
— задача / действие — «предоставить средства для по­
полнения карты лояльности». Здесь следует заметить, что бан­
ковская система выступает как вспомогательное действующее
лицо, помогающее другому действующему лицу, «участнику
программу», пополнить баланс карты лояльности.
«Клиент, приобретая напитки, зерновой или молотый кофе,
аксессуары и др., может сделать это за счет средств на карте
лояльности. Данные об этом (номер карты, дата и время, сум-

45

https://urait.ru


ма покупки, купленный напиток или товар) фиксируются в ба­
зе данных о продажах и передаются на сайт программы лояль­
ности. Данные о покупках, совершенных без карты лояльности,
в программе не учитываются.»
Здесь на первый взгляд кажется, что действующим лицом
является «клиент», а задача, которую он выполняет — это «со­
вершение покупки». Однако если внимательно прочитать этот
абзац и весь текст задания, то становится ясно, что покупки
на сайте программы лояльности не осуществляются. Более то­
го в тексте явно указывается, что покупки фиксируются в базе
данных о продаже, и сведения о покупках, совершаемых за счет
средств карты лояльности, передаются на сайт программы ло­
яльности. Таким образом:
— действующее лицо — «система учета продаж»;
— задача / действие — «передать сведения о покупках
за счет средств на карте лояльности».
«Использованные листовки учитываются в базе данных
о продажах. Сведения о них передаются на сайт, который по­
мечает вознаграждение как использованное»:
— действующее лицо — «система учета продаж»;
— задача / действие — «передать сведения об использо­
ванных листовках».
«Вознаграждение “бесплатный напиток” начисляется кли­
енту ежегодно в его день рождения.»
— действующее лицо — «время»;
— задача / действие — «начислить вознаграждение по да­
те рождения».
«Изменение старых правил и заведение новых правил начис­
ления фишек/вознаграждений за покупки, пополнения или в за­
висимости от дат осуществляется менеджером сайта»:
— действующее лицо — «менеджер»;
— задача / действие — «изменить старые правила»;
— задача / действие — «завести новые правила».
«Менеджер может редактировать сведения и добавлять но­
вые виды вознаграждений, обмениваемых на “фишки”, а также
публиковать на сайт статьи о напитках, зерновом кофе и ак­
сессуарах, предлагаемых в кофейнях. Неактуальные статьи ме­
неджер может править или удалять с сайта»:
— действующее лицо — «менеджер»;
— задача / действие — «редактировать сведения возна­
граждений»;

46

https://urait.ru


— задача / действие — «добавлять новые виды вознаграж­
дений»;
— задача / действие — «публиковать на сайте статьи»;
— задача / действие — «править статьи»;
— задача / действие — «удалять статьи с сайта».
«Эти статьи доступны любому посетителю сайта про­
граммы лояльности»:
— действующее лицо — «посетитель»;
— задача / действие — «просматривать статьи сайта»;
«При выявлении нарушений менеджер может вноситъ изме­
нения в данные любой учетной записи, или блокировать учет­
ную запись пользователя-нарушителя.»
— действующее лицо — «менеджер»;
— задача / действие — «вносить изменения в данные лю­
бой учетной записи»;
— задача / действие — «блокировать учетную запись поль­
зователя-нарушителя».
2.3. Список действующих лиц и их задач

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

47

https://urait.ru


— наименование варианта использования должно быть кратким,
но емким и понятным (обычно не более 5 слов). Если сразу этому
правилу следовать сложно, начните с более длинной фразы и поста­
райтесь ее потом сократить.

Таблица 2.1
Список действующих лиц и вариантов использования
Действую­
щее лицо

Описание

Задачи

Посети­
тель

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

Создать учетную запись.
Просмотреть статьи сайта

Участник
програм­
мы

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

Войти в системуПЬ ^І.
Изменить сведения в учетной
записи.
Добавить новую карту.
Заблокировать карту.
Пополнить баланс карты.
Просмотреть операции по карте.
Просмотреть количество фишек.
Просмотреть список вознаграж­
дений.
Распечатать листовку

Бан­
ковская
система

Внешняя система,
которая участвует в ва­
рианте использования

Пополнить баланс карты

Система
учета про­
даж

Внешняя система, ко­
торая передает инфор­
мацию о совершаемой
покупке

Передать сведения о покупках
по карте лояльности.
Передать сведения об использо­
ванных вознаграждениях.
Проверить карту лояльности^3!.
Проверить вознаграждение И! •

Менеджер

Пользователь, который
осуществляет админи­
стрирование системы

Завести новое правило.
Изменить имеющееся правило.
Добавить новый вид вознаграж­
дения.
Изменить сведения о возна­
граждении.
Опубликовать статью.
Изменить статью.

48

https://urait.ru


Окончание табл. 2.1
Действую­
щее лицо

Описание

Задачи

Удалить статью.
Внести изменения в учетную
запись пользователя.
Заблокировать учетную запись
нарушителя
Время

Особое действующее
лицо, отвечающее
за инициирование
действий, связанных
с условием времени

Начислить вознаграждение
по дате рождения (определен­
ной дате)

Примечания.
[Ч Подумайте, если можно «Войти в систему», то, наверное, должен
существовать и вариант использования «Выйти из системы».
12І Обратите внимание: эту задачу мы отнесли к участнику програм­
мы, но можно было бы отдельно рассмотреть действующее лицо «Пользо­
ватель» и назначить ему этот вариант использования.
131 Когда покупка осуществляется за счет средств карты локальности,
важно проверить, достаточно ли на карте средств, не заблокирована
ли она. Об этом явно не говорится в описании.
ВИ Как можно проверить, что листовка с вознаграждением еще не ис­
пользовалась? Что вознаграждение действительно было начислено?

2.4. Краткое описание вариантов использования
Это должен быть один абзац, в котором изложена цель вари­
анта использования. Попытайтесь уловить его суть — приклад­
ное значение, которое он имеет для действующих лиц.
1. Создать учетную запись — сайт программы позволяет
посетителю кофейни создать учетную запись. При заведении
учетной записи посетитель сообщает свой e-mail (далее исполь­
зуемый как логин), пароль, ФИО, дату рождения, номер одной
или более карт лояльности «Астрокофе», выданных ему ранее
в кофейнях.
2. Просмотреть статьи сайта — любой посетитель сайта
программы лояльности может просматривать статьи сайта.
3. Войти в систему — пользователь (участник программы),
который имеет учетную запись, получает возможность «вхо-

49

https://urait.ru


дить» в меню сайта, т. е. иметь доступ к функциям участника
программы лояльности.
4. Изменить сведения в учетной записи — участник про­
граммы может отредактировать сведения о себе в своей учет­
ной записи.
5. Добавить новую карту — участник программы может
добавить несколько карт к своему аккаунту.
6. Заблокировать карту — участник программы может за­
блокировать свою карту, если потерял ее.
7. Пополнить баланс карты — пользователь может попол­
нить баланс своей карты с помощью банковского перевода.
Пополнение карты лояльности производится за счет средств
с банковской карты. Карта лояльности должна быть зарегистри­
рована как принадлежащая участнику программы и не заблоки­
рована. Баланс средств на ней может быть нулевым или положи­
тельным. Для пополнения пользователь указывает номер своей
банковской карты и код CW2, а также сумму пополнения. Сайт
программы лояльности связывается с банковской системой и за­
прашивает, можно ли получить средства в пользу «Астрокофе».
Если все указано верно, с банковской карты указанная сумма
переводится на счет «Астрокофе», а баланс указанной карты ло­
яльности пополняется на ту же сумму. В противном случае сайт
сообщает, что пополнение не может быть осуществлено, и ука­
зывает причину этого. Вознаграждение «бесплатная пачка ко­
фе» начисляется клиенту после каждого пополнения его карты
лояльности на сумму, превышающую 1999 рублей.
8. Просмотреть операции по карте — участник програм­
мы лояльности может просмотреть список выполненных им ра­
нее операций покупки и пополнения баланса.
9. Просмотреть количество фишек — участник программы
лояльности может узнать свой баланс по накопленным фишкам.
10. Просмотреть список вознаграждений — участник про­
граммы лояльности может просмотреть список доступных ему
вознаграждений.
11. Распечатать листовку — участник программы лояльно­
сти может распечатать листовку, чтобы получить вознагражде­
ние. После печати листовки количество накопленных «фишек»
уменьшается соответственно выбранному вознаграждению.
12. Передать сведения о покупках по карте лояльно­
сти — накопление «фишек» происходит после покупок в ко­
фейне. Клиент, приобретая напитки, зерновой или молотый ко-

50

https://urait.ru


фе, аксессуары и др., может сделать это за счет средств на карте
лояльности. Данные об этом (номер карты, дата и время, сумма
покупки, купленный напиток или товар) фиксируются в базе
данных о продажах и передаются на сайт программы лояльно­
сти. Данные о покупках, совершенных без карты лояльности,
в программе не учитываются. За каждую покупку начисляется
одна «фишка». Если покупка крупная (на сумму более 1500 ру­
блей), то начисляется дополнительная «фишка».
13. Передать сведения об использованных вознагражде­
ниях — использованные листовки учитываются в базе данных
о продажах. Сведения о них передаются на сайт, который по­
мечает вознаграждение как использованное.
14. Проверить карту лояльности — система учета продаж
перед оплатой покупки за счет средств по карте лояльности
должна убедиться, что карта не заблокирована и на ее балансе
достаточно средств или фишек.
15. Проверить вознаграждение — система учета продаж
при погашении предъявленного вознаграждения должна убе­
диться, что вознаграждение еще не использовано и действи­
тельно начислено клиенту.
16. Завести новое правило — менеджер может завести но­
вые правила получения вознаграждений.
17. Изменить имеющееся правило — менеджер может из­
менить имеющиеся правила получения вознаграждений.
18. Добавить новый вид вознаграждения — менеджер мо­
жет добавить новые виды вознаграждений.
19. Изменить сведения о вознаграждении — менеджер
может изменить существующие условия получения вознаграж­
дений.
20. Опубликовать статью — менеджер может опублико­
вать статью на сайте.
21. Изменить статью — менеджер может отредактировать
существующую статью на сайте.
22. Удалить статью — менеджер может удалить существу­
ющую статью на сайте.
23. Внести изменения в учетную запись — при выявлении
нарушений менеджер может внести изменения в данные лю­
бой учетной записи пользователя-нарушителя.
24. Заблокировать учетную запись — при выявлении на­
рушений менеджер может удалить любую учетную запись
пользователя-нарушителя.

51

https://urait.ru


25. Начислить вознаграждение по дате рождения — воз­
награждение «бесплатный напиток» начисляется клиенту еже­
годно в его день рождения.
2.5. Диаграмма вариантов использования

Теперь нужно всю накопленную информацию отобразить
в графическом виде на диаграмме использования.
В Model Explorer найдите пакет «Варианты использова­
ния», в контекстном меню выберите пункт Sub Diagrams / New
Diagrams и в открывшемся окне выберите Use Case Diagram.
В результате будет создан новый документ с диаграммой вари­
антов использования. Также сюда перенесите выявленные ва­
рианты использования из пакета Candidate Items.
Аналогичным образом в пакет «Действующие лица» пере­
несите акторов из пакета Candidate Items.
Для построения модели вариантов использования:
— нарисуйте границы системы (используйте элемент □ sy.t™
на панели инструментов);
— вне границ разместите действующих лиц (перетащите
их в модель из пакета Candidate Items);
— внутри границ системы разместите варианты использо­
вания (перетащите их в модель из пакета Candidate Items).
В результате у вас получится примерно следующая диаграм­
ма (рис. 2.2).
Сайт программа лояльности сети "Астрокофе"
Інести изменения в

Войти в

зменить сведения в

учетную запись _

систему

„учетной записи

Менеджер

Посетитель
Ірбавить новыйвид'

•публиковать'

(осмотреть операциі

^вознаграждения^.

.статью__

^

по карте

X

Участник программы

Время

Банковская система

Система учета продаж

Рис 2.2. Действующие лица и варианты использования

52

https://urait.ru


Теперь требуется соединить действующих лиц с соответству­
ющими им вариантами использования, чтобы получить окон­
чательную диаграмму использования (рис. 2.3).
Между действующими лицами и вариантами использования
может быть единственный вид связи «коммуникация», пред­
ставляющий собой канал взаимодействия действующего лица
и проектируемой системы.
Помимо этого, между действующими лицами может суще­
ствовать отношение «обобщения». На рис. 2.3 это отношение
представлено между Участником программы и Посетителем.
Это отношение означает, что участник программы также явля­
ется и посетителем и, таким образом, наследует варианты ис­
пользования посетителя, позволяя сгруппировать и сфокусиро­
вать поведенческие паттерны вокруг действующего лица. При
этом диаграмма становится более понятной и наглядной.

Рис. 23. Диаграмма вариантов использования

53

https://urait.ru


Чек-лист
□ Составлен список действующих лиц.
□ Составлен список вариантов использования.
□ Название каждого варианта использования является гла­
гольной фразой.
□ В модели используется одинаковый стиль именования ва­
риантов использования.
□ Названия вариантов использования уникальны в рамках
модели.
□ Наименование каждого варианта использования отра­
жает цель, с которой пользователь использует проектируемую
систему.
□ Для каждого варианта использования дано краткое опи­
сание.
□ Составлена диаграмма вариантов использования.
Вопросы для самоконтроля
1. Что такое вариант использования?
2. Из каких сущностей состоит диаграмма вариантов использова­
ния?
3. Может ли в диаграмме вариантов использования актор находиться
внутри границ системы? Почему?
4. Может ли в диаграмме вариантов использования вариант ис­
пользования находиться вне границ системы? Почему?
5. Сколько действующих лиц и вариантов использования может
находиться на диаграмме вариантов использования?
6. Может ли один и тот же актор быть соединен с несколькими
вариантами использования?

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 3.
УТОЧНЕНИЕ КОНЦЕПТУАЛЬНОЙ
МОДЕЛИ КЛАССОВ
Что нужно сделать в рамках данной лабораторной работы:
1) уточнить модель классов;
2) проверить полученную модель через ОСЬ-запросы.

3.1. Введение

Особенностью объектно-ориентированного подхода в раз­
работке ПО является то, что любая используемая в ходе испол­
нения программы информация должна быть представлена тем
или иным объектом. Ранее, в предыдущей лабораторной рабо­
те, мы сосредоточились на выявлении концептуальных сущно­
стей, составляющих основные понятия предметной области,
и отношений между ними, формирующих общую структуру
информационной модели. Теперь необходимо детализировать
модель, добавив необходимые характеристики, т. е. атрибуты
для каждой сущности.
Атрибуты — это свойства объектов, такие как вес, скорость
или цвет. Атрибуты присутствуют в описании в виде существи­
тельных притяжательных оборотов (отвечают на вопрос «чей»),
например, цвет машины. Прилагательные часто соответствуют
конкретным значениям атрибутов-перечислений. Если в опи­
сании присутствуют атрибуты-перечисления, то следует ис­
пользовать UML элемент со стереотипом «перечисление», или
«enumeration».
В процессе анализа может возникнуть потребность обобще­
ния каких-либо свойств класса или наоборот уточнения, специ­
ализации. В этом случае необходимо использовать отношение
обобщения, или generalization. Например, классы Преподава-

55

https://urait.ru


тель и Студент могут быть обобщены классом Персона с атри­
бутами ФИО, Дата рождения, Пол. При этом класс Персона бу­
дет абстрактным и обозначаться курсивом: Персона.
Может возникнуть и потребность уточнения свойств клас­
са. Например, класс Конфигурация может быть уточнен (спе­
циализирован) до классов Стандартная конфигурация и Поль­
зовательская конфигурация. При этом класс Пользовательская
конфигурация будет иметь связь с классом Клиент, а класс
Стандартная конфигурация — нет.
Каждое отношение между классами должно быть уточнено
до указания кратности с каждой стороны отношения. При этом
следует избегать отношений типа «один-к-одному». Применяй­
те связи «один-ко-многим», «многие-ко-многим».
3.2. Уточнение концептуальной модели классов
Для начала еще раз внимательно перечитайте описание за­
дачи, обращая внимание на свойства концептуальных классов,
выраженных дополнениями, притяжательными существитель­
ными, прилагательными, обозначающие конкретные значения
свойств этих классов. Не забывайте, что некоторые наименова­
ния классов могут иметь синонимы.
Проанализировав описание задачи, мы получим следующие
классы:
— участник программы (email, пароль, ФИО, дата рожде­
ния, количество фишек (или просто фишки));
— карта лояльности (номер, баланс, блокирована);
— операция (номер, дата, сумма, тип операции);
— вознаграждение (номер, дата, использовано);
— правило (код, тип правила, условие, описание);
— вид вознаграждения (код, название, описание).
Результат добавления атрибутов на диаграмму классов пред­
ставлен на рис. 3.1. Некоторые атрибуты не вызывают никаких
вопросов и напрямую следуют из описания. Другие не столь
очевидны и требуют внимательного изучения текста и анализа
полученной модели. Дополнительную помощь в выявлении не­
обходимых составляющих классов можно получить из кратких
описаний вариантов использования. При этом надо понимать,
что не всегда удается с первой попытки построить исчерпыва­
ющую модель. Чаще всего приходится делать несколько подхо-

56

https://urait.ru


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

Рис 3.1. Первый вариант уточненной модели предметной области

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

57

https://urait.ru


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

Рис. 3.2. Второй вариант уточненной модели предметной области

Важным этапом уточнения модели классов является опреде­
ление типов данных для каждого атрибута. Visual Paradigm име-

58

https://urait.ru


ет развитые возможности для задания типов атрибута и опре­
деления дополнительных свойств каждого атрибута. Для этого
через команду контекстного меню Open specification нужно
открыть окно спецификации атрибута (рис. 3.3). В поле Туре
можно выбрать доступные простые типы данных или класс мо­
дели. Например, в случае атрибута Тип операции следует за­
дать в качестве типа данных перечисление Тип операции. Если
среди доступных типов данных нужный тип отсутствует, его
следует задать, выполнив команду Tools / Project Options... /
Data Type / UML (language in use) / Add...
$ Attribute Specification

General

R«et

X

▼

I У I I Cancel I I Appk I I Help I

Puc. 3.3. Окно спецификации атрибута

Помимо типа данных для каждого атрибута можно задать:
— значение по умолчанию (Initial value);
— кратность атрибута (Multiplicity), часто используют [0..1],
это означает значение атрибута необязательное, т. е. атрибут
можно оставить пустым, в противоположность кратности [1],
что указывает на обязательность значения такого атрибута;
— видимость атрибута (Visibility);
— и другие полезные свойства, например, является ли атри­
бут вычисляемым (Derived).

3.3. Проверка модели методом ОСЬнавигации

После окончательного формирования модели было бы не­
плохо проверить правильность выбранных решений, прове-

59

https://urait.ru


рить, соответствует ли модель всем предъявленным требо­
ваниям и отвечает ли на вопросы заказчика. При написании
исходного кода корректность его определяется в ходе процесса
отладки, когда компилятор анализирует написанный ход, об­
наруживает синтаксические ошибки. Правильность разрабо­
танного приложения проверяется заказчиком в ходе его непо­
средственного использования для решения конкретных задач.
Для проверки правильности составленных моделей можно
использовать возможности приложения MDriven Designer1,
позволяющего на основе разработанной модели классов сгене­
рировать структуру данных и простой прототип приложения.
К сожалению, не существует автоматизированных инстру­
ментов переноса модели классов, разработанных в Visual
Paradigm, в приложение MDriven Designer, поэтому эту задачу
вам придется выполнить вручную.
Для этого
— запустите приложение Gaffr.exe;
— создайте новый файл (если он не был создан по умолча­
нию) и сохраните с именем Astrokofe.modlr;
— в окне Overview выберите пиктограмму Diagraml и пе­
рейдите в окно диаграммы;
— через контекстное меню добавьте нужное количество
классов согласно ранее разработанной модели классов;
— определите имя каждому классу либо в окне свойств (оно
располагается с правой стороны), либо прямо на графическом
элементе класса (двойной щелчок мышью или нажатие клавиши
Enter включает режим редактирования имени). Если имя класса
состоит из нескольких слов, либо введите его без пробелов,
либо вместо пробела поставьте знак подчеркивания;
— свяжите классы соответствующими ассоциациями:
• выделите класс,
• через контекстное меню выберите команду Add associa­
tion,
• проведите связь до нужного класса,
• укажите правильные кратности концам связи,
Обратите внимание на автоматически появляющиеся имена кон­
цов связи.
Согласно методологии MDA [8] каждый конец связи должен
получить имя. Имя конца связи (ассоциации) — это роль, которую
1 URL: https://mdriven.net/downloads

60

https://urait.ru


класс играет в данной связи. Наличие имени конца связи облегчает
построение навигационных запросов.

• добавьте атрибуты для каждого класса,
• в контекстном меню выполните команду Add Attribute,
• задайте имя атрибута согласно модели, если имя атрибу­
та состоит из нескольких слов, либо введите его без про­
белов, либо вместо пробела поставьте знак подчеркивания,
• в окне свойств определите тип данных Туре.
Более подробно о создании моделей в MDriven Designer будет
рассказано на практических занятиях. Кроме того, об этом мож­
но прочитать в документе, «Создание бизнес-модели» («Creating
an ECO business model») [9], подготовленном компанией-разра­
ботчиком, и на сайте компании MDriven1. Результат построен­
ной в MDriven Designer модели классов представлен на рис. 3.4.
После переноса модели классов из Visual Paradigm в MDriven
Designer можно приступить к испытанию разработанной моде­
ли. Кстати, при определенных условиях можно было бы сразу
формировать модель в MDriven Designer, минуя ее разработку
в Visual Paradigm. Но это, как мы полагаем, вам и так понятно.
Для проверки модели классов мы будем использовать спе­
циальный язык объектных ограничений и запросов OCL [10,
11]. Как следует из самого названия, язык OCL предназначен
для задания специальных ограничений и правил, накладывае­
мых на модель классов и которые не могут быть реализованы
только средствами языка UML. При этом ОСЬ содержит набор
свойств и операций, который позволяет строить навигацион­
ные выражения, объектные запросы, и по результату выполне­
ния этих запросов проверять корректность составленной моде­
ли и ее соответствия исходным требованиям.
Как вы понимаете, основной задачей любой системы являет­
ся решение задач заказчика или пользователя. В нашем случае
такие задачи удобно сформулировать в виде вопросов, ответы
на которые нужно получить с помощью нашей модели. Такие
вопросы должны отражать характер изучаемой предметной об­
ласти и должны быть сформулированы в прикладном ключе.
Минимальное количество вопросов, необходимых для провер­
ки качества модели, зависит от количества классов и связей
между ними, а также семантической сложности самой модели.
1 URL: https://wiki.mdriven.net/index.php/UML_School

61
https://urait.ru


Участникпрограммы
emM: String?
Дага-рилграции Date
Додрохдемо Oat*
Пароле String?
ОИО String?
Оишки: integer

1.*

1
.* Операции
0..’ Вознаграждения

Дат» Daw
Исполнена*© Вяоіып
Номер Integer

0-’

Омвкж integer

0..* Вознаграждения

Правило_по_операции
Msr.cyuna: Double

Ѵіп.омиз. Double
Тип операции: String

Правило
Им* String’
Код: Weger
Ксиецл«ѵс-іи«: Date
на^ало-деисеия: Date
Фишки' integer

Дахсвип"' snng
Лризмк_доты: Boolean

0.." Правида

Вид_вознаграждения
Кох Autclnc
назоамие: String?
Описами*: String?

Рис 3.4. Диаграмма классов, реализованная в MDriven Designer

Поскольку мы изучаем навигационные возможности моде­
ли, то в каждом вопросе должны участвовать как минимум два
соседних класса и одна связь между ними. Но лучше, если в на­
вигационный запрос включаются три и более классов. Таким
образом, количество запросов должно быть не меньше числа
связей между классами. В качестве учебных целей минималь­
ное число запросов к модели не должно быть меньше 6.
Составить грамотные вопросы не так просто. Давайте по­
пробуем сделать это для нашей учебной задачи. Вниматель­
но посмотрите на полученную модель классов, перечитайте
описание учебной задачи, встаньте на точку зрения каждого
из действующих лиц (акторов), попытайтесь сформулировать
вопросы, на которые каждый из этих действующих лиц хо­
тел бы получить ответы.
1. На какую сумму совершил покупок каждый из участников
программы лояльности?
2. Кто из участников программы лояльности получил боль­
ше всего вознаграждений?
3. По каким правилам можно получитъ вознаграждение
«Бесплатный напиток»?
4. На какую сумму пополнил свой счет участник программы
лояльности X за первые полгода 2019 года?

62

https://urait.ru


5. Когда было реализовано последнее вознаграждение бес­
платный напиток каждым из участников?
6. Сколько фишек заработали каждый из участников за счет
покупок, превышающих 1500 рублей (ну или за счет покупок
превышающих некую заданную сумму)?
Прежде чем ответить на эти вопросы, необходимо выпол­
нить предварительную работу с исходной моделью, которая
заключается
— в добавлении вычислимых атрибутов (они могут быть
простым ответом на поставленный вопрос либо помочь полу­
чить на него ответ более простым способом);
— настройке отображения некоторых атрибутов в запросах;
— задании ограничений на принимаемые значения атрибу­
тов;
— наполнении модели (на самом деле хранилища, состав­
ленного на основе этой модели) данными для выполнения экс­
периментов и исследования.
Задание ограничений позволяет контролировать значения
атрибутов. Представим несколько примеров того, как это мож­
но сделать.
Для атрибутов класса Правило зададим ограничение: конеч­
ная дата периода действия правила должна превышать на­
чальную дату периода действия. Чтобы задать ограничение:
— выделите класс Правило;
— в окне свойств найдите свойство Constraints и по кнопке
«три точки» вызовите диалог задания ограничений;
— в поле Name введите название правила: Конечная дата
должна превышать начальную дату;
— в поле Body введем OCL-выражение:
• кнопкой Осі откройте редактор Ocl-выражений (рис. 3.5);

Рис 3.5. Редактор OCL-ограничений

63

https://urait.ru


• в окно редактора добавьте Конец_действия: зе1ЕКонец_
действия;
• добавьте к выражению знак сравнения: зеІЕКонецлействия > ;
• из списка атрибутов добавьте Начал содействия: self.Koнец_действия >.Начало_действия;
• валидатор выражения показывает ошибку, чтобы ее устра­
нить, нужно исправить выражение: зеИ.Консіщействия > self.
Начало_действия. Зеленый цвет показывает, что выражение со­
ставлено корректно.
Для атрибутов класса Участник программы зададим ограни­
чения (табл. 3.2).
Таблица 3.2
OCL Expression

Кате

ФИО не должно
быть пустым

self.0HO->NotEmpty
или
self-ФИО. notNull

Участник програм­
мы должен быть
совершеннолетним
на момент реги­
страции

(self-Дата регистрации.Year - self.flaTa_
рождения.Year) >= 18

Некорректный
электронный адрес

(self.email.length = 0)
или
(self.email. reg ExpMatch(‘\\w+([-+.]\\w+)*@\\w+([-.]\
w+)*\\.\\w+([-.]\w+)*’))

Пароль должен
быть иметь не ме­
нее 6 символов

self.riaponb.Length >= 6

Обычно новые экземпляры каждого класса представлены
по умолчанию первым строковым атрибутом. Чтобы задать
представление нужного вида, следует использовать свойство
DefaultStringRepгesentation (табл. 3.2).
Таблица 3.2
Класс

DefaultStringRepresentation

Участник про­
граммы

self-ФИО

Карта

self.HoMep.asString +’(*+ self.EanaHC.asString +’)’

64

https://urait.ru


Окончание табл. 3.2
DefaultStringRepresentation

Класс
Операция

зеІЬТип_операции + ‘ №’ + self.HoMep.asString

Вознагражде­
ние

‘№’ + self.HoMep.asString + ‘ от ‘ + self.flaTa.asString

Правило

self-Имя

Вид вознаграж­
дения

self-Название

Значения некоторых атрибутов нашей модели зависят
от значения других. Например, баланс карты определяется
разницей всех операций пополнения и всех операций покупок
за деньги. Количество фишек у каждого участника также ме­
няется в зависимости от того, сколько было накоплено за вы­
четом количества потраченного на вознаграждения. В нашей
модели значения этих атрибутов будут храниться в базе дан­
ных, а метод их вычисления откладывается на более поздние
этапы разработки приложения. Если потребности в хранении
такой информации нет, то можно превратить такие атрибуты
в вычисляемые. Свойство вычисляемости или Derived задается
атрибуту во время создания модели, а значение вычисляется
по заранее созданному выражению. В нашем случае мы также
будем использовать язык ограничений ОСЬ.
Формирование вычисляемых атрибутов рассмотрим на при­
мере расчета баланса карты. Для этого
— в редакторе модели выделите атрибут Баланс класса Карта;
— в окне свойств найдите свойство AttributeMode и задайте
ему значение Derived;
— перейдите к свойству DerivationOcl и задайте выражение
sei 1\Операции-> select (Тип_операции =’пополнение’). Сумма>sum - 5еИ.Операции->5е1есГ(Тип_операции=’покупка за день­
ги’) .Сумма-> sum.
Для каждой карты мы выбираем и суммируем все опера­
ции «пополнение», затем выбираем и суммируем все операции
«покупка за деньги», и окончательно вычисляем разницу этих
двух сумм. Результат выполнения заданного выражения можно
будет протестировать в ходе добавления соответствующих за­
писей в базу данных.
Чтобы завершить этап подготовки модели к проверке по ра­
нее по сформулированным вопросам и заданным ограниче-

65

https://urait.ru


ниям, необходимо заполнить базу данных достаточным коли­
чеством записей. Какое количество признать достаточным,
приходится решать по ситуации, но обычно нужно не менее
5—10 записей для каждого класса модели. Для этого:
— в окне редактора модели нажмите кнопку создание про­
тотипа >;
— в качестве метода хранения данных выберите вариант
XML;
— укажите имя файла для хранения;
— нажмите кнопку Start system;
— запустите окно отладки кнопкой OldD;
— последовательно заполните базу данных необходи­
мым для последующего тестирования количеством записей
(рис. 3.6):
• выберите требуемый класс из списка (рекомендуется
начинать с классов, кратность связи которых равна 1: Вид
вознаграждения, Участник программы, и далее спускаться
по иерархии классов: Правило, Карта, Операция и завершаем
Вознаграждением),
• добавьте новую запись в табличной части класса с помо­
щью кнопки Add,
• для удобства ввода данных двойным щелчком левой кноп­
ки мыши откройте автоформу и заполните пустые поля.
Обратите внимание, что на автоформе могут находиться до­
полнительные вкладки. Например, как показано на рис. 3.6,
объект класса Участник программы в соответствии с моделью
классов связан с классом Карта (вкладка Карты) и классом Воз­
награждение (вкладка Вознаграждения).
—

С MOriven debugger

□

Яе
OaaesandOCL

Oj Obede

1Мо/Якк>

ECO loo

Sjno

In-port tao wparatod

Рис. 3.6. Окно отладки и тестирования модели

66

https://urait.ru

X


В такой ситуации удобно сформировать набор записей, свя­
занных с объектом родительского класса. Достаточно перей­
ти, например, на вкладку Карты и добавить столько записей,
сколько нужно (рис. 3.7).

Рис. 3.7. Автоформы

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

Более подробно работа с отладчиком и автоформами опи­
сана в учебном материале [11] либо на сайте разработчика1.
Обратите внимание, что на каждой автоформе есть вкладка
Constraints. Она содержит список определенных ограничений
и результат соответствия введенных данных этим ограничени­
ям (рис. 3.8).

Рис. 3.8. Вкладка заданных ограничений класса «Участник программы»

После того, как все готово: все данные введены, все ошибки
и недочеты, обнаруженные в ходе настройки модели устране1 URL: https://wiki.mdriven.net/index.php/MDriven_Designer_Overview_Series

67

https://urait.ru


ны, попробуем найти ответы на ранее сформулированные во­
просы.
Естественно, чтобы найти ответы, необходимо составить
соответствующее OCL-выражение и выполнить его. Для это­
го найдите в окне отладчика кнопку вызова OCL-редактора
(рис. 3.9) и нажмите ее, чтобы открыть редактор.

Рис 3.9. Кнопка вызова OCL-редактора

В соответствии с вопросом «На какую сумму совершил по­
купок каждый, из участников программы лояльности?» подго­
товим OCL-выражение и выполним его, нажав на кнопку Eval
(см. рис. 3.9).
Ответом на поставленный вопрос будет выражение:
Участник_программы.allinstances->collect('Совершено
покупок на сумму: ' + Карты.Операции->select(Тип_
операции='покупка за деньги') .CyMMa->sum.asString + '
(' + ФИО + ')')

а результат его выполнения показан на рис. 3.10.

Рис. 3.10. Результат выполнения введенного выражения

Выражение требует комментария. В начале мы формируем
коллекцию объектов класса «Участник программы», чтобы от­
ветить на часть вопроса «каждый из участников программы
лояльности», и получаем Участник_программы. allinstances. Да­
лее нам необходимо произвести отбор всех операций покупок
для каждого члена такой коллекции, поэтому мы используем
операцию ->collect(). Выражение внутри операции collect до­
статочно понятно и без объяснений.
Получим ответы на все оставшиеся вопросы.
2. Кто из участников программы лояльности получил боль­
ше всего вознаграждений?

68

https://urait.ru


OCL-выражение:
Участник_программы.allln stances-> select (Вовна граждения>зіге=Участник_программы.aIlinstances>collect(Вознаграждения ->size)->maxValue).ФИО

Результат выполнения выражения:
Expression программы а!1И81апсее->со1ес1(Вознаграж^и«ь>вйё>о^^

Evaluator

Object Ccnstrart Language (OCL)

AaSthng

Type

►

9 Systecr Sbng

.

Eval

□ link expression to selected

| _ Оыг J

Ml

1 Сидеров Сергей Васильевич

СиАОрсв Сергей Васильєві*

3. По каким правилам можно получить вознаграждение
«Бесплатный напиток»?
ОСЬ-выражение:
Вид_вознаграждения.allInstances>5е1есТ(Название='Бесплатный напиток').Правила.Имя

Результат выполнения выражения:

4. На какую сумму пополнил свой счет участник программы
лояльности Сидоров за 2019 год?
ОСЬ-выражение:
Участиик_программы.alllnstances>select(OHO. sqllike('Сидоров %')).Карты.
Onepaunn->select((Дата.Year='2019') and (Тип
операции='пополнение')).CyMMa->sum

Результат выполнения выражения:
Expressen [Участмик^прсграммы aihstances->seted(<₽HO sqlket

Evaluator

Object Constrart Language (OCL)

Type

Аз Strng

□ Link e:

[7|

Eval

?

Clear

act'

69

https://urait.ru


5. Когда было реализовано последнее вознаграждение бес­
платный напиток каждым из участников?
OCL-выражение:
Участник_программы.allInstances->collect(OHO + ' реа­
лизовал вознаграждение за дату ' + Вознаграждения>select(Использовано).Дата->last.asstring)

Результат выполнения выражения:
Expression |y'HacTH«_nporpaMMbialln$tances->co#ect( <FMO ♦ 'pearwooBan eoonarpe
Evaluator

Object Constrant Language ©CL)

Туре

►

v

Eval

□ Link expression to Mlects|

АзЗігіпд

|

Clear

sef

System String

Сидоров Сергей Васильевич реализовал вознаграждение за дату 20 12 2019

Одор<

System String

Петров Иван Иванович реализовал вознагражден» за дату 10.10 2019 0 00:00

Петрос

System.String

Мегъник Карина Альбертовна реализовал вознагражден» за дату 05.12 201 ..

Мельн

<

>

6. Сколько фишек заработал каждый из участников за счет
покупок, превышающих 1500 рублей?
ОСЬ-выражение:
Участник_программы.allInstances->collect(OHO + f получил f +
(Карты.0перации->зе1есі((Тип_операции='покупка за деньги')
and (Сумма>1500))->size*2).asString + ’ фишек')

Результат выполнения выражения:

Чек-лист
□ Нет ни одного класса без атрибутов и (или) связей.
□ Все выявленные атрибуты распределены по классам.
□ Между классами нет избыточных связей.
□ Связи обобщения используются корректно и грамотно.
□ При наличии перечислений они правильно отражены
на диаграмме.
□ Для обоих концов каждой ассоциации заданы кратности
и имена.

70

https://urait.ru


□ OCL-выражения для навигации по модели включают как
минимум два соседних класса.
□ Введено достаточно данных для корректной иллюстра­
ции OCL-запросов.
Вопросы для самоконтроля
1. Что такое атрибут класса?
2. В чем отличие перечисления от класса, с какой целью используют
перечисления?
3. Какие типы данных бывают? Что означает простой или сложный
(составной) тип данных?
4. Какие типы связей разрешены на диаграмме классов?
5. В чем назначение отношения «обобщение»?
6. Что за вид связи используется для связывания класса Операция
и перечисления Тип операции?
7. Какие свойства бывают у атрибута? Каково их назначение?
8. Как расшифровывается ОСЬ?
9. Какую задачу выполняет имя конца ассоциации?
10. Для чего используется приложение MDriven Designer?
11. Что такое constraint, какую задачу это понятие выполняет?
12. Зачем используются автоформы?

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 4.
СПЕЦИФИКАЦИЯ ВАРИАНТА
ИСПОЛЬЗОВАНИЯ
Что нужно сделать в рамках данной лабораторной работы:
1) проанализировать список вариантов использования, расставить
их приоритеты и по согласованию с преподавателем выбрать один или
несколько вариантов использования с наибольшим приоритетом;
2) составить подробную спецификацию для выбранных вариантов
использования;
3) представить спецификацию варианта использования в виде диа­
граммы деятельности.

4.1. Введение

Функциональные требования подробно фиксируются в опи­
саниях вариантов использования. Описания составляются спе­
циальным образом, чтобы уменьшить вероятность неверно­
го толкования и облегчить восприятие текста. Стандарт ІІМЬ
не определяет единых правил для создания описаний вариан­
тов использования. Однако существует ряд шаблонов, которы­
ми вы можете воспользоваться: шаблон от Алистера Коберна
[12], от Карла Вигерса [13], от КНР, от ІСОМІХ, от Ореп11Р и т. п.
В конце концов, вы можете изобрести свой собственный ша­
блон. Нужно лишь придерживаться максимальной простоты.
Мы представим рекомендации и примеры вариантов ис­
пользования на базе следующего шаблона.
Имя варианта использования. Нет стандарта. Рекоменду­
ем начинать с глагола или глагольной группы (отглагольного
существительного). Например, «Выплатить налог с оборота»
или «Выплата налога с оборота». Не смешивайте оба стиля в од­
ной модели. Является уникальным идентификатором в рамках
модели ВИ.

72

https://urait.ru


ID варианта использования. Суррогат идентификатора.
Используется для облегчения и краткости при описании ссы­
лок. Например, UC001, ВИ123 или П546.
Краткое описание. Изложение цели или сути варианта ис­
пользования. Не более одного абзаца.
Действующие лица. Каждый вариант использования всегда
инициируется одним действующим лицом. Но в разные момен­
ты времени один и тот же вариант использования может быть
инициирован разными действующими лицами. Любое действу­
ющее лицо, которое может инициировать вариант использова­
ния, является основным действующим лицом. Все остальные
действующие лица — второстепенные. В рассматриваемом
примере это Банковская система.
Предусловия и постусловия. Предусловия определяют,
в каком состоянии должна находиться система, чтобы запуск
варианта использования был возможным. Постусловия опреде­
ляют, какие условия будут истинными после завершения вари­
анта использования. Рекомендуется явно указывать на отсут­
ствие пред- и постусловий. Например, словом Нет.
Основной поток. «Идеальный» ход развития событий, опи­
сывающий взаимодействие системы и действующих лиц, при
котором достигается цель основного действующего лица. Все
идет, как ожидается и хочется. Нет ошибок, отклонений, пре­
рываний или ответвлений. Шаблон записи шага — <номер>
< кто-либо < совершает некоторое действие >. Первый шаг
рекомендуем записывать, так: 1. ВИ начинается, когда <дей­
ствующее лицо <действие>
Альтернативные потоки (ветвления, повторения и ис­
ключения). У каждого ВИ есть один основной поток и может
быть множество альтернативных потоков. Альтернативные по­
токи часто не возвращаются в основной поток ВИ. Это связано
с тем, что они обычно обрабатывают ошибки и исключения ос­
новного потока и имеют другие постусловия. Альтернативные
потоки можно задокументировать в конце ВИ или отдельно.
Здесь будет представлен второй вариант. Спецификация аль­
тернативного потока подобна спецификации всего ВИ. Альтер­
нативные потоки могут быть инициированы тремя разными
способами:
1) вместо основного потока. Такая ситуация часто возника­
ет в вариантах использования типа CRUD (Create, Read, Update,
Delete);

73

https://urait.ru


2) после определенного этапа основного потока;
3) в любой момент в ходе выполнения основного потока.
В реальном рабочем процессе описания составляются для
всех вариантов использования. Мы создадим лишь несколько
описаний в качестве примера.
4.2. Описание вариантов использования

4.2.1. Вариант использования ІІСОЗ «Войти в систему»
Краткое описание.
Участник программы, который имеет учетную запись, полу­
чает возможность «входить» в меню сайта, т. е. иметь доступ
к функциям участника программы лояльности.
Основной поток событий.
1. Участник программы входит на сайт программы лояльно­
сти участника.
2. Система запрашивает имя пользователя и пароль.
3. Участник программы вводит имя и пароль.
4. Система подтверждает правильность имени и пароля.
5. Система выводит страницу профиля участника програм­
мы лояльности, дающую доступ к функциям программы.
Альтернативные потоки.
4А. Неправильное имя/пароль:
1) система обнаруживает, что комбинация имени и пароля
не верна;
2) система сообщает об ошибке и предлагает пользовате­
лю либо заново ввести имя и пароль, либо отказаться от входа
в систему;
3) участник программы сообщает системе свой выбор;
4) в соответствии с выбором участника программы либо вы­
полняется переход на шаг 2 основного потока, либо вариант
использования завершается неуспешно.
Предусловия.
Отсутствуют.
Постусловия.
Если вариант использования выполнен успешно, система
предоставляет пользователю, сообщившему верную комбина­
цию имени и пароля, доступ к своему профилю. В любом слу­
чае система гарантирует, что пользователю, не сообщившему
верную комбинацию имени и пароля, доступ в систему не бу­
дет предоставлен.

74

https://urait.ru


Обратите внимание на номера альтернативных потоков. Цифра
указывает номер шага основного потока, на котором может про­
изойти переключение на альтернативный поток, буква позволяет
различить несколько альтернативных потоков, на которые можно
переключиться на одном и том же шаге. Если переход на альтер­
нативный поток может происходить в течение нескольких под­
ряд идущих шагов, указывают их номера через дефис (например,
1-ЗБ). Если поток вызывается из разных шагов, он может иметь
несколько номеров, перечисленных через запятую.

Добавьте в модель описание, приведенное выше. Для этого
скопируйте текст описания, выделите нужный вариант исполь­
зования, откройте его спецификацию и на вкладке General
вставьте текст в поле Description.
Описание варианта использования можно полностью вы­
полнить в специальном редакторе, предоставляемом Visual
Paradigm. Чтобы войти в редактор описания варианта исполь­
зования, выделите его на диаграмме или Model Explorer, вы­
зовите контекстное меню и выполните команду Open Use Case
Details...
Варианты использования -> Войти в систему-» Войти в систему Details

Войти в систему
Info

Use Case Notes

Row of Events

О’
Details

Requirements

Oagrams

Test Ran

References

Пользователь (участник программы ). который имеет учетную запись,
получает возможность "входитъ’ в меню сайта, т.е. иметь доступ к
функциям участника программы лояльности.
□ Abstract

□ Leaf

О Root

Рис 4.1. Редактор спецификации варианта использования. Вкладка Info

На вкладке Info (рис. 4.1) отображаются имя редактируемо­
го варианта использования, его идентификатор, который зада­
ется автоматически при добавлении варианта использования
к модели, основное действующее лицо, ранг, статус и описа­
ние варианта использования. Как вы могли заметить, некого-

75

https://urait.ru


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

Рис 4.2. Редактор спецификации варианта использования. Вкладка Details

Потоки событий записываются на соответствующей вкладке
Flow of Events. Давайте разберемся, как это делается.
Перейдите на вкладку Flow of Events. Нажмите кнопку X
Edit Scenario и переименуйте наименование сценария по умол­
чанию в «Основной поток событий». Перейдите в правую часть
окна и активируйте строку с текстом «Enter a step here». Щелч­
ком правой кнопки мыши вызовите контекстное меню и выпол­
ните команду Add Actor. Выберите актера «Посетитель» и на­
жмите ОК. Добавьте текст первого шага согласно сделанному
ранее описанию: «входит на сайт программы лояльности участ­
ника». Нажмите Enter, чтобы добавить новый шаг. Вызовите
контекстное меню и выполните команду Add Control —> System
Response, чтобы добавить реакцию системы на действия поль­
зователя. Повторите действия, чтобы сформировать основной
поток событий. У вас должно получиться следующее (рис. 4.3).
Теперь сформируем альтернативные потоки. Для этого вы­
делите шаг 4 основного потока событий, вызовите контекстное
меню и выполните команду Add Extension. Сформируйте шаги
альтернативного потока согласно рис. 4.4.

76

https://urait.ru


Ш

Варианты использования -> Войти в систему -> Войти в систему Details

«

Войти в систему
Info

Use Case Notes

Ho** of Events

Detais

Requrements

t>agrams

Test Pian

References

Рис. 4.3. Редактор спецификации варианта использования. Вкладка Flow of Events
Неправильное имя/пароль

1. SYSTEM обнаруживает, что комбинация имени и пароля не верна

ѳ
ѳ
ѳ

2. SYSTEM сообщает об ошибке и предлагает пользователю либо
заново ввести имя и пароль, либо отказаться от входа в
систему.
3. $ Участник программы сообщает системе свой выбор

3.1. if выбрано продолжить

3.1.1. jump to 2. SYSTEM запрашивает имя пользователя...
3.2. else
3.2.1. exit Основной поток событий
end if

Рис. 4.4. Расширения потока варианта использования

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

77

https://urait.ru


4.2.2. Вариант использования ІІС15
«Пополнить баланс карты»
Краткое описание.
Участник программы может пополнить баланс своей кар­
ты с помощью банковского перевода. Пополнение карты ло­
яльности производится за счет средств с банковской карты.
Карта лояльности должна быть зарегистрирована как при­
надлежащая участнику программы и не заблокирована. Ба­
ланс средств на ней может быть нулевым или положитель­
ным. Для пополнения пользователь указывает номер своей
банковской карты и код СѴѴ2, а также сумму пополнения.
Сайт программы лояльности связывается с банковской си­
стемой и запрашивает, можно ли получить средства в поль­
зу «Астрокофе». Если всё указано верно, с банковской карты
указанная сумма переводится на счет «Астрокофе», а баланс
указанной карты лояльности пополняется на ту же сумму.
В противном случае сайт сообщает, что пополнение не может
быть осуществлено, и указывает причину этого. Вознаграж­
дение «бесплатная пачка кофе» начисляется клиенту после
каждого пополнения его карты лояльности на сумму, превы­
шающую 1999 рублей.
Основной поток событий.
1. Участник программы запрашивает список своих карт ло­
яльности.
2. Система отображает список карт лояльности пользовате­
ля.
3. Участник программы выбирает карту, для которой хочет
пополнить баланс.
4. Система отображает детали выбранной карты.
5. Участник программы выбирает опцию «Пополнить ба­
ланс».
6. Система предлагает ввести данные банковской карты
и сумму пополнения.
7. Участник программы вводит требуемые данные и запра­
шивает пополнение средств.
8. Система связывается с банковской системой и делает за­
прос на получение средств.
9. Банковская система подтверждает перевод средств.
10. Система получает ответ банковской системы.
11. Система обновляет баланс карты.

78

https://urait.ru


12. Система сообщает участнику программы о результате
операции.
13. Вариант использования завершается.
Альтернативные потоки.
9А. Банк отказывает в проведении транзакции:
1) банковская система отказывает в проведении транзакции;
2) система выдает сообщение об ошибке;
3) вариант использования завершается.
НА. Поступила сумма, превышающая 1999 рублей:
1) система обнаруживает, что баланс пополнился на сумму,
превышающую 1999 рублей;
2) система начисляет участнику программы вознагражде­
ние «бесплатная пачка кофе»;
3) система сообщает участнику программы о начислении
вознаграждения;
4) происходит переход к шагу 12.
Предусловия.
Участник программы вошел в систему. Открыт профиль
участника программы.
Постусловия.
Если вариант использования выполнен успешно, система
пополняет баланс карты лояльности на указанную сумму. Ес­
ли при этом сумма превышает 1999 рублей, система начисляет
вознаграждение «бесплатная пачка кофе». Если транзакция по­
полнения не удалась, баланс средств на карте лояльности оста­
ется прежним, списания денег с банковской карты не проис­
ходит, т. е. баланс средств на банковской карте остается таким,
каким он был до начала операции пополнения.

43. Построение диаграмм деятельности

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

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

79

https://urait.ru


Диаграмма деятельности (activity diagram) — это один из пяти
видов диаграмм, применяемых в UML для моделирования ди­
намических аспектов систем (поведения). По сути, диаграмма
деятельности представляет собой блок-схему, которая показы­
вает, как поток управления переходит от одной деятельности
к другой.
Для создания диаграммы деятельности варианта использо­
вания выполните следующие действия. На диаграмме вариан­
тов использования (см. рис. 2.3) выделите вариант использова­
ния «Войти в систему», вызовете контекстное меню и выберите
пункт Sub Diagrams / New Diagram. В открывшемся окне вы­
берите из списка Activity Diagram, нажмите кнопку Next, за­
дайте имя для диаграммы или оставьте по умолчанию и на­
жмите кнопку ОК, завершая создание новой диаграммы.

4.3.1. Диаграмма деятельности «Войти в систему»
На диаграмму добавляем два раздела (Vertical Swimlane):
Участник программы и Сайт программы лояльности, каждый
из которых обозначает свою зону ответственности. Далее свя­
зываем каждый раздел с элементом модели, который он пред­
ставляет, через окно спецификации на вкладке General в по­
ле Represents: первый раздел связываем с действующим лицом
Участник программы (выбираем его из пакета Actor), а второй
с системой (выбираем из пакета System). Заметим, что, ес­
ли бы с вариантом использования были связаны два действу­
ющих лица, на диаграмме следовало бы создать три раздела
(два для действующих лиц и один для системы). Входной узел
(Initial Node) помещаем в раздел Участник программы, так как
это действующее лицо основное для данного варианта исполь­
зования и инициирует процесс взаимодействия.
Согласно описаниям потоков событий варианта использова­
ния создаем узлы действия (Action), размещая их в соответству­
ющих разделах.
Не следует вместо узлов действия (Action) создавать деятельно­
сти (Activity)!

Добавляем узлы логического ветвления (Decision Node). Со­
единяем узлы ребрами потоков управления (Control Flow). За-

80

https://urait.ru


дать сторожевые условия можно, открыв спецификацию пото­
ка, на вкладке General в поле Guard (или через контекстное
меню потока —> Guard...).
Не следует указывать сторожевые условия в названиях потоков
управления!
Не следует вместо узлов логического ветвления (Decision Node')
создавать узлы логического объединения (Merge Node)!

Добавляем два узла завершения деятельности (Activity Final
Node) с именами, указывающими на успешное или неуспешное
завершение варианта использования. Вид получившейся диа­
граммы представлен на рис. 4.5.

Если спецификация варианта использования разраба­
тывалась в редакторе Use Case Details, то можно попробо­
вать сгенерировать диаграмму деятельности автоматически
по описанию потоков событий. Для этого откройте редактор
Use Case Details для варианта использования «Войти в систе­
му», перейдите на вкладку Flow of Events, нажмите на кноп-

81
https://urait.ru


ку Synchronize to diagram и выполните команду Synchronize
to Activity Diagram (рис. 4.6).
Flow of Events

Details

1■

2.
3.

Retirements

Diagrams

Test Man

References

£ Посетитель ВХОДИТ на сайт программъ *>
SYSTEM

Й.ОРа.Ц^^І ІѴД9,ПО^

Synchronize to Activity Diagram
Synchronize to Sequence Diagram

J Посетитель вводит имя и пароль

Рис 4.6. Команда автоматического создания диаграмм по описанию

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

4.3.2. Диаграмма деятельности
«Пополнить баланс карты»
На диаграмму добавляем три раздела (Vertical Swimlane'):
Участник программы, Сайт программы лояльности и Банков­
ская системы. Далее связываем каждый раздел с элементом
модели, который он представляет, через окно спецификации
на вкладке General в поле Represents: первый раздел связы­
ваем с действующим лицом Участник программы (выбираем
его из пакета Actor), второй с системой (выбираем из пакета
System), а третий вновь с действующим лицом Банковская
система (выбираем его из пакета Actor). Входной узел (Initial
Node) помещаем в раздел Участник программы, так как это
действующее лицо основное для данного варианта использова­
ния и инициирует процесс взаимодействия.
Согласно описаниям потоков событий варианта использова­
ния создаем узлы действия (Action), размещая их в соответству­
ющих разделах.
Добавляем узлы логического ветвления (Decision Node). Со­
единяем узлы ребрами потоков управления (Control Flow). За­
дать сторожевые условия можно, открыв спецификацию пото­
ка, на вкладке General в поле Guard (или через контекстное
меню потока —> Guard...).
Добавляем два узла завершения деятельности (Activity Final
Node) с именами, указывающими на успешное или неуспешное
завершение варианта использования. Вид получившейся диа­
граммы представлен на рис. 4.7.

82

https://urait.ru


Рис 4.7. Диаграмма деятельности «Пополнить баланс карты»

Чек-лист
□ Наименование варианта использования соответствует
тому, что вы определили во второй лабораторной работе.
□ Перечислены все действующие лица данного варианта
использования.
□ Ясно и точно определены предусловия варианта исполь­
зования.
□ Ясно и точно сформулированы постусловия, т. е. резуль­
таты выполнения варианта использования.
□ Каждый шаг варианта использования начинается с под­
лежащего — это или действующее лицо, или проектируемая
система. Ясно укажите, кто «владеет мячом».

83

https://urait.ru


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

Вопросы для самоконтроля
1. Какова структура полного описания варианта использования?
2. Что такое основное действующее лицо?
3. В чем отличие второстепенного действующего лица от основного?
4. Какие типы сценариев имеет вариант использования?
5. Каковы правила описания потока варианта использования?
6. Что такое предусловие варианта использования?
7. Что такое постусловие варианта использования?
8. Что такое CRUD вариант использования? В каких случаях его
удобно применять?
9. Чем отличается Action от Activity?
10. Зачем на диаграмме деятельности изображают дорожки?
11. Какие виды узлов применяются на диаграмме деятельности?
12. Что такое сторожевое условие?

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 5.
РАЗРАБОТКА МОДЕЛИ ВЗАИМОДЕЙСТВИЯ
Что нужно сделать в рамках данной лабораторной работы:
1) для одного или всех вариантов использования создать последова­
тельность экранных форм (прототипов), иллюстрирующих выполнение
сценариев экранных форм;
2) для одного или всех вариантов использования составить систем­
ную диаграмму последовательности;
3) представить спецификацию выявленных системных операций.

5.1. Введение

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

85

https://urait.ru


5.2. Раскадровка варианта использования

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

Для создания макетов экранных форм существует большое
количество различных инструментов, в том числе эту задачу
можно решить и в Visual Paradigm. Этот способ является пред­
почтительным, так как анализ проекта, создание диаграмм про­
изводятся в этом инструменте, и будет лучше, если и макеты
будут созданы тут. Так легче отслеживать зависимости и обе­
спечивать согласованность проекта, меньше вероятность чтото забыть. Но в Visual Paradigm есть один минус — он обла­
дает достаточно скудным изобразительным инструментарием,
т. е. макеты будут весьма схематичны. Но при этом и нет цели
сделать макеты максимально приближенными к тому виду, ко­
торый они получат в итоге. Если же вы чувствуете в себе жела­
ние сделать макеты «покрасивее», то можете воспользоваться
специализированными инструментами для прототипирования
интерфейсов. Здесь нет никаких ограничений — используйте
тот способ и инструмент, который вам больше нравится.

5.2.1. Раскадровка варианта использования
«Войти в систему»
Данный вариант использования проиллюстрируем с помо­
щью имеющихся механизмов в Visual Paradigm.
Откройте вариант использования и перейдите на вкладку
Flow of Events. Здесь необходимо создать интерфейс для каж­
дого шага потока. Для этого нужно установить курсор на нуж­
ном шаге и нажать на кнопку Define Wireframe.

86

https://urait.ru


Рис 5.1. Создание макета интерфейса из описания варианта использования

В открывшейся справа панели дважды щелкните по надпи­
си Click Here to Select Wireframe. Система предложит выбрать
вид фрейма — у нас веб-система, поэтому выбираем Website.
В результате откроется рабочая область, в которой непосред­
ственно рисуется макет веб-страницы.
Первый шаг в варианте использования — посетитель входит
в систему программы лояльности. Это может выглядеть при­
мерно вот так:

Следующий шаг — система запрашивает имя пользователя
и пароль.

87

https://urait.ru


Далее пользователь вводит логин и пароль и нажимает
на кнопку входа в систему.

Рис. 5.4. Макет экрана 2. Страница входа с данными

На данном этапе может сработать альтернативный сцена­
рий — логин или пароль неправильный. В этом случае систе-

88

https://urait.ru


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

Рис 5.5, Макет экрана 3. Результат неудачного входа

Если логин и пароль верные, то пользователь попадает
на страницу своего профиля и на этом данный вариант исполь­
зования завершается.

Рис 5.6. Макет экрана 4. Страница участника программы

89

https://urait.ru


Следите за тем, чтобы описание варианта использования, диа­
грамма деятельности и раскадровка были согласованными.

5.2.2. Раскадровка варианта использования
«Пополнить баланс карты»
Второй вариант использования проиллюстрируем с помо­
щью стороннего инструмента для прототипирования интер­
фейсов, которых существует большое количество, например:
Axure RP, Mockplus, Balsamiq Mockups, Justinmind, InVision,
Sketch, Adobe XD, Figma и т. п.
Остановим свой выбор на Figma; он бесплатный и для него
имеются библиотеки с готовыми интерфейсными элементами1.
Вариант использования начинается с того, что пользователь
находится в своем профиле и выбирает действие пополнения
карты.
Поскольку Figma обладает большими изобразительны­
ми возможностями по сравнению с Visual paradigm, то ниже
вы видите более детализированный прототип страницы профи­
ля пользователя, чем в варианте использования «Войти в систе­
му», но при этом сохраняющий ту же функциональность.

Рис 5.7. Макет экрана 1. Страница участника программы
1 Библиотека интерфейсных элементов: https://tinyurl.com/wt758bz

90

https://urait.ru


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

Иванов Алексей

Программа лояльности сети
кофеен 'Астрокофе'

Выберите карт» лояльности для пополнения
О «4250 000? 3454

0 • 4250 0002 345*

Рис. 5.8. Макет экрана 2. Список карт лояльности участника

После выбора карты система отображает сведения об этой
карте и выдает форму с данными банковской карты и суммой
пополнения.
Программа лояльности сети
кофеен 'Астрокофе'

Выберите карту лояльности для пополнения

Пополнение карты лояльности

© 4 4250 0002 3456

МИ^

VISA

С

0 4 4250 0002 3456

Детали выбранной карты лояльности

10.122017

420

1150

Рис. 5.9. Макет экрана 3. Страница подготовки к пополнению

91
https://urait.ru


После ввода необходимых данных система связывается
с банковской системой и делает запрос на получение средств.
При этом может случиться ошибка, и банковская система отка­
жет в проведении транзакции (альтернативный поток). В этом
случае наша система должна сообщить об этом пользователю.
△ tntr ОіѵСм л ірмтлн Потеря* психіку

Программа лояльности сети
кофеен 'Астрокофе'

Ьй-р«г» карту поагьиосім для поганими*

Лолоімеиие карты пошъиостх

$ * 4’50 ОХИ МИ

МИР VISA ^

а 42» ОКОМ»

1234 «6 7 7800 000
№<gm «(.«ратной сарты локлдиосги

06/21
сад

были** ■««•м

332

MANOV AlfKSEY

10121017

ОО

II®

Рис. 5.10. Макет экрана 3. Ошибка выполнения операции пополнения

В случае положительного исхода система начисляет фишки
и сообщает об этом пользователю. Дополнительно, если сумма по­
полнения больше 1999 руб, система сообщает о начислении воз­
награждения «бесплатная пачка кофе» (альтернативный поток).
программа лояльности сети
кофеен 'Астрокофе'

Иванов Алексей

шеврига карту іюлиьносім для лопоімінир

Попшывние карлы лошъиостм

@ 4 47® ОХ» ММ

МИР VISA с
42® ОХ» ММ

1234 «62 7890 000
Двгвпа еьОражоА «аріи лмлыаосгм
MANOV AUKS6Y

10122017

11®

200

Рис. 5.11. Макет экрана 3. Успешное пополнение баланса карты1
1 Исходные макеты на Figma можно получить по ссылке: https://goo.
SU/52H0
92

https://urait.ru


5.3. Выявление системных событий и операций

Системная диаграмма последовательности [14] может стро­
иться совместно с раскадровкой интерфейсов. Системная диа­
грамма последовательности применяется для того, чтобы вы­
явить системные события, а затем на их основе определить
системные операции. Можно сказать, что на данном этапе про­
исходит переход от аналитической модели к модели реализации.
Системные события — это внешние по отношению к систе­
ме события. То есть такие события, которые приходят в систе­
му извне, и на которые система должна тем или иным образом
реагировать. Системные события изображаются стрелками, ис­
ходящими от действующего лица и входящие в систему.
Системные операции — это события, преобразованные
в программные операции, в которых показывается, что полу­
чает и возвращает функция системы.
Системная диаграмма последовательности содержит только
действующие лица и систему. Система представляется «чер­
ным ящиком», что именно происходит внутри системы, здесь
не отображается (этим мы будем заниматься в следующей ла­
бораторной работе). По сути, мы выявляем функциональность
системы в контексте варианта использования.
Перед началом работы над диаграммой последовательности
выполните следующие настройки:
1) отключите вывод активаций на диаграмме последователь­
ности (Project Options —> Diagramming —> Interaction —» Show
activations in Sequence Diagram);
2) отключите нумерацию.

Рассмотрим процесс создания системной диаграммы по­
следовательности на примере варианта использования Во­
йти в систему. Выделите на диаграмме нужный вариант ис­
пользования, вызовите контекстное меню, выберите пункт
Sub Diagrams / New diagram и в открывшемся окне выберите
Sequence Diagram (рис. 5.12).
В Model Explorer создайте пакет «Программные классы»
и добавьте в нем новый класс Система. Далее этот класс пере­
тащите на диаграмму последовательности в качестве lifeline.
Также из пакета «Действующие лица» перетащите на диаграм­
му действующее лицо Участник программы (рис. 5.13).

93

https://urait.ru


Впити в систему
Open Specification

витьновут

Stereotypes

Model Element Properties
Open use Case Details...

'•п--л;ирэвэп

'■Л

Generate Requirements Spec

>

SuO Diagrams

нить бала
карты
Просмотреть

STEPS Wizards

A

Cui

1

Войти в систем Activity Diagram

:
Войти в систему - Основной поток событий
Add
New Diagram..

Com-

Brams...

0 Мел Digram

я система

Activity Diagram
Model the workflow within a system with the use of activity action
decision, etc.

Model how users, objects and systems interact with one another and in
what order interactions are arranged from top to bottom, following their
order of occurrence

ета продаж

Рис. 5.12. Алгоритм добавления диаграммы последовательности

Рис. 5.13. Диаграмма последовательности. Начало

Опираясь на созданную ранее спецификацию варианта
использования, а также на диаграмму деятельности и раска­
дровку, нужно на диаграмме последовательности отобразить
сообщения, которыми обмениваются участники диалога. Сооб­
щения, идущие от действующего лица к объекту системы, пред­
ставляют собой системные события. От действующего лица
к системе рисуются стрелки Message, а обратно такие же стрел­
ки, но с типом Reply (рис. 5.14). Стрелка с типом Reply изобра­
жается пунктирной стрелкой и обозначает возврат результата,
в данном случае результата на обращения действующего лица
к системе. Если действующее лицо — это пользователь, то от­
вет системы выглядит как появление какого-то текста, формы,
списка, какого-то изменения на экране, возможно звукового
сигнала. На сложных диаграммах последовательности с боль­
шим количеством сообщений и участников сценария стрелки

94

https://urait.ru


с типом Reply обычно опускаются, так как их действие вполне
подразумевается из общего контекста. Оставляют обычно толь­
ко какие-то важные Reply, которые обеспечивают лучшее по­
нимание отображаемой последовательности действий.
sd Войти в систему Sequence Diagram J

: Система

Участник программы
1: Вход на сайт программы лояльности

1.1: Запрос имени пользователя и пароль
Q

Open SpecibcaMn

Ег**г

Stereotypes

U cdel Element Properties

Type (Unspecified)
И Créa» Cortiwo Rajnwt
Sub Diagrams

rut

Unspecified

Call

Uninterpreted
Send

A cut

Reply

Copy

Destroy

Detail

Termnate

Duplicate.

Sequence

Puc. 5.14. Добавление сообщений актора и ответа системы

Самое простое, с чего следует начать при построении си­
стемной диаграммы последовательности, это отобразить после­
довательность сообщений, которыми обмениваются участники
основного потока варианта использования. То есть мы просто
берем каждое предложение основного потока, начиная с пер­
вого, убираем из него подлежащее, представляющее собой ли­
бо действующее лицо, либо систему, и записываем прямо над
стрелкой или в окне спецификации, вызвав его через контекст­
ное меню. Например:
— шаг «Участник программы входит на сайт программы
лояльности участника» переделываем в сообщение «Войти
на сайт программы лояльности» или «Вход на сайт программы
лояльности»;
— следующий шаг «Система запрашивает имя пользователя
и пароль» переделываем в сообщение «Запросить имя и пароль
пользователя» или «Введите имя и пароль пользователя» или
«Запрос имени и пароля пользователя», и т. д.
Чтобы отобразить на диаграмме альтернативный поток,
нужно выделить Message, которое в нем будет находиться,
и в контекстном меню выбрать действие Create Combined
Fragment. Выбор типа фрагмента будет сильно зависеть от об­
щей логики альтернативных сценариев. Наиболее распростра-

95

https://urait.ru


ненными являются: alt — альтернатива, аналог конструкции
if... then... else или оператора выбора case; opt — опционально,
по сути тот же фрагмент alt, в котором существует только про­
верка на истинность условия; loop — цикл.
В описываемом нами варианте использования «Войти в си­
стему» ответвление от основного потока начинается на 4-м ша­
ге, а после определенной последовательности действий про­
исходит или возврат к шагу 2, или завершение варианта
использования. Очевидно, что в этом случае надо выделить
стрелку 4 (сообщение) и выбрать действие в контекстном ме­
ню Create Combined Fragment —> loop, и затем растянуть его
вверх, чтобы захватить все стрелки, включая вторую. Можно
поступить и иначе, перетащить фрагмент с панели инструмен­
тов.
Alt. Combined

И loop Combined Fragment (shift+o)

Puc. 5.15. Элемент Combined Fragment на панели инструментов

Для отображения условия альтернативного сценария вы­
делите блок loop и в контекстном меню выберите действие
Open specification. В открывшемся окне перейдите на вклад­
ку Interaction Operands и откройте окно спецификации име­
ющегося тут элемента (дайте ему подходящее имя, напри­
мер, extension). В открывшемся окне на вкладке Guard в поле
Constraint впишите название альтернативного сценария (оно
должно быть сформулировано в виде условия: пока логин и па­
роль не верны или не выбран отказ от входа).
Чтобы отобразить на диаграмме условный переход, на па­
нели инструментов нужно выбрать элемент Alt.Combined
Fragment (не выбирайте Alt через контекстное меню, элемент
нужно выбрать именно через панель инструментов). Чтобы
на диаграмме отобразить альтернативные условия (в нашем
примере их всего два, но их может быть сколько угодно), вы­
делите добавленный блок alt и в контекстном меню выберите
действие Open specification. В открывшемся окне перейдите
на вкладку Interaction Operands, для каждого операнда, разме­
щенного на вкладке, откройте спецификацию, задайте имя для
элемента, перейдите на вкладку Guard и в поле Constraint за­
пишите условие: для операнда с истинным значением —логин
и пароль верны, для альтернативного условия — иначе или else.

96

https://urait.ru


В общем случае альтернативных вариантов может быть
сколько угодно, а не только два, формируемые по умолчанию.
Чтобы добавить дополнительные альтернативные варианты,
выделите блок alt, в контекстном меню выберите действие
Operand —> Add operand, добавьте требуемое количество вари­
антов. Затем для каждого операнда в спецификации на вклад­
ке Guard задайте взаимоисключающие условия. В этом случае
мы получаем аналог оператора выбора switch или case.
Согласно спецификации рассматриваемого варианта ис­
пользования, пользователь может отказаться продолжать рабо­
тать с системой, если его логин и пароль не подошел. В данном
случае можно смоделировать такую ситуацию с использовани­
ем фрагмента opt.
В результате у вас получится следующая модель:

Рис. 5.16. Результирующая диаграмма последовательности

97

https://urait.ru


Теперь каждую стрелку (событие) на диаграмме последова­
тельности, входящую в lifeline системы, нужно превратить
в системную операцию. Для этого выделите событие и в кон­
текстном меню выберите пункт Туре / Call / Create Operation.
: Система
Q

Участник прогрг

Open Specification...

Enter

Stereotypes

Model Element Properties

Type (Unspecified)

^^“

loop

ЕЛ

Create Comt 14

Шока ли иі“°"”т

'Г

qh
Select Operation...
Create Operation...

Л

Cut
Create Operation 'войти на сайт программы лояльности'

Unspecified

Call

Uninterpreted

Send
Reply

СОРУ

Destroy

Delete

Terminate

Duplicate...

Sequence

Рис. 5.17. Преобразование сообщений в системные операции

В открывшемся окне укажите:
— имя операции (Name), например, начатьНовуюПродажу
или добавитьНовыйТовар и т. п.,
— тип возвращаемого значения (Return type) (если есть),
— передаваемые параметры и их тип (вкладка Parameters),
— описание операции (Description).
Для каждой системной операции необходимо составить
спецификацию со следующей информацией:
— ссылка на вариант использования;
— название исходного события;
— название операции на русском или английском языке;
— тип возвращаемого операцией значения;
— параметры и их тип;
— предусловия, в которых начинается операции;
— постусловия, которые типично представляют собой:
• создание или удаление экземпляра класса,
• модификацию атрибута,
• формирование или разрыв ассоциации.
Первое событие — «Войти на сайт программы лояльно­
сти». Пользователь заходит на сайт и вызывает функцию входа,
которая инициализирует дальнейший процесс (например, от­
крывается форма авторизации в систему). Каких-либо параме­
тров сама функция не передает в систему (она лишь запускает
работу последующих операций). Также функция ничего не воз­
вращает, поэтому у нее будет тип void. Для простоты вообще
не будем указывать тип возвращаемого значения функции.

98

https://urait.ru


Спецификация для данной операции будет выглядеть следу­
ющим образом:
Вариант использования

ІІСОЗ «Войти в систему»

Название исходного события

Войти на сайт программы лояльности

Название операции

запроситьВходВСистему

Тип возвращаемого значения

—

Параметры

—

Предусловия

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

Постусловия

Создана форма авторизации / входа
на сайт (создание экземпляра)

Пунктирные стрелки от системы к действующему лицу
(с типом Reply), как мы говорили выше, являются результатом
действия (ответом) системы на возникшее системное событие
или сообщение, идущее от действующего лица. Таким образом
стрелки Reply игнорируем. Они помогают правильно опреде­
лить постусловия предыдущей системной операции.
«Ввести имя и пароль» — преобразуем в операцию ввестиДанныеО — это будет универсальной функцией, параметрами
которой будут являться текстовые переменные.
Вариант использования

UC03 «Войти в систему»

Название исходного события

Ввести имя и пароль

Название операции

ввестиДанныеАвторизации

Тип возвращаемого значе­
ния

—

Параметры

логин : string
пароль: string

Предусловия

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

Постусловия

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

99

https://urait.ru


«Выбрать действие» — преобразуем в операцию выбратьДействие(), которая будет использоваться, когда пользователю
необходимо выбрать один из вариантов в каком-либо объекте.
Соответственно, функция будет передавать в систему иденти­
фикатор выбранной опции.
Вариант использования

UC03 «Войти в систему»

Название исходного события

Сообщено, что выбрано

Название операции

выбратьДействие

Тип возвращаемого значения

—

Параметры

Действие : string
(идентификатор опции)

Предусловия

Пользователь ввел логин и пароль,
которые оказались некорректными
и отображена форма выбора дальней­
ших действий

Постусловия

Выбрано продолжить: Отображается
форма авторизации (инициализация
или создание экземпляра).
Иначе: Отображается исходное состоя­
ние системы

В результате модель станет выглядеть следующим образом:

Рис. 5.18. Диаграмма последовательности с системными операциями
100

https://urait.ru


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

Рис. 5.19. Диаграмма последовательности для ВИ «Пополнить баланс карты»

Чек-лист
□ Начинайте раскадровку с экрана, соответствующего
предусловию варианта использования.
□ Каждый экран раскадровки должен соответствовать од­
ному шагу описания варианта использования.
□ Вся последовательность экранов в раскадровке наглядно
показывает, как пользователь взаимодействует с системой для
достижения своей цели.

101
https://urait.ru


□ Убедитесь, что системная диаграмма последовательности
соответствует описанию варианта использования, диаграмме
деятельности и раскадровке, т. е. все артефакты согласованы
и не противоречат друг другу.
□ Убедитесь, что в пакет «Модель структуры» добавлен па­
кет «Модель приложения», а в нем пакет «Программные клас­
сы».
□ Убедитесь, что в пакет «Программные классы» добавлен
класс «Система».
□ Убедитесь, что каждое системное событие (стрелка, вхо­
дящая в lifeline Системы) преобразовано в системную опера­
цию.
□ Убедитесь, что для каждой системной операции опреде­
лена спецификация по заданному шаблону.
Вопросы для самоконтроля
1. Что такое раскадровка?
2. С какой целью применяют раскадровку?
3. Какие способы составления раскадровки вы можете предложить?
В чем отличия каждого из предложенных способов?
4. Что такое системная диаграмма последовательности?
5. Чем обмениваются участники взаимодействия?
6. Как называется линия каждого объекта?
7. Что означает пунктирная стрелка, идущая от одного объекта
к другому на диаграмме последовательности?
8. Что такое комбинированный фрагмент? Какие типы бывают?
9. Как задать условие фрагмента?
10. Что такое системное событие? Какие системные события бы­
вают?

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 6.
РЕАЛИЗАЦИЯ ВАРИАНТА
ИСПОЛЬЗОВАНИЯ
Что нужно сделать в рамках данной лабораторной работы:
1) для одного или всех вариантов использования составить частные
диаграммы последовательности для всех сценариев варианта исполь­
зования;
2) для одного или всех вариантов использования составить диа­
грамму классов View only Participating Classes (VOPC).

6.1. Введение
Диаграмма последовательности представляет собой один
из вариантов отображения поведения системы. Если систем­
ные диаграммы последовательности служат для выявления
системных операций, то детальная диаграмма последователь­
ности представляет собой инструмент анализа способов реали­
зации этих системных операций и проектирования структуры
программных классов.
Для построения диаграммы последовательности мы будет
использовать подход или паттерн ЕСВ1, основанный на разде­
лении программных классов на три группы:
1) граничные, boundary — классы, задачей которых являет­
ся взаимодействие с внешними действующими лицами. Если
действующее лицо является человеком, то граничные классы
представляют собой элементы графического пользовательского
интерфейса, GUI. Если действующее лицо представляет собой
другую систему, то граничные классы будут является частью так
называемого программного интерфейса приложения, API;
2) управляющие, control — классы, задачей которых являет­
ся управление и организация взаимодействия объектов для ре1 Статья Википедии: Entity-control-boundary. URL: https://en.wikipedia .
org/wiki/Entity-control-boundary

юз
https://urait.ru


ализации конкретного варианта использования. Управляющие
классы реализуют бизнес-логику приложения;
3) сущностные, entity — классы предметной области, пред­
назначенные для хранения и предоставления информации, ре­
левантной рассматриваемой предметной области.
Между ЕСВ паттерном и архитектурным стилем МѴС1 [15]
существует определенное сходство. Так, сущности (entity) соот­
носятся с моделями (model), а граничные классы (boundary) —
с представлениями (view). Однако ECB-control сильно отлича­
ются от МѴС-контроллеров, поскольку управляющий класс ЕСВ
инкапсулирует бизнес-логику варианта использования, тогда
как МѴС-контроллер обрабатывает ввод данных пользовате­
лем, за который в ЕСВ отвечают граничные классы.
Использование ЕСВ подхода накладывает определенные
ограничения:
— действующие лица могут взаимодействовать только
с граничными классами (boundary);
— граничные классы могут взаимодействовать только
с действующими лицами (actor) и управляющими классами
(control);
— управляющие классы могут взаимодействовать с гранич­
ными и сущностными классами, и если необходимо, с другими
управляющими классами;
— сущностные классы могут знать другие сущностные клас­
сы и взаимодействовать только с управляющими классами.

6.2. Подготовка к работе
Для решения поставленной задачи сделайте следующие из­
менения в вашем проекте.
1. В пакет «Моделирование использования» добавьте подчи­
ненный пакет «Реализация вариантов использования».
2. В пакете «Реализация вариантов использования» добавьте
пустую диаграмму вариантов использования.
3. Перетащите на диаграмму действующих лиц и варианты
использования, которые вы будете реализовывать (в пределе
все, но в рамках учебного задания те, которые вы выделили
и описали в лабораторной работе 4).
1 Статья Википедии: Model-View-Controller. URL: https://ru.wikipedia.org/
wiki/Model-View-Controller

104
https://urait.ru


4. Добавьте на диаграмму из панели элементов столько
collaboration, сколько у вас размещено вариантов использования.
5. Свяжите каждую collaboration с соответствующим вари­
антом использованием отношением «реализация».
6. Назовите каждую collaboration также, как называется
связанный с ней вариант использования.
7. Назначьте каждой collaboration стереотип <<use case
realization> >. Если такого стереотипа нет, создайте его само­
стоятельно. В результате у вас должно получиться что-то подоб­
ное показанному на рис. 6.1.
8. Добавьте (если ранее вы еще этого не сделали) в контек­
сте проекта пакет «Модель приложения».
9. В пакете «Модель приложения» создайте пакет «Про­
граммные классы».
10. Перейдите на диаграмму, которую мы сделали выше,
и для каждой collaboration добавьте две диаграммы: sequence
diagram и class diagram.
11. Перед названием диаграммы классов добавьте префикс
ѴОРС (view only participating classes'). Диаграмма классов VOPC
иначе называется диаграммой робастности или пригодности.
Ее назначение заключается в идентификации потенциальных
объектов, необходимых для реализации варианта использования.

Рис. 6.1. Фрагмент диаграммы реализации вариантов использования

6.3. Реализация варианта использования

Основная задача объектно-ориентированного подхода
в анализе и проектировании приложений состоит в декомпозиции системы на специализированные классы, которые, взаи-

105

https://urait.ru


модействуя друг с другом, реализуют необходимую заинтересо­
ванным лицам функциональность надлежащего качества.
В качестве примера рассмотрим реализацию варианта ис­
пользования «Войти в систему». Ранее мы подготовили для это­
го варианта использования системную диаграмму последова­
тельности. Сейчас нам необходимо заменить объект Система
на набор объектов в соответствии с паттерном ЕСВ. Для реше­
ния этой задачи можно поступить следующим образом.
1. Проанализировать раскадровку варианта использования
и для каждого отдельного экрана добавить в модель соответ­
ствующий экрану граничный класс. Так для варианта исполь­
зования «Войти в систему» в ходе раскадровке были выделены:
стартовая страница, страница входа, страница с сообщением
об ошибке и страница участника программы лояльности. Сле­
довательно, можно сразу добавить в модель классы: MainPage,
LoginPage, MessagePage и UProfilePage. Для этого найдите па­
кет «Программные классы» и через команду Model element —>
Class контекстного меню добавьте новые классы и задайте
им соответствующие имена.
2. Для каждого граничного класса задать стереотип
<<boundary>>. Выделите класс в списке, вызовите контекст­
ное меню, выполните команду Stereotypes —> boundary.
3. Для каждого варианта использования нужно добавить,
как минимум один управляющий класс. Имя такого класса
следует образовывать из слов, характеризующих рассматри­
ваемый вариант использования, и таких слов, как Manager,
Handler, Controller, Dispatcher. В случае варианта использова­
ний «Войти в систему» управляющий класс можно именовать
как UserAccountManager.
4. Для каждого управляющего класса следует задать стере­
отип <<control>>. Выделите класс в списке, вызовите кон­
текстное меню, выполните команду Stereotypes —> control.
5. Проанализировать описание варианта использования
и спецификации системных операций и определить, какие
классы предметной области будут участвовать в реализации
конкретного варианта использования. Так в реализации ва­
рианта использования «Войти в систему» должен участвовать
класс «Участник программы». Для такого класса следует задать
стереотип <<entity>>.
6. Используя системную диаграмму последовательности, по­
лученную на предыдущем этапе работы (пятая лабораторная

Юб

https://urait.ru


работа), разработать подробную диаграмму последовательно­
сти, показывающую как программные классы реализуют каж­
дую системную операцию. Ниже представлен вариант такой
реализации (рис. 6.2).
: MamPagc

Участіте программы

□іегАссоигАЛзладсг

запрсснтъвходВСистемуО

Сплх* Го лих» оа тел е А

wc

loginTo$«tenX>

И----------

LogmPage

[ома попы, парой» не моны или не омарам опаэ от входа]
мстпДаниыаАвториаацииОшин

йпнд пароль elrrgi
________

1
^|

_ ..
.
checkLoglnfuurnamt password)

►

And U cerise rame. password)

Участим программа

*Уин!м

(логин и троль верны]

и. Участник программы
к-------------------------------

и Участим программы

getUærNamei)
jetSAlutehnnQ
«croate»

UProffePage
инисто но найдено

[иначе)

«create»

сосОчцает об ошибке и предлагает сделать выбор
аы6рат4№с*аие(Дейстауе

глеш декаде*

_

Лгпді

^м»еаАсасп^сіепі

С05СЦ
—Г
—г

X
[іыЛрйм отказ от мода)
гс<сао;)
нсуданая попытка охода

і

I
1
T
I
1
I
I
4
I
I
Г
I

Рис. 6.2. Диаграмма последовательности варианта использования
«Войти в систему»

программы

Рис. 6.3. УОРС диаграмма классов для варианта использования «Войти в систему»

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

https://urait.ru


анта использования, рассматривается в видеоуроках, ссылки
на которые представлены в приложении к практикуму.
Для лучшего понимания того, что представлено на деталь­
ной диаграмме последовательности, давайте подробно опишем
ход моделируемого сценария.
Участник программы (пользователь) открывает сайт про­
граммы лояльности. Загружается стартовая страница прило­
жения с набором разрешенных команд. Участник программы
выбирает опцию «Войти в систему». При реализации это мо­
жет быть кнопка, пункт меню, гиперссылка с соответствующим
именем команды.
Стартовая страница :MainPage обрабатывает это действие
пользователя и вызывает метод loginToSystem() экземпляра
управляющего класса UserAccountManager. В ответ на это со­
общение управляющий класс генерирует экземпляр страницы
входа :LoginPage. Страница входа ожидает действий пользовате­
ля. После получения команды подтверждения входа :LoginPage
передает введенные данные на проверку, вызывая метод
checkLogin() действующего экземпляра :UserAccountManager.
Экземпляр :UserAccountManager посылает запрос ЯпбизегО
на проверку наличия учетной записи пользователя с введенны­
ми именем пользователя и паролем в коллекцию :СписокПользователей.
В реальных условиях все будет немного сложнее. Как ми­
нимум небезопасно загружать в оперативную память список
пользователей с их данными для входа. Кроме того, объем
этих данных может быть просто впечатляющим. Вероятнее
всего, :UserAccountManager отправит запрос экземпляру дру­
гого управляющего класса, который отвечает за доступ к дан­
ным, например :DataManager. :DataManager в свою очередь
подключится к внешнему хранилищу данных и в случае удачи
возвратит экземпляр и:Участник программы. В нашем вари­
анте реализации сценария всю эту задачу выполняет коллек­
ция :СписокПользователей.
Если поиск завершается удачей, то выполняется ветка [ло­
гин и пароль верны]. :UserAccountManager получает ссылку
на объект и:Участник программы, получает все необходимые
данные и формирует страницу профиля участника программы.
Вариант использования на этом успешно завершается.
Если поиск завершается неудачей, то выполняется ветка
[иначе]. :UserAccountManager в этом случае генерирует со­

юз

https://urait.ru


общение :MessagePage с сообщением, что пользователя с вве­
денными данными не существует, и предложением завершить
вариант использования или повторить ввод данных для входа
в систему повторно. Если пользователь выбирает повтор ввода
данных, то отображается страница входа, и участник програм­
мы делает еще одну попытку входа в систему. В противном слу­
чае вариант использования завершается, и пользователь пере­
направляется на стартовую страницу.
Обратите внимание на искусственный прием разделения
системных и программных операций. Системные операции
именуются на русском языке и отражают действия и задачи
пользователя, т. е. относятся в большей степени к предметной
области рассматриваемой задачи. Программные операции уже
именуются на английском языке (или латиницей), что призва­
но отражать функции, которые система реализует, чтобы вы­
полнять задачи пользователя.
Программные операции создаются так же, как это было опи­
сано в предыдущей работе при определении системных опера­
ций. Если программная операция задана корректно, то у клас­
са, на входящей стрелке которого эта операция определена,
появляется соответствующая операция, как это показано на ди­
аграмме ѴОРС (см. рис. 6.3).
Чек-лист
□ Убедитесь, что создан пакет «Модель приложения».
□ Убедитесь, что создан пакет «Программные классы».
□ Убедитесь, что все новые программные классы размеще­
ны в пакете «Программные классы».
□ Убедитесь, что на диаграмме последовательности и (или)
ѴОРС присутствуют объекты всех трех типов классов ВСЕ.
□ Проверьте, что actor обмениваются сообщениями только
с граничными (boundary) классами.
□ Проверьте, что граничные классы получают сообщения
от внешних пользователей (actor) и передают их для обработки
только управляющим классами.
□ Убедитесь, что организацией, координацией и реализаци­
ей бизнес-логики занимаются управляющие (control) классы.
□ Убедитесь, что данные необходимые для реализации ва­
рианта использования предоставляются или сохраняются сущ­
ностными (entity) классами.

109

https://urait.ru


□ Проверьте, что ваша диаграмма последовательности де­
монстрирует логичный и непротиворечивый сценарий реали­
зации варианта использования.
Вопросы для самоконтроля
1. Что такое диаграмма последовательности? Какую задачу она
выполняет?
2. Какие типы программных классов предлагает использовать
паттерн ЕСВ?
3. Каких правил следует придерживаться при построении диаграммы
последовательности в рамках паттерна ЕСВ?
4. Каковы отличия паттерна ЕСВ от архитектурного стиля МУС?
5. Что означает аббревиатура УОРС?

https://urait.ru


ЛАБОРАТОРНАЯ РАБОТА № 7.
РАЗРАБОТКА МОДЕЛИ СОСТОЯНИЙ
Что нужно сделать в рамках данной лабораторной работы:
1) перечислить все объекты, для которых возможно изменение
значения атрибутов в ходе их жизненного цикла;
2) для одного или всех таких объектов построить диаграмму авто­
мата.

7.1. Введение

Язык UML предлагает несколько различных способов моде­
лирования поведения. Для описания взаимодействия с внеш­
ними действующими лицами используются диаграмма вариан­
тов использования и варианты использования. Для описания
взаимодействия между объектами используются диаграммы
последовательности или коммуникации. Для описания логики
исполнения отдельных операций классов или взаимодействия
вариантов использования используется диаграмма деятель­
ности. Поведение отдельного объекта можно представить как
последовательность смены его состояний в ответ на происхо­
дящие внешние и внутренние события. При этом в качестве
объекта может рассматриваться вся система в целом, какаято ее отдельная часть: подсистема, компонент, модуль или эк­
земпляр класса. Описание поведения объекта в этом случае ба­
зируется на хорошо известной концепции конечного автомата,
реализуемой в UML в виде диаграммы автоматов (англ, state
machine diagram).
Диаграмма автоматов — это граф, узлами которого явля­
ются состояния, а направленными дугами — переходы между
состояниями. Диаграмма автоматов описывает последователь­
ности состояний, вызываемые последовательностями событий.
Названия состояний должны быть уникальными в рамках диа-

іи
https://urait.ru


граммы. Все объекты класса следуют диаграмме состояний,
описывающей общее для них поведение. Диаграмма состояний
может быть реализована непосредственной интерпретацией
или преобразованием семантики в эквивалентный программ­
ный код [4].

7.2. Список объектов-кандидатов

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

112

https://urait.ru


«Действует», если текущая дата попадает в период между «На­
чалом действия» и «Концом действия», и «Не действует», если
текущая дата меньше «Начала действия» или больше «Конца
действия».
Дополнительным источником информации о состояниях мо­
делируемых объектов могут стать сценарии вариантов исполь­
зования, описывающие бизнес-логику приложения. Напри­
мер, при описании варианта использования «Создать учетную
запись» можно выделить такие состояния объекта «Участник
программы», как: «Регистрация», «На подтверждении», «Акти­
вен», «Аутентифицирован», «Не аутентифицирован», «Заблоки­
рован» и «Удален».
Результат предварительного анализа удобно свести в табли­
цу (табл. 7.1).
Таблица 7.1

Список объектов и их возможные состояния
№
п/п

Имя объ­
екта

1

Карта лояль­
ности

Действует, Заблокирована
Отрицательный баланс, Нулевой баланс, Поло­
жительный баланс

2

Вознаграж­
дение

Начислено, Использовано

3

Правило

Действует, Не действует

4

Участник
программы

Регистрация, На подтверждении, Активен, Аутен­
тифицирован, Не аутентифицирован, Заблокиро­
ван, Удален

Состояния объекта

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

7.3. Диаграммы автоматов
Для построения диаграмм автоматов в Visual Paradigm от­
кройте проект и загрузите диаграмму классов. На диаграмме
классов выберите тот класс, для которого будете строить диа­
грамму автоматов. Вызовите контекстное меню и выполните

113

https://urait.ru


команду: Sub Diagrams —> New Diagram и добавьте новую диа­
грамму автоматов (State Machine Diagram).
На экране отобразится пустая диаграмма с начальным псев­
досостоянием (Initial Pseudo State). Используя Resource Catalog
или палитру элементов, добавьте два состояния и дайте им со­
ответствующие названия: «Действует» и «Заблокирована». Со­
едините все состояния переходами согласно рис. 7.1.

Рис. 7.1. Диаграмма автомата объекта «Карта лояльности»

Будем считать, что при создании новой карты ее начальное
состояние будет «Действует». Это означает, что атрибут «Блоки­
рована» будет иметь значение «false». Чтобы отразить этот мо­
мент на диаграмме, выделите состояние «Действует», вызови­
те контекстное меню и выполните команду Open specification.
В выпадающем списке поля Entry выберите команду Create
Activity. В окне Activity specification в поле Name запишите вы­
ражение: self-Блокирована := false. Аналогично при переходе
в состояние «Заблокирована» значение атрибута «Блокирова­
на» меняется на «true».
Переход из состояния в состояние будет происходить в ре­
зультате возникновения соответствующего события, в част­
ности, когда владелец карты выполнит соответствующую
команду в своем профиле. Для отображения события на пере­
ходе вызовите контекстное меню и выполните команду Open
specification. В поле Name введите имя события, как показано
на рис. 7.1. Сохраните изменения.
На рис. 7.2 представлена возможная диаграмма автомата
для объекта типа «Вознаграждение». При начислении возна­
граждения значение атрибута «Использовано» по умолчанию

114
https://urait.ru


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

Рис. 7.2. Диаграмма автомата объекта «Вознаграждение»

На рис. 7.3 представлена диаграмма автомата объекта «Пра­
вило». Построение ее полностью аналогично, кроме того, как
заданы события на переходах. Давайте рассмотрим этот момент
немного подробнее. На переходе между состоянием «Действу­
ет» —> «Не действует» вызовите контекстное меню, перейдите
на вкладку Triggers, выполните команду Add —> Time event.
В редакторе Time Event Specification в поле Name задайте зна­
чение «Завершен период действия», а в поле When выражение
«Текущая дата > self. Конечная дата периода».

Рис. 7.3. Диаграмма автомата объекта «Правило»

115

https://urait.ru


Находясь в состоянии «Действует», мы можем продлевать
действие правила. Также мы можем реактивировать правило
после его деактивации путем смены конечной даты периода
действия. Аналогично мы можем менять начальную дату пери­
ода, переводя действующее правило в недействующее состоя­
ние, или сохраняя его в недействующем состоянии.
7.4. Интерактивная диаграмма автоматов

Диаграмму автомата для объекта «Участник программы»
построим с использованием программы MDriven Modeler [16].
В этом случае мы не только построим диаграмму, но и прове­
рим ее корректность в интерактивном режиме.
Откройте в MDriven Modeler ранее созданную диаграмму
классов. На диаграмме выделите нужный класс, в нашем слу­
чае это «Участник программы», и вызовите контекстное меню.
В контекстном меню выполните команду Add StateMachine
и подготовьте диаграмму, как показано на рис. 7.4.

» LU

На подтверждении

V

Удален <

> Активен

ѵ
Заблокирован

Рис 7.4. Заготовка диаграммы автомата объекта «Участник программы»

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

116
https://urait.ru


пользоваться ее возможностями. В противном случае учетная
запись переходит в состояние «Удален». Хотя в описании зада­
чи нет никаких указаний на возможность блокировки учетной
записи, в нашей модели мы предусмотрели это. Таким образом,
если определенный участник программы ведет себя некоррек­
тно, то его учетная запись может быть заблокирована. Впослед­
ствии учетная запись может быть разблокирована или удалена.
Отобразим все это на диаграмме и проверим, что автомат
действует, как и было задумано. Выделите линию перехода
между состояниями «Регистрация» и «На подтверждении».
В окне свойств перехода (в правой части экрана программы)
в поле Trigger введите событие: Зарегистрировать.
Аналогично выделите переход из состояния «Регистрация»
в само себя и задайте событие «Зарегистрировать», выбрав его
из выпадающего списка.
Расставьте на переходах события, как это показано на рис. 7.5.
Зарегистрировать

Зарегистрировать

Регистрация

Подтвердить

> Активен

На подтверждении

Разблокировать

Удалить

Удалить

Заблокировать

V

Удален <------------------------------------ Заблокирован

Рис. 7.5. Диаграммы автомата объекта «Участник программы». События

Обратите внимание, что на диаграмме классов у класса
«Участник программы» появился новый атрибут «State» и новые
методы, соответствующие заданным нами событиям (рис. 7.6).

Рис. 7.6. Измененная структура класса «Участник программы»

В принципе, мы уже можем проверить работу нашего авто­
мата, единственное, что будет нам мешать, это два одинаковых

117

https://urait.ru


перехода из состояния «Регистрация». Автомат не может одно­
временно находиться в двух разных состояниях. Поэтому не­
обходимо задать взаимоисключающие условия перехода. В тре­
тьей лабораторной работе для класса «Участник программы»
мы задавали ограничения на значения ряда атрибутов: ФИО,
email, пароль и дату рождения. Для простоты не будем рассма­
тривать соблюдение всех этих условий, а рассмотрим только
соблюдение условия по паролю.
Выделите переход между состояниями «Регистрация»
и «На подтверждении». В окне свойств перехода в поле Guard
откройте окно OCL-редактора и введите выражение: self.naроль.Length > = 6. В поле Effect добавьте действие на переходе:
ОтправитьЕтаіІ. В результате действия пользователю на ука­
занный при регистрации e-mail будет отправлено письмо с ин­
струкцией подтверждения регистрации.
Аналогично выделите переход между состояниями «Реги­
страция» и «Регистрация». В окне свойств перехода в поле
Guard откройте окно OCL-редактора и введите выражение: self.
Пароль.Length < 6. Результат представлен на рис. 7.7.
Зарегистрировать
[ 5еК.Пароль1епдЖ < 6 ]

Зарегистрировать
[ self.napoflb.Length > = 6 ]

/ОтправитьЕтаіІ

Регистрация

Подтвердить

> Активен

На подтверждении

А

Разблокировать

Удалить

Удалить

Удален <

Заблокировать

V

Заблокирован

Рис. 7.7. Диаграммы автомата объекта «Участник программы»
с условиями на переходе

Сохраните изменения в модели и запустите прототип мо­
дели, как мы это делали раньше в третьей лабораторной ра­
боте. Создайте новый объект участника программы (рис. 7.8).
Обратите внимание, что новый объект создается в состоянии
«Регистрация». Если теперь перейти на вкладку State и нажать
на кнопку Зарегистрировать, имитируя переход по событию,
то ничего не происходит. На самом деле срабатывает переход
из «Регистрация» в «Регистрация», так как мы не задали па­
роль, т. е. сработало условие: self.Пapoль.Length < 6.

118

https://urait.ru


Рис. 7.8. Тестируем автомат. Начальное состояние

Зададим пароль в соответствии бизнес-правилам и проте­
стируем наш автомат снова. Как можно видеть из рис. 7.9, со­
стояние объекта изменилось на «На подтверждении» и стали
доступны переходы в состояния «Активен» и «Удален».

Й ... -

□

Вознаграждения

State

х
<

*

subregion_O.Ha подтверждении

Подтвердить

Удалить

11

Show debugger

Close

Рис. 7.9. Тестируем автомат. В состоянии «На подтверждении»

Если мы выполним действие «Удалить», то автомат перей­
дет в конечное состояние. Если выполнить действие «Подтвер­
дить», то автомат переходит в состояние «Активен». Из состо­
яния «Активен» в соответствии с диаграммой можно перейти
в состояние «Заблокирован». Из состояния «Заблокирован»
можно вернуться в состояние «Активен» или перейти в конеч­
ное состояние «Удален».
Состояние «Активен» — это обычное рабочее состояние
учетной записи. При этом пользователь в любой момент време-

119

https://urait.ru


ни может быть аутентифицирован или не аутентифицирован.
Как это смоделировано в нашем случае? Очень просто! Пре­
вратим состояние «Активен» в составное и добавим в него еще
один маленький автомат.
Для этого выделите состояние «Активен», вызовите контекст­
ное меню и выполните команду Add region. Внутри региона до­
бавьте начальное псевдосостояние и два обычных состояния:
«Аутентифицирован» и «Не аутентифицирован». На переходе
между состояниями «Аутентифицирован» и «Не аутентифици­
рован» задайте триггер (событие): «Войти в систему», а на об­
ратном переходе: «Выйти из системы». Результат представлен
на рис. 7.10.
Зарегистрировать

[ $»И.ПарольЛ»пд(Ь < 6 ]

^4

Удален

Заблокирован

Рис 7.10. Диаграмма автомата объекта «Участник программы»

Сохраните изменения в модели и запустите прототип моде­
ли. Создайте новый объект «Участник программы» и протести­
руйте сделанные изменения.

7.5. Спецификация состояний
Состояния можно характеризовать несколькими способами.
Ниже приведены примеры спецификаций состояний для диа­
граммы автомата объекта «Участник программы».
Состояние: Регистрация.
Описание: поведение объекта в этом состоянии.
События, приводящие к данному состоянию: пользова­
тель инициировал процесс регистрации.
Условия, характеризующие данное состояние: пока не за­
полнены все обязательные поля; пока логин не соответствует

120

https://urait.ru


правилам формирования логина; пока пароль не соответствует
требованиям задания паролей.
События, возможные в данном состоянии:
Событие

Отклик

Следующее
состояние

Регистрация

Зарегистрировать [self-Пароль.
Length < 6]

Зарегистрировать [зеИ.Пароль.
Length >= 6]

ОтправитьЕтаіі

На подтверж­
дении

Состояние: На подтверждении.
Описание: объект заданное время ожидает подтверждения
активации учетной записи.
События, приводящие к данному состоянию: Зарегистри­
ровать.
Условия, характеризующие данное состояние: пока
не получено подтверждения активации или не прошло 24 часа
с момента регистрации.
События, возможные в данном состоянии:
Событие

Отклик

Следующее состояние

Подтвердить

—

Активен

Удалить

—

Удален

Состояние: Активен.
Описание: пользователю доступны все действия согласно
его правам, в частности, он может войти в систему.
События, приводящие к данному состоянию: Подтвер­
дить; Разблокировать.
Условия, характеризующие данное состояние: пока не за­
блокирована.
События, возможные в данном состоянии:
Событие

Заблокировать

Отклик

—

Следующее состояние

Заблокирован

Состояние: Заблокирован.
Описание: пользователю запрещен доступ в систему.
События, приводящие к данному состоянию: Заблокиро­
вать.
Условия, характеризующие данное состояние: учетная за­
пись помечена как «Заблокирована».

121
https://urait.ru


События, возможные в данном состоянии:
Событие

Отклик

Следующее состояние

Разблокировать

—

Активен

Удалить

—

Удален

Состояние: Удален.
Описание: объект помечен на удаление, никакие действия
невозможны.
События, приводящие к данному состоянию: Удалить.
Условия, характеризующие данное состояние: объект по­
мечен на удаление.
События, возможные в данном состоянии: нет.
Чек-лист
□ Убедитесь, что при описании состояний объекта вы на­
ходитесь на нужном уровне абстракции.
□ Проверьте, что выделены все свойства (атрибуты и пове­
дение), характеризующие данное состояние.
□ Убедитесь, что выделены значимые характеристики объ­
екта, которые меняются при переходе из одного состояния
в другое.
□ Проверьте, что диаграмма автомата построена с позиции
одного выбранного объекта.
□ Убедитесь, из одного состояния все переходы взаимои­
сключающие.
□ При использовании прототипа убедитесь, что поведение
объекта демонстрирует ту логику, что вы проектировали.
Вопросы для самоконтроля
1. Что такое состояние?
2. Какие виды состояний бывают?
3. Что такое событие?
4. Какие типы событий существуют?
5. С какой целью используются сторожевые условия?
6. В чем отличие действия от деятельности?
7. Что такое деятельности в состоянии? Какие типы деятельностей
бывают?
8. Что такое диаграмма автоматов? Какую задачу она выполняет?
9. Запишите сигнатуру перехода.

122

https://urait.ru


10. Возможны ли переходы без событий?
11. Равноценны ли деятельность на переходе и деятельность на входе
в состояние?
12. Какой вид деятельности нельзя прикрепить к переходу?
13. Что такое вложенное состояние?
14. Каким образом можно смоделировать вложенное состояние?

https://urait.ru


Список используемых источников
1. Черткова, Е. А. Программная инженерия. Визуальное
моделирование программных систем : учебник для вузов /
Е. А. Черткова. — 2-е изд., испр. и доп. — Москва : Издательство
Юрайт, 2021. — 147 с. — URL: https://urait.ru/bcode/471564 .
2. Проектирование информационных систем : учебник
и практикум для вузов / Д. В. Чистов, П. П. Мельников, А. В. Золотарюк, Н. Б. Ничепорук ; под общей редакцией Д. В. Чисто­
ва. — Москва : Издательство Юрайт, 2020. — 258 с. — URL:
https://urait.ru/bcode/450339.
3. Григорьев, М. В. Проектирование информационных си­
стем : учебное пособие для вузов / М. В. Григорьев, И. И. Гри­
горьева. — Москва : Издательство Юрайт, 2020. — 318 с. —
URL: https://urait.ru/bcode/451794.
4. Рамбо, Дж. UML 2.0. Объектно-ориентированное моде­
лирование и разработка / Дж. Рамбо, М. Блаха. — 2-е изд. —
Санкт-Петербург : Питер, 2007.
5. Спецификация OMG Unified Modeling Language™. Version
2.5.1. — URL: https://www.omg.Org/spec/UML/2.5.l/PDF.
6. Справочный ресурс no UML. — URL: https://www.umldiagrams.org.
7. Арлоу, Д. UML 2 и Унифицированный процесс. Практиче­
ский объектно-ориентированный анализ и проектирование :
перевод с английского / Д. Арлоу, И. Нейштадт. — 2-е изд. —
Санкт-Петербург : Символ-плюс, 2007. — 624 с., ил.
8. MDA® — The architecture of choice for a changing world. —
URL: https://www.omg.org/mda/index.htm.
9. Методическое пособие по созданию диаграммы клас­
са «Creating an ECO business model». — URL: https://yadi.sk/
i/lheYb3o4OONDEw
10. Грибачев, К. Г. Delphi и Model Driven Architecture. Раз­
работка приложений баз данных / К. Г. Грибачев. — СанктПетербург : Питер, 2004. — 348 с.
11. Методическое пособие по тестированию диаграммы
класса «Prototyping». — URL: https://yadi.Sk/i/d97z3qM92p-J5A.
124

https://urait.ru


12. Коберн, А. Современные методы описания функциональ­
ных требований к системам / А. Коберн. — Москва : Лори,
2014. — 264 с.
13. Вигерс, К. Разработка требований к программному обе­
спечению / К. Вигерс, Дж. Битти. — Санкт-Петербург : ВНѴ,
2020. — 736 с.
14. Ларман, К. Применение UML 2.0 и шаблонов проектиро­
вания: перевод с англ. / К. Ларман. — 3-є изд. — Москва : ООО
«И. Д. Вильямс», 2007.
15. Тузовский, А. Ф. Проектирование и разработка webприложений : учебное пособие для вузов / А. Ф. Тузовский. —
Москва : Издательство Юрайт, 2020. — 218 с.
16. Методическое пособие по созданию диаграммы авто­
матов «Creating a state machine». — URL: https://yadi.Sk/i/
JXetC5V9N53Gqw.

https://urait.ru


Наши книги можно приобрести:
Учебным заведениям и библиотекам:
в отделе по работе с вузами
тел.: (495) 744-00-12, e-mail: vuz@urait.ru

Частным лицам:
список магазинов смотрите на сайте urait.ru
в разделе «Частным лицам»

Магазинам и корпоративным клиентам:
в отделе продаж
тел.: (495) 744-00-12, e-mail: sales@urait.ru
Отзывы об издании присылайте в редакцию
e-mail: gred@urait.ru

Новые издания и дополнительные материалы доступны
на образовательной платформе «Юрайт» urait.ru,
а также в мобильном приложении «Юрайт.Библиотека»

Учебное издание
Галиаскаров Эдуард Геннадьевич,
Воробьев Алексей Сергеевич

АНАЛИЗ И ПРОЕКТИРОВАНИЕ
СИСТЕМ С ИСПОЛЬЗОВАНИЕМ UML
Учебное пособие для вузов

Формат 60x90 ’/іб.
Гарнитура «Charter». Печать цифровая.
Усл. печ. л. 7,81

ООО «Издательство Юрайт»
111123, г. Москва, ул. Плеханова, д. 4а.
Тел.: (495) 744-00-12. E-mail: izdat@urait.ru, www.urait.ru