ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 14.04.2021
Просмотров: 2416
Скачиваний: 4
3
Глава
1
.
Основные
сведения
о
языке
UML
Самое
лучшее
средство
–
это
большая
диаграмма
,
приколотая
к
стене
.
Даг
Скотт
1.1.
Цели
и
история
создания
языка
UML
Унифицированный
язык
моделирования
UML (Unified Modeling
Language)
–
это
преемник
того
поколения
методов
объектно
-
ориентированного
анализа
и
проектирования
,
которые
появились
в
конце
80-
х
и
начале
90-
х
годов
.
Создание
UML
фактически
началось
в
конце
1
994
г
.,
когда
Гради
Буч
и
Джеймс
Рамбо
начали
работу
по
объединению
их
методов
Booch [
Буч
-
1
999]
и
OMT (Object Modeling Technique)
под
эгидой
компании
Rational Software.
К
концу
1
995
г
.
они
создали
первую
спецификацию
объединенного
метода
,
названного
ими
Unified
Method,
версия
0.8.
Тогда
же
в
1
995
г
.
к
ним
присоединился
создатель
метода
OOSE (Object-Oriented Software Engineering)
Ивар
Якобсон
.
Таким
образом
, UML
является
прямым
объединением
и
унификацией
методов
Буча
,
Рамбо
и
Якобсона
,
однако
дополняет
их
новыми
возможностями
.
UML
находится
в
процессе
стандартизации
,
проводимом
консорциумом
OMG (Object Management Group),
в
настоящее
время
он
принят
в
качестве
стандартного
языка
моделирования
и
получил
широкую
поддержку
. UML
принят
на
вооружение
практически
всеми
крупнейшими
компаниями
–
производителями
программного
обеспечения
(Microsoft,
IBM, Hewlett-Packard, Oracle, Sybase
и
др
.).
Кроме
того
,
практически
все
мировые
производители
CASE-
средств
,
помимо
Rational Software (Rational
Rose),
поддерживают
UML
в
своих
продуктах
(Paradigm Plus (CA), System
Architect (Popkin Software), Microsoft Visual Modeler
и
др
.).
Полное
описание
UML
можно
найти
на
сайтах
http://www.omg.org
и
http://www.rational.com.
Первое
описание
UML
на
русском
языке
содержится
в
книге
[
Фаулер
-
1
999],
в
дальнейшем
изложении
терминология
языка
соответствует
данному
переводу
.
Кроме
него
,
имеются
также
переводы
[
Боггс
-2000], [
Буч
-2000]
и
[
Ларман
-200
1
].
4
1.2.
Средства
UML
Создатели
UML
представляют
его
как
язык
для
определения
,
представления
,
проектирования
и
документирования
программных
систем
,
организационно
-
экономических
систем
,
технических
систем
и
других
систем
различной
природы
. UML
содержит
стандартный
набор
диаграмм
и
нотаций
самых
разнообразных
видов
.
Стандарт
UML
версии
1
.
1
,
принятый
OMG
в
1
997
г
.,
предлагает
следующий
набор
диаграмм
для
моделирования
:
–
диаграммы
вариантов
использования
(use case diagrams)
–
для
моделирования
бизнес
-
процессов
организации
и
требований
к
создаваемой
системе
);
–
диаграммы
классов
(class diagrams)
–
для
моделирования
статической
структуры
классов
системы
и
связей
между
ними
;
–
диаграммы
поведения
системы
(behavior diagrams):
•
диаграммы
взаимодействия
(interaction diagrams):
♦
диаграммы
последовательности
(sequence diagrams)
и
♦
кооперативные
диаграммы
(collaboration diagrams)
–
для
моделирования
процесса
обмена
сообщениями
между
объектами
;
•
диаграммы
состояний
(statechart diagrams)
–
для
моделирования
поведения
объектов
системы
при
переходе
из
одного
состояния
в
другое
;
•
диаграммы
деятельностей
(activity diagrams)
–
для
моделирования
поведения
системы
в
рамках
различных
вариантов
использования
,
или
моделирования
деятельностей
;
–
диаграммы
реализации
(implementation diagrams):
•
диаграммы
компонентов
(component diagrams)
–
для
моделирования
иерархии
компонентов
(
подсистем
)
системы
;
•
диаграммы
размещения
(deployment diagrams)
–
для
моделирования
физической
архитектуры
системы
.
1.3.
Диаграммы
вариантов
использования
Понятие
варианта
использования
(use case)
впервые
ввел
5
Ивар
Якобсон
и
придал
ему
такую
значимость
,
что
в
настоящее
время
вариант
использования
превратился
в
основной
элемент
разработки
и
планирования
проекта
.
Вариант
использования
представляет
собой
последовательность
действий
(
транзакций
),
выполняемых
системой
в
ответ
на
событие
,
инициируемое
некоторым
внешним
объектом
(
действующим
лицом
).
Вариант
использования
описывает
типичное
взаимодействие
между
пользователем
и
системой
.
В
простейшем
случае
вариант
использования
определяется
в
процессе
обсуждения
с
пользователем
тех
функций
,
которые
он
хотел
бы
реализовать
.
Действующее
лицо
(actor) –
это
роль
,
которую
пользователь
играет
по
отношению
к
системе
.
Действующие
лица
представляют
собой
роли
,
а
не
конкретных
людей
или
наименования
работ
.
Несмотря
на
то
,
что
на
диаграммах
вариантов
использования
они
изображаются
в
виде
стилизованных
человеческих
фигурок
,
действующее
лицо
может
также
быть
внешней
системой
,
которой
необходима
некоторая
информация
от
данной
системы
.
Показывать
на
диаграмме
действующих
лиц
следует
только
в
том
случае
,
когда
им
действительно
необходимы
некоторые
варианты
использования
.
Действующие
лица
делятся
на
три
основных
типа
–
пользователи
системы
,
другие
системы
,
взаимодействующие
с
данной
,
и
время
.
Время
становится
действующим
лицом
,
если
от
него
зависит
запуск
каких
-
либо
событий
в
системе
.
Для
наглядного
представления
вариантов
использования
в
качестве
основных
элементов
процесса
разработки
программного
обеспечения
(
ПО
)
применяются
диаграммы
вариантов
использования
.
На
рис
.
1
.
1
показан
пример
такой
диаграммы
для
банкомата
(Automated Teller Machine, ATM).
На
данной
диаграмме
человеческие
фигурки
обозначают
действующих
лиц
,
овалы
–
варианты
использования
,
а
линии
и
стрелки
–
различные
связи
между
действующими
лицами
и
вариантами
использования
.
На
этой
диаграмме
показаны
два
действующих
лица
:
клиент
и
кредитная
система
.
Существует
также
шесть
основных
действий
,
выполняемых
моделируемой
системой
:
перевести
деньги
,
сделать
вклад
,
6
снять
деньги
со
счета
,
показать
баланс
,
изменить
идентификационный
код
и
осуществить
оплату
.
Снять
деньги
со
счета
Сделать
вклад
Перевести
деньги
Изменить
идентификационный
код
Показать
баланс
Клиент
Банковская
система
Осуществить
оплату
Рис
.
1
.
1
.
Пример
диаграммы
вариантов
использования
На
диаграмме
вариантов
использования
показано
взаимодействие
между
вариантами
использования
и
действующими
лицами
.
Она
отражает
требования
к
системе
с
точки
зрения
пользователя
.
Таким
образом
,
варианты
использования
–
это
функции
,
выполняемые
системой
,
а
действующие
лица
–
это
заинтересованные
лица
(stakeholders)
по
отношению
к
создаваемой
системе
.
Такие
диаграммы
показывают
,
какие
действующие
лица
инициируют
варианты
использования
.
Из
них
также
видно
,
когда
действующее
лицо
получает
информацию
от
варианта
использования
.
Данная
диаграмма
,
например
,
отражает
взаимодействие
между
вариантами
использования
и
действующими
лицами
системы
АТМ
.
В
сущности
,
диаграмма
вариантов
использования
иллюстрирует
требования
к
системе
.
В
нашем
примере
,
клиент
банка
инициирует
большое
количество
различных
вариантов
использования
: «
Снять
деньги
7
со
счета
», «
Перевести
деньги
», «
Сделать
вклад
», «
Показать
баланс
»
и
«
Изменить
идентификационный
код
».
От
варианта
использования
«
Осуществить
оплату
»
стрелка
указывает
на
Банковскую
систему
.
Действующими
лицами
могут
быть
внешние
системы
,
и
потому
в
данном
случае
Банковская
система
показана
именно
как
действующее
лицо
–
она
внешняя
для
системы
АТМ
.
Направленная
от
варианта
использования
к
действующему
лицу
стрелка
показывает
,
что
вариант
использования
предоставляет
некоторую
информацию
,
используемую
действующим
лицом
.
В
данном
случае
вариант
использования
«
Осуществить
оплату
»
предоставляет
Банковской
системе
информацию
об
оплате
по
кредитной
карточке
.
Все
варианты
использования
,
так
или
иначе
,
связаны
с
внешними
требованиями
к
функциональности
системы
.
Варианты
использования
всегда
следует
анализировать
вместе
с
действующими
лицами
системы
,
определяя
при
этом
реальные
задачи
пользователей
и
рассматривая
альтернативные
способы
решения
этих
задач
.
Действующие
лица
могут
играть
различные
роли
по
отношению
к
варианту
использования
.
Они
могут
пользоваться
его
результатами
или
могут
сами
непосредственно
в
нем
участвовать
.
Значимость
различных
ролей
действующего
лица
зависит
от
того
,
каким
образом
используются
его
связи
.
Конкретная
цель
диаграмм
вариантов
использования
–
это
документирование
вариантов
использования
(
всё
,
входящее
в
сферу
применения
системы
),
действующих
лиц
(
всё
вне
этой
сферы
)
и
связей
между
ними
.
Разрабатывая
диаграммы
вариантов
использования
,
старайтесь
придерживаться
следующих
правил
:
–
Не
моделируйте
связи
между
действующими
лицами
.
По
определению
действующие
лица
находятся
вне
сферы
действия
системы
.
Это
означает
,
что
связи
между
ними
также
не
относятся
к
её
компетенции
.
–
Не
соединяйте
сплошной
стрелкой
(
коммуникационной
связью
)
два
варианта
использования
непосредственно
.
Диаграммы
данного
типа
описывают
только
,
какие
варианты
использования
доступны
системе
,
а
не
порядок
их
выполнения
.
Для
отображения
порядка