SlideShare a Scribd company logo
1 of 13
Никифоров Д.И.
2014г.

 Диаграмма последовательности является одной из
разновидности диаграмм взаимодействия и предназначена
для моделирования взаимодействия объектов Системы во
времени, а также обмена сообщениями между ними.
 Одним из основных принципов ООП является способ
информационного обмена между элементами Системы,
выражающийся в отправке и получении сообщений друг от
друга. Таким образом, основные понятия диаграммы
последовательности связаны с понятием Объект и
Сообщение.
Диаграмма
последовательности

 На диаграмме последовательности объекты в основном представляют
экземпляры класса или сущности, обладающие поведением. В
качестве объектов могут выступать пользователи, инициирующие
взаимодействие, классы, обладающие поведением в Системе или
программные компоненты, а иногда и Системы в целом.
Объекты диаграммы

 Объекты располагаются с лева на права таким
образом, чтобы крайним с лева был тот объект,
который инициирует взаимодействие.
Неотъемлемой частью объекта на диаграмме
последовательности является линия жизни объекта.
Линия жизни показывает время, в течение которого
объект существует в Системе. Периоды активности
объекта в момент взаимодействия показываются с
помощью фокуса управления. Временная шкала на
диаграмме направлена сверху вниз.
Назначение и состав

 На диаграммах последовательности допустимо
использование стандартных стереотипов класса:
Стереотипы класса
Actor – экземпляр участника процесса (роль на диаграмме прецедентов)
Control – Класс-контроллер - активный элемент, который
используются для выполнения некоторых операций над объектами
(программный компонент, модуль, обработчик)

Стереотипы класса
 Boundary – Класс-Разграничитель - используется для
классов, отделяющих внутреннюю структуру системы от
внешней среды (экранная форма, пользовательский
интерфейс, устройство ввода-вывода). Объект со
стереотипом отличается от, привычного нам, класса
<<Интерфейс>>, который по большей части предназначен
для вызова методов класса, с которым он связан. Объект
boundary показывает именно экранную форму, которая
принимает и передает данные обработчику.
Entity – Класс-сущность - обычно применяется для
обозначения классов, которые хранят некую информацию о
бизнес-объектах (соответствует таблице или элементу БД)

Также одним из основных понятий, связанных
с диаграммой последовательности,
является Сообщение.
Сообщение

 На диаграмме деятельности выделяются сообщения, инициирующие
ту или иную деятельность или являющиеся ее следствием. На
диаграмме состояний частично показан обмен сообщениями в рамках
сообщений инициирующих изменение состояния объекта.
 Диаграмма последовательности объединяет диаграмму деятельности,
диаграмму состояний и диаграмму классов.
 Таким образом, на диаграмме последовательности мы можем увидеть
следующие аспекты:
 Сообщения, побуждающие объект к действию
 Действия, которые вызываются сообщениями (методы) – зачастую
это передача сообщения следующему объекты или возвращение
определенных данных объекта
 Последовательность обмена сообщениями между объектами
Аспекты диаграммы

Сообщения
 Прием сообщения инициирует выполнение определенных
действий, направленных на решение отдельной задачи тем
объектом, которому это сообщение отправлено. Сообщение
в большинстве случаев (за исключением диаграмм,
описывающих концептуальный уровень Системы) это
вызов методов отдельных объектов, поэтому для
корректного исполнения метода в сообщении необходимо
передать какие-то данные и определить, что мы хотим
видеть в ответ. При именовании сообщения на уровне
проектирования реализации системы в качестве имени
сообщения следует использовать имя метода.

Пример сообщения

 В UML различают следующие виды сообщений:
 синхронное сообщение (synchCall) - соответствует синхронному вызову
операции и подразумевает ожидание ответа от объекта получателя. Пока
ответ не поступит, никаких действий в Системе не производится.
 асинхронное сообщение (asynchCall) - которое соответствует асинхронному
вызову операции и подразумевает, что объект может продолжать работу, не
ожидая ответа.
 ответное сообщение (reply) – ответное сообщение от вызванного метода.
Данный вид сообщения показывается на диаграмме по мере необходимости
или, когда возвращаемые им данные несут смысловую нагрузку.
 потерянное сообщение (lost) – сообщение, не имеющее адресата сообщения,
