лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 43 из 62

Динамические модели объектно-ориентированных программных систем

Элементы динамических моделей:

• 
  автоматы;
  
• 
  взаимодействия.
  

Автомат (State machine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни.

Взаимодействие (Interaction) описывает поведение в терминах обмена сообщениями между объектами.

Автомат задает поведение системы как цельной, единой сущности, моделирует ЖЦ единого объекта. Автоматный подход применяют для формализации динамики отдельного трудного для понимания блока системы.

Взаимодействия — определяют поведение системы в виде коммуникаций между его частями (объектами). Взаимодействия - основной аппарат для фиксации полной динамики системы.

Автоматы отображают с помощью диаграмм схем состояний и диаграмм деятельности.

Взаимодействия отображают с помощью: диаграмм сотрудничества (кооперации) и диаграмм последовательности.

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

Конечный автомат — последовательность состояний в ходе существования объекта.

Последовательность состояний — ответ на события.

Диаграмма схем состояний показывает:

1. 
   набор состояний системы;
   
2. 
   события, которые вызывают переход из одного состояния в другое;
   
3. 
   действия, которые происходят в результате изменения состояния.
   

Состоянием называют период в жизни объекта, в течение которого объект:

• 
  удовлетворяет некоторому условию;
  
• 
  выполняет определенную деятельность;
  
• 
  ожидает некоторого события.
  

Состояние:

Переходы между состояниями:

Примеры событий:

Табл. 8. Пример событий

баланс<0 Изменение в состоянии помехи Сигнал (объект с именем) уменьшить(Давление) Вызов действия after (5 seconds) Истечение периода времени when (time=16:30) Наступление абсолютного момента времени

 

Примеры действий:

Табл. 9. Пример действий

Кассир.прекратитьВыплаты Вызов одной операции flt:=new(Фильтр); flt.убратьПомехи() Вызов двух операций send Ник.привет Посылка сигнала в объект Ник

Переход в начальное состояние:

Переход в конечное состояние:

Пример:

Рис. 45. Диаграмма схем состояний для системы охранной сигнализации

Действия в состояниях:

Условные переходы.

Между состояниями возможны различные типы переходов, инициируемые событием. Допускаются переходы без событий. Разрешены условные или охраняемые переходы.

Порядок выполнения условного перехода:

1. 
   происходит событие;
   
2. 
   вычисляется условие УсловиеПерехода;
   
3. 
   при УсловиеПерехода-true запускается переход и активизируется действие, в противном случае переход не выполняется.
   

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

Состояние действия считается атомарным (действие нельзя прервать) и выполняется за один квант времени, его нельзя подвергнуть декомпозиции. Для представления сложного действия, представленного рядом простых, используют состояние поддеятельности.

То есть, в данную вершину вписывается имя другой диаграммы, имеющей внутреннюю структуру.

Вспомогательные вершины:

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

Рис. 46. Диаграмма

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

Разновидности диаграммы взаимодействия:

1. 
   диаграмма последовательности;
   
2. 
   диаграмма сотрудничества.
   

Диаграмма последовательности — это диаграмма взаимодействия, которая выделяет упорядочение сообщений по времени.

Диаграмма сотрудничества — это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения.

Элементами диаграмм взаимодействия являются: объекты, связи, сообщения.

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

Рис. 47. Объект

Синтаксис представления имени имеет вид:

ИмяОбъекта: ИмяКласса

Табл. 10.

Адам:Человек Имя объекта и класса :Пользователь Только имя класса (анонимный объект) мойКомпьютер Только имя объекта (подразумевается, что имя класса известно) агент: Объект - сирота (подразумевается, что имя класса неизвестно)

Синтаксис представления свойства имеет вид:

Имя: Тип = Значение

Табл. 11.

номер:Телефон="7350-420" Имя, тип, значение активен=True Имя и значение

Связь между парой объектов — экземпляр ассоциации между их классами.

Связь между двумя объектами существует только тогда, когда имеется ассоциация между их классами. Неявно все классы имеют ассоциацию сами с собой, следовательно, объект может послать сообщение самому себе.

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

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

Табл. 12.

<> Объект-поставщик находится в глобальной области определеия <> Объект-поставщик находится в локальной области определеия объекта-клиента < > Объект-поставщик является параметром операции объекта-клиента <> Один и тот же объект является и клиентом, и поставщиком

Сообщение — это спецификация передачи информации между объектами в ожидании того, что будет обеспечена требуемая деятельность. Приём сообщения рассматривается как событие. Результатом обработки сообщения обычно является действие.

В языке UML моделируются следующие разновидности действий:

1. 
   Вызов — в объекте запускается операция.
   
2. 
   Возврат — возврат значения в вызывающий объект.
   
3. 
   Посылка (Send) — в объект посылается сигнал.
   
4. 
   Создание — создание объекта, выполняется по стандартному сообщению "create".
   
5. 
   Уничтожение — уничтожение объекта, выполняется по стандартному сообщению "destroy".
   

Синтаксис сообщений:

ВозврВеличина : ИмяСообщения (Аргументы)

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

Табл. 13.

коорд:=текущПоложение(самолетТ1) Вызов операции, возврат значения оповещение() Посылка сигнала установитьМаршрут(х) Вызов операции с действительным параметром <> Стандартное сообщение для создания объекта

Из сообщений формируется поток сообщений — последовательность управления. Общую форму управления задает процедурный или вложенный поток (поток синхронных сообщений).

Рис. 48. Поток сообщений

Все сообщения процедурной последовательности считаются синхронными.

Правило работы с синхронным сообщением: Передатчик ждет до тех пор, пока получатель не примет и не обработает сообщение.

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

Асинхронный поток управления — форма управления, при которой передатчик не ждет реакции от получателя сообщения.

Рис. 49. Асинхронный поток

Такой вид связи имеет семантику почтового ящика — получатель принимает сообщение по мере готовности, т.е. передатчик и получатель не синхронизируют свою работу.

Кроме линейных потоков управления можно моделировать итерации и ветвления.

*[i:=1..n]

1*[i:=1..4]:рисоватьСторонуПрямоугольника(i)

Таким образом, для формирования диаграммы сотрудничества выполняются следующие действия:

1. 
   отображаются объекты, которые участвуют во взаимодействии;
   
2. 
   рисуются связи, соединяющие эти объекты;
   
3. 
   связи помечаются сообщениями, которые посылают и получают выделенные объекты.
   

Рис. 50.Диаграмма сотрудничества

 

Рис. 51. Поток управления

В итоге формируется ясное визуальное представление потока управления (в контексте структурной организации сотрудничающих объектов).

Диаграммы последовательности (разновидность диаграмм взаимодействия):

• 
  отражают сценарий поведения в системе;
  
• 
  обеспечивает наглядное представление порядка передачи сообщений.
  

Графически диаграмма последовательности — разновидность таблицы, показывающая:

• 
  объекты, размещенные вдоль оси X,
  
• 
  сообщения, упорядоченные по времени вдоль оси У
  

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

Используются те же синтаксис и обозначения синхронизации, что и в диаграммах сотрудничества. Таким образом, обеспечивается визуальное представление потока управления во времени.

Отличия:

• 
  линия жизни объекта;
  
• 
  фокус управления.
  

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

Рис. 53.

Фокус управления — это высокий тонкий прямоугольник, отображающий период времени, в течение которого объект выполняет действие.

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

Замечания.

1. 
   Для отображения ветвления линия жизни может быть разделена на несколько параллельных линий жизни.
   
2. 
   Ветвление показывается множеством стрелок, идущих из одной точки. Каждая стрелка отмечается сторожевым условием.
   

Рис. 54.

Диаграммы Use Case:

• 
  определяют поведение системы с точки зрения пользователя;
  
• 
  главное средство для первичного моделирования динамики системы;
  
• 
  используются для выяснения требований к разрабатываемой системе.
  

Состав диаграмм Use Case:

• 
  актеры;
  
• 
  отношения;
  
• 
  зависимости;
  
• 
  обобщения;
  
• 
  ассоциации;
  
• 
  примечания и ограничения;
  
• 
  пакеты — для группировки элементов модели в крупные фрагменты.
  

Актеры и элементы Use Case:

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

Элементы Use Case представляют действия, выполняемые системой в интересах актеров

Рис. 55. Актер и элемент Use Case

Актер — это роль объекта вне системы, который прямо взаимодействует с ее частью — конкретным элементом (элементом Use Case ).

Различают актеров и пользователей.

Пользователь — это физический объект, который использует систему. Пользователь может играть несколько ролей и поэтому может моделироваться несколькими актерами.

Актером могут быть разные пользователи.

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

Между актером и элементом Use Case возможен только один вид отношения — ассоциация, отображающая их взаимодействие.

Рис. 56. Отношение между актером и элементом Use Case

Между актерами допустимо отношение обобщения.

Рис. 57. Отношение обобщения

То есть, экземпляр потомка может взаимодействовать с такими же разновидностями экземпляров элементов Use Case , что и экземпляр родителя.

Между элементами Use Case определены отношение обобщения и две разновидности отношения зависимости — включения и расширения.

Отношение обобщения фиксирует, что потомок наследует поведение родителя.

Рис. 58. Родитель-потомок

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

Отношение включения между элементами Use Case означает, что базовый элемент Use Саse явно включает поведение другого элемента Use Case в точке, которая определена в базе. Включаемый элемент Use Case никогда не используется самостоятельно — его конкретизация может быть только частью другого, большего элемента Use Case.

Рис. 59.

Таким способом можно отделить обязательное поведение от необязательного. Можно моделировать отдельные потоки, вставка которых в определенную точку управляется актером. Диаграмма Use Case , в которой использованы отношения включения и расширения:

Рис. 60.

 

Рис. 61.