Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 51

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 51)

Такимобразом, для каждого поступающего на линию жизни сообщения вызова в классификаторе этой линии жизни должна существовать соответствующая операция. UML допускает несовпадение (рассинхронизацию) сообщений и операций на диаграммах взаимодействий, что обеспечивает возможность динамической и гибкой работы с моделью. Однако в ходе дальнейшего анализа сообщения и операции должны бытьсинхронизированы.Когда линия жизни посылает сообщение, в ней находится фокус управ+ления (focus of control), или активация (activation). По мере развитиявзаимодействия во времени активация перемещается между линиямижизни.

Это движение называют потоком управления (flow of control).Сообщения отображаются в виде стрелок между линиями жизни. Еслилиния жизни имеет пунктирный «хвост» (как на диаграммах последовательностей), сообщения обычно размещают между пунктирнымилиниями. В противном случае сообщения выстраиваются между пиктограммами линий жизни. В данной книге приводится множествопримеров изображения сообщений.

Существует семь типов сообщений(табл. 12.2).Таблица 12.2СинтаксисИмяСемантикаaMessage(aParameter)СинхронноесообщениеОтправитель ожидает завершения выполнения сообщения получателем.aMessage(aParameter)Асинхронное Отправитель посылает сообщение и продолсообщениежает исполнение – он не ожидает возвратаот получателя.«create» aMessage():AВозвратПолучатель сообщения возвращает фокусуправления отправителю этого сообщения.СозданиеобъектаОтправитель создает экземпляр классификатора, определенного получателем.272Глава 12.

Реализация прецедентовТаблица 12.2 (продолжение)Синтаксис«destroy»ИмяСемантикаУничтожение объектаОтправитель уничтожает получателя.Если у линии жизни есть «хвост», он завершается символом X.НайденноесообщениеОтправитель сообщения находится вне области видимости взаимодействия.Используется, когда необходимо показатьполучение сообщения без указания его источника.ПотерянноесообщениеСообщение никогда не достигает точкисвоего назначения.Может использоваться для обозначениясостояний ошибки, при которых пропадают сообщения.12.7.1.

Синхронные, асинхронные и сообщения возвратаПри синхронном вызове сообщения отправитель ожидает завершениявыполнения получателем запрашиваемой операции. При асинхронном отправитель ничего не ожидает, а переходит к следующему этапу.Для аналитических моделей различие между синхронными и асинхронными сообщениями обычно является слишком высоким уровнемдетализации. При анализе нас не интересует глубокая семантика процесса обмена сообщениями. Достаточно того факта, что сообщение отправлено. В этом случае все сообщения можно показывать как синхронные или асинхронные – это на самом деле не важно.

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

Обычно они не имеют особого значения, и их наносят на диаграмму, толькоесли это не загромождает ее.12.7.2. Сообщения создания и уничтоженияВ OO анализе обычно нас не интересует конкретная семантика создания или уничтожения объекта, но понимать, что происходит, необходимо. Поэтому уделим внимание этому вопросу.12.7. Сообщения273Сообщение создания объекта обычно изображается как сплошная линия с открытой стрелкой.

Создание объекта можно показать с помощью сообщения со стереотипом «create» (создать). Или можно послатьконкретное именованное сообщение создания объекта, которое такжеможет быть обозначено стереотипом «create». В C++, C# или Java операции создания объектов являются специальными операциями, которые называют конструкторами. Имя конструктора совпадает с именемкласса.

Конструкторы не имеют возвращаемого значения, они могутиметь от нуля и более параметров. Например, для создания новогообъекта Account можно было бы послать сообщение Account() и инициализировать его атрибут accountNumber некоторым значением. Однакоконструкторы есть не во всех языках программирования. Например,в Smalltalk было бы послано сообщение «create» init: accountNumber.Сообщение уничтожения объекта показывают сплошной линией с открытой стрелкой и стереотипом «destroy» (уничтожить).

