
ЛекUML
.pdfДеятельность в UML — это средство структурной композиции действий. Деятельность в UML моделирует то же, что и действие, т. е. какую-то содержательную активность во время работы системы; в этом смысле деятельность подобна действию, но деятельность противопоставляется действию по всем характеристическим признакам.
Сопоставление действия и деятельности |
|
|
|
|
|
Характеристика |
Действие |
Деятельность |
|
||
Внешнее событие |
Не прерывает выполнения |
Может |
прервать |
и |
|
|
|
|
завершить выполнение |
|
|
Завершаемость |
Всегда |
завершается |
Может |
продолжаться |
|
|
самостоятельно |
|
неограниченно долго |
|
|
Внутренняя структура |
Не моделируется в UML |
Может |
быть раскрыта |
в |
|
|
|
|
отдельной диаграмме |
|
|
Время выполнения |
Пренебрежимо мало |
Продолжительное |
|
Теперь мы может точно и кратко определить основные сущности на диаграмме деятельности UML. Таковых две:
состояние действия — это состояние, внутренняя активность которого является действием;
состояние деятельности— это состояние, внутренняя активность которого является деятельностью.
Состояние действия не имеет специальной нотации и изображается на диаграмме как простое состояние с действием на входе.
Состояние деятельности, является существенным элементом диаграммы деятельности и имеет специальное обозначение — прямоугольник со скругленными сторонами. Это обозначение очень похоже на обозначение простого состояния (прямоугольник со скругленными углами), но в тоже время отлично от него. Тем самым подчеркивается родственная связь диаграмм состояний и действий. Внутри фигуры состояния деятельности пишется так называемое выражение деятельности. Никакого специального синтаксиса для данного выражения UML не определяет: это может быть текст на псевдокоде, фрагмент кода на языке программирования и просто название деятельности на естественном языке. Никакой видимой внутренней структуры состояние деятельности не имеет, в противоположность простому состоянию, которое может иметь действия на входе, выходе, внутренние и отложенные переходы.
5.3.2. Переходы по завершении и ветвления
На диаграмме деятельности применяется один основной тип отношений — простые переходы по завершении. Переход по завершении не имеет возбуждающего события — событием является завершение внутренней активности (деятельности) в состоянии. Как правило, исходящий переход по завершении один; если их несколько, они должны быть снабжены сторожевыми условиями, образующими полную систему. Кроме того, можно использовать и переходы, возбуждаемые событиями.

Срабатывание такого перехода означает прерывание выполнения деятельности в состоянии и переход в другое состояние.
5.3.3.Дорожки
ВUML имеется своеобразное графическое средство, которое называется дорожкой. Дорожка — это графический комментарий, позволяющий классифицировать по некоторому признаку сущности на диаграмме активности. Дорожка не является элементом модели — в метамодели UML нет такого понятия. Это именно графический комментарий, подобный границам системы на диаграмме использования. Дорожки (или подобные им конструкции) часто применяются при моделировании бизнес-процессов в организациях, откуда они и были заимствованы в UML. Рассмотрим бизнес-процесс приема сотрудника на работу в нашей информационной системе отдела кадров. Мы считаем, что наш процесс включает четыре деятельности:
Interview — сбор информации;
Approve — анализ собранной информации и принятие решения;
Fill Forms — заполнение документов;
Refuse — отказ в найме.
Interview
|
|
Approve |
|
|
[accept] |
[reject] |
|
FillForms |
Refuse |
||
|
На диаграмме пока нет никаких дорожек — все деятельности равноправны и однородны. Допустим теперь, что деятельность, в которую нанимаемый вовлечен непосредственно (Interview, Fill Forms, Refuse) происходит в одном месте и, так сказать, у него на глазах, а важная деятельность (о которой нанимаемый может не догадываться) по анализу информации и принятию решения осуществляется в другом месте и, может быть, другими действующими лицами (техническими специалистами, руководителями подразделений и т. д.). Эта важная

