UML Диаграммы
1. Введение
2. Диаграмма взаимодействия
2.1.Термины и понятия
2.2.Объекты и роли
3. Диаграммы прецедентов
4. Заключение
5. Список литературы
2. Диаграмма взаимодействия
2.1.Термины и понятия
2.2.Объекты и роли
3. Диаграммы прецедентов
4. Заключение
5. Список литературы
Каждое здание живет своей жизнью. Хотя дома конструируют из статических материалов (кирпичей, известкового раствора, дерева, пластика, стекла, стали), в процессе эксплуатации жилища совокупность этих объектов работает в динамике, реализуя поведение, призванное обеспечить удобство жильцов Двери и окна открываются и закрываются; свет включается и выключается; кондиционеры, отопление, термостаты и вентиляционные отверстия поддерживают требуемую температуру. В некоторых помещениях устанавливаются даже специальные детекторы, регулирующие освещение, обогрев и громкость музыки в зависимости от наличия или отсутствия людей. Дома строятся так, чтобы облегчить перемещение людей и вещей из одной комнаты в другую. При проектировании зданий учитываются суточные и сезонные перепады температур, из-за которых материалы сжимаются и расширяются. Хорошо спроектированные здания реагируют и на динамические нагрузки, так что при ветре, землетрясении или передвижении жильцов строение сохраняет равновесие.
Программные системы функционируют аналогично. Например, система управления авиалиниями может работать с десятками терабайтов информации, однако в течение длительного времени эта информация не используется, а "оживает" только под воздействием внешних событий - таких, например, как заказ билета, перемещение самолета или планирование рейса. В реактивных системах (скажем, в процессоре микроволновой печи) активизацией и работой объектов управляют такие события, как нажатие кнопки пользователем или истечение некоторого промежутка времени.
В UML статические аспекты системы моделируются с помощью диаграмм классов или диаграмм объектов. Они позволяют визуализировать, специфицировать, конструировать и документировать сущности, входящие в состав системы, включая классы, интерфейсы, компоненты, узлы, прецеденты и их экземпляры, а также способы их взаимодействия друг с другом.
Динамические аспекты системы в UML моделируются с помощью взаимодействий (а также с помощью автоматов). Подобно диаграммам объектов, диаграммы взаимодействия готовят статическую сцену, на которой затем будет "разворачиваться" некоторое поведение, выводя на эту сцену объекты, работающие совместно ради выполнения определенного действия. Но в диаграммах взаимодействия, помимо всего прочего, фигурируют и сообщения, передаваемые между объектами. Чаще всего сообщение (Message) сводится к вызову операции или посылке сигнала, но оно может также создавать и уничтожать другие объекты.
С помощью взаимодействий моделируют потоки управления внутри операции, класса, компонента, прецедента или системы в целом. Взаимодействия позволяют анализировать такие потоки по двум критериям: во-первых, можно сосредоточиться на временной последовательности сообщений, во-вторых - акцентировать внимание на структурных
Программные системы функционируют аналогично. Например, система управления авиалиниями может работать с десятками терабайтов информации, однако в течение длительного времени эта информация не используется, а "оживает" только под воздействием внешних событий - таких, например, как заказ билета, перемещение самолета или планирование рейса. В реактивных системах (скажем, в процессоре микроволновой печи) активизацией и работой объектов управляют такие события, как нажатие кнопки пользователем или истечение некоторого промежутка времени.
В UML статические аспекты системы моделируются с помощью диаграмм классов или диаграмм объектов. Они позволяют визуализировать, специфицировать, конструировать и документировать сущности, входящие в состав системы, включая классы, интерфейсы, компоненты, узлы, прецеденты и их экземпляры, а также способы их взаимодействия друг с другом.
Динамические аспекты системы в UML моделируются с помощью взаимодействий (а также с помощью автоматов). Подобно диаграммам объектов, диаграммы взаимодействия готовят статическую сцену, на которой затем будет "разворачиваться" некоторое поведение, выводя на эту сцену объекты, работающие совместно ради выполнения определенного действия. Но в диаграммах взаимодействия, помимо всего прочего, фигурируют и сообщения, передаваемые между объектами. Чаще всего сообщение (Message) сводится к вызову операции или посылке сигнала, но оно может также создавать и уничтожать другие объекты.
С помощью взаимодействий моделируют потоки управления внутри операции, класса, компонента, прецедента или системы в целом. Взаимодействия позволяют анализировать такие потоки по двум критериям: во-первых, можно сосредоточиться на временной последовательности сообщений, во-вторых - акцентировать внимание на структурных
1.Джозеф Шмуллер «Освой самостоятельно UML за 24 часа »
2. Гради Буч «Объектно-ориентированный анализ и проектирование »
2. Гради Буч «Объектно-ориентированный анализ и проектирование »
Дисциплина: Информатика, Программирование, Базы данных
Тип работы: Реферат
Бесплатно: Антиплагиат
Объем: 21 страниц
В избранное:
Тип работы: Реферат
Бесплатно: Антиплагиат
Объем: 21 страниц
В избранное:
Введение
Каждое здание живет своей жизнью. Хотя дома конструируют из статических
материалов (кирпичей, известкового раствора, дерева, пластика, стекла,
стали), в процессе эксплуатации жилища совокупность этих объектов работает
в динамике, реализуя поведение, призванное обеспечить удобство жильцов
Двери и окна открываются и закрываются; свет включается и выключается;
кондиционеры, отопление, термостаты и вентиляционные отверстия поддерживают
требуемую температуру. В некоторых помещениях устанавливаются даже
специальные детекторы, регулирующие освещение, обогрев и громкость музыки в
зависимости от наличия или отсутствия людей. Дома строятся так, чтобы
облегчить перемещение людей и вещей из одной комнаты в другую. При
проектировании зданий учитываются суточные и сезонные перепады температур,
из-за которых материалы сжимаются и расширяются. Хорошо спроектированные
здания реагируют и на динамические нагрузки, так что при ветре,
землетрясении или передвижении жильцов строение сохраняет равновесие.
Программные системы функционируют аналогично. Например, система управления
авиалиниями может работать с десятками терабайтов информации, однако в
течение длительного времени эта информация не используется, а "оживает"
только под воздействием внешних событий - таких, например, как заказ
билета, перемещение самолета или планирование рейса. В реактивных системах
(скажем, в процессоре микроволновой печи) активизацией и работой объектов
управляют такие события, как нажатие кнопки пользователем или истечение
некоторого промежутка времени.
В UML статические аспекты системы моделируются с помощью диаграмм классов
или диаграмм объектов. Они позволяют визуализировать, специфицировать,
конструировать и документировать сущности, входящие в состав системы,
включая классы, интерфейсы, компоненты, узлы, прецеденты и их экземпляры, а
также способы их взаимодействия друг с другом.
Динамические аспекты системы в UML моделируются с помощью взаимодействий (а
также с помощью автоматов). Подобно диаграммам объектов, диаграммы
взаимодействия готовят статическую сцену, на которой затем будет
"разворачиваться" некоторое поведение, выводя на эту сцену объекты,
работающие совместно ради выполнения определенного действия. Но в
диаграммах взаимодействия, помимо всего прочего, фигурируют и сообщения,
передаваемые между объектами. Чаще всего сообщение (Message) сводится к
вызову операции или посылке сигнала, но оно может также создавать и
уничтожать другие объекты.
С помощью взаимодействий моделируют потоки управления внутри операции,
класса, компонента, прецедента или системы в целом. Взаимодействия
позволяют анализировать такие потоки по двум критериям: во-первых, можно
сосредоточиться на временной последовательности сообщений, во-вторых -
акцентировать внимание на структурных отношениях между взаимосвязанными
объектами и затем рассмотреть, как сообщения передаются в контексте этой
структуры.
Графическое изображение сообщений в UML показано на рисунке. Эта нотация
позволяет визуализировать основные составные части сообщений: их имена,
параметры (если таковые имеются) и последовательность. Сообщения
представляют в виде линии со стрелкой и почти всегда добавляют название
соответствующей операции.
Рис. 1. Сообщения, связи и последоват
Термины и понятия
Взаимодействием (Interaction) называется поведение, выражающееся в обмене
сообщениями между множеством объектов в некотором контексте, в результате
чего достигается определенная цель. Сообщение (Message) - это спецификация
обмена данными между объектами, при котором передается некая информация в
расчете на то, что в ответ последует определенное действие.
Контекст
Взаимодействия имеют место всегда, когда объекты связаны друг с другом (эти
структурные связи отображаются на диаграммах объектов,. Взаимодействия
можно обнаружить в кооперациях объектов в контексте системы или подсистемы.
Они существуют и в контексте операций, и в контексте классов.
Чаще всего взаимодействия обнаруживаются в кооперации объектов в контексте
системы или подсистемы как целого. Скажем, в системе электронной коммерции
на стороне клиента есть взаимодействующие друг с другом объекты (например,
экземпляры класса). На стороне клиента есть объекты, которые
взаимодействуют с объектами на стороне сервера (например, с экземпляром
класса). Таким образом, взаимодействия охватывают не только локальные
кооперации объектов, как в первом случае, но могут распространяться и на
несколько концептуальных уровней системы, как во втором случае.
Взаимодействия между объектами встречаются и при реализации операций.
Параметры операции, любые локальные для нее переменные и глобальные
объекты, видимые внутри операции, могут взаимодействовать друг с другом для
выполнения реализуемого ею алгоритма (о моделировании операций подробно
рассказывается в. Так, вызов операции moveToPosition(p:Position),
определенной в классе мобильного робота, предполагает взаимодействие между
параметром ( р), глобальным для операции объектом (currentPosition)и,
возможно, несколькими локальными объектами (скажем, локальными переменными,
используемыми внутри операции для вычисления промежуточных точек на пути
робота к новому местоположению).
Наконец, взаимодействия существуют в контексте класса. С их помощью можно
визуализировать, специфицировать, конструировать и документировать
семантику класса.Например, для понимания назначения класса
RayTraceAgent(АгентТрассировкиЛучей ) можно создать взаимодействие,
показывающее, как атрибуты этого класса сотрудничают друг с другом (а также
с глобальными по отношению к его экземплярам объектами и с параметрами,
определенными в операциях класса).
Объекты и роли
Участвующие во взаимодействии объекты могут быть конкретными сущностями или
прототипами. В качестве конкретной сущности объект представляет нечто,
существующее в реальном мире. Так, р, экземпляр класса Человек, может
обозначать конкретного человека. Напротив, прототип р может представлять
любой экземпляр класса Человек.
В контексте взаимодействия можно встретить экземпляры классов, компонентов,
узлов и прецедентов. Хотя у абстрактных классов и интерфейсов по
определению не бывает непосредственных экземпляров, во взаимодействиях их
присутствие допустимо. Конечно, они представляют собой не экземпляры
абстрактного класса или интерфейса, а экземпляры (или прототипы) любого
конкретного потомка данного абстрактного класса или некоего конкретного
класса, реализующего интерфейс.
Диаграмму объектов можно рассматривать как представление статического
аспекта взаимодействия, поскольку она описывает сцену, определяя все
объекты, работающие совместно. Взаимодействие добавляет к этому
динамическую последовательность сообщений, циркулирующих вдоль связей между
объектами.
Связи
Связью (Link) называется семантическое соединение между объектами. В общем
случае связь представляет собой экземпляр ассоциации. Как показано на
рисунке, если два класса входят в ассоциацию, то между их экземплярами
может наличествовать связь; если же между двумя объектами существует связь,
один из них может посылать сообщения другому.
Связь определяет путь, по которому один объект передает сообщения другому
(или самому себе). Чаще всего достаточно указать, что такой путь
существует, Если вы хотите его подробно специфицировать, дополните
соответствующую концевую точку связи одним из следующих стандартных
стереотипов:
association- показывает, что соответствующий объект видим для ассоциации;
self- соответствующий объект видим, потому что является диспетчером для
операции;
global- соответствующий объект видим, так как находится в объемлющей
области действия;
local- соответствующий объект видим, поскольку находится в локальной
области действия; ,
parameter- соответствующий объект видим, так как является параметром.
Рис.1.1. Связи и ассоциации
Сообщения
Предположим, что есть множество объектов и множество соединяющих эти
объекты связей. Если больше ничего не задано, то перед вами статическая
модель, которая может быть представлена на диаграмме объектов. Такие
диаграммы моделируют состояние сообщества объектов в данный момент времени
и оказываются полезны для визуализации, специфицирования, конструирования и
документирования статической объектной структуры.
Сообщением называется спецификация обмена данными между объектами, при
котором передается некая информация в расчете на то, что в ответ последует
определенное действие. Получение объектом экземпляра сообщения можно
считать экземпляром события.
Действие, являющееся результатом получения сообщения, - это исполняемое
предложение, которое образует абстракцию вычислительной процедуры. Действие
может привести к изменению состояния.
UML позволяет моделировать действия нескольких видов:
call(вызвать) - вызывает операцию, применяемую к объекту. Объект может
послать сообщение самому себе, что приведет к локальному вызову операции;
return(возвратить) - возвращает значение вызывающему объекту;
send(послать) - посылает объекту сигнал;
create(создать) - создает новый объект;
destroy(уничтожить) - удаляет объект. Объект может уничтожить самого себя.
В UML можно моделировать и сложные действия. Помимо пяти основных
перечисленных видов действий к сообщению можно Присоединить произвольную
строку, содержащую запись сложного выражения. UML не определяет синтаксис
или семантику таких строк.
Перечисленные виды сообщений можно различить визуально, как показано на
рисунке. При этом действия createи destroyвизуализируются как стереотипы.
Различие между синхронными и асинхронными действиями наиболее существенно в
контексте одновременности (см. главу 22).
Чаще всего встречающийся в моделях вид сообщений - вызов одним объектом
операции другого (или своей собственной). Объект не может вызвать
произвольную операцию. Если, например, объект с из вышеприведенного примера
вызывает операцию setltineraryэкземпляра класса Ticket Agent, то она должна
быть не только определена в классе Ticket Agent(другими словами, объявлена
либо непосредственно в нем, либо в одном из его предков), но и доступна для
объекта с.
Такие языки программирования, как С+ +, статически типизированы (хотя и
полиморфны), то есть законность вызова проверяется во время компиляции. Но,
например, Smalltalk является динамически типизированным языком, то есть до
момента выполнения нельзя определить, может ли объект получать сообщение
данного типа. Хорошо оформленную модель UML в общем случае можно проверить
статически с помощью инструментальных средств, так как на этапе
моделирования разработчику обычно известно назначение каждой операции.
Рис. 1.2. Сообщения
Когда объект вызывает операцию или посылает сигнал другому объекту, вместе
с сообщением можно передать его фактические параметры. Аналогичным образом,
когда объект возвращает управление другому объекту, можно смоделировать
возвращаемое значение.
Операции допустимо квалифицировать также по классу или интерфейсу, в
котором они были объявлены. Так, выполнение операции registerна экземпляре
класса Studentполиморфно вызывает ту операцию, которая соответствует имени
в иерархии данного класса; обращение к IMember : : registerвызывает
операцию, определенную в интерфейсе IMember(и реализованную каким-нибудь
подходящим классом, также принадлежащим к иерархии класса Student).
Последовательности
Когда объект посылает сообщение другому объекту (фактически делегируя ему
некоторое действие), получатель может, в свою очередь, отправить сообщение
третьему объекту, тот - четвертому и т.д. Такой поток сообщений формирует
последовательность (Sequence). Она всегда должна иметь начало в некотором
процессе или вычислительной нити; последовательность может продолжаться,
пока существует владеющий ею процесс или нить. Постоянно работающая система
, например встроенная в некоторое устройство реального времени, продолжает
выполняться, пока не остановлен содержащий ее узел.
Каждый процесс и нить в системе определяет отдельный поток управления, и в
каждом таком потоке сообщения упорядочены по времени. Чтобы удачно
визуализировать последовательность сообщений, можно явно смоделировать их
порядок относительно начала последовательности, предпослав каждому
сообщению его порядковый номер, отделенный двоеточием.
Процедурные и вложенные потоки управления обычно изображают в Виде линий с
закрашенными стрелками, как показано на рисунке. В данном случае сообщение
findAt является первым из тех, которые вложены во второе сообщение
последовательности.
Рис.1.3. Процедурная последовательность
Менее распространенный, но вполне приемлемый способ показан на рисунке
Здесь линия с незакрашенной стрелкой представляет простой
(неструктурированный) поток управления, который моделирует непроцедурную
передачу управления от одного шага к другому. В данном случае сообщение
assertCall является вторым в последовательности.
Рис.1.4. Одноуровневая (простая) последовательность
Различие между простой и процедурной последовательностью довольно тонкое и
принадлежит к числу сложных вопросов моделирования. Обычно простые
последовательности применяют только при моделировании взаимодействий в
контексте прецедентов, относящихся к системе в целом, включая, актеры вне
системы. Такие последовательности зачастую оказываются простыми, поскольку
управление передается от шага к шагу без учета вложенных потоков
управления. Почти во всех остальных случаях применяют процедурные
последовательности, поскольку с их помощью представляются вложенные вызовы
операций, примеры которых можно найти в большинстве языков
программирования.
Моделируя взаимодействия, в которых участвует несколько потоков управления,
особенно важно идентифицировать процесс или нить , пославшие сообщение. Для
того чтобы различать потоки управления, в UML перед порядковым номером
сообщения можно указать имя процесса или нити, являющихся источником данной
последовательности сообщений. Например, выражение
D5:ejectHatch(3), показывает, что операция ejectHatch(с фактическим
параметром 3) выполняется в результате получения пятого сообщения в
последовательности, начатой процессом или потоком D. Асинхронный поток
управления изображается с помощью "полустрелки".
Можно показывать не только фактические аргументы, посланные вместе с
операцией или сигналом в контексте взаимодействия, но и возвращаемые
значения функции. Например, из выражения ниже явствует, что операция findс
фактическим параметром " Rachelle" возвращает значение р. Это вложенная
последовательность: операция выполняется в результате второго сообщения,
вложенного в третье, которое, в свою очередь, вложено в первое сообщение
последовательности. На той же самой диаграмме р можно использовать в
качестве фактического параметра других сообщений.
1.3.2 : р := find("Rachelle")
UML позволяет моделировать и более сложные виды последовательностей:
итерации, ветвления и охраняемые сообщения. Кроме того, для моделирования
временных ограничений, встречающихся в системах реального времени, с
последовательностью можно связать отметки времени. Более экзотические виды
передачи сообщений (например, тайм-ауты) допустимо моделировать, определяя
подходящий стереотип .
Создание, модификация и уничтожение
Чаще всего участвующие во взаимодействии объекты существуют на протяжении
всего взаимодействия. Но иногда объекты приходится создавать (с помощью
сообщения create) и уничтожать (с помощью сообщения destroy). Сказанное
относится и к связям: отношения между объектами могут возникать и исчезать.
Чтобы отметить, что объекты или связи появились либо пропали в ходе
взаимодействия, к элементу присоединяют одно из следующих ограничений :
new(новый) - показывает, что данный экземпляр или связь создается во время
выполнения объемлющего взаимодействия;
destroyed(уничтоженный) - экземпляр или связь уничтожается до завершения
выполнения объемлющего взаимодействия;
transient(временный) - экземпляр или связь создается во время выполнения
объемлющего взаимодействия и уничтожается до его завершения.
Во время взаимодействия значение атрибутов объекта, его состояние или роли,
как правило, Изменяются. Это можно отобразить, создавая копии объекта с
другими значениями атрибутов, состоянием и ролями. При этом на диаграмме
последовательностей все вариации объекта должны быть расположены на одной и
той же линии жизни На диаграмме взаимодействий их нужно связать друг с
другом посредством сообщения со стереотипом become
Представление
При моделировании взаимодействия обычно включают как объекты, каждый из
которых играет свою роль, так и сообщения, каждое из которых представляет
обмен данными между объектами, в результате чего выполняются определенные
действия.
Участвующие во взаимодействии сообщения и объекты можно визуализировать
двумя способами: акцентируя внимание на временной упорядоченности сообщений
или на структурной организации объектов, посылающих и принимающих
сообщения. В UML первый тип называется диаграммами последовательностей, а
второй - диаграммами кооперации; те и другие являются разновидностью
диаграмм взаимодействий .
Диаграммы последовательностей и кооперации являются изоморфными, то есть
могут быть преобразованы друг в друга без потери информации. Однако между
ними существуют визуальные различия. Диаграммы последовательностей
обеспечивают моделирование линии жизни объекта, которая описывает его
существование в определенный промежуток времени - возможно, включая моменты
создания и уничтожения объекта. Диаграммы кооперации позволяют моделировать
структурные связи, существующие между объектами, которые участвуют во
взаимодействии.
Типичные приемы моделирования
Поток управления
Чаще всего взаимодействия используют для моделирования потока управления,
характеризующего поведение системы в целом, включая прецеденты , образцы,
механизмы и каркасы, поведение одного класса или отдельной операции. При
этом классы, интерфейсы , компоненты , узлы и отношения между ними
моделируют статические аспекты системы, а взаимодействия - ее динамические
аспекты (для моделирования последних используются также автоматы.
Моделируя взаимодействия, вы, по сути дела, описываете последовательности
действий, выполняемых объектами из некоторой совокупности. Для выявления и
осмысления взаимодействий очень полезно применение CRC-карточек.
Моделирование потока управления состоит из следующих шагов:
Определите контекст взаимодействия, будь то система в целом, одиночный
класс или отдельная операция.
Опишите сцену, на которой будет происходить взаимодействие. Для этого нужно
идентифицировать объекты, играющие какую-либо роль, и установить их
начальные свойства, в том числе значения атрибутов, состояния и роли.
Если в вашей модели внимание акцентируется на структурной организации
объектов, идентифицируйте связи между ними, имеющие отношение к обмену
данными, который происходит во взаимодействии. При необходимости опишите
особенности каждой связи с помощью стандартных стереотипов и ограничений
UML.
Если основное внимание уделяется временной упорядоченности, специфицируйте
сообщения, передаваемые между объектами. В случае необходимости выделите
разные виды сообщений, включите в описание параметры и возвращаемые
значения.
Для передачи существенных деталей взаимодействия можно указать состояние и
роль каждого объекта ... продолжение
Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.
Каждое здание живет своей жизнью. Хотя дома конструируют из статических
материалов (кирпичей, известкового раствора, дерева, пластика, стекла,
стали), в процессе эксплуатации жилища совокупность этих объектов работает
в динамике, реализуя поведение, призванное обеспечить удобство жильцов
Двери и окна открываются и закрываются; свет включается и выключается;
кондиционеры, отопление, термостаты и вентиляционные отверстия поддерживают
требуемую температуру. В некоторых помещениях устанавливаются даже
специальные детекторы, регулирующие освещение, обогрев и громкость музыки в
зависимости от наличия или отсутствия людей. Дома строятся так, чтобы
облегчить перемещение людей и вещей из одной комнаты в другую. При
проектировании зданий учитываются суточные и сезонные перепады температур,
из-за которых материалы сжимаются и расширяются. Хорошо спроектированные
здания реагируют и на динамические нагрузки, так что при ветре,
землетрясении или передвижении жильцов строение сохраняет равновесие.
Программные системы функционируют аналогично. Например, система управления
авиалиниями может работать с десятками терабайтов информации, однако в
течение длительного времени эта информация не используется, а "оживает"
только под воздействием внешних событий - таких, например, как заказ
билета, перемещение самолета или планирование рейса. В реактивных системах
(скажем, в процессоре микроволновой печи) активизацией и работой объектов
управляют такие события, как нажатие кнопки пользователем или истечение
некоторого промежутка времени.
В UML статические аспекты системы моделируются с помощью диаграмм классов
или диаграмм объектов. Они позволяют визуализировать, специфицировать,
конструировать и документировать сущности, входящие в состав системы,
включая классы, интерфейсы, компоненты, узлы, прецеденты и их экземпляры, а
также способы их взаимодействия друг с другом.
Динамические аспекты системы в UML моделируются с помощью взаимодействий (а
также с помощью автоматов). Подобно диаграммам объектов, диаграммы
взаимодействия готовят статическую сцену, на которой затем будет
"разворачиваться" некоторое поведение, выводя на эту сцену объекты,
работающие совместно ради выполнения определенного действия. Но в
диаграммах взаимодействия, помимо всего прочего, фигурируют и сообщения,
передаваемые между объектами. Чаще всего сообщение (Message) сводится к
вызову операции или посылке сигнала, но оно может также создавать и
уничтожать другие объекты.
С помощью взаимодействий моделируют потоки управления внутри операции,
класса, компонента, прецедента или системы в целом. Взаимодействия
позволяют анализировать такие потоки по двум критериям: во-первых, можно
сосредоточиться на временной последовательности сообщений, во-вторых -
акцентировать внимание на структурных отношениях между взаимосвязанными
объектами и затем рассмотреть, как сообщения передаются в контексте этой
структуры.
Графическое изображение сообщений в UML показано на рисунке. Эта нотация
позволяет визуализировать основные составные части сообщений: их имена,
параметры (если таковые имеются) и последовательность. Сообщения
представляют в виде линии со стрелкой и почти всегда добавляют название
соответствующей операции.
Рис. 1. Сообщения, связи и последоват
Термины и понятия
Взаимодействием (Interaction) называется поведение, выражающееся в обмене
сообщениями между множеством объектов в некотором контексте, в результате
чего достигается определенная цель. Сообщение (Message) - это спецификация
обмена данными между объектами, при котором передается некая информация в
расчете на то, что в ответ последует определенное действие.
Контекст
Взаимодействия имеют место всегда, когда объекты связаны друг с другом (эти
структурные связи отображаются на диаграммах объектов,. Взаимодействия
можно обнаружить в кооперациях объектов в контексте системы или подсистемы.
Они существуют и в контексте операций, и в контексте классов.
Чаще всего взаимодействия обнаруживаются в кооперации объектов в контексте
системы или подсистемы как целого. Скажем, в системе электронной коммерции
на стороне клиента есть взаимодействующие друг с другом объекты (например,
экземпляры класса). На стороне клиента есть объекты, которые
взаимодействуют с объектами на стороне сервера (например, с экземпляром
класса). Таким образом, взаимодействия охватывают не только локальные
кооперации объектов, как в первом случае, но могут распространяться и на
несколько концептуальных уровней системы, как во втором случае.
Взаимодействия между объектами встречаются и при реализации операций.
Параметры операции, любые локальные для нее переменные и глобальные
объекты, видимые внутри операции, могут взаимодействовать друг с другом для
выполнения реализуемого ею алгоритма (о моделировании операций подробно
рассказывается в. Так, вызов операции moveToPosition(p:Position),
определенной в классе мобильного робота, предполагает взаимодействие между
параметром ( р), глобальным для операции объектом (currentPosition)и,
возможно, несколькими локальными объектами (скажем, локальными переменными,
используемыми внутри операции для вычисления промежуточных точек на пути
робота к новому местоположению).
Наконец, взаимодействия существуют в контексте класса. С их помощью можно
визуализировать, специфицировать, конструировать и документировать
семантику класса.Например, для понимания назначения класса
RayTraceAgent(АгентТрассировкиЛучей ) можно создать взаимодействие,
показывающее, как атрибуты этого класса сотрудничают друг с другом (а также
с глобальными по отношению к его экземплярам объектами и с параметрами,
определенными в операциях класса).
Объекты и роли
Участвующие во взаимодействии объекты могут быть конкретными сущностями или
прототипами. В качестве конкретной сущности объект представляет нечто,
существующее в реальном мире. Так, р, экземпляр класса Человек, может
обозначать конкретного человека. Напротив, прототип р может представлять
любой экземпляр класса Человек.
В контексте взаимодействия можно встретить экземпляры классов, компонентов,
узлов и прецедентов. Хотя у абстрактных классов и интерфейсов по
определению не бывает непосредственных экземпляров, во взаимодействиях их
присутствие допустимо. Конечно, они представляют собой не экземпляры
абстрактного класса или интерфейса, а экземпляры (или прототипы) любого
конкретного потомка данного абстрактного класса или некоего конкретного
класса, реализующего интерфейс.
Диаграмму объектов можно рассматривать как представление статического
аспекта взаимодействия, поскольку она описывает сцену, определяя все
объекты, работающие совместно. Взаимодействие добавляет к этому
динамическую последовательность сообщений, циркулирующих вдоль связей между
объектами.
Связи
Связью (Link) называется семантическое соединение между объектами. В общем
случае связь представляет собой экземпляр ассоциации. Как показано на
рисунке, если два класса входят в ассоциацию, то между их экземплярами
может наличествовать связь; если же между двумя объектами существует связь,
один из них может посылать сообщения другому.
Связь определяет путь, по которому один объект передает сообщения другому
(или самому себе). Чаще всего достаточно указать, что такой путь
существует, Если вы хотите его подробно специфицировать, дополните
соответствующую концевую точку связи одним из следующих стандартных
стереотипов:
association- показывает, что соответствующий объект видим для ассоциации;
self- соответствующий объект видим, потому что является диспетчером для
операции;
global- соответствующий объект видим, так как находится в объемлющей
области действия;
local- соответствующий объект видим, поскольку находится в локальной
области действия; ,
parameter- соответствующий объект видим, так как является параметром.
Рис.1.1. Связи и ассоциации
Сообщения
Предположим, что есть множество объектов и множество соединяющих эти
объекты связей. Если больше ничего не задано, то перед вами статическая
модель, которая может быть представлена на диаграмме объектов. Такие
диаграммы моделируют состояние сообщества объектов в данный момент времени
и оказываются полезны для визуализации, специфицирования, конструирования и
документирования статической объектной структуры.
Сообщением называется спецификация обмена данными между объектами, при
котором передается некая информация в расчете на то, что в ответ последует
определенное действие. Получение объектом экземпляра сообщения можно
считать экземпляром события.
Действие, являющееся результатом получения сообщения, - это исполняемое
предложение, которое образует абстракцию вычислительной процедуры. Действие
может привести к изменению состояния.
UML позволяет моделировать действия нескольких видов:
call(вызвать) - вызывает операцию, применяемую к объекту. Объект может
послать сообщение самому себе, что приведет к локальному вызову операции;
return(возвратить) - возвращает значение вызывающему объекту;
send(послать) - посылает объекту сигнал;
create(создать) - создает новый объект;
destroy(уничтожить) - удаляет объект. Объект может уничтожить самого себя.
В UML можно моделировать и сложные действия. Помимо пяти основных
перечисленных видов действий к сообщению можно Присоединить произвольную
строку, содержащую запись сложного выражения. UML не определяет синтаксис
или семантику таких строк.
Перечисленные виды сообщений можно различить визуально, как показано на
рисунке. При этом действия createи destroyвизуализируются как стереотипы.
Различие между синхронными и асинхронными действиями наиболее существенно в
контексте одновременности (см. главу 22).
Чаще всего встречающийся в моделях вид сообщений - вызов одним объектом
операции другого (или своей собственной). Объект не может вызвать
произвольную операцию. Если, например, объект с из вышеприведенного примера
вызывает операцию setltineraryэкземпляра класса Ticket Agent, то она должна
быть не только определена в классе Ticket Agent(другими словами, объявлена
либо непосредственно в нем, либо в одном из его предков), но и доступна для
объекта с.
Такие языки программирования, как С+ +, статически типизированы (хотя и
полиморфны), то есть законность вызова проверяется во время компиляции. Но,
например, Smalltalk является динамически типизированным языком, то есть до
момента выполнения нельзя определить, может ли объект получать сообщение
данного типа. Хорошо оформленную модель UML в общем случае можно проверить
статически с помощью инструментальных средств, так как на этапе
моделирования разработчику обычно известно назначение каждой операции.
Рис. 1.2. Сообщения
Когда объект вызывает операцию или посылает сигнал другому объекту, вместе
с сообщением можно передать его фактические параметры. Аналогичным образом,
когда объект возвращает управление другому объекту, можно смоделировать
возвращаемое значение.
Операции допустимо квалифицировать также по классу или интерфейсу, в
котором они были объявлены. Так, выполнение операции registerна экземпляре
класса Studentполиморфно вызывает ту операцию, которая соответствует имени
в иерархии данного класса; обращение к IMember : : registerвызывает
операцию, определенную в интерфейсе IMember(и реализованную каким-нибудь
подходящим классом, также принадлежащим к иерархии класса Student).
Последовательности
Когда объект посылает сообщение другому объекту (фактически делегируя ему
некоторое действие), получатель может, в свою очередь, отправить сообщение
третьему объекту, тот - четвертому и т.д. Такой поток сообщений формирует
последовательность (Sequence). Она всегда должна иметь начало в некотором
процессе или вычислительной нити; последовательность может продолжаться,
пока существует владеющий ею процесс или нить. Постоянно работающая система
, например встроенная в некоторое устройство реального времени, продолжает
выполняться, пока не остановлен содержащий ее узел.
Каждый процесс и нить в системе определяет отдельный поток управления, и в
каждом таком потоке сообщения упорядочены по времени. Чтобы удачно
визуализировать последовательность сообщений, можно явно смоделировать их
порядок относительно начала последовательности, предпослав каждому
сообщению его порядковый номер, отделенный двоеточием.
Процедурные и вложенные потоки управления обычно изображают в Виде линий с
закрашенными стрелками, как показано на рисунке. В данном случае сообщение
findAt является первым из тех, которые вложены во второе сообщение
последовательности.
Рис.1.3. Процедурная последовательность
Менее распространенный, но вполне приемлемый способ показан на рисунке
Здесь линия с незакрашенной стрелкой представляет простой
(неструктурированный) поток управления, который моделирует непроцедурную
передачу управления от одного шага к другому. В данном случае сообщение
assertCall является вторым в последовательности.
Рис.1.4. Одноуровневая (простая) последовательность
Различие между простой и процедурной последовательностью довольно тонкое и
принадлежит к числу сложных вопросов моделирования. Обычно простые
последовательности применяют только при моделировании взаимодействий в
контексте прецедентов, относящихся к системе в целом, включая, актеры вне
системы. Такие последовательности зачастую оказываются простыми, поскольку
управление передается от шага к шагу без учета вложенных потоков
управления. Почти во всех остальных случаях применяют процедурные
последовательности, поскольку с их помощью представляются вложенные вызовы
операций, примеры которых можно найти в большинстве языков
программирования.
Моделируя взаимодействия, в которых участвует несколько потоков управления,
особенно важно идентифицировать процесс или нить , пославшие сообщение. Для
того чтобы различать потоки управления, в UML перед порядковым номером
сообщения можно указать имя процесса или нити, являющихся источником данной
последовательности сообщений. Например, выражение
D5:ejectHatch(3), показывает, что операция ejectHatch(с фактическим
параметром 3) выполняется в результате получения пятого сообщения в
последовательности, начатой процессом или потоком D. Асинхронный поток
управления изображается с помощью "полустрелки".
Можно показывать не только фактические аргументы, посланные вместе с
операцией или сигналом в контексте взаимодействия, но и возвращаемые
значения функции. Например, из выражения ниже явствует, что операция findс
фактическим параметром " Rachelle" возвращает значение р. Это вложенная
последовательность: операция выполняется в результате второго сообщения,
вложенного в третье, которое, в свою очередь, вложено в первое сообщение
последовательности. На той же самой диаграмме р можно использовать в
качестве фактического параметра других сообщений.
1.3.2 : р := find("Rachelle")
UML позволяет моделировать и более сложные виды последовательностей:
итерации, ветвления и охраняемые сообщения. Кроме того, для моделирования
временных ограничений, встречающихся в системах реального времени, с
последовательностью можно связать отметки времени. Более экзотические виды
передачи сообщений (например, тайм-ауты) допустимо моделировать, определяя
подходящий стереотип .
Создание, модификация и уничтожение
Чаще всего участвующие во взаимодействии объекты существуют на протяжении
всего взаимодействия. Но иногда объекты приходится создавать (с помощью
сообщения create) и уничтожать (с помощью сообщения destroy). Сказанное
относится и к связям: отношения между объектами могут возникать и исчезать.
Чтобы отметить, что объекты или связи появились либо пропали в ходе
взаимодействия, к элементу присоединяют одно из следующих ограничений :
new(новый) - показывает, что данный экземпляр или связь создается во время
выполнения объемлющего взаимодействия;
destroyed(уничтоженный) - экземпляр или связь уничтожается до завершения
выполнения объемлющего взаимодействия;
transient(временный) - экземпляр или связь создается во время выполнения
объемлющего взаимодействия и уничтожается до его завершения.
Во время взаимодействия значение атрибутов объекта, его состояние или роли,
как правило, Изменяются. Это можно отобразить, создавая копии объекта с
другими значениями атрибутов, состоянием и ролями. При этом на диаграмме
последовательностей все вариации объекта должны быть расположены на одной и
той же линии жизни На диаграмме взаимодействий их нужно связать друг с
другом посредством сообщения со стереотипом become
Представление
При моделировании взаимодействия обычно включают как объекты, каждый из
которых играет свою роль, так и сообщения, каждое из которых представляет
обмен данными между объектами, в результате чего выполняются определенные
действия.
Участвующие во взаимодействии сообщения и объекты можно визуализировать
двумя способами: акцентируя внимание на временной упорядоченности сообщений
или на структурной организации объектов, посылающих и принимающих
сообщения. В UML первый тип называется диаграммами последовательностей, а
второй - диаграммами кооперации; те и другие являются разновидностью
диаграмм взаимодействий .
Диаграммы последовательностей и кооперации являются изоморфными, то есть
могут быть преобразованы друг в друга без потери информации. Однако между
ними существуют визуальные различия. Диаграммы последовательностей
обеспечивают моделирование линии жизни объекта, которая описывает его
существование в определенный промежуток времени - возможно, включая моменты
создания и уничтожения объекта. Диаграммы кооперации позволяют моделировать
структурные связи, существующие между объектами, которые участвуют во
взаимодействии.
Типичные приемы моделирования
Поток управления
Чаще всего взаимодействия используют для моделирования потока управления,
характеризующего поведение системы в целом, включая прецеденты , образцы,
механизмы и каркасы, поведение одного класса или отдельной операции. При
этом классы, интерфейсы , компоненты , узлы и отношения между ними
моделируют статические аспекты системы, а взаимодействия - ее динамические
аспекты (для моделирования последних используются также автоматы.
Моделируя взаимодействия, вы, по сути дела, описываете последовательности
действий, выполняемых объектами из некоторой совокупности. Для выявления и
осмысления взаимодействий очень полезно применение CRC-карточек.
Моделирование потока управления состоит из следующих шагов:
Определите контекст взаимодействия, будь то система в целом, одиночный
класс или отдельная операция.
Опишите сцену, на которой будет происходить взаимодействие. Для этого нужно
идентифицировать объекты, играющие какую-либо роль, и установить их
начальные свойства, в том числе значения атрибутов, состояния и роли.
Если в вашей модели внимание акцентируется на структурной организации
объектов, идентифицируйте связи между ними, имеющие отношение к обмену
данными, который происходит во взаимодействии. При необходимости опишите
особенности каждой связи с помощью стандартных стереотипов и ограничений
UML.
Если основное внимание уделяется временной упорядоченности, специфицируйте
сообщения, передаваемые между объектами. В случае необходимости выделите
разные виды сообщений, включите в описание параметры и возвращаемые
значения.
Для передачи существенных деталей взаимодействия можно указать состояние и
роль каждого объекта ... продолжение
Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.
Похожие работы
Дисциплины
- Информатика
- Банковское дело
- Оценка бизнеса
- Бухгалтерское дело
- Валеология
- География
- Геология, Геофизика, Геодезия
- Религия
- Общая история
- Журналистика
- Таможенное дело
- История Казахстана
- Финансы
- Законодательство и Право, Криминалистика
- Маркетинг
- Культурология
- Медицина
- Менеджмент
- Нефть, Газ
- Искуство, музыка
- Педагогика
- Психология
- Страхование
- Налоги
- Политология
- Сертификация, стандартизация
- Социология, Демография
- Статистика
- Туризм
- Физика
- Философия
- Химия
- Делопроизводсто
- Экология, Охрана природы, Природопользование
- Экономика
- Литература
- Биология
- Мясо, молочно, вино-водочные продукты
- Земельный кадастр, Недвижимость
- Математика, Геометрия
- Государственное управление
- Архивное дело
- Полиграфия
- Горное дело
- Языковедение, Филология
- Исторические личности
- Автоматизация, Техника
- Экономическая география
- Международные отношения
- ОБЖ (Основы безопасности жизнедеятельности), Защита труда
