19275

История UML Описание UML. Сущности UML. Отношения UML. Диаграммы UML. Расширения языка UML. Диаграммы классов

Лекция

Информатика, кибернетика и программирование

Лекция 7. История UML Описание UML. Сущности UML. Отношения UML. Диаграммы UML. Расширения языка UML. Диаграммы классов. Диаграммы использования usecase диаграммы прецедентов. Диаграмма последовательности. Диаграмма кооперации. Диаграмма состояний. Диаграмма деятельности. ...

Русский

2013-07-11

290.15 KB

126 чел.

Лекция 7.

История UML Описание UML. Сущности UML. Отношения UML. Диаграммы UML. Расширения языка UML. Диаграммы классов. Диаграммы использования (use-case) (диаграммы прецедентов). Диаграмма последовательности. Диаграмма кооперации. Диаграмма состояний. Диаграмма деятельности. Диаграмма компонентов. Диаграмма развертывания (диаграммы размещения).

7.1. История UML 

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

7.2. Описание UML 

UMLпредставляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками:

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

Унифицированный язык моделирования (UML - Unified Modeling Language) является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем. UML разработан таким образом, чтобы удовлетворять потребности при моделировании любых систем: от информационных систем масштаба предприятия до распределенных Web-приложений и даже встроенных систем реального времени. Это выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования.

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

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

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

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

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

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

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

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

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

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

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

Словарь UML включает три вида основных конструкций (слайд 3):

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

7.3. Сущности UML 

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

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

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

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

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

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

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

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

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

Поведенческие сущности (behavioral things)  - динамические составляющие модели UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве. Существует всего два основных типа поведенческих сущностей:

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

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

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

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

7.4. Отношения UML 

Отношения являются основными связующими конструкциями в UML и применяются для построения корректных моделей (слайд 4). В языке UML определены четыре типа отношений:

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

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

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

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

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

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