информация не является частью модели, т. к. не имеет отношения к поведению системы, но мы можем отразить ее на диаграмме с помощью дорожек.
HR Dpt |
Some Dpt |
Interview |
Approve |
[accept]
FillForms
[reject]
Refuse
Графически дорожки изображаются в виде прямоугольников с названиями.
5.3.4. Траектория объекта
Диаграммы деятельности UML позволяют моделировать поведение не только определяя поток управления, как в приведенных выше примерах, но и поток данных. При объектно-ориентированном подходе к моделированию поток данных — это изменение состояний объектов во времени, и описание такого изменения существенным образом характеризует поведение. Для описания данной характеристики поведения в UML используются понятия траектория объекта и объект в состоянии.
Объект в состоянии — это объект некоторого класса, про который известно, что он находится в определенном состоянии в данной точке вычислительного процесса. Синтаксически объект в состоянии изображается, как обычно, в виде прямоугольника и его имя подчеркивается, но дополнительно после имени объекта в квадратных скобках пишется имя состояния, в котором в данной точке вычислительного процесса находится объект. В некоторых случаях состояние объекта не важно, например, если достаточно указать, что в данной точке вычислительного процесса создается новый объект данного класса, и в этом случае применяется обычная нотация для изображения объектов. Важно подчеркнуть, что
объект в состоянии на диаграммах деятельности "по определению" считается состоянием.
Траектория объекта — это переход особого рода, исходным и/или целевым состоянием которого является объект в состоянии. Траектория объекта изображается
ввиде пунктирной стрелки (в отличии от сплошной стрелки обычного перехода). Семантически траектория объекта, проведенная от состояния деятельности к объекту
всостоянии означает, что результатом деятельности является переход указанного объекта в данное состояние (или может быть, создание нового объекта в указанном состоянии, что является частным случаем изменения состояния). Траектория объекта, проведенная от объекта в состоянии к состоянию деятельности к означает, что объект
вданном состоянии является необходимым входным данным указанной деятельности.
Рассмотрим это на примере диаграммы деятельности, описывающей процесс найма сотрудника в информационной системы отдела кадров. Здесь представлена
траектория объекта класса Person, хранящего данные о принимаемом сотруднике. На диаграмме хорошо видно, что именно является входными и выходными данными каждого из состояний деятельности: в результате деятельности Interview создается новый объект, который далее обрабатывается, меняя свое состояние.

|
HR Dpr |
Some Dpt |
|
Interview |
Approve |
|
|
: Person |
|
|
[Empty] |
: Person |
Fill Forms |
[accept] |
[Accepted] |
|
|
|
|
|
|
|
: Person |
|
|
[Approved] |
: Person |
Refuse |
[reject] |
[Rejected] |
|
|
|
|
5.3.5.Отправка и прием сигналов
ВUML имеется довольно много обозначений, применяемых для повышения наглядности, сокращения записи и просто для украшения диаграмм. Особенно много таких украшений предусмотрено для диаграмм деятельности. К таким обозначениям можно отнести специальную нотацию, применяемую для обозначения действий по отправке и получению сигналов на переходах.
Вернемся еще раз к примеру с наймом на работу и допустим, что мы хотим отразить в модели несколько иной вариант поведения. Ранее мы предполагади,что процесс происходящий в приемной отдела кадров приостанавливается на то время, пока не будут завершена деятельность по оценке кандидата и принятию решения, которая фактически происходит в другом месте. Такое вынужденное ожидание может быть психологически неприятно кандидату (равно как и менеджеру по персоналу). Допустим, что в проектируемой информационной системы отдела кадров требуется обеспечить асинхронное проведение процесса приема: после сбора сведений о кандидате менеджер по персоналу отправляет сигнал в соответствующие инстанции и в ожидании ответного сигнала с решением переводит себя и кандидата в состояние

ожидания с внутренней активностью — угощает чаем, рассказывает о миссии организации и т. п. В рамках уже рассмотренных обозначений такая ситуация может быть описана диаграммой деятельности (с использованием простого состояния), как показано на рисунке ниже.
Interview Состояние
деятельности
Переход по
завешении / send Request(person)
с действием отправка сигнала
Bla-bla-bla
Простое
состояние
Переход
по событию Answer(desicion)
сигнала
|
[decision = accept] |
[decision = reject] |
|
Fill Forms |
Refuse |
||
|
Сегменты перехода со сторожевыми условиями
Приведенная здесь диаграмма точно описывает желаемое поведение, но может показаться не слишком наглядной: между тем имеется хорошо знакомая очень многим наглядная система обозначений для передачи и приема сигналов - эта система обозначений также включена в UML.