т.е. для него существует событие передачи и отсутствует событие приема
 найденное сообщение (found) – сообщение, не имеющее инициатора
сообщения, т.е. для него существует событие приема и отсутствует событие
передачи
Виды сообщений
 Диаграммы последовательности предназначены для моделирования
взаимодействия между несколькими объектами. Зачастую диаграммы
последовательности создаются для моделирования взаимодействия в рамках
одного прецедента.
 На концептуальном уровне можно использовать диаграммы последовательности
для моделирования взаимодействия между Бизнес-актерами, но зачастую
подобные диаграммы обрастают лишними подробностями и плохо читаются. На
данном уровне лучше подойдут диаграммы деятельности, исключение составляют
случае, когда необходимо смоделировать обмен сообщениями между двумя
независимыми Системами.
 Также диаграммы последовательности подойдут для моделирования
взаимодействия пользователя и Системы в целом.
 На уровне детальной спецификации требований диаграммы последовательности
используются для моделирования взаимодействия компонентов Системы и
пользовательских классов в рамках выбранного прецедента.
 На уровне реализации с помощью диаграммы последовательности моделируется
взаимодействие между отдельными компонентами Системы. На данном уровне
детализации лучше подойдет диаграмма коммуникации.
Назначение диаграмм
последовательности
принцип построения диаграммы последовательности (24 32)

More Related Content

Similar to принцип построения диаграммы последовательности (24 32)

Sequence diagram
Sequence diagramSequence diagram
Sequence diagramaepetelin
 
tema1
tema1tema1
tema1comp
 
Введення Uml
Введення UmlВведення Uml
Введення Umlpogromskaya
 
о моделях
о моделяхо моделях
о моделяхserge_luch
 
Collaboration diagram
Collaboration diagramCollaboration diagram
Collaboration diagramaepetelin
 
лекция 6
лекция 6лекция 6
лекция 6cezium
 
Шаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLШаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLSergey Nemchinsky
 
лекция 7
лекция 7лекция 7
лекция 7cezium
 
лекция 7
лекция 7лекция 7
лекция 7cezium
 
Тема 3. Модели и закономерности систем
Тема 3. Модели и закономерности системТема 3. Модели и закономерности систем
Тема 3. Модели и закономерности системСергей Солнечный
 
лабораторная работа №4 Михалюк В.А.
лабораторная работа №4 Михалюк В.А.лабораторная работа №4 Михалюк В.А.
лабораторная работа №4 Михалюк В.А.Верочка Михалюк
 
Нотации оформления требований
Нотации оформления требованийНотации оформления требований
Нотации оформления требованийJaneKozmina
 
Классы и объекты в Java
Классы и объекты в JavaКлассы и объекты в Java
Классы и объекты в Javametaform
 
Диаграмма последовательности
Диаграмма последовательностиДиаграмма последовательности
Диаграмма последовательностиDEVTYPE
 
введение в объектно ориентированный анализ
введение в объектно ориентированный анализвведение в объектно ориентированный анализ
введение в объектно ориентированный анализMaksim Nikitin
 

Similar to принцип построения диаграммы последовательности (24 32) (20)

Sequence diagram
Sequence diagramSequence diagram
Sequence diagram
 
tema1
tema1tema1
tema1
 
Введення Uml
Введення UmlВведення Uml
Введення Uml
 
UML Glossary
UML GlossaryUML Glossary
UML Glossary
 
Uml Glossary
Uml GlossaryUml Glossary
Uml Glossary
 
о моделях
о моделяхо моделях
о моделях
 
8 (1)
8 (1)8 (1)
8 (1)
 
Collaboration diagram
Collaboration diagramCollaboration diagram
Collaboration diagram
 
лекция 6
лекция 6лекция 6
лекция 6
 
Шаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UMLШаблоны разработки ПО. Часть 2. ООП и UML
Шаблоны разработки ПО. Часть 2. ООП и UML
 
лекция 7
лекция 7лекция 7
лекция 7
 
лекция 7
лекция 7лекция 7
лекция 7
 
п2 04 05
п2 04 05п2 04 05
п2 04 05
 
Тема 3. Модели и закономерности систем
Тема 3. Модели и закономерности системТема 3. Модели и закономерности систем
Тема 3. Модели и закономерности систем
 
