Точки ветвления и объединения потоков управления

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

Условие в точке ветвления имеет вид: если…иначе ( if…else ), и пара этих условий должна быть взаимоисключающей.

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

Точка объединения обозначает окончание условного ветвления, порожденного точкой ветвления, и имеет несколько входных потоков и один выходной.

На рис.6.6 показан простой пример диаграммы деятельности.

Условное поведение схематически обозначается с помощью решений (decisions) и слияний (merges). Решение имеет один входящий поток и несколько защищенных выходных потоков. Слияние обозначает завершение условного поведения, которое было начато решением.

Каждый выходной из решения поток имеет защиту – условное выражение, помещенное в квадратные скобки. Защиты должны быть взаимно исключающими. Применение [ else ] в качестве защиты означает, что поток [ else ] используется в том случае, когда другие защиты данного решения принимают ложное значение.

 

 

Рис.6.6. Простая диаграмма деятельности

 

Декомпозиция деятельности

Деятельность может быть разбита на вложенные деятельности (subactivities). Можно взять алгоритм доставки и определить его как самостоятельную деятельность, а затем вызвать его как операцию (рис.6.7).

 

Рис.6.7. Дополнительная диаграмма деятельности

Разделы

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

 

Сигналы

В простом примере на рис.6.6 диаграммы деятельности имеют четко определенную стартовую точку, соответствующую вызову программы или процедуры. Кроме того, деятельности могут отвечать на сигналы.

Временной сигнал – проходит по происшествии некоторого времени. Например, при окончании планового времени в отчетном периоде, или приходить каждую секунду в контроллере реального времени.

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

 

 

 

Рис.6.8. Распределение состояний деятельности между ролями

 

Рис.6.9. Сигналы в диаграмме деятельности

 

Можно как принимать сигналы, так и посылать их. Это полезно, когда мы посылаем сообщение, а затем должны ожидать ответа, перед тем, как продолжить поток управления (рис.6.10).

 

 

Рис.6.10. Отправка и прием сигналов

 

На приведенной диаграмме деятельности (рис.6.10), участвуют два потока управления: первый, достигший финального состояния, выигрывает и прерывает выполнение другого потока. Хотя блоки приема сигналов только ожидают внешнего события, мы можем также показать входящий в него поток. Это означает, что мы не начинаем прослушивание до тех пор, пока поток не инициирует прием.

 

 

В заключении следует отметить, что технология диаграмм деятельности очень обширна и требует значительного объема изложения. В этом разделе мы сделали попытку привести минимально необходимый материал для анализа и проектирования систем, освещенный в версиях языка UML. В наибольшей степени технология диаграмм деятельности может проявиться в случае применения UML как языка программирования в стандартном подходе MDA (Model Driven Architecture – архитектура, управляемая моделью)[21]. Здесь диаграммы деятельности являются ценным инструментом для представления логики поведения систем.

 

Диаграммы взаимодействия

В этом разделе рассмотрим две модели взаимодействия между объектами систем: диаграммы последовательности и кооперативные диаграммы (кооперации). Обе диаграммы отображают события, участвующие в процессе обработки информации вариантов использования, и сообщения, которыми обмениваются объекты. События на диаграмме последовательности упорядочены во времени, а кооперативная диаграмма организована вокруг самих объектов.

На диаграмме взаимодействия отображают процесс обработки информации для варианта использования: какие объекты нужны потоку, какими сообщениями обмениваются объекты, какие действующие лица инициируют поток и в какой последовательности отправляются сообщения. В варианте использования «Продажа авиабилета», как мы видели, имеется несколько альтернативных потоков. Это значит, что для данного варианта использования нужно создать несколько диаграмм взаимодействия: одна диаграмма будет показывать нормальный ход событий, другие – альтернативные потоки (может быть смешанный вариант).

Диаграммы взаимодействия предоставляют достаточно информации для того, чтобы можно было писать код реализации. Объекты диаграмм являются экземплярами классов, поэтому необходимо определить класс для каждого объекта. Сообщения в общем случае переходят в методы, а каждый метод помещается в класс, получающий сообщение (класс целевого объекта), но не в исходный класс, который вызывает метод. То, как будет выглядеть код реализации, зависит от двух факторов: опыта и языка программирования.

Рассмотрим два типа диаграмм взаимодействия – диаграммы последовательности и кооперативные диаграммы (коммуникационные диаграммы в версии языка UML 2.0). На диаграммах обоих типов представлена одна и та же информация, однако между ними существуют два различия. Диаграммы последовательности заостряют внимание на управлении, а коммуникационные - отображают поток данных. Главное в этих диаграммах - объекты, которые должны быть созданы для реализации функциональных возможностей, заложенных в анализируемый вариант использования. На диаграммах обоих типов могут быть показаны объекты, классы или то и другое вместе.

 

⇐ Предыдущая13141516171819202122Следующая ⇒

Поделиться: