Диаграмма последовательности (Sequence Diagram)
Удобное средство для обозначения очередности следования друг за другом различных стимулов (сообщений), с помощью которых объекты взаимодействуют между собой.
Например, когда нужно проработать буквально по шагам какой-то очень важный участок выполнения программы.
Главный акцент – порядок и динамика поведения, т.е. как и в каком порядке происходят события.
Отличие от диаграммы классов:
Диаграмма классов дает статическую картинку, т.е. описание которое не меняется во время выполнения программы.
Отличие от диаграммы коммуникаций (или как она раньше называлась colaboration):
Диаграмма последовательности фокусирует наше внимание на очередности выполнения по времени, а диаграмма коммуникаций – на составляющих элементах.
Обычно нормальные люди стараются описывать одной диаграммой только один определенный кейс (UseCase, вариант использования), например: “оставить коммент к сообщению в блоге”, “стать постоянным читателем” и т.д…
Диаграммы последовательности, которые описывают всю систему сразу, представляют из себя монстра, пожирающего внимание, сознание, силы, время и мозг разработчика.
Итак, предлагаю рассмотреть простенькую диаграмму последовательности.
Возьмем банальный пример:
Эта диаграмма показывает как приготовить яичницу.
Когда мы смотрим на такую диаграмму последовательности, мы сразу понимаем что:
– нужно не забыть включить плиту
– перед жаркой нужно хорошо разогреть масло
– первым нужно положить масло, а потом яйца, а не наоборот.
– cоль можно добавить асинхронно, в процессе жарки.
Разберем каждый элемент диаграммы, по отдельности:
1. Объект, Участник (Object, Participant)
Обозначается прямоугольником, в котором указывается информация об участнике действий. Это, как правило, название объекта и его класс, разделенные двоеточием.
Например: saveButton или saveButton:JButton или :JButton
Т.е. по большому счету, название класса можно опустить или наоборот не указывать название объекта, но что-то одно из двух (объект или класс) следует указать, а то останется нечто совсем анонимное.
Если имя объекта не указано, двоеточие перед названием класса обязательно!
В старой нотации (до UML 2.0) требовалось еще и подчеркивать.
Приблизительно вот так: oldButton:JButton
Располагаются объекты (как правило) вдоль верхнего края диаграммы. От прямоугольника вниз спускается Линия Жизни.
2. Линия жизни (Life Line)
Линия, идущая вниз от участника, обозначающая отведенное объекту время жизни. Обозначается пунктирной линией.
3. Активация, фрагмент выполнения (Activation Bar, Execution Occurances)
Обозначается узким прямоугольником (серого или белого цвета), расположенным на линии жизни. Указывает начало и завершение действия, в котором участвует объект. Поскольку линия жизни – это метафора времени, то прямоугольник на линии жизни указывает на активизацию объекта во времени.
4. Сообщение, Стимул (Message, Stimulus)
Стрелка от одной жизни к другой. Показывает взаимодействие объектов.
Очень легко запомнить так: Стимул – это латинское слово, древние римляне так называли заостренную палку, которой гнали скот. Так вот, стимул в UML обозначается такой острой палкой.
Стимулы бывают разные, отличаются наконечником.
Синхронное сообщение обозначается закрашенной стрелкой, асинхронное – незакрашенной.
В нотации до 2.0, асинхронные сообщения обозначались “спиленным” снизу наконечником стрелки.
Возврат показывается пунктирной стрелкой, в обратном направлении.
5. Уничтожение объекта
Обозначается диагональным крестом на линии жизни. Обозначает конец жизни объекта.
UML замечателен тем, что в нем можно забить на многое не обозначать детали. Очень многие обозначения являются необязательными, опциональными.
Т.е. мы не обязаны описывать взаимодействие всех-всех объектов, которые задействованы в варианте использования. Более того, это нежелательно.
Поскольку главная цель – это понять и договориться, что будет происходить в каком-то конкретном случае. Мы можем опустить не очень нужные нам объекты, которые несут вспомогательную функцию.
Если вы с коллегами знаете, о том что
– нужно записывать в лог
– закрывать потоки
– проверять входные аргументы
– обрабатывать исключения
– осуществлять другие действия, которые “подразумеваются” к выполнению в вашем процессе разработки и вы уже про них знаете…
Тогда вы можете не описывать все объекты, а описать главное.
Конечно, если вы хотите специально акцентировать внимание, например, на ведении логов или рассматриваете кейс “отлов и обработка исключений”, то тогда эти объекты становятся из вспомогательных главными, и их необходимо обозначать на диаграмме.
Но даже в этом случае, вам не следует захламлять диаграмму лишними объектами. Ведь если завалить диаграмму всеми объектами, то с ней невозможно будет работать.
Например, если возвращаться к приготовлению яичницы.
В том случае, если мы включим в диаграмму такие объекты как: нагревательный элемент плиты, регулятор температуры, ручка сковородки, прихватка, масленка, холодильник, в котором хранятся яйца, инструмент для отрезания кусочка масла, инструмент для переноса кусочка масла в сковородку, предмет для разбивания яиц, мусорное ведро, механизм регулирующий количество высыпаемой соли, лопатка, рука левая, рука правая и, наконец, голова, то диаграмма станет намного менее понятной, что плохо…
Список литературы
Мартин Фаулер. UML. Основы. Краткое руководство по стандартному языку объектного моделирования
IMHO: Возможно лучшая книжка по UML…
Thomas A. Pender UML Weekend Crash Course
UML за выходные! Из плюсов – легко читается и удобная структура, из минусов – нет на русском.
http://ru.wikipedia.org/wiki/UML
Ну и конечно же, как без Википедии…
http://www.uml.org/
Официальный сайт UML. Спецификации и другая полезная информация.