ЛекUML

Реализация

DBMS

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

Для программных компонентов часто бывает нужно показать, какие объекты (классы) находятся в данном компоненте. Это можно сделать тремя способами: поместить изображение фигуры класса внутрь фигуры компонента;

включить внутрь фигуры компонента дополнительный раздел с текстовым списком имен классов;

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

4.3.5. Диаграммы размещения

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

На диаграмме размещения, по сравнению с диаграммами компонентов, применяются только один дополнительный тип сущности — узел и два дополнительных отношения: ассоциация между узлами и размещение компонента на узле. В остальном диаграммы размещения наследуют возможности диаграмм компонентов. Узел — это физический вычислительный ресурс, участвующий в работе системы. Компоненты системы во время ее работы размещаются на узлах. На диаграмме узел представляется фигурой, изображающей прямоугольный параллелепипед. Ассоциация между узлами означает то же, что и в других контекстах: возможность обмена сообщениями. Применительно к вычислительным сетям ассоциация означает наличие канала связи. Если нужно указать дополнительную информацию о свойствах канала, то это можно сделать используя общие механизмы: стереотипы, ограничения и именованные значения, приписанные ассоциации.

Размещение компонента на узле, как правило, изображают, помещая фигуру компонента внутрь фигуры узла.

Ниже представлена диаграмма размещения для нашего примера.

Выводы

Структура сложной системы описывается на уровне дескрипторов Диаграммы классов моделируют структуру объектов и связей между ними

Классы выбираются на основе анализа предметной области, взаимного согласования элементов модели и общих теоретических соображений

Диаграмма объектов — это пример связей программных объектов в отдельный момент выполнения системы

Диаграммы компонентов моделируют структуру компонентов (артефактов) и взаимосвязей между ними

Диаграммы размещения моделируют структуру вычислительных ресурсов и размещение компонентов

Лекция 5. Моделирование поведения

Что такое моделирование поведения?

Как может статическая модель описывать динамическое поведение? Что такое конечный автомат?

Какие элементы применяются для моделирования поведения? Для чего применяются диаграммы состояний?

Что общего и в чем различие диаграмм состояний и деятельности? Какова область применения диаграмм взаимодействия?

5.1. Объектно-ориентированное моделирование поведение

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

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

Модель поведения должна быть компактной и обозримой, чтобы служить средством общения между людьми в процессе разработки системы и для обмена идеями.

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

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

Удовлетворить сразу всем требованиям в полной мере практически невозможно — средства моделирования поведения UML являются результатом многочисленных компромиссов.

5.1.2. Поведение приложения

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

Для пользователя поведение приложения проявляется прежде всего в интерфейсе. В принципе возможны два архитектурных решения интерфейса с пользователем:

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

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

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

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

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

устоявшейся за последние несколько лет привычкой массового пользователя к пассивному интерфейсу.

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

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

Однако приложения для бизнеса с пассивным пользовательским интерфейсом являются хотя и распространенным, но не единственным типом приложений. Нетрудно привести примеры важных типов приложений, в которых реакция на внешние события отсутствует или играет второстепенную роль: компиляторы, программы инженерно-технических и научных расчетов и др. В таких программах для описания поведения традиционно используется понятие потока управления. Поток управления — это последовательность выполнения операторов (команд) в программе. Если программа представляет собой просто последовательность операторов, то операторы в программе выполняются по очереди в естественном порядке (от начала к концу). В этом случае поток управления просто совпадает с последовательностью операторов в программе. Однако обычно это не так. Вопервых, на поток управления оказывают влияние различные управляющие конструкции: операторы перехода, условные операторы, операторы цикла и т. д. Вовторых, в большинстве практических систем программирования используется понятие подпрограммы: при выполнении оператора вызова подпрограммы выполнение операторов программы приостанавливается, управление передается в подпрограмму, т. е. в поток управления попадают операторы подпрограммы, а при выходе из подпрограммы возобновляется выполнение операторов программы. При этом считается, что вызванная подпрограмма активизирована и остается таковой, пока не возобновится выполнение вызвавшей программы или подпрограммы. Кроме того, на поток управления влияют факторы, находящиеся вне данной программы, например, поток управления меняется при обработке прерываний и при возникновении событий. Различаются однопоточные (т. е. с одним потоком управления) и многопоточные программы. Характерным признаком однопоточной программы является то, что в каждый момент времени можно указать единственный оператор программы, который выполняется в данный момент — говорят, что этот оператор имеет фокус управления. В многопоточной программе имеется несколько потоков управления и сосуществуют несколько фокусов управления, соответственно. При этом совершенно необязательно, чтобы различные потоки управления выполнялись физически одновременно на разных процессорах: достаточно иметь в операционной системе механизм, обеспечивающий переключение процессора на выполнение разных потоков управления.

5.1.3.Средства моделирования поведения

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

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

Диаграммы состояний можно составить не только для программных объектов — экземпляров отдельных классов, но и для более крупных конструкций, в частности, для всей модели приложения в целом или для более мелких — отдельных операций. Для описания потока управления, т. е. последовательности выполняемых элементарных шагов при выполнении отдельной операции или реализации сложного варианта использования, удобно использовать диаграммы деятельности. Взаимодействие нескольких программных объектов между собой описывается диаграммами взаимодействия (диаграммы кооперации и диаграммы последовательности). Моделирование многопоточности в UML выполняется с помощью понятия активного класса.

5.2. Диаграммы состояний

Диаграммы состояний в UML являются реализацией конечных автоматов как средства описания алгоритмов. На диаграммах состояний применяется всего один тип сущностей — состояния, и всего один тип отношений — переходы. Совокупность состояний и переходов между ними образует машину состояний. Машина состояний состоит из набора состояний, для каждого из которых определены исходящие (outgoing) переходы и входящие (incoming) переходы, и набора переходов, для каждого из которых определено исходное (source) и целевое (target) состояния.

Состояния бывают: простые,

составные, специальные

Каждый тип состояний имеет дополнительные подтипы и различные составляющие элементы.

Переходы бывают простые и составные, и каждый переход содержит от двух до пяти составляющих:

исходное состояние, событие перехода, сторожевое условие, действие на переходе, целевое состояние.

5.2.1. Простое состояние

Простое состояние имеет следующую структуру: имя;

действие при входе; действие при выходе;

множество внутренних переходов; внутренняя активность;

множество отложенных событий.

Имя состояния является обязательным. Все остальные составляющие простого состояния не являются обязательными.

Действие при входе (обозначается при помощи ключевого слова entry) — это указание атомарного действия, которое должно выполняться при переходе автомата в данное состояние. Действие при входе выполняется после всех других действий, предписанных переходом, переводящим автомат в данное состояние.

Действие при выходе (обозначается при помощи ключевого слова exit) — это указание атомарного действия, которое должно выполняться при переходе автомата из данного состояние. Действие при выходе выполняется до всех других действий, предписанных переходом, выводящим автомат из данного состояния.

Множество внутренних переходов — это множество простых переходов из данного состояния в это же состояние (так называемых переходов в себя). Внутренний переход отличается от простого перехода в себя тем, что действия при выходе и входе не выполняются. Синтаксис внутреннего перехода совпадает с синтаксисом простого перехода.

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

5.2.2. Простой переход

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

Прочие составляющие — событие перехода, сторожевое условие и действия на переходе не являются обязательными. Если они присутствуют, то изображаются в виде текста в определенном синтаксисе рядом со стрелкой, изображающей переход. Синтаксис описания перехода следующий:

Событие [ Сторожевое условие ] / Действие

Общая семантика перехода такова. Допустим, что автомат находится в состоянии S1, в котором определен исходящий переход T с событием Е, сторожевым условием G и

действием D, ведущий в состояние S2. Если возникает событие E, то переход T возбуждается (в данном состоянии могут быть одновременно возбуждены несколько переходов — это не считается противоречием в модели). Далее проверяется сторожевое условие G (проверяются сторожевые условия всех возбужденных переходов в неопределенном порядке). Если сторожевое условие выполнено, то переход T срабатывает — выполняется действие на выходе из состояния S1, выполняется действие на переходе D, выполняется действие на входе в состояние S2 и автомат переходит в состояние S2. Даже если у нескольких возбужденных переходов сторожевые условия оказываются истинными, то, тем не менее, срабатывает всегда только один переход из возбужденных. Какой именно переход срабатывает — не определено. Таким образом поведение, описываемое подобным автоматом, является недетерминированным. Если же сторожевое условие G не выполнено, то переход T не срабатывает. Если ни один из возбужденных переходов не срабатывает, то событие T теряется и автомат остается в состоянии S1. Событие перехода — это тот входной символ (стимул), который определяет следующее состояние. UML допускает наличие переходов без событий — такой переход называется переходом по завершении. Семантика перехода по завершении такова. Имеется одно неявное, а потому безымянное событие, которое наступает при завершении внутренней активности в состоянии (если никакой внутренней активности не предусмотрено, то это событие наступает немедленно после перехода автомата в данное состояние). Поскольку событие завершения является безымянным, оно никак не отображается на диаграмме: в тексте, сопутствующем переходу, просто отсутствует первая часть, относящаяся к событию перехода. В остальном переходы по завершении ничем не отличаются от простых переходов: они могут содержать сторожевые условия, может быть несколько исходящих переходов по завершении для данного состояния (с альтернативными сторожевыми условиями), для переходов по завершении можно определять последовательности действий при переходе и т. д. Сторожевое условие — это логическое выражение, которое должно оказаться истинным для того, чтобы возбужденный переход сработал. Для каждого возбужденного перехода сторожевое условие проверяется ровно один раз, сразу после того, как переход возбужден и до того, как в системе произойдут какие-либо другие события. Если сторожевое условие ложно, то переход не срабатывает и событие теряется. Даже если впоследствии сторожевое условие станет истинным, переход сможет сработать только если повторно возникнет событие перехода.

Как уже было сказано, возможны несколько исходящих переходов из данного состояния с одним и тем же событием перехода, но с разными сторожевыми условиями. Все такие переходы возбуждаются при наступлении события перехода, но только один срабатывает. Сторожевые условия формулируются относительно значений аргументов события перехода и значений атрибутов объекта, поведение которого моделируется. Для того, чтобы поведение автомата было определено детерминировано, набор сторожевых условий должен образовывать полную систему, т. е. при любых значениях переменных, входящих в сторожевое условие, ровно одно из сторожевых условий должно быть истинным. Сторожевые условия могут написаны на любом языке, в частности, на естественном. Поэтому автоматически проверить выполнение данного требования невозможно. В UML предусмотрены синтаксические средства, облегчающие семантически правильное построение сторожевых условий за счет более наглядного их изображения. Это:

сегментированные переходы;

символы ветвления; переходные состояния;

предикат else.

Линия перехода может быть разбита на части, называемые сегментами. Разбивающими элементами являются следующие фигуры:

переходное состояние (изображается в виде небольшого кружка); ветвление (изображается в виде ромба); действия посылки и приема сигнала.

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

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

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

Действие является безальтернативным и завершаемым. Раз начавшись, действие выполняется до конца. Оно не может "раздумать" выполняться или выполняться неопределенно долго.

Последовательность действий также является действием. (Синтаксически, действия в последовательности разделяются запятыми).

Действия являются важнейшей частью описания поведения с помощью конечных автоматов.