ПКС / ПКС. Материалы лекций
.pdf
UML-диаграмма деятельности (Activity): использование нотации SDL |
51 |
(Specification and Description Language) |
start (начало)
;
|
<
>
stop (нормальное завершение)
end (аварийное завершение)
|
@startuml |
/ |
|Admin| |
|
start |
\\ |
:SDL_1; |
|
|User| |
] |
:SDL_2| |
|
split |
} |
:SDL_3< |
|
:SDL_4> |
|
stop |
|
split again |
|
:SDL_5/ |
|
:SDL_6\\ |
|
:SDL_7] |
|
:SDL_8} |
|
end |
|
end split |
|
@enduml |
Для представления блоков activity в UML 2 используется нотация SDL (язык спецификаций и описания): для информационных блоков указывается спецификатор < (см. SDL_3) для входящей информации и спецификатор > (см. SDL_4) для исходящей информации; для смешанных блоков указывается один из спецификаторов: ; | / \\ ] } (см. SDL_1, SDL_2, SDL_5, SDL_6, SDL_7, SDL_8).
UML-диаграмма деятельности (Activity): пример (начало) |
52 |
UML-диаграмма деятельности (Activity): пример (продолжение) |
53 |
|Admin| |
|Admin| |
@startuml |
|
start |
:Получение отчета |
skinparam activity{ |
|
:Подготовка файлов |
о запуске сервиса; |
fontSize 14 |
|
конфигурации сервиса; |
|Service| |
diamondFontSize 14 |
|
|Service| |
|
arrowFontSize 14 |
|
repeat:Конфигурирование\nсервиса; |
|
} |
|
:Запуск сервиса; |
|
UML-диаграмма деятельности (Activity): пример (окончание) |
54 |
repeat while (\nИнициализация\nкорректна?\n) is (Нет) not (Да) repeat:Обновление данных\nна сервисе;
Считывание\nуправляющих директив;
|Admin|
if(Есть ли\nдиректива\nостановки\nсервиса?) then (Да)
stop
else (Нет)
:switch(Код результата)
|Service|
case (\n 0)
endif
:Формирование отчета
:Передача управления
для администратора;
пользователю;
|Admin|
|User|
:Получение отчета
:Отправка запроса
о предупреждении
в Интернет-браузере;
в сервисе;
|Service|
|Service|
:Попытка выполнить
:Попытка исправления
запрос с критически
предупреждения
важными данными;
в сервисе;
case (\n\n <0)
:Фиксация ошибки
в сервисе;
case (\n >0)
:Формирование ответа пользователю;
|User|
:Отправка ответа в Интернет-браузер;
|Service|
:Фиксация корректной
работы сервиса;
endswitch
repeat while (Найдена ли\nошибка\nв работе\nсервиса?) is (Нет) not (Да)
:Остановка сервиса;
stop
@enduml
UML-диаграмма деятельности (Activity): пример |
55 |
UML-диаграмма состояний (State Machine) |
56 |
|
Диаграмма состояний (State Machine) определяет концепты (элементы представления знаний) для моделирования дискретных режимов работы системы, управляемой событиями на основе дискретной логики (необходимо перечислить все возможные варианты).
Основные элементы:
- state (состояние, объект-состояние) – объект, в котором определено поведение частей системы в виде конечного автомата;
-- entry / – действие при инициализации состояния;
-- do / – набор действий во время нормальной работы состояния; -- exit / – действие при завершении состояния.
Указывать entry/do/exit в общем случае необязательно.
Часто указывают несколько выполняемых функций: do[func1] / …. do[func2] / … либо func1 / … func2 /
- pseudostate (псевдосостояние) – состояние, предназначенное для выполнения или протоколирования определенного действия в системе или подсистеме:
-- initial state: начальное состояние; в PlantUML: [*]-->
-- final state: состояние выхода из системы / подсистемы (состояние нормального завершения); -->[*] H -- shallow history: состояние, которое возвращает последние действия в объекте-состоянии; [H]
H* -- deep history: состояние, которое возвращает все действия в объекте-состоянии; [H*]
-- entry point entry: состояние, ассоциированное c выполняемыми объектами-состояниями:
--- entry point : вход в объект-состояние: <<entryPoint>> в PlantUML; то же, что entry /
--- exit point : выход из объекта-состояния: <<exitPoint>> в PlantUML; то же, что exit /
--- junction : асинхронное объединение нескольких переходов в другое состояние;
--- choice : выбор действия; <<choice>> в PlantUML;
--- terminate : аварийное завершение состояния;
--- fork : разветвитель на несколько параллельно выполняемых действий;
--- join : синхронное объединение нескольких переходов в другое состояние.
UML-диаграмма состояний (State Machine): пример (начало) |
|
57 |
Блок 1
state
Блок 2
|
блоки 2 |
|
state |
и 3 |
|
|
выпол- |
Блок 3 |
няются парал-
лельно
pseudostate
UML-диаграмма состояний: пример (окончание) |
58 |
@startuml
'left to right direction
state Init as "Сервис включается"{ state InitEntry1 <<entryPoint>>
state InitReceive as "Инициализация данных"
<<sdlreceive>>
state InitChoice <<choice>>
state InitSettings as "Конфигурации" state InitRes as "Удаленные ресурсы" state InitExit1 <<exitPoint>>
state InitExit2 <<exitPoint>> InitEntry1 --> InitSettings InitEntry1 --> InitRes InitSettings -right--> InitRes InitSettings --> InitReceive InitRes --> InitReceive InitReceive --> InitChoice
InitChoice --> InitExit1 : [Нет ошибок загрузки]
InitChoice --> InitExit2 : [Есть ошибки загрузки]
}
state Run as "Сервис включен"{ state RunEntry1 <<entryPoint>>
state RunWork as "Нормальная работа" state RunWarning as "Предупреждение" state RunError as "Ошибка работы" state RunExit1 <<exitPoint>>
state RunExit2 <<exitPoint>>
RunEntry1 --> RunWork
RunWork -right--> RunWarning RunWork --> RunError RunWarning -left--> RunWork RunWarning -right--> RunError RunWork --> RunExit1 RunError --> RunExit2
}
state Final as "Сервис выключается"{ state FinalEntry1 <<entryPoint>> state FinalEntry2 <<entryPoint>>
state FinalWork as "Нормальное завершение" state FinalError as "Аварийное завершение"
FinalWork -right--> FinalError state FExit1 <<exitPoint>> state FExit2 <<exitPoint>>
FinalEntry1 --> FinalWork
FinalEntry2 --> FinalError FinalWork --> FExit1 FinalError --> FExit2
}
InitExit2 --> FinalEntry2
RunExit2 --> FinalEntry2 [*] --> InitEntry1 InitExit1 --> RunEntry1 RunExit1 --> FinalEntry1 FExit1 --> [*]
FExit2 --> [*] @enduml
UML-диаграмма состояний (пример) |
|
||
59 |
|||
|
|
|
|
|
|
|
|
|
|
|
|
UML-диаграмма профилей (Profile) |
|
60 |
Диаграмма профилей (Profile) определяет то, как программные компоненты в виде расширений с ограничениями относятся к базовой метамодели (высокоуровневой модели), – с целью адаптации такой метамодели к определенной платформе или области определения.
Основные элементы:
<<profile>> (профиль данных) может применяться в каждом отдельном случае, при этом необходимо определить любые требуемые взаимосвязи с метаклассами (высокоуровневыми классами) и/или метамоделями, если они содержат какие-либо стереотипы (конкретные типовые объекты); <<metaclass>> (метакласс, высокоуровневый класс; также называют «расширение» (extension)) определяет способность к «гибкому» добавлению (и впоследствии удалению) стереотипов в обобщающие классы;
<<stereotype>> (стереотип) определяет, каким образом существующий метакласс можно расширить; обеспечивает конкретное использование платформы или терминологии или нотации («системы обозначений»);
{required} (необходимая взаимосвязь) указывает на то, что экземпляр расширяющего стереотипа необходимо создать, если это возможно;
{strict} (строгая взаимосвязь) определяет, что правила фильтрации данных для метаклассов следует строго применять.