На этом шаге рассмотрим моделирование межпроцессных коммуникаций в UML.
При включении в систему нескольких потоков управления необходимо также рассмотреть механизмы, с помощью которых объекты из разных потоков управления взаимодействуют друг с другом. Объекты, находящиеся в разных потоках (существующих в рамках одного и того же процесса), могут общаться с помощью событий, сигналов или вызовов, причем последние могут иметь синхронную и асинхронную семантику. Для обмена информацией через границы процессов, у каждого из которых свое собственное адресное пространство, обычно применяются другие механизмы.
Сложность проблемы межпроцессной коммуникации усугубляется еще и тем, что в распределенных системах процессы могут выполняться на различных узлах. Существует два классических подхода к межпроцессной коммуникации: передача сообщений и вызовы удаленных процедур. В UML эти механизмы моделируются как асинхронные и синхронные события соответственно. Но поскольку это уже не простые вызовы внутри одного процесса, то проект необходимо обогатить дополнительной информацией.
Для моделирования межпроцессной коммуникации необходимо:
- смоделировать несколько потоков управления;
- смоделировать обмен сообщениями с помощью асинхронных коммуникаций, а вызовы удаленных процедур – с помощью синхронных;
- неформально описать используемый механизм с помощью примечаний или, более строго, с помощью коопераций.
На рис. 1 показана распределенная система бронирования билетов, в которой процессы выполняются в четырех узлах.
Рис.1. Моделирование межпроцессной коммуникации
Каждый объект маркирован стереотипом process, а также помеченным значением location, которое определяет его физическое положение. Коммуникации между объектами ReservationAgent (АгентБронирования), TicketingManager (ДиспетчерВыдачиБилетов) и HotelAgent (ГостиничныйАгент) асинхронны. В примечании написано, что коммуникации построены на основе службы сообщений, реализованной на JavaBeans. Коммуникация между объектами TripPlanner (ПланировщикМаршрута) и ReservationSystem (СистемаРезервирования) синхронная. Семантика их взаимодействия показана в кооперации, названной CORBA ORB. TripPlanner выступает в роли клиента, а ReservationAgent – сервера. Раскрыв эту кооперацию, вы увидите детали совместной работы сервера и клиента.
Хорошо структурированные активный класс и активный объект обладают следующими свойствами:
- представляют независимый поток управления, который максимально использует возможности истинного параллелизма в системе;
- не настолько мелки, чтобы требовать наличия других активных элементов, избыток которых может создать переусложненную и нестабильную архитектуру процессов;
- аккуратно управляют коммуникацией между активными элементами, выбирая наиболее подходящий случаю механизм – синхронный или асинхронный;
- исходят из трактовки каждого объекта как критической области, используя подходящие синхронизирующие свойства для сохранения его семантики в присутствии нескольких потоков управления.
Рисуя в UML активный класс или активный объект, руководствуйтесь следующими принципами:
- показывайте только те атрибуты, операции и сигналы, которые важны для понимания абстракции в соответствующем контексте;
- явно показывайте все синхронизирующие свойства операции.
На следующем шаге рассмотрим временные ограничения и местоположение в распределенной системе.