Состояние Interview деятельности
Отправка
Request сигнала
Простое
состояние Bla-bla-bla
Answer
Прием
сигнала
|
[decision = accept] |
[decision = reject] |
|
Fill Forms |
Refuse |
||
|
Сегменты перехода со сторожевыми условиями
5.4. Диаграммы взаимодействия
Диаграммы взаимодействия предназначены для моделирования поведения путем описания взаимодействия объектов. Взаимодействие происходит путем обмена сообщениями. Диаграммы взаимодействия применяются на разных уровнях моделирования: как для описания поведения отдельных операций, так и целых вариантов использования. Данный тип диаграмм позволяет описывать не только взаимодействие программных объектов (экземпляров классов), но и взаимодействие экземпляров иных классификаторов: действующих лиц, вариантов использования, подсистем, компонентов, узлов. Диаграммы взаимодействия графически изображаются в двух формах: диаграммы последовательности и диаграммы кооперации.
Диаграммы кооперации и диаграммы последовательности семантически эквиваленты, хотя графически выглядят совсем по-разному. Семантически эти диаграммы эквиваленты потому, что описывают одно и то же: последовательность передачи сообщений между объектами в процессе взаимодействия объектов. А выглядят по-разному они потому, что в диаграмме последовательности графически подчеркивается упорядоченность во времени передаваемых сообщений, в то время как в диаграмме кооперации на передний графический план выдвигается структура связей между объектами, по которым передаются сообщения.
Диаграммы взаимодействия находятся "ближе" к реальному выполнению программы, чем другие средства описания поведения. Слабость диаграмм взаимодействия
состоит в том, что это диаграммы описывают поведение на уровне объектов, а не классов, на уровне протоколов выполнения алгоритма, а не самого алгоритма. Диаграммы взаимодействия менее "алгоритмичны", чем машины состояний и диаграммы деятельности.
На диаграммах обоих типов основными сущностями являются объекты: экземпляры классификаторов — классов и действующих лиц. Отношениями же являются связи, т. е. экземпляры ассоциаций, по которым передаются сообщения.
Наряду с основными сущностями и отношениями на диаграммах последовательности и кооперации применяется множество дополнительных элементов нотации.
Но прежде чем переходить к особенностям нотации, необходимо рассмотреть основные элементы, используемые на этих диаграммах — сообщения.
5.4.1. Сообщения
Сообщение — это передача управления и информации от одного объекта (отправителя) к другому (получателю). Отправка сообщения является действием, а получение сообщения — событием.
В UML действия связанными с передачей информации(сообщений) считаются: вызов операции;
создание объекта; уничтожение объекта; возврат значения; посылка сигнала.
Действие записывается в виде текста над стрелкой, символизирующей сообщение. Если действие имеет параметры (вызов операции, создание объекта, посылка сигнала), то аргументы, соответствующие параметрам по числу и типам, записываются справа от имени действия в круглых скобках. Если действием является вызов операции, возвращающей значения, то слева от имени записывается список переменных для возвращаемых значений (их может быть несколько в случае широковещательного вызова) знак присваивания :=. Таком образом, имеется следующий синтаксис.
переменные := ИМЯ ( аргументы )
Сообщение имеет отправителя и получателя. Получателей может быть несколько, такое сообщение называется широковещательным. Все получатели широковещательного сообщения получают одно и то же сообщение.
Поскольку получение сообщения является событием, то получатель сообщения вместе с информацией получает и управление. В UML различается несколько типов тип передачи управления с помощью сообщения. Чтобы отличить тип передачи сообщения, в UML применяется специальная графическая нотация, различаются виды стрелок, которыми обозначаются сообщения.
Для того, чтобы сообщение могло быть передано от отправителя к получателю, отправитель должен "знать" получателя. Другими словами, должна существовать ассоциация между классами отправителя и получателя, экземпляр которой (связь) и служит тем путем, по которому передается сообщение. На диаграмме кооперации эта
связь всегда изображается в явном виде, на диаграмме последовательности она подразумевается.
Однако поведение определяется не только и не столько тем, какие объекты посылают какие сообщения, но прежде всего тем, в каком порядке это происходит. UML позволяет определить относительный порядок сообщений во взаимодействии, причем это делается несколькими различными способами.
На диаграмме последовательности порядок сообщений определяется временем их отправки, а время считается текущим на диаграмме сверху вниз. Таким образом, сообщения, изображенные выше, предшествуют сообщениям, изображенным ниже.
Порядок можно задать с помощью последовательного номера сообщения. Данные номера уникальны и обладают тем свойством, что сообщения с меньшими номерами предшествуют сообщениям с большими.
Порядок можно указать, перечислив (через запятую) номера сообщений,
предшествующих данному.
5.4.2. Диаграммы последовательности
Диаграмма последовательности предназначена для моделирования поведения в форме описания протокола сеанса обмена сообщениями между взаимодействующими объектами во время выполнения одного из возможных сценариев
На диаграмме присутствуют только те объекты, которые задействованы в данном сеансе. Прочие объекты не показываются, хотя возможно и присутствуют в системе.
Отображаются только те связи (экземпляры ассоциаций), которые нужны для передачи данной последовательности сообщений, прочие ассоциации не показываются.
Состав сообщений (а тем самым операций и сигналов) определяется назначением данного взаимодействия; в других взаимодействиях эти же объекты могут обмениваться другими сообщениями.
На диаграмме последовательности считается выделенным одно направление, соответствующее течению времени. Считается, что время течет сверху вниз. Сообщения изображаются прямыми стрелками разного вида. Если передача сообщения считается мгновенной (т. е. время передачи пренебрежимо мало), то стрелка горизонтальна. Если же нужно отобразить задержанную доставку сообщения, то стрелку немного наклоняют, так чтобы конец стрелки был ниже начала.
Среди сообщений есть первое, которое кладет начало данному взаимодействию. Стрелка этого сообщения расположена выше всех других стрелок сообщений. Все объекты, которые находятся выше первого сообщения, существуют до начала данного взаимодействия; все объекты, которые расположены ниже, возникают в процессе данного взаимодействия. Обычно объект возникает в результате выполнения конструктора класса данного объекта. Стрелку сообщения, соответствующую вызову операции конструктора, принято направлять к фигуре (прямоугольнику), обозначающей созданный объект.

