Материал: Лабораторные_Архитерктура ИС
33
Входное
действие
Входным
действием
(entry action)
называется
поведение
,
которое
выполняется
,
когда
объект
переходит
в
данное
состояние
.
В
примере
счета
в
банке
,
когда
он
переходит
в
состояние
«
Превышен
счет
»,
выполняется
действие
«
Временно
заморозить
счет
»,
независимо
от
того
,
откуда
объект
перешел
в
это
состояние
.
Таким
образом
,
данное
действие
осуществляется
не
после
того
,
как
объект
перешел
в
это
состояние
,
а
,
скорее
,
как
часть
этого
перехода
.
В
отличие
от
деятельности
,
входное
действие
рассматривается
как
непрерываемое
.
Входное
действие
также
показывают
внутри
состояния
,
ему
предшествует
слово
entry (
вход
)
и
двоеточие
.
Выходное
действие
Выходное
действие
(exit action)
подобно
входному
.
Однако
,
оно
осуществляется
как
составная
часть
процесса
выхода
из
данного
состояния
.
В
нашем
примере
при
выходе
объекта
Account
из
состояния
«
Превышен
счет
»,
независимо
от
того
,
куда
он
переходит
,
выполняется
действие
«
Разморозить
счет
».
Оно
является
частью
процесса
такого
перехода
.
Как
и
входное
,
выходное
действие
является
непрерываемым
.
Выходное
действие
изображают
внутри
состояния
,
ему
предшествует
слово
exit (
выход
)
и
двоеточие
.
Поведение
объекта
во
время
деятельности
,
при
входных
и
выходных
действиях
может
включать
отправку
события
другому
объекту
.
Например
,
объект
account (
счет
)
может
посылать
событие
объекту
card reader
(
устройство
чтения
карты
).
В
этом
случае
описанию
деятельности
,
входного
действия
или
выходного
действия
предшествует
знак
« ^ ».
Соответствующая
строка
на
диаграмме
выглядит
как
Do: ^
Цель
.
Событие
(
Аргументы
)
Здесь
Цель
–
это
объект
,
получающий
событие
,
Событие
–
это
посылаемое
сообщение
,
а
Аргументы
являются
параметрами
посылаемого
сообщения
.
Деятельность
может
также
выполняться
в
результате
получения
объектом
некоторого
события
.
Например
,
объект
account
может
быть
34
в
состоянии
Открыто
.
При
получении
некоторого
события
выполняется
определенная
деятельность
.
Переходом
(Transition)
называется
перемещение
из
одного
состояния
в
другое
.
Совокупность
переходов
диаграммы
показывает
,
как
объект
может
перемещаться
между
своими
состояниями
.
На
диаграмме
все
переходы
изображают
в
виде
стрелки
,
начинающейся
на
первоначальном
состоянии
и
заканчивающейся
последующим
.
Переходы
могут
быть
рефлексивными
.
Объект
может
перейти
в
то
же
состояние
,
в
котором
он
в
настоящий
момент
находится
.
Рефлексивные
переходы
изображают
в
виде
стрелки
,
начинающейся
и
завершающейся
на
одном
и
том
же
состоянии
.
У
перехода
существует
несколько
спецификаций
.
Они
включают
события
,
аргументы
,
ограждающие
условия
,
действия
и
посылаемые
события
.
Рассмотрим
каждое
из
них
в
контексте
примера
АТМ
.
События
Событие
(event) –
это
то
,
что
вызывает
переход
из
одного
состояния
в
другое
.
В
нашем
примере
событие
«
Клиент
требует
закрыть
»
вызывает
переход
счета
из
открытого
в
закрытое
состояние
.
Событие
размещают
на
диаграмме
вдоль
линии
перехода
.
На
диаграмме
для
отображения
события
можно
использовать
как
имя
операции
,
так
и
обычную
фразу
.
В
нашем
примере
события
описаны
обычными
фразами
.
Если
вы
хотите
использовать
операции
,
то
событие
«
Клиент
требует
закрыть
»
можно
было
бы
назвать
RequestClosure().
У
событий
могут
быть
аргументы
.
Так
,
событие
«
Сделать
вклад
»,
вызывающее
переход
счета
из
состояния
«
Превышен
счет
»
в
состояние
«
Открыт
»,
может
иметь
аргумент
Amount (
Количество
),
описывающий
сумму
депозита
.
Большинство
переходов
должны
иметь
события
,
так
как
именно
они
,
прежде
всего
,
заставляют
переход
осуществиться
.
Тем
не
менее
,
бывают
и
автоматические
переходы
,
не
имеющие
событий
.
При
этом
объект
сам
перемещается
из
одного
состояния
в
другое
со
скоростью
,
позволяющей
осуществиться
входным
действиям
,
деятельности
и
выходным
действиям
.
35
Ограждающие
условия
Ограждающие
условия
(guard conditions)
определяют
,
когда
переход
может
,
а
когда
не
может
осуществиться
.
В
нашем
примере
событие
«
Сделать
вклад
»
переведет
счет
из
состояния
«
Превышение
счета
»
в
состояние
«
Открыт
»,
но
только
если
баланс
будет
больше
нуля
.
В
противном
случае
переход
не
осуществится
.
Ограждающие
условия
изображают
на
диаграмме
вдоль
линии
перехода
после
имени
события
,
заключая
их
в
квадратные
скобки
.
Ограждающие
условия
задавать
необязательно
.
Однако
если
существует
несколько
автоматических
переходов
из
состояния
,
необходимо
определить
для
них
взаимно
исключающие
ограждающие
условия
.
Это
поможет
читателю
диаграммы
понять
,
какой
путь
перехода
будет
автоматически
выбран
.
Действие
Действием
(action),
как
уже
говорилось
,
является
непрерываемое
поведение
,
осуществляющееся
как
часть
перехода
.
Входные
и
выходные
действия
показывают
внутри
состояний
,
поскольку
они
определяют
,
что
происходит
,
когда
объект
входит
или
выходит
из
него
.
Большую
часть
действий
,
однако
,
изображают
вдоль
линии
перехода
,
так
как
они
не
должны
осуществляться
при
входе
или
выходе
из
состояния
.
Например
,
при
переходе
счета
из
открытого
в
закрытое
состояние
выполняется
действие
«
Сохранить
дату
закрытия
счета
».
Это
непрерываемое
поведение
осуществляется
только
во
время
перехода
из
состояния
«
Открыт
»
в
состояние
«
Закрыт
».
Действие
рисуют
вдоль
линии
перехода
после
имени
события
,
ему
предшествует
косая
черта
.
Событие
или
действие
могут
быть
поведением
внутри
объекта
,
а
могут
представлять
собой
сообщение
,
посылаемое
другому
объекту
.
Если
событие
или
действие
посылается
другому
объекту
,
перед
ним
на
диаграмме
помещают
знак
« ^ ».
Диаграммы
состояний
не
надо
создавать
для
каждого
класса
,
они
применяются
только
в
сложных
случаях
.
Если
объект
класса
может
36
существовать
в
нескольких
состояниях
и
в
каждом
из
них
ведет
себя
по
-
разному
,
для
него
может
потребоваться
такая
диаграмма
.
1.7.
Диаграммы
деятельности
В
отличие
от
большинства
других
средств
UML,
диаграммы
деятельностей
не
имеют
явно
выраженного
источника
в
предыдущих
работах
Буча
,
Рамбо
и
Якобсона
,
и
заимствуют
идеи
из
нескольких
различных
методов
,
в
частности
,
метода
моделирования
состояний
SDL
и
сетей
Петри
.
Эти
диаграммы
особенно
полезны
в
описании
поведения
,
включающего
большое
количество
параллельных
процессов
[
Фаулер
-
1
999].
Подобно
большинству
других
средств
,
моделирующих
поведение
,
диаграммы
деятельностей
обладают
определенными
достоинствами
и
недостатками
,
поэтому
их
лучше
всего
использовать
в
сочетании
с
другими
средствами
.
Самым
большим
достоинством
диаграмм
деятельностей
является
поддержка
параллелизма
.
Благодаря
этому
они
являются
мощным
средством
моделирования
потоков
работ
и
,
по
существу
,
параллельного
программирования
.
Самый
большой
их
недостаток
заключается
в
том
,
что
связи
между
действиями
и
объектами
просматриваются
не
слишком
четко
.
Эти
связи
можно
попытаться
определить
,
используя
для
деятельностей
метки
с
именами
объектов
,
но
этот
способ
не
обладает
такой
же
простой
непосредственностью
,
как
у
диаграмм
взаимодействия
.
Диаграммы
деятельностей
предпочтительнее
использовать
в
следующих
ситуациях
:
•
Анализ
варианта
использования
.
На
этой
стадии
нас
не
интересует
связь
между
действиями
и
объектами
,
а
нужно
только
понять
,
какие
действия
должны
иметь
место
и
каковы
зависимости
в
поведении
системы
.
Связывание
методов
и
объектов
выполняется
позднее
с
помощью
диаграмм
взаимодействия
.
•
Анализ
потоков
работ
(workflow)
в
различных
вариантах
использования
.
Когда
варианты
использования
взаимодействуют
друг
с
другом
,
диаграммы
деятельностей
являются
мощным
средством
представления
и
анализа
их
поведения
.
37
1.8.
Диаграммы
компонентов
Диаграммы
компонентов
показывают
,
как
выглядит
модель
на
физическом
уровне
.
На
них
изображены
компоненты
программного
обеспечения
и
связи
между
ними
.
При
этом
на
такой
диаграмме
выделяют
два
типа
компонентов
:
исполняемые
компоненты
и
библиотеки
кода
.
Каждый
класс
модели
(
или
подсистема
)
преобразуется
в
компонент
исходного
кода
.
После
создания
они
сразу
добавляются
к
диаграмме
компонентов
.
Между
отдельными
компонентами
изображают
зависимости
,
соответствующие
зависимостям
на
этапе
компиляции
или
выполнения
программы
.
На
рис
.
1
.
1
7
изображена
одна
из
диаграмм
компонентов
для
системы
АТМ
.
Card Reader
Cash Dispenser
ATM Screen
ATM.exe
Cash Dispenser
Card Reader
ATM Screen
Рис
.
1
.
1
7.
Диаграмма
компонентов
для
клиента
АТМ
На
этой
диаграмме
показаны
компоненты
клиента
системы
АТМ
.
В
данном
случае
система
разрабатывается
на
языке
С
++.
У
каждого
класса