лабораторная работа №4 Михалюк В.А.
лабораторная работа №4 Михалюк В.А.лабораторная работа №4 Михалюк В.А.
лабораторная работа №4 Михалюк В.А.
 
Uml
UmlUml
Uml
 
Нотации оформления требований
Нотации оформления требованийНотации оформления требований
Нотации оформления требований
 
Классы и объекты в Java
Классы и объекты в JavaКлассы и объекты в Java
Классы и объекты в Java
 
Диаграмма последовательности
Диаграмма последовательностиДиаграмма последовательности
Диаграмма последовательности
 
введение в объектно ориентированный анализ
введение в объектно ориентированный анализвведение в объектно ориентированный анализ
введение в объектно ориентированный анализ
 

More from romachka_pole

защита информации (53)
защита информации (53)защита информации (53)
защита информации (53)romachka_pole
 
управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)romachka_pole
 
технология и отладка по (47)
технология и отладка по (47)технология и отладка по (47)
технология и отладка по (47)romachka_pole
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)romachka_pole
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)romachka_pole
 
технология Rational unified process (44)
технология Rational unified process (44)технология Rational unified process (44)
технология Rational unified process (44)romachka_pole
 
шаблоны проектирования (42)
шаблоны проектирования (42)шаблоны проектирования (42)
шаблоны проектирования (42)romachka_pole
 
Xp программирование (41)
Xp программирование (41)Xp программирование (41)
Xp программирование (41)romachka_pole
 
принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)romachka_pole
 
модульное программирование (35)
модульное программирование  (35)модульное программирование  (35)
модульное программирование (35)romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )romachka_pole
 
принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)romachka_pole
 
язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)romachka_pole
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)romachka_pole
 
этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)romachka_pole
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)romachka_pole
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)romachka_pole
 

More from romachka_pole (20)

защита информации (53)
защита информации (53)защита информации (53)
защита информации (53)
 
управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)управление конфигураций и документирование программного обеспечения (49)
управление конфигураций и документирование программного обеспечения (49)
 
технология и отладка по (47)
технология и отладка по (47)технология и отладка по (47)
технология и отладка по (47)
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)
 
метод Oracle (45)
метод Oracle (45)метод Oracle (45)
метод Oracle (45)
 
технология Rational unified process (44)
технология Rational unified process (44)технология Rational unified process (44)
технология Rational unified process (44)
 
шаблоны проектирования (42)
шаблоны проектирования (42)шаблоны проектирования (42)
шаблоны проектирования (42)
 
Xp программирование (41)
Xp программирование (41)Xp программирование (41)
Xp программирование (41)
 
принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)принципы проектирования интерфейса (37)
принципы проектирования интерфейса (37)
 
модульное программирование (35)
модульное программирование  (35)модульное программирование  (35)
модульное программирование (35)
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )диаграмма кооперации, реализации(25 26 33 34 )
диаграмма кооперации, реализации(25 26 33 34 )
 
принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)принцип построения диаграммы последовательности (24 32)
принцип построения диаграммы последовательности (24 32)
 
язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)язык Uml. диаграмма использования. (19)
язык Uml. диаграмма использования. (19)
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)
 
этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)этапы создания по при обьективном подходе( ) (16)
этапы создания по при обьективном подходе( ) (16)
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)
 
Case средства (16 17)
Case средства (16 17)Case средства (16 17)
Case средства (16 17)
 

