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

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

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

Обычно они не имеют особого значения, и их наносят на диаграмму, толькоесли это не загромождает ее.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), потому что на диаграмме легко размещать и соединять линии жизни.

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

Рассмотрим реализацию прецедента AddCourse (добавить курс) (рис. 12.6). Чтобы пример был простым, сохранен очень высокий уровень абстракции этого прецедента.Прецедент: AddCourseID: 8Краткое описание:Добавляет детали нового курса в систему.Главные актеры:RegistrarВторостепенные актеры:Нет.Предусловия:1. Registrar вошел в систему.Основной поток:1. Registrar выбирает «add course».2. Registrar вводит имя нового курса.3. Система создает новый курс.Постусловия:1.

Новый курс добавлен в систему.Альтернативные потоки:CourseAlreadyExistsРис. 12.6. Спецификация прецедента AddCourse276Глава 12. Реализация прецедентовRegistrationManager10..*Coursecourses0..*registration0..*10..*StudentstudentsРис. 12.7. Диаграмма классов анализа прецедента AddCourseИсходный анализ созданного прецедента представлен на рис.