Обобщение (generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (проще говоря, потомок) может быть подставлен вместо объекта обобщенного элемента (родителя, предка). Как и положено в объектно-ориентированном программировании, потомок (child) наследует структуру и поведение своего предка (parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на предка.

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

7.5. Диаграммы UML 

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

  •  классов (class);
  •  объектов (object);
  •  прецедентов (вариантов использования) (use-case);
  •  взаимодействия (interaction):
  •  последовательности (sequence);
  •  кооперативных (collaboration);
  •  состояний (statechart);
  •  деятельностей (activity);
  •  компонентов  (component);
  •  развертывания (размещения) (deployment).

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

1. Цель создания диаграмм на языке UMLне рисование красивых картинок, а визуализация, специфицирование, конструирование и документирование. Диаграммыэто только одно из средств, но не все диаграммы необходимо сохранять. Иногда стоит создавать их на лету путем опроса элементов модели использовать для анализа системы по мере ее построения.

2. Следует избегать избыточных диаграмм, они только загромождают модель.

3. Каждая диаграмма должна содержать только необходимые детали.

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

5. Не следует делать диаграммы очень большими или очень маленькими.

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

7.6. Расширения языка UML 

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

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

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

7.7. Диаграммы классов 

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

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

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

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

Видимость свойства класса указывает на возможность его использования другими классами. В языке UML определены 3 уровня видимости:

  •  public (общий) - любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;
  •  protected (защищенный) - только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;
  •  private (закрытый) - только данный класс может пользоваться этими свойствами. Обозначаются символом «-» .

Пример. (слайд 6)

7.8. Диаграммы использования (use-case)

(диаграммы прецедентов)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры. (слайд 7)

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

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

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

Вторым измерением диаграммы последовательности является вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения, а их порядок определяется временем возникновения. Масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже».

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

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

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

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

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

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

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

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

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

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

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

Некоторые стандартные действия, выполняемые в ответ на получение соответствующего сообщения могут быть явно указаны на диаграмме последовательности в форме стереотипа рядом с сообщением, к которому они относятся ("call" (вызвать) "return" (возвратить) "create" (создать) "destroy" (уничтожить) ".

Примеры. (слайд 9)

7.10. Диаграмма кооперации 

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

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

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

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

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

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

Связьлюбое семантическое отношение между некоторой совокупностью объектов. Связь может иметь некоторые стереотипы, которые записываются рядом с одним из ее концов и указывают на особенность реализации данной связи ("association" –ассоциация "parameter" - параметр метода"local" - локальная переменная метода"global" - глобальная переменная "self - рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе).

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

Пример. (слайд 10):

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

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

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

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

Элементы диаграммы состояний (слайд 11).

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

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

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

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

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

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

Переходом (transition) называется перемещение объекта из одного состояния в другое. 

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

Событие (event) вызывает переход из одного состояния в другое. 

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

Ограничивающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться. Ограничивающие условия задавать необязательно. Если условие принимает значение «истина», то соответствующий переход может сработать. Если условие принимает значение «ложь», то переход не может сработать, объект остается в исходном состоянии.

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

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

Пример диаграммы состояний. (слайд 12)

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

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

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

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

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

Элементы диаграммы деятельности. (слайд 13)

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

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

Конечная точка необязательна. На диаграмме может быть несколько конечных точек.

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

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

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

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

Пример. (слайд 14)

Дорожки

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

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

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

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

7.13. Диаграмма компонентов 

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

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

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

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

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

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

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

7.14. Диаграмма развертывания

(диаграммы размещения)

 

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

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

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

Пример 1: (слайд 16)

Пример 2. (слайд 17):


 

А также другие работы, которые могут Вас заинтересовать

37062. Я- гражданин России. Класный час 31.56 KB
  Тема классного часа: Я гражданин России Задачи: Образовательные Знакомство с понятием гражданин. Знакомство с символами России. Воспитывать интерес к России.
37063. Классный час, посвященный 200 - летию Бородинской битвы 26.21 KB
  Наполеон Бонапарт- человек необычной судьбы. Он родился 15 августа 1769 года на небольшом острове Корсика, принадлежащем Франции. Сын бедного дворянина Наполеон закончил военную академию в Париже, когда ему было 16 лет. В 24 года он уже был генералом, затем стал консулом Франции
37064. Вредные привычки. Классный час 23.17 KB
  У1 – слайд №2 “Здоровье это состояние полного физического психического и социального благополучия а не только отсутствие болезней и поврежденийâ€. Основная часть: слайд 3 У2 На слайде мы видим три основных вредных привычки которые портят наше с вами здоровье. слайд №4 Табак приносит вред телу разрушает разум отупляет целые нации. слайд№5 Из истории Курение табака возникло еще в глубокой древности.
37065. Личностно-ориентированный классный час 74.5 KB
  Классный час это гибкая по составу и структуре форма фронтальной воспитательной работы представляющая собой специально организуемое во внеурочное время общение классного руководителя с учащимися класса с целью содействия формированию классного коллектива и развитию его членов Е. Час классного руководителя – это форма воспитательной работы при которой школьники под руководством педагога включаются в специально организованную деятельность способствующую формированию у них системы отношений к окружающему миру Г. Основные компоненты...
37066. ВИКТОРИНА ПО СКАЗКАМ К.И. ЧУКОВСКОГО 23.93 KB
  ЧУКОВСКОГО Тема: ВИКТОРИНА ПО СКАЗКАМ К. ЧУКОВСКОГО Цели: 1. Такова внешность Корнея Ивановича Чуковского. Сегодня мы встретимся с героями сказок Корнея Чуковского.
37067. В дела ты добрые вложи всё лучшее своей души! 55.5 KB
  Сформировать в сознании детей понятие доброта; 2. Говорят что если есть в человеке доброта значит он как человек состоялся. Человеческая доброта и милосердие умение радоваться и переживать за других людей создают основу человеческого счастья. Сейчас возрождаются такие понятия как доброта милосердие доброжелательность внимание друг к другу.
37070. Ценности и ценностные ориентации (Ценности жизни) 28 KB
  Рокича Ценности и ценностные ориентации Дать определение слов счастье успех цель и установить логическую связь между этими словами. Команды должны нарисовать важные по убывающей ценности Пирамиду счастья Дети: Крепкая семья преданные друзья любовь и уважение окружающих любимое дело и цель в жизни и кончено же успех.мы можем установить такую смысловую связь между этими словами: цельуспехсчастье.И только третий будет понастоящему счастливым: он видит большую красивую цель ради которой работает и живет.