2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 67
Текст из файла (страница 67)
Моделирование потоков управленияТипичные приемы моделированияАвтоматыобсуждаются в главе 22347К подобным диаграммам часто присоединяют автоматы с ортогональными состояниями, чтобы в деталях передать поведениеактивных объектов.Моделирование межпроцессныхкоммуникацийПри включении в систему нескольких потоков управления необходимо также рассмотреть механизмы, с помощью которых объекты из разных потоков управления взаимодействуют друг с другом.Объекты, находящиеся в разных потоках (существующих в рамкаходного и того же процесса), могут общаться с помощью событий,сигналов или вызовов, причем последние могут иметь синхроннуюи асинхронную семантику.
Для обмена информацией через границы процессов, у каждого из которых свое собственное адресное пространство, обычно применяются другие механизмы.МоделиСложность проблемы межпроцессной коммуникации усугуброваниеляется еще и тем, что в распределенных системах процессы могутместорасвыполняться на различных узлах. Существует два классическихположенияподхода к межпроцессной коммуникации: передача сообщенийобсуждается и вызовы удаленных процедур.
В UML эти механизмы моделив главе 24.руются как асинхронные и синхронные события соответственно.Но поскольку это уже не простые вызовы внутри одного процесса,то проект необходимо обогатить дополнительной информацией.Для моделирования межпроцессной коммуникации необходимо:Сигналыи событиявызоваобсуждаютсяв главе 21.Стереотипыи примечания обсуждаютсяв главе 6,кооперации –в главе 28. Смоделировать несколько потоков управления.
Смоделировать обмен сообщениями с помощью асинхронных коммуникаций, а вызовы удаленных процедур – с помощью синхронных. Неформально описать используемый механизм с помощьюпримечаний или, более строго, с помощью коопераций.На рис. 23.5 показана распределенная система бронированиябилетов, в которой процессы выполняются в четырех узлах. Каждый объект маркирован стереотипом process, а также помеченнымзначением location, которое определяет его физическое положение.Коммуникации между объектами ReservationAgent (АгентБронирования), TicketingManager (ДиспетчерВыдачиБилетов) и HotelAgent (ГостиничныйАгент) асинхронны. В примечании написано, что коммуникации построены на основе службы сообщений, реализованнойна JavaBeans. Коммуникация между объектами TripPlanner (ПланировщикМаршрута) и ReservationSystem (СистемаРезервирования)синхронная. Семантика их взаимодействия показана в кооперации,Процессы и потоки348названной CORBA ORB.
TripPlanner выступает в роли клиента,а ReservationAgent – сервера. Раскрыв эту кооперацию, вы увидите детали совместной работы сервера и клиента.Глава 24. Время и пространство««»В этой главе»««»»Рис. 23.5. Моделирование межпроцессной коммуникацииСоветы и подсказкиХорошо структурированные активный класс и активный объект обладают следующими свойствами: представляют независимый поток управления, который максимально использует возможности истинного параллелизмав системе; не настолько мелки, чтобы требовать наличия других активных элементов, избыток которых может создать переусложненную и нестабильную архитектуру процессов; аккуратно управляют коммуникацией между активными элементами, выбирая наиболее подходящий случаю механизм –синхронный или асинхронный; исходят из трактовки каждого объекта как критической области, используя подходящие синхронизирующие свойства длясохранения его семантики в присутствии нескольких потоков управления.Рисуя в UML активный класс или активный объект, руководствуйтесь следующими принципами: показывайте только те атрибуты, операции и сигналы, которые важны для понимания абстракции в соответствующемконтексте; явно показывайте все синхронизирующие свойства операции.Время, длительность и местоположениеМоделирование временных ограниченийМоделирование распределения объектовМоделирование мигрирующих объектовСистемы реального времени и распределенные системыКак уже говорилось, реальный мир суров и не прощает ошибок.События в нем происходят в непредсказуемые моменты времени и, тем не менее, требуют адекватной и своевременной реакции.Системные ресурсы могут быть распределены по всему миру, а некоторые способны перемещаться в пространстве, – в связи с этимвозникают проблемы задержек, синхронизации, безопасности и качества услуг.Моделирование времени и пространства – важный элемент любой распределенной системы или системы реального времени.
Длявизуализации, специфицирования, конструирования и документирования таких систем UML предлагает различные средства, включая отметки времени, временные выражения, ограничения и помеченные значения.Проектирование систем реального времени и распределенныхсистем – трудная задача. Хорошая модель должна высветить всенеобходимые и достаточные пространственноFвременные свойствасистемы.ВведениеПриступая к моделированию большинства программных систем, обычно делают установку на идеальность среды: предполагают,что доставка сообщения осуществляется мгновенно, сетевые сбоиисключены, рабочие станции никогда не выходят из строя, а загрузка сети всегда равномерна.
К сожалению, реальность отнюдьне укладывается в эту схему: сообщения доставляются с некоторой задержкой (а иногда и вовсе не доставляются), сеть «падает»,Время и пространство350Компонентыобсуждаются в главе 26,узлы – в главе 27.рабочие станции «зависают» и загрузка сети далека от сбалансированной. Поэтому, рассматривая моделируемую систему, необходимо принимать во внимание как пространственные, так и временныехарактеристики.Система реального времени (real time system) называется такпотому, что она должна выполнять свои функции в строго определенный абсолютный или относительный момент времени и затрачивать на это предсказуемое и зачастую ограниченное время. Среди подобных систем бывают такие, для которых требуемое времяреакции исчисляется наноF или миллисекундами. Но встречаютсясистемы «почти реального времени», для которых допустимое время реакции – порядка секунды и даже больше.Под распределенной системой (distributed system) понимаетсятакая система, компоненты которой могут быть физически размещены на различных узлах.
Узлы могут представлять собой разныепроцессоры, смонтированные в одном и том же корпусе, или разные компьютеры, находящиеся в противоположных точках земногошара.Чтобы удовлетворить потребности моделирования систем реального времени и распределенных систем, UML включает графическое представление для отметок времени, временных выражений, временных ограничений и местоположения, как показанона рис. 24.1.location = consolelocation = serverlocation = central—отметки времени—{b-a < 10 ms}Рис. 24.1.
Временные ограничения и местоположениеБазовые понятияОтметка времени (timing mark) служит для обозначения момента времени, в который произошло событие. Она изображаетсяв виде засечки (короткой горизонтальной линии) на границе диаграммы последовательности.Базовые понятия351Временное выражение (time expression) – это выражение, значением которого является абсолютное или относительное время. Временное выражение может быть также сформировано с использованием имени сообщения и указания стадии его обработки, напримерrequest.sendTime или request.receiveTime.Временное ограничение (timing constraint) – это семантическоеутверждение об относительном или абсолютном времени. Графически временное ограничение изображается как любое другое –строкой, заключенной в скобки, и обычно связано с некоторым элементом зависимостью.Местоположение (location) – это размещение компонента в узле.Является атрибутом объекта.ВремяСобытия,включаясобытиявремени,обсуждаютсяв главе 21,сообщенияи взаимодействия –в главе 16,временныеограничения – в главе 6.Для систем реального времени, как следует из самого названия,важна своевременность реакции.
События в них могут происходитьрегулярно или спонтанно, но в любом случае время реакции на событие должно быть предсказуемо – либо в абсолютном выражении,либо относительно момента возникновения события.Передача сообщений – это один из динамических аспектов любой системы, поэтому при моделировании ее временных особенностей с помощью UML можно каждому сообщению, принимающемуучастие во взаимодействии, дать имя, которое будет использоваться как отметка времени. Обычно сообщениям, принимающим участие во взаимодействии, имена не присваиваются. Как правило, приих изображении используется имя события, например сигнала иливызова. При этом нельзя вводить имя события в запись выражения,поскольку одно и то же событие может повлечь за собой различные сообщения.
Если имеет место такого рода неоднозначность,следует присвоить явное имя сообщению в отметке времени, чтобыв дальнейшем его можно было использовать во временном выражении. Если задано имя сообщения, допускается применение любой из трех его функций – sendTime, receiveTime, transmissionTime. (Этифункции – наше собственное изобретение, они не описаны в UML.Системы реального времени могут включать и другие функции.)Для синхронных вызовов можно также указать ссылку на времякругового (roundFtrip) сообщения – executionTime (еще одно наше нововведение). Эти функции удобны для построения сложных временных выражений (в том числе включающих веса и смещение),которые представляют собой константы или переменные (если этипеременные можно вычислить в момент выполнения). Наконец,как показано на рис.
24.2, временное выражение можно поместитьвнутрь временного ограничения, чтобы описать поведение системыВремя и пространство352Типичные приемы моделирования353в виде артефакта initializer.exe, который размещается на узле типаRouter (Маршрутизатор).Как видно из рисунка, моделировать положение артефактав UML можно двумя способами. ВоFпервых, как в случае с Router,можно физически поместить элемент (его текстовое или графическое описание) в дополнительный раздел включающего узла.ВоFвторых, вы можете использовать зависимость с ключевым словом «deploy» от артефакта к узлу, который его содержит.местоположениепо вложенностиво времени. Как и любые другие ограничения, они изображаютсярядом с соответствующим сообщением или явно присоединяютсяс помощью связей зависимости.«manifest»На заметку. Вместо явного упоминания времени в выражениях стоит употреблять именованные константы, в особенности при моделировании сложных систем.