Уничтожениеозначает, что экземпляр классификатора, на который ссылается целевая линия жизни, больше не доступен для использования. Если у линии жизни есть «хвост», он должен завершаться большим крестомв точке уничтожения. Для уничтожения объектов нет возвращаемогозначения.В разных языках программирования семантика уничтожения различна. Например, в С++ уничтожение обычно явно обрабатывается программистом, и при уничтожении объекта гарантированно инициируется специальный метод (если он существует), называемый деструктором. Этот метод часто используется для проведения операций очистки,таких как высвобождение ресурсов, например файлов или соединенийс базой данных. Вызов деструктора высвобождает память, выделенную под объект.В таких языках программирования, как Java и C#, уничтожение объектов обрабатывается виртуальной машиной с помощью механизма подназванием «сборка мусора». Например, если на объект Javaпрограммыбольше не ссылается ни один другой объект, он помечается как готовыйк уничтожению.

Уничтожение произойдет в некоторый момент времени в соответствии с алгоритмом сборки мусора, но вы не знаете, когдаэто случится! У объектов в Java и C# могут быть методы«финализаторы», которые будут исполняться в момент реального уничтожения, осуществляемого сборщиком мусора. Однако использовать этот метод опасно, потому что мы точно не знаем, когда сборщик мусора вызовет его.12.7.3. Найденные и потерянные сообщенияОбычно в анализе найденные и потерянные сообщения могут бытьпроигнорированы.

Мы рассматриваем их здесь в основном для полноты обсуждения.Найденные сообщения могут быть полезны, если необходимо показатьполучение сообщения классом, но неизвестно (в данный момент време274Глава 12. Реализация прецедентовни), откуда поступило это сообщение. На практике такое встречаетсяредко.Потерянные сообщения позволяют показать, что сообщение потеряно –оно никогда не достигает точки своего назначения.

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

Существует четыре разных типа диаграмм взаимодействий, каждый из которых делаетакцент на различных аспектах взаимодействия.Четыре типа диаграмм взаимодействий предоставляют разные проекции взаимодействий объектов.•Диаграммы последовательностей (sequence diagrams) акцентируютвнимание на временной упорядоченности сообщений. Обычно пользователи лучше понимают диаграммы последовательностей, чемкоммуникационные диаграммы, поскольку они намного легче читаются. Как правило, коммуникационные диаграммы очень быстрозагромождаются.

Диаграммы последовательностей обсуждаютсяв разделе 12.9.•Коммуникационные диаграммы (communication diagrams) выделяют структурные отношения между объектами и очень полезны прианализе, особенно для создания эскиза совместной работы объектов. В UML 2 эти диаграммы предлагают только лишь подмножество функциональности диаграмм последовательностей.

Коммуникационные диаграммы обсуждаются в разделе 12.11.•Диаграммы обзора взаимодействий (interaction overview diagrams)показывают, как сложное взаимодействие реализуется рядом простых взаимодействий. Это особый случай диаграммы деятельности,в которой узлы ссылаются на другие взаимодействия. Они полезныдля моделирования потока управления системы. Диаграммы обзора взаимодействий обсуждаются в разделе 15.12.•Временные диаграммы (timing diagrams) обращают внимание нафактическое время взаимодействия.

Их основное назначение – помочь оценить временные затраты. Временные диаграммы рассматриваются в разделе 20.7.12.9. Диаграммы последовательностей275Диаграммы последовательностей и коммуникационные диаграммыявляются самыми важными с точки зрения реализации прецедентов.Оставшаяся часть этой главы посвящена их детальному обсуждению.12.9. Диаграммы последовательностейДиаграммы последовательностей представляют взаимодействия между линиями жизни как упорядоченную последовательность событий.Это самая богатая и гибкая форма диаграммы взаимодействий.Диаграммы последовательностей представляют взаимодействия междулиниями жизни как упорядоченную последовательность событий.Иногда моделирование начинают с создания эскиза реализации прецедента с помощью коммуникационной диаграммы (раздел 12.11), потому что на диаграмме легко размещать и соединять линии жизни.

Характеристики

Список файлов книги