принцип построения диаграммы последовательности (24 32)

  • 2.   Диаграмма последовательности является одной из разновидности диаграмм взаимодействия и предназначена для моделирования взаимодействия объектов Системы во времени, а также обмена сообщениями между ними.  Одним из основных принципов ООП является способ информационного обмена между элементами Системы, выражающийся в отправке и получении сообщений друг от друга. Таким образом, основные понятия диаграммы последовательности связаны с понятием Объект и Сообщение. Диаграмма последовательности
  • 3.   На диаграмме последовательности объекты в основном представляют экземпляры класса или сущности, обладающие поведением. В качестве объектов могут выступать пользователи, инициирующие взаимодействие, классы, обладающие поведением в Системе или программные компоненты, а иногда и Системы в целом. Объекты диаграммы
  • 4.   Объекты располагаются с лева на права таким образом, чтобы крайним с лева был тот объект, который инициирует взаимодействие. Неотъемлемой частью объекта на диаграмме последовательности является линия жизни объекта. Линия жизни показывает время, в течение которого объект существует в Системе. Периоды активности объекта в момент взаимодействия показываются с помощью фокуса управления. Временная шкала на диаграмме направлена сверху вниз. Назначение и состав
  • 5.   На диаграммах последовательности допустимо использование стандартных стереотипов класса: Стереотипы класса Actor – экземпляр участника процесса (роль на диаграмме прецедентов) Control – Класс-контроллер - активный элемент, который используются для выполнения некоторых операций над объектами (программный компонент, модуль, обработчик)
  • 6.  Стереотипы класса  Boundary – Класс-Разграничитель - используется для классов, отделяющих внутреннюю структуру системы от внешней среды (экранная форма, пользовательский интерфейс, устройство ввода-вывода). Объект со стереотипом отличается от, привычного нам, класса <<Интерфейс>>, который по большей части предназначен для вызова методов класса, с которым он связан. Объект boundary показывает именно экранную форму, которая принимает и передает данные обработчику. Entity – Класс-сущность - обычно применяется для обозначения классов, которые хранят некую информацию о бизнес-объектах (соответствует таблице или элементу БД)
  • 7.  Также одним из основных понятий, связанных с диаграммой последовательности, является Сообщение. Сообщение
  • 8.   На диаграмме деятельности выделяются сообщения, инициирующие ту или иную деятельность или являющиеся ее следствием. На диаграмме состояний частично показан обмен сообщениями в рамках сообщений инициирующих изменение состояния объекта.  Диаграмма последовательности объединяет диаграмму деятельности, диаграмму состояний и диаграмму классов.  Таким образом, на диаграмме последовательности мы можем увидеть следующие аспекты:  Сообщения, побуждающие объект к действию  Действия, которые вызываются сообщениями (методы) – зачастую это передача сообщения следующему объекты или возвращение определенных данных объекта  Последовательность обмена сообщениями между объектами Аспекты диаграммы
  • 9.  Сообщения  Прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Сообщение в большинстве случаев (за исключением диаграмм, описывающих концептуальный уровень Системы) это вызов методов отдельных объектов, поэтому для корректного исполнения метода в сообщении необходимо передать какие-то данные и определить, что мы хотим видеть в ответ. При именовании сообщения на уровне проектирования реализации системы в качестве имени сообщения следует использовать имя метода.
  • 11.   В UML различают следующие виды сообщений:  синхронное сообщение (synchCall) - соответствует синхронному вызову операции и подразумевает ожидание ответа от объекта получателя. Пока ответ не поступит, никаких действий в Системе не производится.  асинхронное сообщение (asynchCall) - которое соответствует асинхронному вызову операции и подразумевает, что объект может продолжать работу, не ожидая ответа.  ответное сообщение (reply) – ответное сообщение от вызванного метода. Данный вид сообщения показывается на диаграмме по мере необходимости или, когда возвращаемые им данные несут смысловую нагрузку.  потерянное сообщение (lost) – сообщение, не имеющее адресата сообщения, т.е. для него существует событие передачи и отсутствует событие приема  найденное сообщение (found) – сообщение, не имеющее инициатора сообщения, т.е. для него существует событие приема и отсутствует событие передачи Виды сообщений
  • 12.  Диаграммы последовательности предназначены для моделирования взаимодействия между несколькими объектами. Зачастую диаграммы последовательности создаются для моделирования взаимодействия в рамках одного прецедента.  На концептуальном уровне можно использовать диаграммы последовательности для моделирования взаимодействия между Бизнес-актерами, но зачастую подобные диаграммы обрастают лишними подробностями и плохо читаются. На данном уровне лучше подойдут диаграммы деятельности, исключение составляют случае, когда необходимо смоделировать обмен сообщениями между двумя независимыми Системами.  Также диаграммы последовательности подойдут для моделирования взаимодействия пользователя и Системы в целом.  На уровне детальной спецификации требований диаграммы последовательности используются для моделирования взаимодействия компонентов Системы и пользовательских классов в рамках выбранного прецедента.  На уровне реализации с помощью диаграммы последовательности моделируется взаимодействие между отдельными компонентами Системы. На данном уровне детализации лучше подойдет диаграмма коммуникации. Назначение диаграмм последовательности