Слайд 1Унифицированный язык моделирования UML
(продолжение)
Бессарабов Н.В.
bes@fpm.kubsu.ru
2008 г.
Слайд 2Диаграммы состояний (Statechart Diagram)
Существуют задачи (например, управление технологическими процессами
), для которых важны состояния системы, последовательность переходов между состояниями
и затрачиваемое время. В этих случаях целесообразно программу понимать как модель цифрового автомата, может быть с памятью.
В диаграммах состояний считается, что автомат в каждом из состояний находится сравнительно долго, а переходы между состояниями практически мгновенны.
Диаграммы состояний в UML описывают переходы между состояниями одного класса. Они могут описывать функциональность вариантов использования, акторов, операций и т. д.
Слайд 3Пример автомата
Хотя выход из строя не мгновенный и ремонт длительный
процесс, диаграмма имеет смысл.
Теоретически состояния могут быть и недостижимы. Достижимость
состояния это бинарное свойство отношения на графе.
Из-за распространенности и важности задач синтеза больших цифровых автоматов важно решать задачи их декомпозиции.
Слайд 4Свойства автомата без памяти
Автомат не запоминает историю смены состояний в
каждый момент, а может находиться в единственном состоянии (изначально автоматы
– это последовательные системы).
Хотя смена состояний автоматов происходит последовательно во времени, концепция времени в формализм не входит. Ни время нахождения в состоянии, ни время перехода не учитывается.
Число событий автомата конечно.
Не существуют изолированные состояния
Не должно быть конфликтующих переходов, т.е. переходов одновременно в несколько состояний, хотя параллельные автоматы в UML можно описывать.
Слайд 5Состояния
Изображение состояний
Очень часто при моделировании бизнеса приходится
работать с динамическими
объектами, для них нужно
уметь найти набор характеризующих инвариантов.
Для
записи действий применяется следующий синтаксис:
<метка_действия “/” выражение_действия>
Слайд 6Типовые метки
entry - указывает, что следующее за ней действие выполняется
в момент входа в данное состояние.
exit – метка действия после
завершения состояния.
do - выполняется в течение всего состояния
include - обращение к подавтомату, в остальных случаях метка действия может выбираться; обычно она характеризует переходы в подсостояния (частные состояния).
Слайд 7Пример 1. Состояния счета
снятие со счета (отри-
цательный баланс)
занесение на счет (по-
ложительный баланс)
проверка баланса (отрица-
тельный баланс в течение определенного числа дней)
Начальное состояние
Конечное состояние
Слайд 8Переходы. Простой переход (Simple transition)
Обозначает смену одного состояния другим.
Возможно,
переход совершается только при выполнении
заданных условий. Переход осуществляется в
результате
события (окончания выполнения деятельности – do activity),
после получения сигнала или сообщения. Если переход
по сигналу требует выполнения условия, то прописывают
сторожевое условие.
Переходы изображаются сплошной линией и помечаются
строкой текста, имеющей формат:
<сигнатура_события>“[”<сторожевое_условие>“]”
<выполнение_действия>
Слайд 9События
Формально событие -- это спецификация некоторого факта.
Семантика события концентрирует внимание
на внешних
проявлениях различных изменений моделируемой
сущности.
Пример события: поднятая телефонная
трубка.
Имя события обозначает отдельный переход на диаграмме
состояния, оно может содержать строку текста
(начинающуюся со строчной буквы), такое событие
называется триггерным. Если стрелка перехода не
обозначена строкой текста, - событие не триггерное; в конце
строки в круглых скобках можно записывать название
триггерного события.
Слайд 10Параллельные и последовательные состояния
Имеются последовательные подсостояния (sequential
substate) и параллельные
подсостояния (concurrent
substate). Параллельные состояния в программировании
реализуются очень часто.
Для обозначения параллельных состояний разделяют
составные состояния горизонтальными линиями.
Слайд 11Сложные состояния
Очень часто системы настолько сложны, что приходится
раскрывать состояние
через другие состояния, такое
состояние называется композитным (composite state).
Слайд 12Автоматы с памятью
Несмотря на то, что не каждый автомат имеет
память и
потому предыстория переходов учитывается не всегда,
исторические данные
бывают очень важны. Поэтому в
UML существуют исторические состояния (history
state), обозначаемые так
Исторические состояния применяются в контексте
составного состояния.
Замечание: На рисунке изображено давнее
историческое состояние
Слайд 13Исторические состояния
Недавнее историческое состояние должно быть первым подсостоянием в составном
состоянии и переход извне должен быть произведен в это историческое
состояние. При первом попадании в (H) оно пусто (не хранит истории), но в этот момент состояние изменяется. Когда подавтомат доходит до конечного состояния его историческое состояние теряет свое содержание.
Давнее историческое состояние (H*) отличается тем, что запоминает историю состояния и всех подсостояний любого уровня вложенности для текущего подавтомата.
Слайд 14Подсостояния
В практике важно учесть детали переходов между
составными состояниями.
a -
переход в подсостояние
b - переход в начальное состояние каждого из
подавтоматов
f и g - переходы из каждого из вложенных подсостояний
c - переход из подсостояния
h - переход между подсостояниями
join и fork не определяют синхронности в параллельных автоматах. f
a c
b d e g
Слайд 15Синхронизация
Переходы между параллельными состояниями могут
потребовать некоторой синхронизации.
Join
Fork
Переход Join сработает, если уже сработали переходы от
S1 до Sn. В Fork переход в состояния S1..Sn произойдет
одновременно.
Слайд 16Соединения и разветвления.
Синхронизация
Синхронизирующее состояние
Синхронизирующее состояние используется совместно с переходом-соединением или
с переходом-ветвлением и явно указывает события других подавтоматов, которые влияют
на поведение данного подавтомата
Слайд 19Диаграммы деятельностей.
(activity diagram)
Описывает динамический аспект, деятельность понимается
как некоторая последовательность
вычислений,
выполняемых автоматом, реализованным в виде
программы.
Каждая диаграмма деятельности имеет
единственное
начальное и единственное конечное состояние.
Начальное состояние –
Конечное состояние –
Слайд 20Состояние действия (action state)
Изображается следующим образом:
И заполняется, например, так:
x :=
x+1
составить план работ
При словесном описании состояние действия
используется глагол в
повелительном наклонении.
Фраза может быть псевдокодом и т.п.
Слайд 21Сложные действия
Для описания сложных действий может быть
использована декомпозиция в
состояния под-
деятельности (Subactivity State)
Слайд 22Пример диаграммы деятельностей: решение квадратного уравнения
Слайд 23Пример
диаграммы
деятельности
приготовле-ние
растворимого
кофе
Слайд 25Плавательные дорожки (продолжение)
Слайд 26Синхронизация параллельных действий
Слайд 27Диаграммы кооперации.
Collaboration Diagram
Взаимодействие элементов представляется двумя диаграммами -- последовательностей и
коопераций. Последовательности отражают временной аспект взаимодействия, а кооперации -- структурный.
Взаимодействуют классы, но в отличие от диаграммы классов на диаграмме коопераций изображают только взаимодействующие классы.
Так как в диаграмме кооперации отсутствуют временные оси, то последовательность сообщений передается с помощью порядковых номеров (при значительном количестве классов и ассоциаций отследить временной аспект на этой диаграмме невозможно, лучше пользоваться диаграммами последовательностей).
Слайд 28Диаграммы кооперации уровня спецификаций
Классы изображаются прямоугольниками, внутри – строка текста
в
формате:
“/” “:”
[“:”]
Могут указываться имена пакетов, перед которыми
стоит знак “::”, и
цепочек вложенных пакетов, разделяемых тем же знаком.
Пример:
Класс
Класс
Кооперация
Слайд 29Некоторые подробности
Если кооперация заключается в реализации
метода некоторого класса, то
символ кооперации
соединяется штриховой стрелкой обобщения с
классом, метод которого
используется.
Изображается символ кооперации, внутри которого
указывается информация о вызываемом классе.
:Платеж/
оформить_счет()
Слайд 30Подробности (продолжение)
Изображение объектов с указанием ролей.
Мультиобъект – это набор
объектов
на одном конце ассоциации,
изображается следующим образом:
Мултиобъект – это набор объектов на одном конце ассоциации, изображается следующим образом:
Слайд 31Активные и пассивные объекты
В UML выделяют две категории объектов:
-активные
-пассивные
Пассивный объект
может оперировать с данными, но не
может инициализировать другой объект.
Активный объект управляет другими объектами и имеет
свою собственную нить (thread).
В UML под нитью понимают поток управления внутри
вычислительного процесса.
Отличие процесса и нити в том, что нить использует часть
ресурсов системы и не может монополизировать какой-либо
ресурс.
Обычно, активные объекты выделяют более толстыми
линиями.
Слайд 32Пример с активными и пассивными объектами
1:принтер := выбрать()
2: печать(документ)
Слайд 33Использование составных объектов в диаграммах кооперации
В диаграммах кооперации используют
составные объекты, изображая их на поле вмещающего объекта.
Связь – это
экземпляр произвольной ассоциации, собственного имени не имеет.
На связи могут указывать стереотипы (например, self, local, global, parameter (параметр метода)).
Слайд 34Сообщения и акторы в диаграммах кооперации
Слайд 35Диаграмма компонентов.
(Component Diagram)
Программная система реализована в том случае, если
определен
набор исполняемых модулей, библиотек
классов и процедур, графических интерфейсов
пользователей,
файлов базы и т.д. Нужны специальные
диаграммы реализаций. Диаграмма компонентов
описывает физическую реализацию системы и
позволяет:
- показать наиболее общие черты структуры программной системы;
-дать спецификации исполняемого варианта;
-обеспечить повторное использование компонентов;
-представить концептуальную, логическую и физическую схемы базы.
Слайд 36Изображения компонентов
Компонент может иметь имя и быть представлен на
уровне
типа или экземпляра.
Могут указываться стереотипы, характеризующие
виды компонентов:
library
table
file
document
Слайд 37Компоненты могут обладать интерфейсами
Интерфейс
Слайд 38Компонент может реализовать свой интерфейс и может использовать интерфейс, реализуемый
другим компонентом
Клиент сервер
использует
Слайд 39Диаграммы последовательностей
На диаграмме последовательностей изображаются взаимодействующие между собой объекты, изображаемые
обычным способом. Вертикальные линии соответствуют оси времени, изображаются пунктиром –
object lifeline (линия жизни).
Если объект существует постоянно, его линия жизни находится на всей диаграмме. Уничтожение объекта изображается:
прерывает линию жизни
так изображается фокус управления объектом
– значит объект не пассивен
Слайд 40Сообщения между объектами
Сообщения – это в некотором смысле законченные фрагменты
информации. Один объект инициирует сообщения, другой получает.
Используются следующие виды сообщений:
вызов
процедур
простой поток управления
асинхронное сообщение
возврат из вызванной процедуры
Поток управления может разветвляться.
Стереотипы сообщений.
“call” – вызов операции или процедуры принимающего объекта.
“return” – возвращение результатов обработки сообщения
“create” – требование создать объект.
“destroy” - требование разрушить объект.
“send” – посылка сообщения объекту. Отличие в том, что такое сообщение должно быть явно описано в инициирующем классе.
Для описания временных ограничений используют фигурные скобки,
например, { время_ожидания <= 5 c }.
Слайд 41Пример диаграммы последовательностей
Слайд 42Пример диаграммы последовательностей
Слайд 43Пакеты, как средство работы с большими проектами
Пакеты представляют собой универсальное
средство для группирования
элементов моделей. Пакеты могут вкладываться друг в
друга и могут
содержать пакеты или элементы моделей. Проект в целом может
рассматриваться как один пакет верхнего уровня, в который вложены все
остальные составляющие части проекта. Пакет может иметь два графических
обозначения: полное и сокращенное. Сокращенное обозначение пакета
предназначено для обозначения пакета, входящего в состав другого пакета:
Слайд 44Пример пакета: многооконный графический редактор диаграмм
Слайд 45Диаграммы развертывания
Диаграммы развертывания показывают конфигурацию исполняемой
программной системы, состоящей
из программных компонентов, процессов,
объектов. Она состоит из узлов и
отношений взаимодействия между узлами и
компонентами. Узлы могут включать компоненты и объекты.
Слайд 46Описание примера
Представлен пример, состоящий из трех вычислительных систем, представляющих типичный
случай системы доступа к базам данным на основе Internet/Intranet технологии,
которая предполагает наличие двух компьютеров, один из которых выполняет функции web - сервера с возможностью исполнения ASP или CGI, который готовит данные для отображения на компьютере клиента. Для подготовки отображаемых данных web - сервер, в лице компонента Исполнение ASP программ, выполняет запросы к SQL - серверу, который хранит данные и обрабатывает их. Все это делается по запросу с клиентского компьютера и на него же посылаются результаты запросов в подготовленном для отображения виде ( HTML ).
Слайд 47Принцип Парето
Вильфредо Парето (1848-1923) сформулировал свой принцип
(называемый еще принципом
дисбаланса) для экономики, но
найденная закономерность работает и во многих
других областях.
Формулировка принципа Парето: Небольшая доля причин,
вкладываемых средств или прилагаемых усилий (например, 20%)
отвечает за большую долю результатов, получаемой продукции
или заработанного вознаграждения (например, 80%).
Примеры:
20% клиентов обеспечивают 80% прибыли;
20% ошибок обусловливают 80% потерь;
80% результатов достигается за 20% расходуемого времени.
Замечание: Не слишком придирайтесь к цифрам!
Слайд 48Зависимость важности UML-диаграмм от назначения программ
Системы реального времени.
Диаграммы:
классов
состояний
последовательностей
использования
компонентов
деятельности
размещения
объектов
взаимодействия
Web-системы.
Диаграммы:
классов
использования
последовательностей
состояний
компонентов
размещения
деятельности
взаимодействия
объектов
Результаты заимствованы
из [1]
Слайд 49Зависимость важности UML-диаграмм от назначения программ и UML-light
Результаты основаны на
[1]
Системы уровня
предприятия
Диаграммы:
классов
использования
последовательностей
деятельности
размещения
компонентов
состояний
взаимодействия
объектов
ИТОГ: UML-light
Диаграммы классов
Диаграммы использования
Диаграммы состояний
Диаграммы
последователь-
ностей
Диаграммы деятельности
“Минимальный” UML
Слайд 50Литература
20% UML, достаточные в 80% случаев
![Диаграммы кооперации уровня спецификацийКлассы изображаются прямоугольниками, внутри – строка текста в формате:“/” “:” [“:”]Могут указываться имена пакетов,](/img/thumbs/08ff2f1a8c0e3a94328923ad5f7ddfcb-800x.jpg "Унифицированный язык моделирования UML ( продолжение ) Диаграммы кооперации уровня спецификацийКлассы изображаются прямоугольниками, внутри – строка текста в")
![Зависимость важности UML-диаграмм от назначения программСистемы реального времени.Диаграммы:классовсостоянийпоследовательностейиспользованиякомпонентовдеятельностиразмещенияобъектоввзаимодействияWeb-системы.Диаграммы:классов использованияпоследовательностейсостоянийкомпонентовразмещениядеятельностивзаимодействияобъектовРезультаты заимствованы из [1]](/img/thumbs/b2af37a3c858bf515568a5fd9b5902f8-800x.jpg "Унифицированный язык моделирования UML ( продолжение ) Зависимость важности UML-диаграмм от назначения программСистемы реального времени.Диаграммы:классовсостоянийпоследовательностейиспользованиякомпонентовдеятельностиразмещенияобъектоввзаимодействияWeb-системы.Диаграммы:классов использованияпоследовательностейсостоянийкомпонентовразмещениядеятельностивзаимодействияобъектовРезультаты заимствованы из [1]")
![Зависимость важности UML-диаграмм от назначения программ и UML-light Результаты основаны на [1]Системы уровня предприятияДиаграммы:классов использования последовательностейдеятельностиразмещениякомпонентовсостоянийвзаимодействияобъектовИТОГ: UML-lightДиаграммы](/img/thumbs/daa42c68942b050bd05b86dc4a7b8ede-800x.jpg "Унифицированный язык моделирования UML ( продолжение ) Зависимость важности UML-диаграмм от назначения программ и UML-light Результаты основаны на")