В направлении оси времени от всех участвующих во взаимодействии объектов отходит прямая пунктирная линия, которая называется линией жизни. Линия жизни представляет объект во взаимодействии: если стрелка отходит от линии жизни объекта, то это означает, что данный объект отправляет сообщение, а если стрелка сообщения входит в линию жизни, то это означает, что данный объект получает сообщение. Если же стрелка пересекает линию жизни объекта, то это ничего не значит — сообщение пролетело мимо. Если в процессе взаимодействия объект заканчивает свое существование, то линия жизни обрывается и в этом месте ставится жирный косой крест.
Над стрелкой сообщения указывается текстовая часть описания сообщения.
|
|
|
|
|
|
|
|
|
|
|
|
Постоянно |
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
существующий |
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
объект |
|
|
|
|
|
||
Экземпляр |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
«utility» |
|
|
|
|
|
|||
действующего |
|
|
|
|
|
|
|
|
|
|
|
|
|
Company |
|
|
|
|
|
||
лица |
Staff |
|
Manager |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
Первое |
|
|
|
open() |
|
Staff Form |
|
|
|
|
|
|
|
|
|
|
|
Созданный |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
сообщение |
|
|
|
create_deparment () |
|
|
|
|
|
|
|
|
|
|
|
|
|
объект |
|||
|
|
|
|
Сообщение |
|
|
CreateDpt() |
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
Вызов |
|
new() |
|
New Department |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
операции |
|
Создание |
|||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
close() |
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
объекта |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Линия жизни |
Уничтожение |
|
|
|
|
|
|||||||||||||||
|
объекта |
|
|
|
|
|
Продолжим описание нотации диаграмм последовательности.
Если нужно в явном виде указать ограничения по времени, например, указать, что время задержки доставки сообщения должно быть ограничено сверху, то на диаграмму в нужном месте рядом с началом или концом стрелки сообщения помещают произвольные идентификаторы, которые называются метками времени (метка времени — это именованная точка на оси времени), и добавляют ограничение, задающее требуемое условие на значения меток времени.
Допустим, что наша информационная система отдела кадров предназначена для организации, имеющей удаленный филиал. В этом филиале имеется и работает свой экземпляр информационной системы, который должен быть проинформирован, что в головной организации создано новое подразделение. Возможно, эта информация дойдет с некоторой задержкой, поскольку для связи используется медленный канал. Такую ситуацию можно промоделировать следующей диаграммой: