для чего нужна диаграмма последовательности
Для чего нужна диаграмма последовательности
Обычно диаграмма последовательности используется для иллюстрации реализации вариантов использования (см. Рабочий продукт: Реализации вариантов использования), т.е. отражения взаимодействия объектов, соответствующего части или всему варианту использования. Взаимодействие объектов, воплощающее вариант использования, иллюстрируется одной или несколькими диаграммами последовательности. Обычно используется одна диаграмма для отражения основного потока событий и по одной для каждого отдельного подпотока варианта использования.
Диаграммы последовательности, в частности, важны при проектировании, т.к. они помогают уяснить роли объектов в потоке и, следовательно, предоставляют начальные данные для определения интерфейсов и назначений классов.
В отличие от диаграммы связей, диаграмма последовательности включает в себя хронологические последовательности, но не включает в себя информацию о взаимосвязи объектов. Диаграммы последовательности и диаграммы связей несут в себе аналогичную информацию, но представляют ее различными способами. Диаграммы последовательности показывают явные последовательности сообщений и хорошо подходят для наглядного представления хронологического порядка сообщений. Если вас интересуют структурные отношения между взаимодействующими экземплярами, используйте диаграммы связей. См. Метод: Диаграмма связей.
Содержание диаграммы последовательности
В диаграмме последовательности показываются экземпляры объектов и субъектов, а также сообщения, описывающие их взаимодействие. Диаграмма описывает происходящее в объектах-участниках (в форме активаций) и взаимодействие объектов посредством обмена сообщениями. Для каждой версии потока событий варианта использования можно сделать отдельную диаграмму.
Диаграмма последовательности, описывающая часть потока событий варианта использования Обслуживание местного звонка для телефонного коммутатора.
Объекты
Объект изображается в виде вертикального штрихового пунктира («генеральная линия»). Генеральная линия указывает на существование объекта в определенное время. Символ объекта рисуется в начале генеральной линии. Имя объекта и его класс выделяются подчеркиванием и разделяются двоеточием:
В диаграмме последовательности объекты можно использовать следующим образом:
Субъекты
Обычно экземпляр субъекта представляется первой (самой левой) генеральной линией диаграммы последовательности, как вызывающий взаимодействие. Если в диаграмме имеется несколько субъектов, размещайте их все ближе к краю (либо левому, либо правому).
Сообщения
Сообщение является способом связи между объектами, которые передают информацию, ожидая, что после последует действие. В диаграммах последовательности сообщение показывается как сплошная горизонтальная стрелка от генеральной линии одного объекта к генеральной линии другого. В случае посылки объектом сообщения самому себе, стрелка может начинаться и заканчиваться на одной и той же генеральной линии. Стрелка помечается названием сообщения и значениями его аргументов. Для отражения последовательности сообщений во взаимодействии в целом стрелка также может помечаться порядковым номером. На диаграммах последовательности, для которых положение стрелок показывает их последовательность относительно друг друга, порядковые номера часто опускаются
Сообщение может быть свободным, т.е. иметь в качестве имени общее описание сообщения и не соответствовать какой-либо конкретной операции объекта, принимающего сообщение. Поставить в соответствие такому сообщению операцию целевого объекта можно позже. Соответственно, имя сообщения станет равным имени операции.
Сценарии
Сценарий содержит текстуальное описание потока событий.
Размещайте сценарии слева от генеральных линий, так, чтобы можно было анализировать весь поток сверху вниз (см. рисунок выше). Сценарии можно прикреплять к сообщениям, что в случае перемещения сообщения также приведет к перемещению сценария.
Распределение управляющего потока в диаграмме последовательности
Централизованное управление потоком событий или его частью означает, что поток контролируется несколькими объектами путем посылки командных и получения ответных сообщений от остальных объектов. Контролирующие объекты определяют порядок активации других объектов в варианте использования. При этом взаимодействие остальных объектов сведено к минимуму или вообще отсутствует.
В варианте использования системы утилизации, Печать ежедневного отчета, отслеживается, среди прочего, число и тип возвращаемых объектов, а затем фиксируется итоговая информация. Контролирующий объект Генератор отчетов определяет порядок, в котором будут извлекаться и записываться суммы.
Поведение варианта использования Печать ежедневного отчета сосредоточено в объекте Генератор отчетов.
Это пример централизованного управления. В данном случае используется такая структура прежде всего из-за того, что различные фазы потока событий взаимонезависимы. Главным преимуществом такого подхода является то, что объекты не должны следить за итогами следующего объекта. Для изменения порядка фаз необходимо сделать соответствующие изменения только в управляющем объекте. Кроме того, аналогичным образом можно добавить новую фазу, например, при появлении нового типа возвращаемого объекта. Другим преимуществом централизованной структуры является простота повторного использования фаз в других вариантах использования, т.к. логика сортировки не встроена в сами объекты.
Децентрализованное управление означает, что объекты-участники обмениваются сообщениями между собой непосредственно, без участия контролирующих объектов.
Вариант использования Отправка письма отражает посылку письма в другую страну через почтовое отделение. Сначала письмо посылается в страну адресата. В ней оно направляется в указанный город. В городе, в свою очередь, оно доставляется домой адресату.
Поведение варианта использования Отправка письма децентрализованное.
Подходящий тип поведения зависит от приложения. Вообще, следует стремиться создавать независимые объекты, т.е. передавать различные задачи объектам, наиболее подходящим для их выполнения.
Потоку событий с централизованным управлением соответствует «вилообразная» диаграмма последовательности, тогда как прямолинейная диаграмма последовательности свидетельствует о децентрализованном управлении.
Потоку событий с централизованным управлением соответствует «вилообразная» диаграмма последовательности. Потоку событий с децентрализованным управлением соответствует прямолинейная диаграмма последовательности.
Поведенческая структура реализации варианта использования чаще всего является смесью централизованной и децентрализованной.
Децентрализованная структура подходит для следующих случаев:
Централизованная структура подходит для следующих случаев:
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Виды диаграмм UML
Диаграмма последовательностей (sequence diagram)
Только что мы познакомились с диаграммой объектов, которая показывает отношения между объектами в некоторый момент времени, т. е. предоставляет нам снимок состояния системы, являясь статической. Диаграмма же последовательностей отображает взаимодействие объектов в динамике. Что значит «в динамике»? Как раз с этим нам и предстоит разобраться.
В UML взаимодействие объектов понимается как обмен информацией между ними. При этом информация принимает вид сообщений. Кроме того, что сообщение несет какую-то информацию, оно некоторым образом также влияет на получателя. Как видим, в этом плане UML полностью соответствует основным принципам ООП, в соответствии с которыми информационное взаимодействие между объектами сводится к отправке и приему сообщений.
Диаграмма последовательностей относится к диаграммам взаимодействия UML, описывающим поведенческие аспекты системы, но рассматривает взаимодействие объектов во времени. Другими словами, диаграмма последовательностей отображает временные особенности передачи и приема сообщений объектами.
Поскольку текст предыдущего абзаца, может быть, не слишком хорошо воспринимается на слух, да и лучше, как известно, «один раз увидеть, чем сто раз услышать», приведем пример диаграммы последовательностей (рис. 2.12):
А вот что описывает следующая диаграмма (рис. 2.13), попробуйте догадаться самостоятельно. Только, чур, не подсматривать в нижеследующий текст лекции!
Узнаете свой мобильный?
Диаграмма взаимодействия (кооперации, collaboration diagram)
Но давайте же, наконец, перейдем к примерам (рис. 2.15):
Как видите, эта диаграмма описывает (очень грубо) работу персонала библиотеки по обслуживанию клиентов: библиотекарь получает заказ от клиента, поручает сотруднику найти информацию по нужной клиенту книге, а после получения данных поручает еще одному сотруднику выдать книгу клиенту. Разобрались? Тогда еще пример (рис. 2.16):
Надеемся, что и эта диаграмма не смогла поставить вас в тупик. Скорее всего, она описывает процесс управления учебными курсами (очевидно, путем создания их из готовых модулей) для некоего учебного центра. Как видите, все просто!
И, наконец, еще один пример (рис. 2.17), который должен вызвать легкое «дежавю» у внимательного читателя.
Проектирование программного обеспечения
Диаграмма вариантов использования (use case diagram)
Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью, так называемых прецедентов. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.
Диаграмма классов (class diagram)
Диаграмма классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру (поля, методы…) и типы отношений (наследование, реализация интерфейсов … ). На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. На этом этапе принципиально знание ООП подхода и паттернов проектирования.
Диаграмма состояний (statechart diagram)
Главное предназначение этой диаграммы — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Диаграмма последовательности (sequence diagram)
Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.
Диаграмма кооперации (collaboration diagram)
На диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации.
В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии.
Диаграмма компонентов (component diagram)
Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Диаграмма развертывания (deployment diagram)
Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Те компоненты, которые не используются на этапе исполнения, на диаграмме развертывания не показываются.
Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации. Эта диаграмма, по сути, завершает процесс ООАП для конкретной программной системы и ее разработка, как правило, является последним этапом спецификации модели.
На этом закончим обзорный экскурс по диаграммам в частности и проектированию в общем. Стоит отметить, что процесс проектирования уже давно стал стандартом разработки ПО, но часто приходится сталкиваться с великолепно написанной программой, которая из за отсутствия нормальной документации обрастает ненужным побочным функционалом, костылями, становится громоздкой и теряет былое качество. =(
Я убежден, что программист в первую очередь это кодер – он НЕ должен общаться с заказчиком, НЕ должен задумываться об архитектуре системы, не должен изобретать интерфейс к программе, он только должен кодировать – реализовывать алгоритмы, функционал, внешний вид, юзабилити, но не более…. Проектировщик же должен начиная от абстрактных диаграмм (описывающих предметную область) до диаграмм представляющих структуру данных, классов и процессов их взаимодействия, детально шаг за шагом все расписать. То есть сложность работы и зарплата проектировщика должна быть на порядок выше чем у программиста == кодера. Простите за крамолу.
Уточняем описание функций системы с помощью диаграммы Sequence
Уточняем описание функций системы с помощью диаграммы Sequence (продолжение «Белки»)
В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.
В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].
Для начала поясню, что мы будем детализировать.
В 1-ой части статьи «От моделирования процессов к проектированию автоматизированной системы» мы моделировали процессы «сказочной» предметной области — строчки про белку из «Сказки о царе Салтане» А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.
Рисунок 1. Связь требования и функции
Теперь мы хотим уточнить информацию о выполнении данной автоматизируемой функции:
Основными элементами диаграммы Sequence являются взаимодействующие объекты с различными стереотипами и связи между ними — взаимодействующие объекты обмениваются между собой некоторой информацией (Рисунок 2).
Рисунок 2. Основные элементы Sequence диаграммы
Объекты расположены в горизонтальной последовательности, между ними передаются сообщения. Ось времени ориентирована сверху вниз.
Элемент Actor может использоваться для представления пользователя, инициирующего поток событий.
Каждый объект имеет пунктирную линию, называемую «линией жизни», где этот элемент существует и потенциально принимает участие во взаимодействиях. Фокус управления обозначается прямоугольником на линии жизни объекта.
Сообщения, которыми обмениваются объекты, могут быть нескольких типов, сообщения также могут быть настроены для отражения операций и свойств исходного и целевого элементов.
Стереотипные элементы, такие как границы (Boundary), элементы управления (Control) и сущности (Entity), могут использоваться для моделирования пользовательского интерфейса (GUI), контроллеров и элементов базы данных, соответственно.
Повторяющийся поток обмена сообщениями может быть обозначен как фрагмент с типом «loop».
Итак, мы планируем уточнить описание функции «Добавить в ведомость информацию о новом орехе».
Договоримся о следующих дополнительных обобщениях и допущениях.
Диаграмма, построенная с учетом этих допущений, приведена на Рисунке 4.
Рисунок 4. Уточнение описания функции «Добавить в ведомость информацию о новом орехе»
О применении других видов диаграмм UML можно почитать здесь:
Основы UML. Диаграммы последовательности
Диаграммы последовательности ( sequence diagram ) являются видом диаграмм взаимодействия языка UML, которые описывают отношения объектов в различных условиях. Условия взаимодействия задаются сценарием, полученным на этапе разработки диаграмм вариантов использования [1]. Существуют различные взгляды на применение этого вида диаграмм:
Рассмотрим этот вид диаграмм на примере главной последовательности сценария добавления ученика в систему:
Пример: диаграмма последовательности сценария добавления ученика в систему тестирования
По приведенной диаграмме можно проследить следующие правила построения:
Кроме того, на ней показаны три основных вида стрелок (сообщений):
При построении диаграммы последовательности обязанности распределяются между объектами (и классами), например мы решили, что база данных будет выступать в роли модели и уведомлять своих подписчиков об изменениях, однако эту же роль мог выполнить объект экрана добавления студента. Внести изменения в диаграмму значительно проще, чем в исходный код. Буч строит этот вид диаграмм сразу после описания вариантов использования, при этом он решает сразу две задачи — выделяет объекты и распределяет между ними ответственность, однако в процессе ICONIX к диаграммам последовательности переходят после построения диаграмм пригодности, т.е. уже выделены объекты, необходимые для реализации прецедента. Процесс построения при этом сводится к четырем шагам:
В нашем случае на диаграмме был оставлен контроллер, т.е. введен новый управляющий объект отображения уведомления о том, что студент был добавлен в базу. Мы, конечно, могли бы добавить этот функционал в виджет главного меню (наиболее простое решение), введение дополнительного объекта не только является более гибким решением, но и позволит снять с меню лишние обязанности, т.е. сделать код более чистым с точки зрения принципа единой обязанности — SRP [6].
Видно, что приведенная диаграмма очень хорошо отражает взаимодействие объектов, однако прецеденты могут содержать предусловия (требования, которые должны быть выполнены для начала выполнения действий прецедента) — они могут быть показаны при помощи механизма использования взаимодействий. Этот механизм позволяет указать что повторно используется какое-либо взаимодействие, определенное в другом месте, изображается с помощью метки ref. Так, можно показать, что до выполнения прецедента учитель должен войти в систему (выполнить прецедент login) и открыть окно главного меню:
Механизм использования взаимодействий диаграмм последовательности (метка ref)
Фреймы взаимодействия могут использоваться для изображения параллельных секций, при этом часть сообщений рисуются внутри фрейма par, так например, мы могли бы показать, что база данных уведомляет параллельно всех трех подписчиков и все они параллельно и независимо друг от друга начинают работать:
Пример использования фрейма взаимодействия par
Существуют также фреймы для изображения условных конструкций (alt, opt), циклов (loop) и критических секций (critical). Ветвление при этом использовать не рекомендуется, т.к. для изображения деталей алгоритмов в языке UML есть диаграммы деятельности, а Фаулер в таких случаях даже считает также обоснованным использование псевдокода.
Фаулер рекомендует строить диаграммы последовательностей не только при проектировании, но и на этапе рефакторинга если требуется заменить централизованную обработку децентрализованной (более гибкой), т.к. этот вид диаграмм является лучшим способом распределения обязанностей. Также, они часто используются при объяснении каких-либо деталей проекта другим участникам, т.к. этот вид диаграмм быстро строится с нужной степенью детализации на маркерной доске. На следующем примере показан фрейм взаимодействия loop:
Пример использования фрейма loop
На приведенной диаграмме показано взаимодействие процессов — главный процесс (go) после запуска создает дочерний (loop), затем в цикле посылает ему свой идентификатор (self())и некоторое сообщение (Msg). Дочерний процесс отправляет назад сообщение, но уже со своим идентификатором. Внутри части фрейма loop подписывается условие выхода из цикла — в данном случае пересылка сообщений продолжается до тех пор, пока Msg не станет равно «stop». После цикла главный процесс отправляет дочернему сообщение stop, которое является сигналом завершения процесса.
Последний пример показывает, что диаграммы последовательностей удобно использовать не только при проектировании архитектуры приложений, но и для описания взаимодействия процессов/потоков. Визуальное представление в таких случаях гораздо проще воспринимается, чем текстовое описание.
Таким образом, диаграммы вариантов использования могут очень широко применяться при разработке программного обеспечения: