Кратность ассоциации

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

Так, для примера, приведенного на рис. 2.25 кратность "1" для класса Компания означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса Сотрудник означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено, но не менее 1.

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

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

Отношение обобщения

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

Класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет собственные свойства и поведение, которые могут отсутствовать у класса-предка.

На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рис. 2.26). Стрелка указывает на более общий класс (класс-предок или суперкласс).

Рис. 2.26. Графическое изображение отношения обобщения в языке UML

От одного класса-предка одновременно могут наследовать несколько классов-потомков. Например, абстрактный класс Транспортное средство (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным транспортным средствам, таким как: Автомобиль, Автобус, Трактор и другим (рис. 2.27 и 2.28).

Рис. 2.27. Пример графического изображения отношения обобщения для нескольких классов-потомков

Рис. 2.28. Альтернативный вариант графического изображения отношения обобщения классов

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

ü {complete} – означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может.

ü {incomplete} – означает, что на диаграмме указаны не все классы-потомки, которые возможно будут добавлены позже.

ü {disjoint} – означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.

ü {overlapping} – означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

Пример использования ограничений приведен на рис. 2.29.

Рис. 2.29. Вариант уточненного графического изображения отношения обобщения классов с использованием строки-ограничения

Фрагмент программного кода на языке Java для отношения обобщения приведен ниже.

MySuperClass.java: public class MySuperClass {...}   MySubClass.java: public class MySubClass extends MySuperClass {...}

Отношение зависимости

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

Отношение зависимости, в отличие от отношения ассоциации, всегда являются направленными.

Зависимость изображается пунктирной линией со стрелкой, направленной от зависимого элемента к независимому элементу (рис. 2.30).

Рис. 2.30. Графическое изображения отношения зависимости

Отношения зависимости могут быть помечены стереотипами, наиболее часто используемые:

ü «use» – класс А использует класс В любым образом. Является значением по умолчанию, если стереотип не указан явно.

ü «call» – операция зависимого класса вызывает операцию независимого.

ü «parameter» – передается параметр или возвращается значение от независимого класса к зависимому

ü «instantiate» – зависимый класс является разновидностью независимого.

ü «friend» – зависимый элемент имеет доступ к ссылкам независимого.

Фрагмент программного кода на языке Java для отношения зависимости приведен ниже.

Person.java: public class Person { public void BuyHouse(House theHouse) {...} }   House.java: public class House {...}

Отношение реализации (realization relationship)

Реализация (realization) – семантическое отношение между классами, в котором один класс (приемник) должен реализовать поведение, определенное в другом (источник).

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

Рис. 2.31. Графическое изображения отношения реализации

Фрагмент программного кода на языке Java для отношения реализации приведен ниже.

MyInterface.java: public interface MyInterface { public void charge(int x); ...}   AbstractClassF.java: public class AbstractClassF implements MyInterface { public void charge(int x) { ...}; }

Отношение агрегации

Агрегация (aggregation) – специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью.

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

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

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой не закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой "целое" или класс-контейнер (рис. 2.32).

Рис. 2.32. Графическое изображение отношения агрегации в языке UML

Пример отношения агрегации приведен на рис. 2.33.

Рис. 2.33. Диаграмма классов для иллюстрации отношения агрегации на примере системного блока ПК

Отношение композиции

Композиция (composition) – разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое.

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

Композит (composite) – класс, который связан отношением композиции с одним или большим числом классов.

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой класс-композит (рис. 2.34).

Рис. 2.34. Графическое изображение отношения композиции в языке UML

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

Рис. 2.35. Диаграмма классов для иллюстрации отношения композиции на примере класса-композита Окно программы

Рекомендации по построению диаграмм классов

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

Необходимо избегать использования избыточных ассоциаций.

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

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

После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях:

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

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

Контрольные вопросы

1. Для представления какой информации предназначена диаграмма классов?

2. Что такое класс? Из каких секций состоит графическое представление класса?

3. Какой класс называется абстрактным?

4. Какая информация может располагаться в секции имени класса?

5. Что такое атрибут класса?

6. Какой формат имеет запись атрибута класса?

7. Какие уровни видимости определены в UML? Дайте определение каждому из них.

8. Что такое кратность?

9. Что такое операция класса?

10. Какой формат имеет запись операции класса?

11. Что такое интерфейс?

12. Какие отношения могут быть использованы на диаграммах классов? Приведите примеры отношений между классами.

2.5. Диаграмма кооперации (сотрудничества) (Collaboration Diagram)

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

Кооперация

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

Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.

На диаграмме кооперации размещаются:

ü объекты, представляющие собой экземпляры классов,

ü связи между объектами, которые являются экземплярами ассоциаций,

ü сообщения.

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

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

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

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

Объекты и их графическое изображение

Объект (object) – сущность с хорошо определенными границами и индивидуальностью, которая инкапсулирует состояние и поведение.

ü является экземпляром класса, описанного в модели и представленного на диаграмме классов.

ü создается на этапе реализации модели или выполнения программы.

ü имеет имя и конкретные значения атрибутов.

Для диаграмм кооперации полное имя объекта имеет формат:

<имя объекта> / <Имя роли класса>: <Имя класса>

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

Имя класса – это имя одного из классов, представленного на диаграмме классов. Перед именем класса всегда должен ставиться символ двоеточия “: ”.

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

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

Имя объекта, имя роли с символом "/" или имя класса могут отсутствовать.

Примеры изображения объектов на диаграммах кооперации приводятся на рис. 2.36.

Рис. 2.36. Примеры графических изображений объектов

Анонимный объект – если собственное имя объекта отсутствует. (рис. 2.36, в).

Объект-сирота – если отсутствует имя класса (рис. 2.36, г).

Если для объектов указываются атрибуты, то в большинстве случаев они принимают конкретные значения (рис. 2.36, б).

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

Примеры возможных записей имени объекта:

ü о:C – объект с собственным именем о, экземпляр класса С.

ü:C – анонимный объект, экземпляр класса С.

ü о: (или просто о) – объект-сирота с собственным именем о.

ü о/R:C – объект с именем о, экземпляр класса С, играющий роль R.

ü /R:C – анонимный объект, экземпляр класса С, играющий роль R.

ü о/R – объект-сирота с собственным именем о, играющий роль R.

ü /R – анонимный объект и одновременно объект-сирота, играющий роль R.

В контексте языка UML все объекты делятся на два вида:

ü Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они обрабатывают. На диаграмме кооперации пассивные объекты изображаются обычным прямоугольником.

ü Активный объект (active object) имеет собственный процесс управления и может инициировать деятельность по управлению другими объектами. На диаграмме кооперации обозначаются прямоугольником с утолщенными границами.

В примере на рис. 2.37 активный объект а:Клиент является инициатором открытия счета, который представлен анонимным пассивным объектом:Счет.

Рис. 2.37. Графическое изображение активного объекта (слева) и пассивного (справа) на диаграмме кооперации

Мультиобъект (multiobject) – множество анонимных объектов, которые могут быть образованы на основе одного класса.

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

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

На диаграмме кооперации может быть явно указано отношение агрегации или композиции между мультиобъектом и отдельным объектом из его множества (рис. 2.38, б).

Рис. 2.38. Графическое изображение мультиобъектов на диаграмме кооперации

В следующем примере рассматривается ситуация с отправкой почтового сообщений клиенту из редактора электронной почты (рис. 2.39).

Анонимный активный объект класса РедакторEmail вначале посылает сообщение анонимному мультиобъекту класса Клиент. Это сообщение инициирует выбор единственного объекта класса Клиент, удовлетворяющего дополнительным условиям. После этого выбранному объекту посылается сообщение о необходимости отправить электронное письмо.

Рис. 2.39. Фрагмент диаграммы кооперации для выбора адреса клиента для отправки электронного письма

Составной объект (composite object) или объект-композит предназначен для представления объекта, имеющего собственную структуру и внутренние потоки управления.

Составной объект является экземпляром класса-композита, который связан отношением композиции со своими частями. Аналогичные отношения связывают между собой и соответствующие объекты.

На диаграммах кооперации составной объект изображается как обычный объект, состоящий из двух секций: верхней (содержит имя составного объекта) и нижней (содержит объекты-части) (рис. 2.40). В качестве частей могут быть другие составные объекты.

Связи на диаграмме кооперации

Связь (link) – любое семантическое отношение между некоторой

совокупностью объектов.

На рис. 2.41 представлена обобщенная схема компании с именем с, которая состоит из департаментов (анонимный мультиобъект класса Департамент). В последние входят сотрудники (анонимный мультиобъект класса Сотрудник). Рефлексивная связь указывает на то, что руководитель департамента является одновременно и его сотрудником.

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

Сообщения и их графическое изображение

Сообщение (message) – спецификация передачи информации от одного элемента модели к другому с ожиданием выполнения определенных действий со стороны принимающего элемента.

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

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

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

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

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

Для обозначения сообщений на диаграммах кооперации может использоваться один из трех типов стрелок (рис. 2.42):

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

ü Сплошная линия с V-образной стрелкой (рис. 2.42, б) обозначает асинхронное сообщение в простом потоке управления. В этом случае клиент передает асинхронное сообщение и продолжает выполнять свою деятельность, не ожидая ответа от клиента.

ü Пунктирная линия с V-образной стрелкой (рис. 2.42, в) обозначает возврат из вызова процедуры. Стрелки этого типа зачастую отсутствуют на диаграммах кооперации, так как неявно предполагается их существование после окончания процесса выполнения операции или деятельности.

Рис. 2.42. Изображение различных типов сообщений на диаграмме кооперации

Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат:

<Предшествующие сообщения> / <Выражение последовательности>

<Возвращаемое значение> := <имя сообщения> ( <Список аргументов> )

Предшествующие сообщения – это разделенные запятыми номера сообщений, записанные перед наклонной чертой.

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

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

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

Выражение последовательности – это разделенный точками список отдельных термов последовательностей, после которого записывается двоеточие: <Термы последовательностей> :.

Каждый из термов представляет отдельный уровень процедурной вложенности. Наиболее верхний уровень соответствует самому левому терму последовательности. Если все потоки управления параллельные, то вложенность отсутствует.

Терм последовательности имеет синтаксис:

[Номер сообщения | Имя] [Рекуррентность]

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

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

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

o *[ <Предложение-итерация> ] – для записи итеративного выполнения соответствующего выражения. Например, если необходимо сообщение message под номером 5 повторить 3 раза, то можно записать: 5*[i:=1..3]:message(i).

o [ <Предложение-условие> ] – для записи ветвления. Например, если необходимо сообщение answer под номером 2 передавать с разными аргументами в зависимости от условия, то можно записать: 2[k=’Y']:answer(“Yes”) и 2[k<>’Y']:answer(“No”).

Итерация не распространяется на вложенные уровни данного потока. Каждый уровень должен иметь собственное представление для итеративного повторения процедурной последовательности.

Имя сообщения – записанное в сигнатуре после возвращаемого значения, означает имя события, которое инициируется объектом-получателем сообщения после его приема, например вызов операции у объекта-получателя. Можно явно указать в качестве имени сообщения имя вызываемой операции.

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

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

В языке UML определены следующие стереотипы сообщений:

ü <<call>> – сообщение, требующее вызова операции или процедуры объекта-получателя. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у пославшего это сообщение объекта.

ü <<return>> – сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления.

ü <<create>> – сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может стать активным (ему передается поток управления), а может остаться пассивным.

ü <<destroy>> – сообщение, требующее уничтожения соответствующего объекта. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы.

ü <<send>> – обозначает посылку другому объекту сигнала, который асинхронно инициируется одним объектом и принимается (перехватывается) другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.

Рекомендации по построению диаграмм кооперации

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

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

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

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

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

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

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

Контрольные вопросы

1. Для чего используются диаграммы кооперации?

2. Какие элементы размещаются на диаграммах кооперации?

3. Что такое мультиобъект и для чего он используется?

4. Для чего используется составной объект?

5. Что из себя представляет связь на диаграмме кооперации?

6. Что такое сообщение?

7. Какие типы сообщений могут быть на диаграмме кооперации?

8. Какая дополнительная информация может быть указана для сообщения?

2.6. Диаграмма последовательности (Sequence Diagram)

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

На диаграмме последовательности неявно присутствует ось времени, что позволяет визуализировать временные отношения между передаваемыми сообщениями.

Объекты и их изображение на диаграмме последовательности

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

Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени.

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

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

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

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

Начальному моменту времени соответствует самая верхняя часть диаграммы.

Процесс взаимодействия объектов реализуется посредством сообщений, которые посылаются одними объектами другим.

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

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

Линия жизни объекта (object lifeline) – вертикальная линия на диаграмме последовательности, которая представляет существование объекта в течение определенного периода времени.

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

ü служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей рабочей области диаграммы последовательности от самой верхней ее части до самой нижней (объект 1 и анонимный объект Класса 2 на рис. 2.43).

Для обозначения момента уничтожения объекта в языке UML применяется специальный символ в форме латинской буквы "X". На рис. 2.44 этот символ используется для уничтожения анонимного объекта, образованного от Класса 3.

Рис. 2.44. Изображение линий жизни и фокусов управления объектов

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

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

Фокус управления (focus of control) – специальный символ на диаграмме последовательности, указывающий период времени, в течение которого объект выполняет некоторое действие, находясь в активном состоянии.

ü изображается в форме вытянутого узкого прямоугольника (объект а на рис. 2.44), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

ü располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект a на рис. 2.44), если на всем ее протяжении он активен.

Периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта фокусы управления изменяют свое изображение на линию жизни и наоборот (объект сирота ob2 на рис. 2.44).

Если инициатором взаимодействия в системе является актер, то он изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления (рис. 2.45). Актер может иметь собственное имя либо оставаться анонимным.

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

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

Рис. 2.45. Графическое изображение актера, рефлексивного сообщения и рекурсии на диаграмме последовательности

Сообщения на диаграмме последовательности

На диаграммах последовательности могут присутствовать три разновидности сообщений (рис. 2.46).

Рис. 2.46. Графическое изображение различных видов сообщений между объектами на диаграмме последовательности

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

Вторая разновидность сообщения (рис. 2.46, б) используется для обозначения простого асинхронного сообщения, которое передается в произвольный момент времени. Передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем.

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

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

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

Ветвление потока управления

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

Количество ветвей может быть произвольным.

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

Рис. 2.47. Графическое изображение бинарного ветвления потока управления

Если условий более двух, то для каждого из них необходимо предусмотреть ситуацию единственного выполнения. На рис. 2.48 приведен пример моделирования взаимодействия программной системы обслуживания клиентов в банке. В этом примере диаграммы последовательности объект ob1 вызывает выполнение действий у одного из трех других объектов.

Условием ветвления может служить сумма снимаемых клиентом средств со своего текущего счета. Если эта сумма превышает 1500$, то могут потребоваться дополнительные действия, связанные с созданием и последующим разрушением объекта Класса 1. Если же сумма превышает 100$, но не превышает 1500$, то вызывается операция или процедура объекта ob3. И, наконец, если сумма не превышает 100$, то вызывается операция или процедура объекта ob2. При этом объекты ob1, ob2 и ob3 постоянно существуют в системе. Последний объект создается от Класса 1 только в том случае, если справедливо первое из альтернативных условий. В противном случае он может быть никогда не создан.

Объект ob1 имеет постоянный фокус управления, а все остальные объекты – получают фокус управления только для выполнения ими соответствующих операций.

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

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

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

Рекомендации по построению диаграмм последовательности

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

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

Объекты наносятся на диаграмму, с соблюдением порядка инициализации сообщений. Необходимо установить, какие объекты будут существовать постоянно, а какие временно – только на период выполнения ими требуемых действий.

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

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

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

Общим правилом является визуализация особенностей реализации каждого варианта использования на отдельной диаграмме последовательности. В этой ситуации отдельные диаграммы должны рассматриваться совместно как одна модель взаимодействия.

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

Рекомендуется использовать диаграмму последовательностей, если необходимо подчеркнуть временную упорядоченность сообщений, а диаграмму кооперации – если необходимо подчеркнуть структурную организацию участвующих во взаимодействии объектов;

Контрольные вопросы

1. Какую информацию отображает диаграмма последовательности?

2. Что такое линия жизни объекта?

3. Что такое фокус управления? Как он отображается на диаграмме?

4. Какое сообщение называется рефлексивным?

5. Какие разновидности сообщений могут быть на диаграмме последовательности?

6. Как отображается на диаграмме последовательностей ветвление потока управления?

2.7. Диаграмма состояний (Statechart Diagram)

Диаграмма состояний (statechart diagram) – диаграмма, которая представляет конечный автомат, моделирующий процессы функционирования.

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

Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.

Диаграмма состояний показывает:

ü набор состояний системы;

ü события, вызывающие переход из одного состояния в другое;

ü действия, происходящие в результате изменения состояния.

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

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

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

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

В контексте языка UML вершинами графа конечного автомата являются состояния и другие типы элементов модели. Дуги графа служат для обозначения переходов из состояния в состояние.

Предполагается, что переход объекта из состояния в состояние происходит мгновенно.

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

Состояние

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

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

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

Графическое изображение состояния приведено на рис. 2.49, а.

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

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

Рис. 2.49. Графическое изображение состояний на диаграмме состояний

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

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

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

Каждое действие записывается в виде отдельной строки и имеет следующий формат:

<метка действия> / <выражение действия>

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

Набор меток действий в языке UML фиксирован, причем эти метки не могут быть использованы в качестве имен событий:

ü entry – входное действие (entry action) – действие, которое выполняется в момент перехода в данное состояние;

ü exit – действие выхода (exit action) – действие, производимое при выходе из данного состояния;

ü do – внутренняя деятельность (do activity) – выполнение объектом операций или процедур, которые требуют определенного времени. Специфицирует так называемую "ду-деятельность", выполняемую в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не будет прервано внешним событием.

Рассмотрим в качестве примера состояния аутентификацию клиента для доступа к ресурсам моделируемой информационной системы (рис. 2.50).

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

Псевдосостояние (pseudo-state) – вершина в конечном автомате, которая имеет форму состояния, но не обладает поведением.

Примеры псевдосостояний, определенные в UML:

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

В этом состоянии находится объект по умолчанию в начальный момент времени.

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

Каждая диаграмма или под-диаграмма состояний должна иметь единственное начальное состояние.

ü Конечное состояние (final state) – псевдосостояние, обозначающее прекращение процесса изменения состояний конечного автомата или нахождения моделируемого объекта в составном состоянии.

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

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

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

Рис. 2.51. Изображение начального и конечного состояний

Переход и событие

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

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

ü окончание выполнения деятельности (do activity);

ü получение объектом сообщения;

ü прием сигнала.

На переходе указывается:

ü имя события;

ü действия, производимые объектом в ответ на внешние события при переходе из одного состояния в другое.

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

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

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

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

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

Каждый переход может быть помечен строкой текста, имеющей формат:

<имя события> ( <список параметров,разделенных запятыми> )

[ <сторожевое условие> ]/ <выражение действия>

Событие (event) – спецификация существенных явлений в поведении системы, которые имеют местоположение во времени и пространстве.

Отдельные события должны быть упорядочены во времени.

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

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

В зависимости от вида происходящих событий в UML различают два типа переходов:

ü триггерный – переход специфицируется событием-триггером, связанным с внешними условиями по отношению к рассматриваемому состоянию.

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

ü нетриггерный – переход происходит по завершении выполнения ду-деятельности в данном состоянии.

Рядом со стрелкой перехода не указывается никакого имени события, а в исходном состоянии должна быть описана внутренняя ду-деятельность, по окончании которой произойдет тот или иной нетриггерный переход (рис. 2.52, б).

Рис. 2.52. Триггерный (а) и нетриггерный (б) переход на диаграмме состояний

Сторожевое условие (guard condition) – логическое условие, записанное в прямых скобках и представляющее собой булевское выражение, принимающее одно их двух взаимно исключающих значений: "истина" или "ложь".

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

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

Если из состояния существует несколько выходящих переходов с идентичным событием-триггером, то каждый такой переход должен содержать собственное сторожевое условие, при этом никакие два или более сторожевых условий не должны одновременно принимать значение "истина". Аналогично в случае нескольких нетригерных переходов.

Рис. 2.53. Триггерные и нетриггерные переходы на диаграмме состояний

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

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

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

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

Выражение действия записывается после символа " / " в строке текста, присоединенной к соответствующему переходу.

Выражение действия может содержать список отдельных действий, разделенных символом ";". При этом все действия из списка должны четко различаться между собой и следовать в порядке их записи.

На синтаксис записи выражений действия не накладывается никаких ограничений.

На рис. 2.54 приведен пример действия перехода – отображение сообщения на экране банкомата в том случае, когда запрашиваемая клиентом сумма превосходит остаток на его счету. В случае если кредит не превышен, то происходит переход в состояние получения наличных.

Рис. 2.54. Выражение действия перехода на диаграмме состояний

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

Моделирование параллельного поведения с помощью диаграмм состояний

Составное состояние и подсостояние

Составное состояние (состояние-композит) (composite state) – сложное состояние, имеющее другие вложенные в него состояния.

Вложенные состояния выступают по отношению к составному состоянию как подсостояния (substate). Графически все вершины диаграммы, соответствующие вложенным состояниям, изображаются внутри символа составного состояния (рис. 2.55).

Составное состояние может содержать или несколько последовательных подсостояний, или несколько параллельных конечных подавтоматов.

Каждое состояние-композит может уточняться только одним из указанных способов.

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

Количество уровней вложенности составных состояний в UML не фиксировано.

Последовательные подсостояния (sequential substates) – вложенные состояния состояния-композита, в рамках которого в каждый момент времени объект может находиться в одном и только одном подсостоянии.

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

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

Рис. 2.56. Составное состояние с вложенными последовательными подсостояниями

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

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

Если составное состояние содержит внутри себя конечное состояние, то переход в это вложенное конечное состояние означает завершение нахождения объекта в данном составном состоянии.

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

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

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

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

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

Рис. 2.57. Состояние-композит с вложенными параллельными подсостояниями

Несовместимое подсостояние (disjoint substate) – подсостояние, в котором подсистема не может находиться одновременно с другими подсостояниями одного и того же составного состояния. Например, недопустимо нахождение объекта одновременно в подсостояниях (А, Б, В) или (В, Г, Д).

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

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

Рис. 2.58. Составное состояние со скрытой внутренней структурой и специальной пиктограммой

Исторические состояния

Историческое состояние (history state) – псевдосостояние, используемое для запоминания того из последовательных подсостояний, которое было текущим в момент выхода из составного состояния.

Историческое состояние применяется только в контексте составного состояния.

Существует две разновидности исторического состояния: неглубокое или недавнее и глубокое или давнее (рис. 2.59).

Рис. 2.59. Изображение недавнего (а) и давнего (б) исторического состояния

Поиск по сайту: